架构：CAP、BASE

CAP

　　CAP原则又称CAP定理，指的是在一个分布式系统中：

• Consistency（一致性）：每次读操作都能保证返回的是最新数据。

• Availability（可用性）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果。

　　　　备注：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性），换句话就是说，任何时候，任何应用程序都可以读写数据。

• Partition tolerance（分区容错性）：以当节点间出现网络分区，照样可以提供服务。

 

　　选择AP时出现数据不一致的例子：Redis的Sentinel组件会监视集群的状态，可能仅因为Sentinel组件所在服务器和主Redis的网络通讯出现了问题(并不是主Redis故障)，导致发现当前的“主Redis”不可用就会把“从Redis”设为“主Redis”；在做这个主备转换前后，原来已链接“老主Redis”的客户仍然在处理，新加入的链接交给了“新主Redis”，这就导致了“不一致性” 。

BASE

• Base Available

　　当系统发生了不可预知的问题时，允许损失部分可用性，但依然保证系统的大部分可用。其中包括：

1. 时间损失，原来需要0.5秒完成的操作，可能在发生故障时增加到1秒甚至更多完成，但依然能够完成。
2. 功能损失，当大量用户使用时，例如秒杀等大并发时，保证部分用户的功能得到满足，另一部分用户采用降级处理，引导至等待或其他页面。

• Soft state

　　弱状态或软状态，当网络发生故障等情况发生，不强制要求所有节点一致性。在不破坏系统整体的情况下允许部分节点存在中间状态。

• Eventually consistent

　　最终一致性是BASE中最重要的一环，由于上述存在了中间状态，那就要求系统在最终保证一致性。最终一致性分为五类：

1. 因果一致性（Causal consistency） 如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
2. 读己之所写（Read your writes） 节点 A 更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。
3. 会话一致性（Session consistency） 会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
4. 单调读一致性（Monotonic read consistency） 单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
5. 单调写一致性（Monotonic write consistency）指一个系统要能够保证来自同一个节点的写操作被顺序的执行。