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源创计划”,欢迎正在阅读的你也加入,一起分享。