微服务架构中网络断开怎么办，一致性还是可用性
CAP定理是什么
2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。
CAP定理即：分布式数据库系统最多只能保证三分之二的这三个特点：
- 一致性（Consistency）
- 可用性（Availability）
- 分区容错性（Partition tolerance）
cap的定义
一致性（Consistency）
一致性一般值数据一致性
如果所有节点同时看到相同的数据，则认为系统是一致的。
简而言之，如果我们在一致的系统上执行读取操作，则它应该返回最新写入操作的值。
all nodes see the same data at the same time
所有节点同时能看到相同的数据，这就是一致性，但是一致性细化分为三种不同类型：
三种一致性分类
注意：一般中大型项目都使用主从库，这里需要你有主从库的概念
- 强一致性：用户更新头像后，并使其他用户可见，即从库复制属于同步是为强一致。
- 弱一致性：用户更新头像后，后续部分用户访问不到新头像，即从库复制属于异步是为弱一致。
- 最终一致性：当用户从异步从库读取时，如果此异步从库落后，他可能会看到过时的信息。这种不一致只是一个暂时的状态——如果等待一段时间，从库最终会赶上并与主库保持一致。这称为最终一致性
cap理论中的一致性是指强一致性
可用性（Availability）
分布式系统中的可用性可确保系统100％的时间保持运行。不管节点的状态如何，每个请求都会得到一个（非错误）响应。
Reads and writes always succeed （读写一直可用）
分区容错性（Partition tolerance）
现在的微服务基本都是分区部署，即使其中几台服务器挂掉了，那么剩余的服务器也要能够对外提供正常的系统需求.
cap取舍
在cap理论中，P是绝对成立的，现在微服务分区部署是一个绝对的事实，多节点部署是基础设施，如果没有P,也就等于没有分布式系统，更何谈cap理论。所以在cap理论中，我们一般谈论的是ca之间的权衡，然后尽量提升P
cp舍a
如果系统能够接受一段时间无响应或者停机的话，就可以在CAP中保留CP舍A，付出的代价将会是用户的体验感下降，这类设计一般只适用于内部系统,或者用户访问量不多的情况下,相较ap这种设计是比较少的。
ap舍c
保留系统可用性和分区容错性，放弃一致性（CAP中一致性指强一致性），AP注重用户体验，分布式系统中，最大的问题就是网络传输问题，如果服务网络出现问题，那么各节点只能使用自身库（缓存）返回数据，导致用户看到的数据可能不一致。系统中舍弃强一致性并不意味着系统数据就不一致了，只是换了一种方式，不使用强一致性，而使用最终一致性，允许数据短暂时间内不同步，但是类似银行这种系统是必须要使用强一致性的。大多数互联网场景使用AP多一些，但是万事没有绝对，应该根据业务场景来进行架构设计，只有适合的才是最好的
为什么CAP无法同时满足？
可用性、分区容错性、一致性能否同时满足呢，答案是否定的。
假设现在有两台服务器，NodeA和NodeB这两台服务器组成分布式系统：
- 在满足一致性的时候两台服务器的数据是一样的，DB0=DB0。
- 在满足可用性的时候，用户不管是请求NodeA还是NodeB，都会得到立即响应。
- 在满足分区容错性的情况下，NodeA和NodeB有任何一方宕机，或者网络不通的时候，都不会影响NodeA和NodeB彼此之间的正常运作。
如果NodeA和NodeB之间通信的时候网络突然出现故障，有用户向NodeA发送数据更新请求，那NodeA中的数据DB0将被更新为DB1，由于网络是断开的，NodeB中的数据库仍旧是DB0；
如果这个时候，有用户向NodeB发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据NodeB，一般有 二种选择：
- 牺牲数据一致性，响应旧的数据DB0给用户；ap舍c
- 牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作完成之后，再给用户响应最新的数据DB1。cp舍a
p 上面说过分布式架构特殊性，p是必选的
通过以上说明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。所以说分布式系统不可能同时满足三个特性。
总结
简而言之：
- 一致性：无论返回哪个节点，都必须返回相同的Data。
- 可用性：节点应该响应（必须可用）。
- 分区容忍性：集群应该响应（必须提供），即使有节点间AA分区（即网络故障）。
无论架构师、普通开发还是项目经理，cap是必须在系统设计之初做出取舍，选择最适合自己的方案。
