总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://www.jianshu.com/p/b30245d1713e 「黄云斌」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

上文说到的raft内容发布，那其实是对于某一个key来说的，而且还不保证发布的成功。那要如何保证数据的最终一致呢。

其实是通过心跳来保证的

leader发送心跳的时候会带上所有的key和key对应的时间戳，follower发现key不存在或者时间戳比较小，就发送请求给leader拿这些key的数据，最终达到数据一致。

发送心跳带上所有的key

这些数据会有点大，所以做了gzip压缩

follower收到心跳的时候，判断key的存在和时间戳，和leader对不上的，发起请求拿最新的

不一致的key可能比较多，所以批量去拿，每次拿50个key。

数据差距可能比较大，一直循环拿的话对leader的压力会比较大，所以拿一次之后slepp 200ms。

HttpClient异步去获取这些内容，异步回来可能是不同的线程，会有多线程的问题，所以要加锁。

当然这里HttpClient是同步请求，也会是要加锁的，因为受到心跳请求是不同的线程，如果心跳处理比较慢，也变成多线程处理了。

数据更新后会发消息，通知有变更

notifier.addTask(datum, Notifier.ApplyAction.CHANGE);

上面的流程只是处理了key的新增和更新，那key的删除怎么同步呢？

本地的所有的key放到一个map，处理过的key标记一下，如果到最后还有key没标记，说明是本地有，但是leader没有。这种key就是leader已经删除的key了。

问题1 心跳发送所有的key及其时间戳，如果有几十万个key呢，而且是500ms一次的心跳，压力真的很大啊。

不知道阿里的人哪里来的信心用这种方案，如果我提出这种方案，估计早就被老板砍死了。

问题二 用时间戳来作为判断一个key的内容是否一致真的问题很大啊。时间戳只能精确到1ms，1ms发布多次的话就判断不了了。

而且时间同步之后，时间甚至可能回退，通过时间戳大小的判断短时间内就会失效，难道是要所有的机器禁止时间同步吗。

就算是禁止了时间同步，机器之间的时间差是客观存在的，假如leader的变化在很快的时间内完成，新leader可能会落后旧leader一段时间的，这时间差也是可能出问题的啊。

文章目录
  1. 1. 其实是通过心跳来保证的
    1. 1.0.0.1. leader发送心跳的时候会带上所有的key和key对应的时间戳，follower发现key不存在或者时间戳比较小，就发送请求给leader拿这些key的数据，最终达到数据一致。
      1. 1.0.0.1.1. 这些数据会有点大，所以做了gzip压缩
      2. 1.0.0.1.2. follower收到心跳的时候，判断key的存在和时间戳，和leader对不上的，发起请求拿最新的
      3. 1.0.0.1.3. 不一致的key可能比较多，所以批量去拿，每次拿50个key。
      4. 1.0.0.1.4. HttpClient异步去获取这些内容，异步回来可能是不同的线程，会有多线程的问题，所以要加锁。
      5. 1.0.0.1.5. 数据更新后会发消息，通知有变更
    2. 1.0.0.2. 上面的流程只是处理了key的新增和更新，那key的删除怎么同步呢？
    3. 1.0.0.3. 问题1 心跳发送所有的key及其时间戳，如果有几十万个key呢，而且是500ms一次的心跳，压力真的很大啊。
    4. 1.0.0.4. 问题二 用时间戳来作为判断一个key的内容是否一致真的问题很大啊。时间戳只能精确到1ms，1ms发布多次的话就判断不了了。