谈谈数据库的ACID

什么是事务

1. MySQL的事务支持不是绑定在MySQL服务器本身，而是与存储引擎相关 MyISAM：不支持事务，用于只读程序提高性能
2. InnoDB：支持ACID事务、行级锁、并发

3. Berkeley DB：支持事务

   所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位，一个事务是一个连续的一组数据库操作，就好像它是一个单一的工作单元进行。换言之，永远不会是完整的事务，除非该组内的每个单独的操作是成功的。如果在事务的任何操作失败，则整个事务将失败。

   当事务处理系统创建事务时，将确保事务有某些特性。组件的开发者们假设事务的特性应该是一些不需要他们亲自管理的特性。这些特性称为ACID特性。

什么是ACID

• ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）.这是可靠数据库所应具备的几个特性

以前只是简单的理解，后来工作后聆听大神的理解，受益颇深改变了很多看法和认知！

1. 原子性，这个是最简单的，大家都明白.一个事物内的所有操作共同组成一个原子包,要么全部成功，要么全部失败
   这是最基本的特性，保证了因为一些其他因素导致数据库异常，或者宕机.这是原子性是大家对事物理解最多的.
2. 一致性，是大家误解最深的,很多老师喜欢用银行转账的例子来讲一致性.所谓一致性是基于原子性的, 原子性，只是保证了一个事物内的所有操作的同一性，大家同生死，不会出现你死了，我还活着， 但是，原子性并没有保证大家同一时刻一起生，一起死，计算机指令是有先后顺序的，这样就决定了一个事物的提交，会经历一个时间过程 那么，如果事务提交进行到了一半，我读取了数据库，是否会读到中间结果？为了防止这样的情况，数据库事务的一致性规定了 事务提交的前后，永远只可能存在事务提交前的状态和事务提交后的状态，从一个一致性状态到另一个一致性状态，而不可能出现中间的过程态，也就是说事务的执行结果是量子化状态，而不是线性状态。
   一致性是什么意思？假如你和你的老婆是穿一条裤子的，任何你知道的东西你都要告诉她，她知道的东西都要告诉你，那么，你接受一条信息的时候，她并不知道，这个时候，你们两个人的状态是不一致的，通过一定的同步措施，比如打电话，发短信他也知道了，最终你们两个人的状态保持一致，这是一种弱一致性，因为，在你正在发短信高速她的同时，如何外部者同时访问你们两个人，得到的结果会不一致，好了，回到数据库事务，数据库提交事务会有一个过程，如果提交的时候，存在一个时间差，在提交的第一秒，一个删过程还没完成，到了第三秒才完成，会不会第一秒访问的人和第三秒当真的人得到不同的结果？出现不一致，状态的混沌？这就是一致性得保证，只会有前状态和后状态，绝不会出现中间态。
   但是，分布式事务中，为了保证严格的数据一致性，几乎不可能，因为分布式事务涉及到网络开销，两个系统的数据库操作的分布式事务，如果遇到网络延时，或者一方数据库锁定过长，整个分布式事务会瘫痪， 强一致性几乎不可能，中间态出现不可避免，所以，你们现在经常网络购物，钱扣了，但是，会隔很久才会订单生效，或者订单失败了，会几日后才退款，说明了，他们并不是立即一致的，因为银行系统和订单系统并不在一个数据库，他们做不到强一致性，但是，他们最终一致了， 这就是，著名的最终一致性解决方案，单个数据库系统中，事务很好的保证了强一致性。但是，分布式环境下，这一直是个难题，不过，现在很多人都在做这方面的工作，著名的分布式治理框架。zookeeper，就是这个领域的最强开源产品。
3. 隔离性，基于原子性和一致性，因为事务是原子化，量子化的，所以，事务可以有多个原子包的形式并发执行，但是，每个事务互不干扰，但是，由于事务可能操作同一个资源，不同的事务为了保证隔离性，会有很多锁方案，当然，这是数据库的实现，他们怎么实现的，我们也不必深究
4. 持久性，当一个事务提交之后，数据库状态永久的发生了变化，这个事务只要提交了，哪怕提交后，宕机，他就确确实实的提交了，不会因为刚刚提交，而在那一刻宕机了而让提交不生效，只要事务提交，他就想洗不掉的纹身一样，永远的固化了，除非你摧毁了硬盘

结论

• 这四个特性，几乎所有的关系数据库都实现了，可能实现机制各不相同。如果让你去做一个数据库，你会考虑这些可能出现的问题吗？你该怎么设计，保证以上4条？也就是说，上面四个特性，是一种保证，但是，数据库底层如何保证的？锁是一个关键，当然。我们作为数据库的用户， 不需要知道复杂的锁怎么实现的，我们只需要理解上面说的4个特性，那是结论。