FastDFS tracker server不保存文件索引，只保存集群拓扑信息。按照原始设计，FastDFS 多台tracker server是完全对等的，不存在主从关系。FastDFS v3.0开始支持文件合并存储，而trunk空间管理由一个group的一台storage server兼任，我们把这一角色称作trunk server。trunk server由tracker server来指定，如果多台tracker server都可以指定trunk server，那么很可能出现混乱和冲突。于是v3.0开始支持tracker leader 和 follower机制，集群相关的重大事项均由leader决定，比如trunk server由tracker leader来分配。
tracker server对节点数没有要求，并且考虑到业界流行的leader选举算法Raft算法比较复杂，因此采用了基于规则的简单算法，尽可能选出最靠谱的leader，我们可以将其理解为论资排辈算法。tracker leader的选举包含预选和确认两个动作，其中”确认“是由预选出来的leader将其身份通知给各个tracker server。下面介绍一下预选规则和步骤：
1. 如果一台tracker server已经是leader了，那么保留它的资格，否则到下一步；
2. 选择运行时间最长的tracker server，如果均相同到下一步；
3. 选择重启时间间隔最短的tracker server，如果均相同到下一步；
4. 选择IP地址最大的tracker server，如果均相同到下一步；
5. 选择端口最大的tracker server。
注：运行时间和重启时间间隔，按300秒取整加以钝化，以消除批量重启多个fdfs_trackerd实例的微小时间差异，使得钝化后的时间一致。
tracker leader选举出来后，follower定期（目前是每秒）通过ping检测leader是否存活。如果连续三次ping leader失败，则重新选举leader。
简单起见，以两台tracker server为例说明分布式系统著名的脑裂现象。如果两台tracker server之间因某种原因（比如路由器或交换机故障）导致不能相互通信，这时候就会发生两台tracker server均认为自己是leader的情况，产生脑裂。如果两台tracker server之间的网络通道不能恢复畅通，那么脑裂现象将会一直持续。
FastDFS对可能存在的tracker leader脑裂问题又是如何解决的呢？解决方法其实很简单，引入storage server作为观察者和协调者即可。storage server向所有tracker server定期报告其状态（包括磁盘可用空间、文件操作统计信息等等），tracker leader在返回的response中会告诉storage server其身份，然后storage server就知道tracker leader是否出现多个的异常了。如果出现了多个leader，storage server将通知这些tracker server重新选举leader。
感谢大家的耐心阅读。最后再啰嗦一句，FastDFS奉行简单就好的原则，衷心希望FastDFS的简洁设计风格能够给聪明的你带来一点启迪和帮助。
本文分享自微信公众号 - FastDFS分享与交流（fastdfs100）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。