CAP理论之思考

分布式系统的最大难点就是各个节点如何保持一致。最近我在工作中就遇到这样的问题，不同节点之间，彼此通过API，进行通信，交互数据，但有些服务节点存在延迟等问题，导致我看到的并不是实时的数据，以及系统更新时，更新A服务，间接影响到B服务，而B服务受到影响后，C服务随之受到影响，以此类推。对于公司技术架构平台设计者之一的我而言，虽然采用一些临时性措施解决了这些问题，但我不得不深入的去思考分布式一些本质上的东西，因为很多问题不从根本上弄清楚并解决，后面只会以一种或多种不同的状态存在着。搞清楚理论并带着直面的问题思考，或许能找到解决问题的最佳方式。

一、什么是CAP理论(引用维基百科解释)？

在理论计算机科学中，CAP理论，又被称作布鲁尔定理，它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

一致性(等同于所有节点访问同一份最新的数据副本）；
可用性(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)；
分区容错性(以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择)。

C对应的是一致性，A对应的是可用性，P对应的是分区容错性。

二、为什么说C、A、P只可同时满足两点，而不能三者兼顾呢？

一致性、可用性，分区容错性，分区容错性是一致性和可用性的前提。
这里我引用《分布式服务架构:原理、设计与实战》来解释为什么不能三者兼顾，该书是这样概括:
CAP原理证明，任何分布式系统只可满足以上两点，无法三者兼顾。由于关系型数据库是单节点无复制的，因此不具有分区容错性，但是具有一致性和可用性，而分布式的服务化系统都需要满足分区容忍性，那么我们必须在一致性和可用性之间进行权衡。如果在网络上有消息丢失，也就是出现了网络分区，则复制操作可能会被延后，如果这时我们的使用方等待复制完成再返回，则可能导致有限时间内无法返回，就失去了可用性；而如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失去了一致性。

三、C、A、P究竟该如何取舍？

从我个人的角度来看，并结合目前的情况，分区容错性和可用性于我们目前是最重要的，数据上我们可以允许有一定或部分的延迟。A和P是适合我们目前的情况。

四、那么如何实现A和P呢？即如何实现可用性和分区容错性？

最直接的方式就是分布式(分布式中的每个节点都需要集群，通过集群的冗余极大的保证可用性，不同节点的职责保证系统的稳定性)，综合利用多台服务器提高整体性能，这个性能包括提高容错率、提高并发处理能力、各个节点的服务器计算能力等。
之前写过一篇文章《从单体架构到分布式微服务架构的思考》或许让大家对分布式应用系统有一定的理解。

五、总结

近来遇到了很多问题，让我不得不更深入地学习与思考，在不断深入地学习与思考以及实践过程中，摸索出适合公司的分布式架构体系，但这并不是一件很容易的事情，面对着很多突发情况和问题，我需要保持冷静，并积极寻找问题解决的办法。