「cap」CAP - seo实验室

cap

CAP场景分析：

假设我们用一台服务器A对外提供存储服务，为了避免这台服务器宕机导致服务不可用，我们又在另外一台服务器B上运行了同样的存储服务，每当用户在往服务器A写入数据时，A都往服务器B上写一份，然后再返回客户端。一切都运行的很好，用户的每份数据都分别在A和B上，用户访问任意一台机器都能读取到最新的数据。

这时候，不幸的事情发生啦：A和B之间的网络断了导致A和B无法通信，也就是说网络网络出现了分区，那么用户在往服务器A写入数据的时候，A无法将数据写入到服务器B，这时，服务器A就必须做一个艰难的选择：

要么选择一致性C而牺牲可用性：为了保证服务器A和服务器B上面数据是一致的，服务器A决定暂停对外提供写入服务，从而保证了服务器A和B上数据的一致性，凡是牺牲了可用性。注意，这里的可用性不是我们通常所说的高可用性（比如服务器宕机导致服务不可用），而是指服务器虽然还活着，但是却不能对外提供写入服务。

要么选择可用性而牺牲一致性：为了保证服务不中断，服务器A先把数据写入到本地，然后返回客户端，从而让客户端感觉数据已经写入了，这导致了服务器A和B上数据不一致了。

可用性和一致性之间的选择不是非此即彼的，而是根据业务的需求在他们两者之间做妥协：

我们可以放弃对强一致性的要求，让其变成最终一致性，也就是说当服务器不能把数据传给服务器B的时候，先将数据缓存在本地，等到网络恢复之后再将数据传给服务器B，这样，服务还是可用的，只是在一定的时间窗口内两者的数据是不一致的。

保证最终一致性，不保证实时的一致性。