上文说到的raft内容发布，那其实是对于某一个key来说的，而且还不保证发布的成功。那要如何保证数据的最终一致呢。
其实是通过心跳来保证的
leader发送心跳的时候会带上所有的key和key对应的时间戳，follower发现key不存在或者时间戳比较小，就发送请求给leader拿这些key的数据，最终达到数据一致。
发送心跳带上所有的key
image.png
这些数据会有点大，所以做了gzip压缩
image.png
follower收到心跳的时候，判断key的存在和时间戳，和leader对不上的，发起请求拿最新的
image.png
不一致的key可能比较多，所以批量去拿，每次拿50个key。
数据差距可能比较大，一直循环拿的话对leader的压力会比较大，所以拿一次之后slepp 200ms。
HttpClient异步去获取这些内容，异步回来可能是不同的线程，会有多线程的问题，所以要加锁。
当然这里HttpClient是同步请求，也会是要加锁的，因为受到心跳请求是不同的线程，如果心跳处理比较慢，也变成多线程处理了。
image.png
数据更新后会发消息，通知有变更
notifier.addTask(datum, Notifier.ApplyAction.CHANGE);
上面的流程只是处理了key的新增和更新，那key的删除怎么同步呢？
本地的所有的key放到一个map，处理过的key标记一下，如果到最后还有key没标记，说明是本地有，但是leader没有。这种key就是leader已经删除的key了。
image.png
问题1 心跳发送所有的key及其时间戳，如果有几十万个key呢，而且是500ms一次的心跳，压力真的很大啊。
不知道阿里的人哪里来的信心用这种方案，如果我提出这种方案，估计早就被老板砍死了。
问题二 用时间戳来作为判断一个key的内容是否一致真的问题很大啊。时间戳只能精确到1ms，1ms发布多次的话就判断不了了。
而且时间同步之后，时间甚至可能回退，通过时间戳大小的判断短时间内就会失效，难道是要所有的机器禁止时间同步吗。
就算是禁止了时间同步，机器之间的时间差是客观存在的，假如leader的变化在很快的时间内完成，新leader可能会落后旧leader一段时间的，这时间差也是可能出问题的啊。
网友评论