fix readme in dubbo consul sample

ipipman · ipipman · commit b65ee61d879b · 2020-12-25T17:30:39.000+08:00
diff --git a/dubbo-consul-sample/README.md b/dubbo-consul-sample/README.md
@@ -8,9 +8,30 @@ CAP理论是分布式场景绕不开的重要理论
 
 <img src="https://ipman-blog-1304583208.cos.ap-nanjing.myqcloud.com/dubbo/1081608882430_.pic_hd.jpg" width = "400" height = "280" alt="图片名称" align=center />
 
-关于分区容忍性的理解，大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition），分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
+关于分区容忍性P的理解，大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition），分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
 关于提高分区容忍性的办法，就是把同一份数据复制到多个节点上，分布到各个区里，容忍度就提高了。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。
 
 剩下CAP的C和A无法同时做到，原因是
 如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果就会有差异，但数据同步会消耗时间，期间可用性就会降低。
 如果A是第一需求的话，那么只要有一个服务在，就能正常接受请求，但是对于返回结果变化不能保证一致性，原因是在分布式部署的时候，不能保障每个环境下处理速度。
+
+### 主流注册中心或配置中心产品一致性对比
+|   |  Nacos | Eureka  | Consul  | Zookeeper  |
+| ------------ | ------------ | ------------ | ------------ | ------------ |
+|  CAP理论 | CP+AP  |  AP |  CP | CP  |
+|   |   |   |   |   |   |
+
+#### Apache Zookeeper -> CP
+与Eureka有所不同，Apache Zookeeper在设计时就遵循CP原则，即任何时候对Zookeeper访问请求能得到一致的数据结果，同时系统对网络分区具备容错性，但是Zookeeper不能保证每次服务请求都是可用的。
+
+从Zookeeper的实际应用情况来看，在使用Zookeeper获取服务列表时，如果此时Zookeeper集群中的Leader节点宕了，该集群要进行Leader的重新选举，又或者Zookeeper集群中半数节点不可用，都将无法处理请求，所以说Zookeeper不能保证服务可用性。
+
+在大部分分布式环境中，尤其是设计数据存储的场景，数据一致性是首先要保证的，这也是Zookeeper设计CP原则的另一个原因。
+但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不同，也并不会造成灾难性后果。
+因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到了可能不正确的服务提供者信息，也要胜过因无法获取实例而不去消费，导致系统异常要好。（消费者消费不正确的提供者信息可以进行补偿重试机制）
+
+当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，问题在于，选举Leader的时间太长，30～120s，而且选举期间整个zk集群是不可用的，这就导致整个选举期间注册服务瘫痪。
+尤其在云部署环境下，因为网络问题使得ZK集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是无法容忍的。
+
+
+
