分布式系统的CAP不可能三角在实际应用中是怎样取舍的？

Question

题目描述

分布式系统有一个不可能三角理论，指一致性（consistency），可用行（availability），分区容错性（partition tolerance）三者不可兼得。那么在实际的应用中是如何取舍的呢？

本文参与了SegmentFault 思否面试闯关挑战赛，欢迎正在阅读的你也加入。

Answer 1

在分布式系统中，网络故障一定会发生，所以分区容错性必须保证，需要在AP和CP中选择，也就是在保证分区容错性的前提下，要么保证系统的一致性，要么保证系统的可用性。

具体如何选择需要参考业务场景和系统的设计初衷。我用MySQL数据库主从复制举例，客户端写入数据都发送给主库，由主库负责将同步给从库完成复制操作，数据在数据库主从间复制有两种方式，异步复制（MySQL实际采用的方式）和同步复制。异步复制是指客户端的写入请求在主库中完成后不用等待从库的写入操作完成就可以直接返回给客户端表示操作成功。而同步复制是指客户端的写入请求后不仅需要等待主库完成操作，还需要等待所有从库操作完成（等待从库响应）后才可以返回客户端。

对于同步复制而言，可以保证数据一致性，任何时刻从主库或从库读取的数据均为最新值。但由于主从复制的写操作必须等待从库完成才算完成，一旦主从间网络发生问题，从库无响应，数据库的所有写操作也将延时或失败。所以同步复制属于CP模式，即牺牲部分可用性保证一致性。

而对于异步复制来说，主从间网络故障并不会影响数据库写入操作，但是会造成主从间数据不一致，从库没有主库最新数据。所以异步复制属于AP模式，即放弃部分一致性而保证可用性。

如果我们的业务场景允许一定程度的数据不一致情况而完全无法容忍系统不可用的情况，我们选择AP模式，其实大部分业务场景都如此，即使是我们认为的银行、金融领域这种对于一致性要求很强的业务场景，也只是尽量减小“一定程度”的不一致数据范围和发生频率并且通过及时发现这种不一致数据并进行修复等各种方式来降低不一致造成的问题。如果我们对数据一致性要求要远远大于可用性要求，宁可让系统不可用也不能出现不一致的情况否则会出现更大的问题，我们可以选择CP。显然这种场景并不常见，分布式系统高可用性是一个应用保证，确实有部分业务场景可以让系统在出现网络问题的时候整体停机并进行修复，但是那仅仅限制在小范围的专业领域，我们通常理解的互联网场景极少采用这样处理方式。

最后在补充一下，强一致性对性能的影响也不能小觑，可以想象一下同步复制一主十从的写入操作场景。所以当今很多分布式数据库系统也会通过放弃一致性来提高性能。