一致性模型

问题
当我们在生成线上用一台服务器来提供数据服务时，我们会遇到如下两个问题：
1.一台服务器性能不足以提供足够的能力服务于所有的网络请求。
2.我们担心服务器宕机造成服务的不可用或数据丢失。

通常，我们会采用两种手段来扩展我们的数据服务：
1.数据分区：就是把数据分块放在不同服务器上（如uid%16,一致性哈希等）
2.数据镜像：让所有服务器都有相同的数据，提供相当的服务。

那么问题来了：
1.在数据分区方案中：如何解决分布式事务
2.在数据镜像方案中：如何保证数据一致性

思路分析
1.要想让数据有高可用性，就得写多份数据。
2.写多份的问题会导致数据一致性问题。
3.数据一致性问题又会引发性能问题。

数据一致性模型
1.Strong强一致：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。比如：文件系统，RDBMS都是强一致性。根据 CAP 理论，这种实现需要牺牲可用性。
2.Weak弱一致性：系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。
3.Eventually最终一致性：弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。
在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。

2PC（Two Phase Commit）
第一阶段：
1.协调者会问所有参与者结点，是否可以执行提交操作。
2.各个参与者开始事务执行的准备工作：
如：资源上锁，预留资源
3.参与者响应协调者，如果事务的准备工作成功，则回应“可以提交”，否则回应“拒绝提交”。

第二阶段：
1.如果所有的参与者都回应“可以提交”，那么协调者向所有参与者发送“正式提交”命令。参与者完成正式提交，并释放所有资源，然后回应“完成”，协调者手机各个结点的“完成”回应后结束这个Global Transaction。
2.如果有一个参与者回应“拒绝提交”，那么，协调者向所有的参与者发送“回滚操作”，并释放所有资源，然后回应“回滚完成”，协调者收集各结点的“回滚”回应后，取消这个Global Transaction。