Skip to content

Commit ecdbfed

Browse files
authored
docs: add cap framework(doocs#196)
Thanks @hai046
1 parent ba2f131 commit ecdbfed

File tree

1 file changed

+18
-20
lines changed

1 file changed

+18
-20
lines changed
Lines changed: 18 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
## 1、分布式系统 CAP 定理 P 代表什么含义
1+
## 分布式系统 CAP 定理 P 代表什么含义
22

33
作者之前在看 CAP 定理时抱有很大的疑惑,CAP 定理的定义是指在分布式系统中三者只能满足其二,也就是存在分布式 CA 系统的。作者在网络上查阅了很多关于 CAP 文章,虽然这些文章对于 P 的解释五花八门,但总结下来这些观点大多都是指 P 是不可缺少的,也就是说在分布式系统只能是 AP 或者 CP,这种理论与我之前所认识的理论(存在分布式 CA 系统)是冲突的,所以才有了疑惑。
44

@@ -22,34 +22,32 @@
2222

2323
> 文章来源:[维基百科 CAP 定理](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86)
2424
25+
## 几个常用的 CAP 框架对比
2526

26-
## 2、几个常用的CAP框架对比
27+
| 框架 | 所属 |
28+
| --------- | ---- |
29+
| Eureka | AP |
30+
| Zookeeper | CP |
31+
| Consul | CP |
2732

33+
### Eureka
2834

29-
框架 | 所属
30-
---|---
31-
eureka | AP
32-
zookeeper | CP
33-
consul | CP
35+
> Eureka 保证了可用性,实现最终一致性。
3436
35-
### eureka
37+
Eureka 所有节点都是平等的所有数据都是相同的,且 Eureka 可以相互交叉注册。
38+
Eureka client 使用内置轮询负载均衡器去注册,有一个检测间隔时间,如果在一定时间内没有收到心跳,才会移除该节点注册信息;如果客户端发现当前 Eureka 不可用,会切换到其他的节点,如果所有的 Eureka 都跪了,Eureka client 会使用最后一次数据作为本地缓存;所以以上的每种设计都是他不具备`一致性`的特性。
3639

37-
> eureka 保证了可用性,实现最终一致性。
40+
注意:因为 EurekaAP 的特性和请求间隔同步机制,在服务更新时候一般会手动通过 Eureka 的 api 把当前服务状态设置为`offline`,并等待 2 个同步间隔后重新启动,这样就能保证服务更新节点对整体系统的影响
3841

39-
eureka所有节点都是平等的所有数据都是相同的,且eureka可以相互交叉注册。
40-
eureka client 使用内置轮询负载均衡器去注册,有一个检测间隔时间,如果在一定时间内没有收到心跳,才会移除该节点注册信息;如果客户端发现当前eureka不可用,会切换到其他的节点,如果所有的eureka都跪了,eureka client会使用最后一次数据作为本地缓存;所以以上的每种设计都是他不具备`一致性`的特性。
41-
42-
注意:因为eurekaAP的特性和请求间隔同步机制,在服务更新时候一般会手动通过eureka的api把当前服务状态设置为`offline`,并等待2个同步间隔后重新启动,这样就能保证服务更新节点对整体系统的影响
43-
44-
### zookeeper
42+
### Zookeeper
4543

4644
> 强一致性
4745
48-
zk在选举leader时会停止服务,只有成功选举leader成功后才能提供服务,选举时间较长;内部使用paxos选举投票机制,只有获取半数以上的投票才能成为leader,否则重新投票,所以部署的时候最好集群节点不小于3的奇数个(但是谁能保证跪掉后节点也是基数个呢);zk健康检查一般是使用tcp长链接,在内部网络抖动时或者对应节点阻塞时候都会变成不可用,这里还是比较危险的;
46+
Zookeeper 在选举 leader 时会停止服务,只有成功选举 leader 成功后才能提供服务,选举时间较长;内部使用 paxos 选举投票机制,只有获取半数以上的投票才能成为 leader,否则重新投票,所以部署的时候最好集群节点不小于 3 的奇数个(但是谁能保证跪掉后节点也是基数个呢);Zookeeper 健康检查一般是使用 tcp 长链接,在内部网络抖动时或者对应节点阻塞时候都会变成不可用,这里还是比较危险的;
4947

50-
### consul
48+
### Consul
5149

52-
和zk一样数据cp
50+
和 Zookeeper 一样数据 CP
5351

54-
consul 注册时候只有过半的节点都写入成功才认为注册成功;leader挂掉时,重新选举期间整个consul不可用,保证了强一致性但牺牲了可用性
55-
有很多blog说consul属于ap,官方已经确认他为cp机制 原文地址:https://www.consul.io/docs/intro/vs/serf
52+
Consul 注册时候只有过半的节点都写入成功才认为注册成功;leader 挂掉时,重新选举期间整个 Consul 不可用,保证了强一致性但牺牲了可用性
53+
有很多 blog 说 Consul 属于 ap,官方已经确认他为 CP 机制 原文地址:https://www.consul.io/docs/intro/vs/serf

0 commit comments

Comments
 (0)