注册中心及其理论

[Bpazy]

记录下注册中心相关知识。

各种注册中心对比：

指标	Eureka	Zookeeper	Consul	Etcd
一致性协议	AP	CP（Paxos算法）	CP（Raft算法）	CP（Raft算法）
健康检查	TTL(Time To Live)	TCP Keep Alive	TTL\HTTP\TCP\Script	Lease TTL KeepAlive
watch/long polling	不支持	watch	long polling	watch
雪崩保护	支持	不支持	不支持	不支持
安全与权限	不支持	ACL	ACL	RBAC
是否支持多数据中心	是	否	是	否
是否有管理界面	是	否（可用第三方ZkTools）	是	否
Spring Cloud 集成	支持	支持	支持	支持
Dubbo 集成	不支持	支持	支持	不支持
K8S 集成	不支持	不支持	支持	支持

[Bpazy]

CAP 理论

CAP 理论是分布式架构中重要理论：

• 一致性(Consistency)：所有节点在同一时间具有相同的数据；
• 可用性(Availability) ：保证每个请求不管成功或者失败都有响应；
• 分隔容忍(Partition tolerance) ：系统中任意信息的丢失或失败不会影响系统的继续运作。

关于 P 的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求。

CAP 不可能都取，只能取其中两个的原因如下：

• 如果 C 是第一需求的话，那么会影响 A 的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。
• 如果 A 是第一需求，那么只要有一个服务在，就能正常接受请求，但是对于返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。

再如果，同时满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心。

[Bpazy]

分布式系统协议

一致性协议算法主要有 Paxos、Raft、ZAB。

Paxos 算法是 Leslie Lamport 在 1990 年提出的一种基于消息传递的一致性算法，非常难以理解，基于 Paxos 协议的数据同步与传统主备方式最大的区别在于：Paxos 只需超过半数的副本在线且相互通信正常，就可以保证服务的持续可用，且数据不丢失。

Raft 是斯坦福大学的 Diego Ongaro、John Ousterhout 两个人以易理解为目标设计的一致性算法，已经有了十几种语言的 Raft 算法实现框架，较为出名的有 etcd，Google 的 Kubernetes 也是用了 etcd 作为他的服务发现框架。

Raft 是 Paxos 的简化版，与 Paxos 相比，Raft 强调的是易理解、易实现，Raft 和 Paxos 一样只要保证超过半数的节点正常就能够提供服务。

ZooKeeper Atomic Broadcast（ZAB，ZooKeeper 原子消息广播协议）是 ZooKeeper 实现分布式数据一致性的核心算法。

ZAB 借鉴 Paxos 算法，但又不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为 ZooKeeper 专门设计的支持崩溃恢复的原子广播协议。