翻译自：CAP Theorem: Revisited

注意: 大约两个月以前，我写了一篇关于解释CAP理论的博客。发布之后，我意识到我当时的想法有点过时，并不再适用于当下，所以我通过这篇博客做一些补充说明

在如今的技术环境中，当需要让额外的资源（计算，存储等）在合理的时间范围内完成任务，我们有强烈的意愿想要设计出横向扩展的系统。这是通过向系统中添加额外的商业硬件来处理日益增加的负载。由于这种扩展策略导致一个额外的缺点就是系统的负责度增加了。而这正是CAP的用武之处。

CAP理论说明，在一个分布式系统中（一群进行数据分享的节点），数据的读写只能保证以下三个中的两个：（Consistency）一致性，（Availability）可用性，（Partition Tolerance）分区容忍性 - 其中一个必须被舍弃掉。但是，正如下面所说的，你并没有你想象中那么多的选择。

  • Consistency（一致性） - 读操作一定会保证获取到最新写入的数据
  • Availability（可用性） - 没有故障的节点将会在合理的时间内返回合理的结果（没有错误或超市）
  • Partition Tolerance（分区容忍性） - 即时发生了网络分区，系统也将照常运行

在继续深入之前，我们需要说明一件事情。面向对象编程 != 网络编程。在构建共享内存的应用时，我们存在一些想当然的假设，但是一旦某个节点跨越了时间和空间，这种假设就会不成立。

其中一项如荒谬的分布式计算中提到的网络是可靠的，但是其实并不是这样。网络或者部分网络经常性的意外发生故障。你没有办法选择网络故障什么时候在你系统上发生。

考虑到网络并不完全可靠，在分布式系统中，你必须容忍网络分区。幸运的是，在发生网络分区时，你可以选择去做些什么。根据CAP理论，那就意味着，我们只剩下两个选项：一致性与可用性。

  • CP - 一致性/分区容忍性 - 从分区节点中等待响应可能会产生超时。你可以根据自己的场景来选择返回一个错误信息。如果你的业务要原子性读写要求，可以选择一致性而不是可用性

  • AP - 可用性/分区容忍性 - 返回你最近一次版本的数据，但可能不是最新的。系统可以接收写请求，在分区恢复之后对数据进行处理。当你的业务要求数据在系统同步时具有一定的灵活性，那么可以选择可用性而不是一致性。尽管出现了外部异常，系统仍需要继续提供服务，可用性是迫不得已的选项（购物车业务等）。

决定使用一致性与可用性是一种软件上的权衡。在面对网络分区时，你可以选择做些什么 - 选择权在你手上。在日常生活中，在日常生活中，不管你想不想要它发生，网络临时还是永久中断，都是一种既定的事实 - 它存在于你的系统之外。

构建分布式系统提供了许多的优势，但是也会增加复杂度。在面对网络分区时，了解并权衡可行性，选择正确的路径是应用成功的关键。如果一开始就做错了，那么在第一次部署之前，你的应用注定要失败。