1、分布式一致性问题
假设客户端C1将系统的K由V1更新为V2,但客户端C2无法立即读取到K的最新值，需要在一段时间才能读取到。-------数据库之间复制的延迟问题。
数据复制需求：1、为了增加系统的可用性，以防止单点故障引起的系统不可用。2、提高系统的整体性能，通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务。
所谓分布式一致性问题，是指分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致情况。简单地讲，数据一致性就是指在对一个副本进行更新的同时，必须确保也能够更新其他副本，否则不同副本之间的数据将不再一致。
影响性能的解决方法：将写入动作阻塞，直到数据复制完成后，才完成写入。但性能急剧下降。
如何保证数据一致性，又不影响系统运行的性能，是每个分布式系统需要重点考虑和权衡的。于是，一致性级别由此诞生：
1、强一致性：要求系统写入什么，读取出来也会是什么，用户体验好，但性能影响较大。
2、弱一致性：约束系统在写入成功后，不承诺立即读到写入的值，也不承诺多久之后数据达到一致，但会尽可能地保证到某个时间级别（如秒级）后，数据能够达到一致状态，弱一致性还可以再分:
会话一致性：该一致性级别只保证对于写入的值，在同一个客户端会话中可以读取到一致的值，但其他会话不能保证。
用户一致性：该一致性只保证对于写入的值，在同一个用户可以读到一致的值，其他用户不能保证。
3、最终一致性：弱一致性的特例，系统会保证在一定时间内，能够达到一个数据一致性的状态。
2、分布式概念：
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
特征：
分布性
对等性，数据副本和服务副本
并发性
缺乏全局时钟
故障总是会发生
分布式环境的问题：
通信异常
网络分区
三态，成功、失败、超时
节点故障
3、分布式下ACID
ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必须要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
事务：由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行单元。事务可以在多个应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰，另一方面，事务为数据库操作序列提供了一个从失败中恢复到正常状态的方法。
原子性：事务的原子性是指事务必须是一个原子的操作单元，要么全部执行成功，要么全部不执行。
一致性：数据库执行前后，数据库必须处于一致性状态
隔离性：一个事务的执行，不能被其他的事务干扰。
4、事务级别：
未授权读取（未提交但被读到）、授权读取（读已提交），可重复读取和串行化。
可重复读：保证事务在处理过程中，多次读取到同一个数据时，其值和事务开始时刻是一致的，因此该事务级别禁止了不可重复读和脏读，但是可能出现幻影数据，如事务B在第一次操作时读取到1，但是在下一次事务操作中，即使事务B采用同样方式，可能会读取到10或20。
串行化：最严格的事务隔离级别。它要求所有事务都被串行执行，即事务只能一个接一个地进行处理，不能并发执行。
幻读：例如事务 T1 对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务 T2 又对这个表中插入了一行数据项为“1”的数据，并且提交给数据库。而操作事务 T1 的用户如果再查看刚刚修改的数据，会发现数据怎么还是 1？其实这行是从事务 T2 中添加的，就好像产生幻觉一样，这就是发生了幻读。比如，小编准备提取你打赏的一分钱，提取完了，这时又有其他热心网友打赏了一分钱，小编一看，明明已经取出了，怎么又有一分钱！？小编此时以为像做梦一样，我觉得也可以叫「梦读」，哈哈。幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。
5、分布式事务
概念：分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务会涉及对多个数据源或业务系统的操作。
CAP理论：一个分布式系统不可能同时满足一致性、可用性、分区容错性这三个基本需求。最多只能同时满足其中的两项。
一致性（C）：指数据在多个副本之间是否能够保持一致。
可用性（A）：指系统提供的服务必须一直处于可用状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性（P）：分布式在遇到任何网络分区故障的时候，仍然能够保证对外提供一致性和可用性的服务，除非是整个网络环境都发生了故障。
BASE理论是Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）。是基于CAP演化而来。核心思想是，既然无法做到强一致性，但每个应用都可以根据自身的业务特点，采取适当的方式来使系统达到最终一致性。
基本可用：性能上的损失或功能上的损失
弱状态：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响性能的可用性，即允许系统在不同节点的数据副本之间进行同步的过程中存在延迟。
最终一致性：保证系统最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
6、一致性协议：