从Paxos到Zookeeper（一）事务&分布式事务

ACID

Atomicity 原子性

全部成功或者全部失败恐怕是程序员用到的最多的特性，特别是水平比较差并且还不知道自己水平比较差的程序员。在Spring的@Transactional的帮助下，代码被施加了魔法以确保其中的bug不会导致数据混乱。

Consistency 一致性

一致性恐怕是关注的最少的，因为使用数据库来实现一致性有着性能上的消耗。并且外键还不够强大，特别是没有继承这一特性使得FK在描述数据关系时显不够精确，另外逻辑删除也削弱了其管理能力而只是保留了提供数据服务的能力。另外由于产品经理频繁变动的需求，使用外键则给未来添加了太多的束缚。

Isolation 隔离性

隔离性是程序员津津乐道的话题，也是面试中的常客，但是我发现能准确使用隔离性的少之又少，从这一方面也可以看出很多程序员没有掌握计算机科学做事的精髓：tradeoff.显然隔离性的越高出错的可能性越低，但是一个勇敢的程序员，一个敢于承担责任的程序员，一个想把事情做成的程序员应当追求更低的隔离级别。

隔离级别	脏读	非重复读	Phantom read
READ_UNCOMMITTED	allowed	allowed	allowed
READ_COMMITTED	prevented	allowed	allowed
REPETABLE_READ	prevented	prevented	allowed
SERIALIZABLE	prevented	prevented	prevented

下面是书中一个例子

Durability 耐久性

至于这最后一个特新，就是废话，毕竟数据库就是用来进行持久化的。

CAP

cap是下列三个单词的缩写，Consistency，Availability，Partition tolerance，被称为无法同时达到。下面按PAC的顺序来说明下：

Partition tolerance 分区容错

分区容错性是指分布式系统遇到任何网络分区故障的时候，任然保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障
当我们来到cap的时候往往意味着p是无法避免的，否则沿用前面的acid即可。为了系统的可扩展性，p无法妥协。

Availability 可用性

简单的看a是boolean，其实a是一个integer。为了衡量a一般使用相应时间来表示，对于不同类型的系统a可以设计的不一样，这是一个可以讨价还价的地方，需要根据业务价值来确定。

Consistency 一致性

在acid那里看c几乎是天然的，如果没有达到c则系统毫无意义。但是如果我们对数据一个个拎出来来看，不同的数据对c的要求是不一样的。读操作的数据范围往往是不可控的，用户可能想看到任意关联的数据，但是对于写操作其需要读取的数据往往是比较稳定的且比较窄，毕竟不是万事万物之间都有联系。

BASE

Basically Available 基本可用

基本可用又有两种情况

• 功能损失
  这个就要搭配服务降级，在秒杀等业务高峰期停用一些功能。这个对于产品经理而言难以接受，并且需要系统本身是微服务的架构
• 相应时间损失
  这个不再着眼于系统稳定而是考虑在系统不稳定时能快速恢复，所以这样的考虑就是在出现故障时能够忍受更长的响应时间，对于用户而来会感觉系统忽快忽慢。

Soft state 软状态

软状态主要是针对多副本之间的状态一致性而言，它允许系统的多个节点的副本数据同步出现延迟

Evantually consistent 最终一致性

最终一致性是对强一致性的放弃，一般又可以分为以下几种情况

Causal consistency 因果一致性

就是A更新了某个值后调用了B，那么B去读这个值就一定是新值，而对于非A调用的C而言，去读值得时候可以是旧值。这个和单机中遇到的情况很像，系统间的交互必然要保证这个

Read your writes读己之所写

这个一个更弱的限定，就是上面的B就是A的情况

Session consistency 会话一致性

就是限定了读取者的数据范围。同一个会话中的多次读取应该是一致的。这个恐怕对于用户而言是能接受的底线

Monotonic read consistency 单调读一致性

这个和REPETABLE_READ有点类似，不过REPETABLE_READ是让时间停留在那一刻而Monotonic read要求时间不能倒流。

Monotonic write consistency 单调写一致性