如何实现线性一致性？

可能大多数人都有个误解，一个分布式系统，比如ZK、etcd等，如果正确的实现了共识算法(Raft/Paxos)，那么它就能够提供强一致，这个理解其实是不正确的，Raft只能够保证不同节点对于raft日志达成一致，但对于库的使用者来说，实际上对外提供服务的是底层的状态机，比如说一个KV存储，每个raft日志记录的是实际的操作，比如set a 1 set a 2等，而如果只有日志的话，我们怎么查询呢？轮训一遍日志？显然不现实，因此必须将这个状态存起来，比如RocksDB，那么底层raft日志的一致性由raft本身去保证，而上层业务方状态机的一致性该如何去保证呢？

Raft是由leader驱动的共识算法，所有的写入请求都由leader来处理，并将日志同步到follower，然后再将日志依次应用的自身的状态机，比如RocksDB，但由于网络延迟、机器负载等原因，每个节点不可能同时将日志应用到RocksDB，因此对于不同的节点来说，RocksDB的数据快照肯定不是实时一致的，并且这里会涉及到很多的corner case，比如leader切换，也就是说leader的数据也不一定是最新的，因此实际实现的时候需要考虑好这些case。 这里暂不考虑异常情况，对于raft来说，写请求都是由leader处理并同步到follower，因此leader的数据通常是最新的，但如果用户发来一个读取请求，我们直接从状态机读取的话，这里其实是会读到过期数据的，因此这里分为两步，已提交的日志 -> 已经应用到状态机的日志，因此如果不做特殊处理的话，由于还有部分日志没有应用到状态机，直接处理的话必然会造成不一致。优化的方法大致有几种:

• 读取也走raft log
• Read Index
• Lease Read

#读取也走raft log 我们很容易想到，让读取的请求也走一遍raft流程，由于raft日志是全局严格有序的，读写也必然是有序的，因此当处理到读取的日志的时候，能够保证之前的写入请求都已经处理完成并落到状态机，因此这个时候处理读取请求是安全的，不会造成过期读的问题，也能够满足我们说的线性一致性，但这个方法有个很明显的缺点: 性能非常低，每次读取都走一遍raft流程，涉及到网络、磁盘IO等资源，而对于大部分场景来说，都是写少读多，因此如果不对读取进行优化的话，整个类库的性能会非常低效。