From 86683c38be69e7189441cced86a8c0fd206c7d7b Mon Sep 17 00:00:00 2001 From: haizhu Date: Tue, 13 Oct 2020 16:30:56 +0800 Subject: [PATCH 1/4] Update distributed-system-cap.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 几个常用的CAP框架对比 --- .../distributed-system-cap.md | 32 ++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/docs/distributed-system/distributed-system-cap.md b/docs/distributed-system/distributed-system-cap.md index a2ca84c..3519a12 100644 --- a/docs/distributed-system/distributed-system-cap.md +++ b/docs/distributed-system/distributed-system-cap.md @@ -1,4 +1,4 @@ -## 分布式系统 CAP 定理 P 代表什么含义 +## 1、分布式系统 CAP 定理 P 代表什么含义 作者之前在看 CAP 定理时抱有很大的疑惑，CAP 定理的定义是指在分布式系统中三者只能满足其二，也就是存在分布式 CA 系统的。作者在网络上查阅了很多关于 CAP 文章，虽然这些文章对于 P 的解释五花八门，但总结下来这些观点大多都是指 P 是不可缺少的，也就是说在分布式系统只能是 AP 或者 CP，这种理论与我之前所认识的理论（存在分布式 CA 系统）是冲突的，所以才有了疑惑。 @@ -21,3 +21,33 @@ - P 的体现前提是得有分区情况存在 > 文章来源：[维基百科 CAP 定理](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86) + + +## 2、几个常用的CAP框架对比 + + +框架 | 所属 +---|---|--- +eureka | AP +zookeeper | CP +consul | CP + +### eureka + +> eureka 保证了可用性，实现最终一致性。 + +eureka所有节点都是平等的所有数据都是相同的，且eureka可以相互交叉注册。 +eureka client 使用内置轮询负载均衡器去注册，有一个检测间隔时间，如果在一定时间内没有收到心跳，才会移除该节点注册信息；如果客户端发现当前eureka不可用，会切换到其他的节点，如果所有的eureka都跪了，eureka client会使用最后一次数据作为本地缓存；所以以上的每种设计都是他不具备`一致性`的特性。 + +注意：因为eurekaAP的特性和请求间隔同步机制，在服务更新时候一般会手动通过eureka的api把当前服务状态设置为`offline`，并等待2个同步间隔后重新启动，这样就能保证服务更新节点对整体系统的影响 + +### zookeeper + +> 强一致性 + +zk在选举leader时会停止服务，只有成功选举leader成功后才能提供服务，选举时间较长；内部使用paxos选举投票机制，只有获取半数以上的投票才能成为leader，否则重新投票，所以部署的时候最好集群节点不小于3的奇数个（但是谁能保证跪掉后节点也是基数个呢）；zk健康检查一般是使用tcp长链接，在内部网络抖动时或者对应节点阻塞时候都会变成不可用，这里还是比较危险的； + +#### consul + +consul 注册时候只有过半的节点都写入成功才认为注册成功；leader挂掉时，重新选举期间整个consul不可用,保证了强一致性但牺牲了可用性 +https://www.consul.io/docs/intro/vs/serf From 4f22be006fb563576e1de213e9048e1a9cb4dfe5 Mon Sep 17 00:00:00 2001 From: haizhu Date: Tue, 13 Oct 2020 16:37:20 +0800 Subject: [PATCH 2/4] Update distributed-system-cap.md --- docs/distributed-system/distributed-system-cap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/distributed-system/distributed-system-cap.md b/docs/distributed-system/distributed-system-cap.md index 3519a12..66752d3 100644 --- a/docs/distributed-system/distributed-system-cap.md +++ b/docs/distributed-system/distributed-system-cap.md @@ -27,7 +27,7 @@ 框架 | 所属 ----|---|--- +---|--- eureka | AP zookeeper | CP consul | CP From ba2f1313af13d4f4e77e3badf15bfddd5e7df59c Mon Sep 17 00:00:00 2001 From: haizhu Date: Tue, 13 Oct 2020 16:39:52 +0800 Subject: [PATCH 3/4] Update distributed-system-cap.md --- docs/distributed-system/distributed-system-cap.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/distributed-system/distributed-system-cap.md b/docs/distributed-system/distributed-system-cap.md index 66752d3..4d59372 100644 --- a/docs/distributed-system/distributed-system-cap.md +++ b/docs/distributed-system/distributed-system-cap.md @@ -47,7 +47,9 @@ eureka client 使用内置轮询负载均衡器去注册，有一个检测间隔 zk在选举leader时会停止服务，只有成功选举leader成功后才能提供服务，选举时间较长；内部使用paxos选举投票机制，只有获取半数以上的投票才能成为leader，否则重新投票，所以部署的时候最好集群节点不小于3的奇数个（但是谁能保证跪掉后节点也是基数个呢）；zk健康检查一般是使用tcp长链接，在内部网络抖动时或者对应节点阻塞时候都会变成不可用，这里还是比较危险的； -#### consul +### consul -consul 注册时候只有过半的节点都写入成功才认为注册成功；leader挂掉时，重新选举期间整个consul不可用,保证了强一致性但牺牲了可用性 -https://www.consul.io/docs/intro/vs/serf +和zk一样数据cp + +consul 注册时候只有过半的节点都写入成功才认为注册成功；leader挂掉时，重新选举期间整个consul不可用,保证了强一致性但牺牲了可用性 +有很多blog说consul属于ap，官方已经确认他为cp机制 原文地址：https://www.consul.io/docs/intro/vs/serf From ecdbfedf9da9b109dcece3187b155fb234618930 Mon Sep 17 00:00:00 2001 From: Yang Libin Date: Tue, 13 Oct 2020 17:19:33 +0800 Subject: [PATCH 4/4] docs: add cap framework(#196) Thanks @hai046 --- .../distributed-system-cap.md | 38 +++++++++---------- 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/docs/distributed-system/distributed-system-cap.md b/docs/distributed-system/distributed-system-cap.md index 4d59372..0f9b310 100644 --- a/docs/distributed-system/distributed-system-cap.md +++ b/docs/distributed-system/distributed-system-cap.md @@ -1,4 +1,4 @@ -## 1、分布式系统 CAP 定理 P 代表什么含义 +## 分布式系统 CAP 定理 P 代表什么含义 作者之前在看 CAP 定理时抱有很大的疑惑，CAP 定理的定义是指在分布式系统中三者只能满足其二，也就是存在分布式 CA 系统的。作者在网络上查阅了很多关于 CAP 文章，虽然这些文章对于 P 的解释五花八门，但总结下来这些观点大多都是指 P 是不可缺少的，也就是说在分布式系统只能是 AP 或者 CP，这种理论与我之前所认识的理论（存在分布式 CA 系统）是冲突的，所以才有了疑惑。 @@ -22,34 +22,32 @@ > 文章来源：[维基百科 CAP 定理](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86) +## 几个常用的 CAP 框架对比 -## 2、几个常用的CAP框架对比 +| 框架 | 所属 | +| --------- | ---- | +| Eureka | AP | +| Zookeeper | CP | +| Consul | CP | +### Eureka -框架 | 所属 ----|--- -eureka | AP -zookeeper | CP -consul | CP +> Eureka 保证了可用性，实现最终一致性。 -### eureka +Eureka 所有节点都是平等的所有数据都是相同的，且 Eureka 可以相互交叉注册。 +Eureka client 使用内置轮询负载均衡器去注册，有一个检测间隔时间，如果在一定时间内没有收到心跳，才会移除该节点注册信息；如果客户端发现当前 Eureka 不可用，会切换到其他的节点，如果所有的 Eureka 都跪了，Eureka client 会使用最后一次数据作为本地缓存；所以以上的每种设计都是他不具备`一致性`的特性。 -> eureka 保证了可用性，实现最终一致性。 +注意：因为 EurekaAP 的特性和请求间隔同步机制，在服务更新时候一般会手动通过 Eureka 的 api 把当前服务状态设置为`offline`，并等待 2 个同步间隔后重新启动，这样就能保证服务更新节点对整体系统的影响 -eureka所有节点都是平等的所有数据都是相同的，且eureka可以相互交叉注册。 -eureka client 使用内置轮询负载均衡器去注册，有一个检测间隔时间，如果在一定时间内没有收到心跳，才会移除该节点注册信息；如果客户端发现当前eureka不可用，会切换到其他的节点，如果所有的eureka都跪了，eureka client会使用最后一次数据作为本地缓存；所以以上的每种设计都是他不具备`一致性`的特性。 - -注意：因为eurekaAP的特性和请求间隔同步机制，在服务更新时候一般会手动通过eureka的api把当前服务状态设置为`offline`，并等待2个同步间隔后重新启动，这样就能保证服务更新节点对整体系统的影响 - -### zookeeper +### Zookeeper > 强一致性 -zk在选举leader时会停止服务，只有成功选举leader成功后才能提供服务，选举时间较长；内部使用paxos选举投票机制，只有获取半数以上的投票才能成为leader，否则重新投票，所以部署的时候最好集群节点不小于3的奇数个（但是谁能保证跪掉后节点也是基数个呢）；zk健康检查一般是使用tcp长链接，在内部网络抖动时或者对应节点阻塞时候都会变成不可用，这里还是比较危险的； +Zookeeper 在选举 leader 时会停止服务，只有成功选举 leader 成功后才能提供服务，选举时间较长；内部使用 paxos 选举投票机制，只有获取半数以上的投票才能成为 leader，否则重新投票，所以部署的时候最好集群节点不小于 3 的奇数个（但是谁能保证跪掉后节点也是基数个呢）；Zookeeper 健康检查一般是使用 tcp 长链接，在内部网络抖动时或者对应节点阻塞时候都会变成不可用，这里还是比较危险的； -### consul +### Consul -和zk一样数据cp +和 Zookeeper 一样数据 CP -consul 注册时候只有过半的节点都写入成功才认为注册成功；leader挂掉时，重新选举期间整个consul不可用,保证了强一致性但牺牲了可用性 -有很多blog说consul属于ap，官方已经确认他为cp机制 原文地址：https://www.consul.io/docs/intro/vs/serf +Consul 注册时候只有过半的节点都写入成功才认为注册成功；leader 挂掉时，重新选举期间整个 Consul 不可用,保证了强一致性但牺牲了可用性 +有很多 blog 说 Consul 属于 ap，官方已经确认他为 CP 机制 原文地址：https://www.consul.io/docs/intro/vs/serf