分布式架构应用的可用性和一致性问题

前言

对于互联网架构该怎么做，存在着一定的误区，所以写此文章，抛砖引玉。

1. 传统应用的可用性和一致性问题

传统的单体应用架构，其高可用和一致性问题是两个独立的问题，两者并没有关联关系比如，传统的SQL数据库的事务通常都是支持ACID的强事务机制，所以单数据库的模式使得事务强一致性得到满足。

A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行;

C代表一致性，即保证进行事务的过程中整个数据库的状态是一致的，不会出现数据花掉的情况;

I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等;

D表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。在可用性方面，传统单体应用并不一定要求7x24小时高可用，所以其高可用的架构设计依赖于业务需求。如果业务需要7x24小时不间断服务，那么完全可以通过存储冗余（如mirror,raid等），instance冗余（如oracle RAC，J2EE应用多节点部署，多个Http Server,F5 load balance）等方法提高系统可用性。

2. 分布式系统的cap原则

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容错性（P）：

通俗