你觉得ACID别扭吗？

不知道大家在看ACID定义时，有没有感觉疑惑或者别扭。一个疑惑是：AID的定义是很清晰的，看了就能明白是什么意思，但是C的定义似乎不太清晰；另一个疑惑是：难道原子性隔离性持久性不是为了满足一致性吗？他们好像并不是正交的，放在一起合适吗？

那C的概念是什么呢，是对数据的一组特定约束必须始终成立。至于这个约束是什么，是由应用程序定义的，而不是数据库定义的。比如说在会计系统中，所有账户整体上必须借贷相抵，如果事务开始前借贷相抵，那事务后借贷也要相抵，这样才满足一致性。再比如你的系统记录了订单明细金额和订单总金额，那对你这个系统来说，一致性就是订单总金额要和所有订单明细金额之和保持一致

所以首先要明确的一点是，一致性是应用程序的属性而不是数据库的属性，那ACID是不是不应该放在一起？ 大家都是技术人，比较严谨，我这样说大家可能不太愿意相信，毕竟ACID的叫法已经形成习惯。所以我引用了几个名人对ACID的评论：

加州大学伯克利分校的Joe Hellerstein(乔·海勒斯坦)教授，在他的论文中提到，ACID中的"C"是被扔进去凑缩写单词的

《数据密集型应用系统设计》这本书里提到： 原子性，隔离性和持久性是数据库的属性，而一致性（在ACID意义上）是应用程序的属性。应用可以依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库

(ps：这本书豆瓣评分9.7，神书，投入回报比很高，建议大家都去看一看)

周志明在他的《凤凰架构》里提到： 我自己对这种已经形成习惯的“ACID”的提法是不太认同的，因为这四种特性并不正交，A、I、D 是手段，C 是目的，完全是为了拼凑个单词缩写才弄到一块去，误导的弊端已经超过了易于传播的好处

(ps：《凤凰架构》因为是2021年出版的，比较新，所以知名度还不是很高，但是大家肯定都听说过《深入理解Java虚拟机》这本书，也是周志明写的，凤凰架构豆瓣评分9.3，这是周志明第4本评分9分以上的书了，还是很厉害的，这本书也非常值得一看)

所以我们可以得出两个结论：

C并不是数据库的属性，是应用程序的属性

应用程序可以依赖于AID来保证C，但是只有AID并不能保证C，如果你刻意地向数据库写入不一致的数据，数据库并没有什么办法阻止你制造出不一致的数据