做过数据备份的各位一定知道CAP理论。2000年加州伯克利大学认为分布式系统有一致性，所有节点在任何时间都可以访问到最新的数据副本；每个请求都能收到一个响应，无论是成功还是失败，必须有服务器的响应，而不是TCP超时、TCP断开等；其中一个区挂了，不影响其他分区。

这三个特性无法共存，只能取两点，牺牲另一点。

AC模型，可用性+强一致性，牺牲了分区容忍性。比如MySQL Cluster集群，内部还是可以用的，MySQL集群提供两阶段提交事务方式，保证各节点数据强一致性。

MySQL的集群无法忍受脱离集群独立工作，一旦和集群脱离了心跳，节点出问题，导致分布式事务操作到那个节点后，整个就会失败，这是MySQL的牺牲。

CP模型，一致性+分区容忍，牺牲了可用性。Redis客户端Hash和Twemproxy集群，各Redis节点无共享数据，所以不存在节点间的数据不一致问题。

其中节点大了，都会影响整个Redis集群的工作。

当Redis某节点失效后，这个节点里的所有数据都无法访问。如果使用3.0 Redis Cluster，它有中心管理节点负责做数据路由。

AP模型，可用性+分区容忍性，牺牲了强一致性。用Cassandra集群时，数据可以访问，数据能备份到各个节点之间，其中一个节点失效的话，数据还是可以出来的。而分布式事务的各个节点更新了提交了只是其中一部分节点，底层继续同步，这是AP模型。

AC是高可用性和高强制性，所有的关系型数据库、PG等都是强一致性，牺牲了分区容忍性。MongoDB和BerkeleyDB的可用性比较差。AP模型缺少了强一致性。

互联网行业模型。不同的业务类型要求不同的CAP模型，CA适用于支付、交易、票务等强一致性的行业，宁愿业务不可用，也不能容忍脏数据。互联网业务对于强一致性不高，发个帖子要审核，没人看到无所谓。发一个音频要进行编码审核才能看到。

Base模型是什么？eBay工程师提出大规模分布式系统的实践总结，在ACM上发表文章提出 Bash 理论是基本可用、软状态和最终一致性。不要求实时一致性，但一定要实现最后一点。

基本可用（Basically Available）。分布式系统在故障时允许损失可用性，保证核心业务可用。音频直播或是做活动时，当业务量非常大的时候可以降级。做游戏也是，在战斗的时候最关心数值的增长，看了多少人都无所谓，缓解核心内容的压力。

软状态（Soft State）。允许系统中出现的中间状态，中间状态不会耽误可用性。在写代码、编程业务的设计上，必须容忍有一定的临时数据同步，考虑到全局锁和数据多版本的对比，把各个节点的相关数据都上锁，这是一个悲观锁，一旦写任务，其他人都能改我的数据，这是比较悲观的心态。而数据多版本，类似于乐观锁，导致其他人和我方数据冲突的机会并不是那么多，只要在提交的时候发现版本不一样，更新一下，汇总数据就可以了。做好业务上的隔离，多数情况都属于多版本，技术都能解决，不一定要把所有的东西都锁死。允许有一定的临时数据。最终一致性，在临时上的数据不一样，数据同步也是要花时间的。随着时间的迁移，不同节点的数据总是向同一个方向有一个相同的变化，这是Bash模型。这种模型非常适合互联网业务的发展。

数据一致性模型。允许窗口期数据不一致，互相关联的数据要同步。序列一致性，全局按照序列顺序来做。线性一致性，每一个时间的时钟要同步，时间序列是严格的，按顺序的。

最后是强一致性，一个时间只能实行一个任务。