架构师训练营第六周作业

今天聊聊CAP原理。



说CAP之前，得先说说所谓的单体应用和分布式应用这两个概念。从计算机的发展历程来看，一开始的所有计算机应用都是跑在单台服务器上面的，也就是所谓的单体应用。一旦这个服务器由于各种原因不能工作了，整个业务就完全中断了，必须得等服务器恢复。这个时候，如何提高系统的可用性,即A(Availability),是急需解决的问题。



解决可用性的方案就很简单直接，既然一台机器靠不住，那就加多几台呗，不同的机器上面跑同样的软件，如果其中一台挂掉了，其他的就直接顶上。这样业务就不会需要完全中断，可能只是影响很短的时间，或者很小的范围。由于应用是跑在不同的服务器上面，这时候应用就是一个分布式应用了。



分布式应用解决了可用性的问题，但是却也是有副作用，也就是不同服务器之间的数据如何同步。单体应用时期，应用的数据只有一份，不存在说大家请求的数据不一致的问题。现在有多台服务器了，彼此都会处理数据，存储数据，如何保证数据一致，就变成了一个需要考虑的问题。



首先如果说我们要求所有的机器上面访问的数据都要严格保证一致，也就是所谓C(Consistency),那就要求所有的机器之间是有一个同步机制的。由于不同节点之间的网络存在延时和失效的可能，随着集群的规模扩大，集群之间数据同步失败的概率也就越大，这就意味着，如果要严格保证一致，业务的事务处理时间就会变的越来越长。极端的情况下面，如果有一台服务器的数据损坏了，那也就是所谓的一致性就永远保证不了。



针对上面的分析，一般来说，我们理想或者目标的分布式应用应该是，即使是各个节点存在数据延时或者部分节点数据不一致，用户的期待是系统还是可以操作的，也就是所谓的P(Partition tolerance),分区容错性。从另一方面来说，CAP原理里面的C和P是冲突的，本质上面，我们只能实现所谓的AC(一致性的可用系统)和AP(暂时不一致可用的系统)这两种类型，没有所谓的CP系统(理论上面类似三体里面的纠缠通信可能可以实现远程瞬间信息同步)。这就是所谓的CAP三角只能满足两者的原理。



从CAP原理来说，我们可以看看所谓的AC和AP系统的实现的差异。所谓AC系统，一般都是强一致的需求类型，比较典型的就是银行结算，要求不同机器最终读取到的结果要求是强一致的。一般的方案是共用一个数据库，保证事务的一致性。那如果数据量和并发量都很大，如何提升系统的性能呢？一个聪明的做法是，把数据进行分片，针对同一笔数据的操作，就可以锁定在一个事务里面进行处理。针对不同分片间的业务处理，则通过分布式事务的手段进行保证数据的最终一致性。



AP系统，通常对于数据一致性的要求没那么高，比如在线视频就是个典型例子。数据帧丢失部分不影响，只要视频能比较流畅的播放完成就足够了。这个时候，系统的可用性，包括不同用户可能看的的数据不一样，都是允许的。实际上，很多的业务场景，特别是涉及到实时处理的，比如制造，物流，基本都是允许场地离线工作的，最终再做数据的同步，也就是所谓的一致性。



CAP原理的提出，对于我们设计自己的分布式系统，有很好的的指导意义。我们要知道理论的边界，才能结合自己的业务要求，设计合适的系统架构，满足业务的实际要求。