微服务和分布式的区别 分布式是什么概念
先不管CAP是什么 ， 就谈谈对于一个分布式的系统 ， 它有哪些特征或行为 。
（1）分布式系统会把服务部署在多个节点上
（2）每个节点都有可能存储数据 ， 一份数据可能在多个节点上有副本
【微服务和分布式的区别 分布式是什么概念】（3）节点之间通过网络进行数据的同步
假设有个服务 ， 需要部署在3个节点上 ， 每个节点都需要存储同一份数据id ， id的初始值都是1 。
文章插图
现在对节点1写入id=2 ， 当网络正常的情况下 ， 节点1会向节点2与节点3进行数据同步 ， 此时3个节点的id值都是2 。不管访问哪个节点 ， 读取的id都是一样的值 。
文章插图
再对节点1写入id=3时 ， 由于此时发生网络闪断 ， 节点1无法联系到节点2与节点3 ， 那么此时访问节点1与节点2将会得到不一样的值 ， 出现了不一致性 。
文章插图
CAP理论是分布式系统中的核心理论 ， 由三个单词的首字母组成 ， 分别是
C（Consistence）一致性 ， 对于指定的副本数据 ， 访问任意一个节点 ， 都能读到相同的值 。
A（Availability）可用性 ， 访问非故障的节点 ， 总能在合理的时间内得到合理的响应 。
P（Partition Tolerance）分区容错性 ， 发生网络分区时 ， 整个系统依然能对外提供服务 。
一致性对节点1执行数据更新的操作后 ， 如果不进行同步操作 ， 这个时候再去读取节点2的数据 ， 就会得到不一样的结果 ， 从而产生不一致 。如果任意用户能在任意时间访问不同节点 ， 都能得到相同的数据 ， 那么这个分布式系统就是强一致的 。
CAP中的C代表的就是强一致性 ， 并且不考虑数据同步之间的延迟 。
此外 ， 还有
弱一致性 ， 指的是在更新某个节点的数据之后 ， 访问其余一小部分的节点得不到最新的结果 。
最终一致性 ， 指的是某个节点的数据之后 ， 在一段时间内访问其他节点得不到最新的结果 ， 但在稍后的某一个时刻 ， 能够得到最新的结果 。
可用性指的是能在合理的时间内得到合理的响应 ， 或者说在有限的时间内得到一个可以理解的响应 。对于不同的系统 ， 有不同的“有限时间” 。“可以理解的响应”指的是要么返回执行成功 ， 要么执行失败（但状态码是200） ， 而不是返回404、500等 。
分区容错性网络分区指的是 ， 由于网络是不可靠的 ， 本来A机房与B机房可以互相访问 ， 是一个整体 。当A机房与B机房的光纤断了 ， A机房便不能与B机房进行通信 ， 整体被划分成了两个区域（区域内部是可以互相通信的） ， 于是网络也被划分成了两个区域 ， 形成所谓的网络分区 。
对于一个分布式系统 ， 发生网络分区是必然存在的 。必定不发生网络分区的系统 ， 那就是一个单体系统 ， 并不是分布式系统 。
当然 ， 一个分布式系统 ， 在极端的情况下 ， 如果要牺牲P保证AC也是可以的 。
一般来说 ， 分布式系统都会选择满足P 。
那么 ， 剩余的CA可以同时满足吗？
先说结论 ， 在存在网络分区的情况下（即满足P） ， 那就不可以同时满足A与C 。
假设节点1存在于分区a中 ， 节点2与节点3存在于分区b中 。
文章插图
此时修改节点1的副本数据 ， 将id变为2
文章插图
由于存在网络分区 ， 无法将id的新值2同步到其他分区的节点下 。
如果此时要满足A（可用性） ， 且节点2与节点3只是在另外一个分区中 ， 并没有发生节点本身的故障 ， 由可用性的定义 ， 三个节点都可以进行访问 。
此时用户访问节点1 ， 得到id=2 ， 访问节点2时 ， 得到id=1 ， 发生数据不一致的情况 。
所以 ， 满足A的情况下 ， 就满足不了C（一致性） 。
如果一开始要满足C呢？
为了保证访问各个节点 ， 都能用户最新更新的值 ， 就要禁止任何对节点2与节点3的读写操作 ， 这就违背了A 。
所以 ， 在满足C的情况下 ， 就满足不了A 。
既然在发生网络分区的时候 ， 不能同时满足A与C ， 那么怎么在两者之间进行权衡呢？
选择AP在发生网络分区的情况下 ， 选择可用性 ， 就要放弃一致性 。
Eureka就是典型的AP系统
在Eureka集群中 ， 各个server节点没有主从之分 ， 都是相互平等的个体 。
各个server节点会互相复制数据 ， 产生冲突时 ， 直接用最新的数据覆盖掉旧数据即可 。
每一个client只会向一个server节点注册 ， server会将该client的ip等信息放入到注册列表中 。
之后client会向server节点定时发送心跳并同时拉取注册列表到client的本地缓存中 ， 超过一定时间不发送 ， server会将该client从注册列表中剔除 。
如果一个client下线 ， 首先需要过一段时间才能在server的注册列表中体现出来 ， 随后才能在其他的client上的本地缓存中体现出来 。因此client上本地缓存中的服务注册数据并不是最新的 ， 因此这里不能保证强一致性 。
一个server节点宕机或出现网络分区联系不上其他节点 ， 其他节点仍然能提供注册与查询服务 ， 因此保证了可用性 。该server节点没有将自己的注册列表同步到其他节点 ， 就会使得部分client的注册信息丢失 ， 因此这里不能保证一致性 。
当上述server节点重新上线或网络稳定后 ， 就能将当前的注册列表同步到其他节点 ， 整体又能达到最终一致性 。
Eureka作为一个专门的服务注册与发现的系统 ， 能够容忍数据不一致的情况（例如当A调用B ， B已经下线 ， 但A查询server时 ， 依然能够获得B的注册信息 。A随后发起对B的调用 ， 结果肯定是调用失败 ， 这个时候A选择重试或者直接熔断即可） 。即使发生不一致的情况 ， 也基本上是少数数据的不一致 ， 如果这个时候直接强行让注册中心不可用 ， 显然是忍受不了的 。
推荐阅读
- 微信群怎么找到群
- 微信怎么设置强提醒
- 鸽子和红薯能一起吃吗
- xrv怎么起步和停车 看这里
- 天气好心情好的句子 天气和心情的说说
- 伤感微信网名：夏沫之殇
- 榴莲的壳和核的作用
- 面疙瘩怎么和面
- 劳宫穴的功效和作用 按摩这个穴位有什么好处
- 微信朋友圈半夜睡不着句子