真的是好久未坚持写博客了，自己想想除了工作外，少了好多东西，还是得坚持每天总结和思考。无论工作怎样，都应该始终坚持读书和健身！
废话不多说，直接切入正题。
1.传统IT，一致性通常指强一致性，其通常体现在“你中有我、我中有你、浑然一体”；而在互联网时代 ，一致性的含义远远超出它的原有含义。互联网时代信息量巨大，需要非常强大的计算能力，不但要求对用户的响应速度款，还要求吞吐量指标想歪扩展（即水平伸缩），于是单节点的服务器无法满足人们的需求，服务节点开始池化。于是互联网时代讨论最多的话题是拆分。拆分一般分为水平拆分和垂直拆分，这不单指对数据库或者缓存的拆分，主要是表达一种分而治之的思想和逻辑。
水平拆分指由于单个节点无法满足性能需求，需要扩展为多个节点，多个节点具有一致的功能，组成一个服务池，一个节点服务一部分的请求量，所有节点共同处理大规模高并发的请求量。
垂直拆分指按照功能进行拆分，秉着“专业的人干专业的事”的原则，把一个复杂的功能拆分成多个单一、简单的功能，不同的单一功能组合在一起，和未拆分前完成的功能是一样的。由于每个功能职责单一、简单，使得维护和变更都变得更简单、容易、安全，所以更易于产品版本的迭代，还能够快地进行敏捷发布和上线。
在这样的互联网时代，，一致性指分布式服务化系统之间的弱一致性，包括应用系统的一致性和数据的一致性。
2.一致性问题--现实中的应用
下订单和扣库存；同步调用超时；异步回调超时；掉单；系统间状态不一致；缓存和数据库不一致；本地混存节点间不一致；缓存数据结构不一致，eg.出现NullPointerException等。
3.解决一致性的模式和思路--酸碱平衡
ACID（酸），指关系型数据库的四个特性，分别是原子性、一致性、隔离性、持久性。
BASE（碱），解决CAP（分布式系统的原理三要素，一致性、可用性、分区容忍性（关系型数据库是单节点无复制的，不具有分区容忍性））提出的分布式系统的一致性和可用性不可兼得的问题。详细参考维基百科的Eventual consistency页面。BASE模型包含三要素，分别是基本可用、软状态（状态可以在一段时间内不同步）、最终一致（在一定的时间窗口内，最终数据达成一致即可）。
3.分布式一致性协议
两阶段提交协议。在初级阶段锁定资源，是一个重量级操作，能保证强一致性，但实现起来复杂、成本高、不够灵活。有阻塞、单点故障、脑裂三张致命问题。
三阶段提交协议，通过超时机制解决了阻塞的问题。相对而言，主要有量不同点，一是增加了一个询问街U盾那，可以确保尽可能早地发现无法执行操作而需要种植的行为，二是在准备阶段以后，协调者和参与者执行的任务重都增加了超时，一旦超时，则协调者和参与者都会继续提交事务，默认为成功，这也是根据概率统计超时后默认为成功的正确性最大。具体图解和区别 详见《分布式服务架构》63页。
TCC协议，讲一个任务拆分成Try、Confirm、Cancel三个步骤。可以说是简化版的三阶段提交协议，解决了两阶段提交协议的阻塞问题，但是没有解决极端情况下会出现不一致和脑裂的问题。然而TCC通过自动化手段，将需要人工处理的不一致情况降到最小，也是一种非常有用的解决方案。