从单机应用到分布式应用，CAP理论

    随着各个公司的业务量增大、业务复杂度增加和并发量要求，以前的单机应用完全不能再继续支撑（可以通过提升级服务器配置来提高并发量，但是这往往需要巨额资金而且没有解决全部问题），分布式微服务应运而生。

所谓的分布式微服务，就是将以前的单个网站，单个数据库来提供服务分为多个自治的网站及其数据库分布在不同的节点来共同提供服务，其中多个服务是依靠网络进行通信的。

  但是，因为网络是不可靠的（网络波动、延时、断线、消息丢失。。。），而引发了一系列分布式问题，CAP理论总结了分布式的特性：

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

上面的定义是针对相同的数据同时存储在多个分区中的情况，可以转变为以下现实场景：

一致性：就拿支付宝账户与余额宝帐户之间转账来说，假如支付宝账户服务与余额宝账户服务是两个独立的服务、有着各自独立的数据库。现在有一个从支付宝中转10000元到余额宝中的请求，请求被发送到支付宝服务中，分析一下：这不就是两个数据库的分布式事务吗？如果我们要保证数据的一致性（特别是涉及到钱的问题），支付宝账户扣了10000元以后，余额宝账户肯定是增加10000元以后这个请求才能被成功处理返回；但是因为网络不可靠性，如果这时余额宝账户服务暂时不可用，那支付宝账户服务就要么一直等待余额宝账户服务恢复正常，要么就直接返回操作失败，这时服务的可用性就出现了问题。

可用性：还是拿一致性中支付宝账户与余额宝账户之间转账的场景来说明，当余额宝账户服务因网络不可靠原因不可用时，支付宝账户服务如果需要保证服务的可用性（请求成功被处理），那它就必须在成功更新了自己的数据库时立即返回操作成功，将余额宝账户服务中的数据库更新进行延后（可用消息队列等技术保持最终一致性），这个时候，可用性得到了保障，一致性就出现了问题。

分区容忍性：因为网络不可靠的原因，多个服务之间出现通信延迟、丢失、断线是不可避免的，将单体应用拆分为多个微服务就必须接受这个事实，导致一致性与可用性中只能二选一。

 

参考文章：CAP原则(CAP定理)、BASE理论