截止到2020/10,根据官网的资料整理的pingcap对raft算法的优化
1.multi raft,不同于大部分的单raft,tidb采用每个数据分片都分隔开的multi raft,采用自己的分片分裂算法可以保证每个raft group的节点数量不大,这样能保证大数据情况下raft的性能,又能支持节点的横向扩展
2.lease read读优化,平常的读操作需要走一遍raft流程,效率很低效,优化一点的readindex算法可以提高效率,并且安全性可以得到保障;更优化一点的lease read更将readindex算法中的确认当前时间leader是raft组的leader的步骤优化掉,又节省了一次网络时间,不过需要依赖于cpu时钟的安全性,不同服务器的时钟频率不同,可能会出问题。tidb两种方式都有提供,不过由于本身代码的限制,lease read实现方式和论文中略有不同,不是靠心跳来确认,而是靠写操作来确认。
3.Batch and Pipeline优化,tidb认为raft理论按照论文来写,性能完全不行,所以需要增加优化。一个是批优化,也就是每次不是发单个,而是缓存一批一起。Pipeline优化是说,因为网络通常情况下是稳定的,所以可以不用等反馈直接发下一个next位置的日志,如果出错了就调一下next日志,然后重新发
4.Append Log Parallelly优化,简单来说就是leader节点落盘日志和给follower节点发送日志同时进行,因为根据论文来说,leader需要大多数follower落盘日志后才能落盘日志。一,如果大多数follower落盘了日志,leader自然需要落盘日志,可以提前落盘;二,如果大多数follower没有落盘日志,leader已经落盘日志,可以重新发送让大多follower落盘,如果不行,则说明当前集群没有大多数follower节点正常运行,集群崩溃;三,如果大多数follower落盘了日志,但是leader落盘失败,则说明leader节点crash了,重新选举,也不会造成影响
5.Asynchronous Apply优化,就是日志的commit线程和apply线程并发执行。因为当一个 log 被大部分节点 append 之后,我们就可以认为这个 log 被 committed 了,被 committed 的 log 在什么时候被 apply 都不会再影响数据的一致性。所以当一个 log 被 committed 之后,可以用另一个线程去异步的 apply 这个 log。这样处理,集群的吞吐和并发量就会上去了。
6.Asynchronous Lease Read优化,就是读写分离,在另一个线程异步实现 Lease Read,保证 Raft 的 write 流程不会影响到 read。
7.Follower Read优化,直接管leader要commitindex,等follower运行到这个index,就返回,,虽然还是要过一次网络,但是可以减轻leader的负担