consensus协议，有paxos、raft、pacificA，应用最普遍的有paxos。由于paxos难以理解、实现困难，例如日志空洞（leader宕机时，当前leader在上一任leader的任期内可能错过了一些日志的同步, 而这些日志在其他机器上形成多了多数派. 由于logID连续递增, 被错过的日志就成了连续logID连续递增序列中的”空洞”, 需要通过重确认来补全这些”空洞”位置的日志。）的处理等非常复杂，诞生了raft，逐渐替代paxos普遍应用到分布式系统中，例如mongodb、kafka等。 raft 一致性协议，一般是基于replicated state machine，基于这个理论：所有节点处理相同顺序相同内容的指令，结果就会一致。一般是以log的方式实现，将client请求append到log中，并同步给各节点，对raft而言做了简化，只有leader才执行读写，日志只会从leader流向follower，follower只参与选主，平时只做replicate。 consensus解决的实际上是3个问题：选主、log复制、safety(never returning an incorrect result) under all non-Byzantine conditions, including network delays, partitions, and packet loss, duplication, and reordering.)。 client请求只要大多数执行成功即返回成功。只要the majority of servers are operational and can communicate with each other and with clients，这个分布式系统就是稳定的。 Raft只有两类rpc，选举与append log，并约定一定的规则。见如下两图：注意约定的规则，在图中也有说明。 以下是选主rpc 以下是append log rpc 以下是各节点选主状态转换图 初始时，大家都是follower。leader通过定期heartbeat告诉follower自己是主。如果heartbeat间隔大于elect timeout，follower认为没有leader，就会发起选主。 任期term随时间递增，发起elect，会生成新的term，发给rpc给其他所有server，变成candidate. 万一同时有多个candidate多个term怎么办？重试 + […]
近期java之父一直在让大家逐步放弃java 8，转到其他LTS版本上，例如java11或java17，是有道理的。关于java各版本的维护停止时间，详见文末。 通过对线上服务的ab测试，发现java11的zgc在接口响应时间上，优于g1。tp99及平均响应时间都达到30%的提升。 zgc是银弹，适配所有服务吗？ 当然不是，zgc适用于低延迟场景，对吞吐量优先的场景，ZGC可能并不适合。zgc属于当代垃圾收集，每次处理的对象更多，更耗cpu。通过在代码中加入读屏障，需要耗费额外的计算资源。所以对hadoop、kafka等数据服务，不推荐使用zgc。 更多关于zgc的实现细节，请参考： https://tech.meituan.com/2020/08/06/new-zgc-practice-in-meituan.html https://wiki.openjdk.java.net/display/zgc/Main java各版本停止维护时间： https://endoflife.date/java
