从单机数据库到分布式数据库，从数据库事务特性到分布式事务

    所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。例如，银行转帐工作：从一个帐号扣款并使另一个帐号增款，这两个操作要么都执行，要么都不执行。 

单机数据库事物

 数据库事务必须具备ACID特性，ACID是Atomic（原子性）、Consistency（一致性）、Isolation（隔离性）和Durability（持久性）的英文缩写。

• 一致性：指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例如对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNTS表中Tom和Jack的存款总额为2000元。
  • 用类型检查、唯一索引、外键约束和级联更新保护数据的完整性
•  隔离性：指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
  1. 实现事务隔离的主要手段是锁。另外一个关键技术是 MVCC (Multi-version Concurrency Control), 它可以在一些场景避免加锁, 实现同时读写。不同的隔离级别在数据库中的加锁策略不一样：
         Read uncommitted - 读不需要加锁，写仅仅需要加行锁。
         Read committed - 需要加写锁，读必须等待写事务结束。
         Repeatable reads - 需要加读锁，当有事务在读一行记录，其他写同一行的事务都会阻塞。
         Serializable - 需要加范围锁，当有事务 SELECT 某个范围的数据时，其他访问同一范围的事务都会阻塞。
  2. MVCC 则优化了事务读的场景。数据库保存记录的多个版本，在进行更新时，其他只读事务 / 非事务读可以直接访问记录的上一个版本，不需要等待锁。
  3. 引入锁在数据库层面上带来了另一个问题：事务中数据的更新不一定是有序的，因此请求锁的顺序也是无序的。无序的加锁必然会导致死锁。因此数据库实现了另一套机制：死锁检测，来防止业务陷入死锁。单机数据库实现死锁检测的基本办法（ps. 集中式死锁检测）是维护一个活动事务列表，记录每个活动事务上持有和等待的锁。这样——当加锁时，数据库有足够的信息判断等待这一个锁会不会形成闭环，从而识别和阻止死锁。
• 持久性：指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。
  1. 在 linux 下，软件可以用 fsync 保证数据真正写入磁盘 / RAID 卡。另一方面，为了解决 RAID 恢复慢的问题，大部分数据库都支持以数据复制方式实现的 热备机制。一旦数据库发生故障，可以立即用备库代替故障的主库，不用等待较慢的 RAID 数据恢复。

单机数据库事物总结       

事务的（ACID）特性是由关系数据库管理系统（RDBMS，数据库系统）来实现的，ACID特性是每一个数据库API必须保证的。

1.         数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。
2. 　　数据库管理系统采用锁机制来实现事务的隔离性。当多个事务同时更新数据库中相同的数据时，只允许持有锁的事务能更新该数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。

  单机到集群

      单机数据库 已经有一套很成熟的经验和理论，可以在合理的性能下实现业务需要的 ACID 特性。—— 但是，这套经验和理论还面临一个问题：

单机的硬件性能总是有上限的。目前来看，ACID 事务处理的顶峰是 Oracle ——大概 500,000 TPS 每节点。这个数字是在小型机和高端存储设备上达到的 ——而一套这样的设备价值大约是 $30,000,000。显然。当业务增长到单个数据库节点再也容纳不了的时候，自然需要扩容到多个节点。为了有效的维护多个节点上的数据，业务需要能够在多个节点 ——或者说在 分布式环境 上实现 ACID 事务的理论。

       所有的理论都是想通的。借鉴数据库保证了ACID事物，如果我们需要实现一个系统，必须保证其事物性，是不是有所启发呢？其实无论是单机还是集群，事务(Transaction)可以理解成并发控制的基本单位，单机也可以多用户，也可以支持并发，只是由于硬件可能满足不了功能需求或者性能需求，所以才从单机扩展到集群。

 

 总结

    对于分布式事物，其实这些放在纸面上说的东西，和分布式理论CAP，分布式协议都是分不开的。

进一步的讨论

        同样的问题，当我们需要实现一个消息系统，面对可能C10K的并发连接数，我们怎么保证用户事物操作 的原子性，隔离性，一致性，持久性呢。

• 原子性：保证一条消息要么写入成功，要么失败。一条消息就是一个事物。
• 一致性：用户读写的消息是不是和消息持久化结果一致，主从节点上的消息同步是不是一致
• 隔离性：用户之间并发读写不会影响，也不会读到脏数据，要么就是之前的状态，要么就是结束状态，反正不会是中间状态。
• 持久性：为了消息 的可靠性，当系统奔溃时，消息可以不丢失，持久性是应该的。但是实际上，设计是根据需求而定的，其实也没有那么严格的规定，不同的应用场景有不同的实现，例如redis作为一个数据库，持久化不也只是它的一个选项吗？当然，我更愿意说redis是一个分布式缓存。