余大及各位高手。
首先我不懂C开发，只能从OPS使用者的角度来咨询方案的思路和用途，请大家多多包含。
我的问题是从astdfs_for_nginx模块是否设置url_have_group_name为true开始的。
一旦设置url have group name 为false，那就代表这个nginx服务器要执行读操作时，会从mod_fastdfs.conf中取出tracker server的IP、默认的group name和默认的磁盘存储路径（store_path0）。
其中默认的groupID加上用户提供的remote_filename就是完整的fileID。
一旦设置url have group name 为true，那就代表这个nginx服务器要执行读操作时，会从mod_fastdfs.conf中取出tracker server的IP、用户直接提供完整的、带groupID的fileID。
请问我的理解是不是对的？
现在假设我的理解是对的，则我有个问题：
1，设置url have group name 为false 时，为什么要设置store_path0这类磁盘存储路径，是否有实际意义？我注释掉了该选项以后，文件是404错误。
2，一旦设置url have group name 为true ，然后在模块配置文件里配置该节点支持多个group，我仔细看配置文件，这个时候仍然要设置每个group的store_path0。
请如果用客户端fdfs_upload_file 上传下载文件，只要找准tracker，提交完整fileID就可以了，为什么用扩展模块就必须设置这个值？我朦胧的感觉跟URL中“M00”这一部分定义是访问哪块磁盘的选项有关。
更深入点对使用模式的理解，最终会出现两套nginx方案，请问我对两套方案的分析对不对，
1，设置url have group name 为false ，然后每个storage服务器上配置一个nginx，所有nginx只处理本group甚至本机的业务。
这样做的好处，给我的感觉就是节省了nginx模块到storage节点的网络IO了，他俩交互数据不用走局域网了；但从其他方面来说都不如另一套方案。
还有一个技术难点我无法理解，客户访问我方的URL可能是第一次生成后就写死到静态页面或数据库记录中的；url中有IP/主机名的部分，他们怎么知道一个group中有多少节点，哪个节点是可用的？
如果解决不了这个技术难点，所有客户的访问请求都会被固定到一台storage 上，这不符合分布式文件系统设计的初衷，任何一个storage宕机都会影响客户读写数据。
2，一旦设置url have group name 为true，只在特定的一组机器上，专门跑nginx，每个nginx都要处理到所有group的请求。
这样做的坏处就是网络IO占用比较多，nginx模块到storage节点要走内网交换机；在一个大规模的分布式存储网络里，网络IO可能是比磁盘IO更稀缺的资源。
但这种方案的优点是易于部署，客户端可以写同一个IP/host，且这几台nginx服务器还可以加上缓存功能。
如果让我按个人喜好选，我肯定选nginx相对集中的方案，因为在我看来他的优点远大于缺点。但我在论坛上看有朋友说鱼大就是配置的每个storage上都有nginx server，且url have group name默认值是false。
我想请教一下鱼大，你设计这两种模式的时候，是怎么个思路，想把他们分别用到什么场景？各位已经在用fastdfs的朋友，你们自己用的什么模式？作者: ruying 时间: 2014-04-02 13:32 本帖最后由 ruying 于 2014-04-02 13:36 编辑
