自己原文公众号： https://mp.weixin.qq.com/s/WB83b6o_FoUtb-KJFBhoqQ
有时候发现开发其实分不清锁和死锁、以及怎么会造成这种。为了防止锁把架构变得复杂，但是其实没什么用。比如我账户有10元钱，我需要买一个5元的东西还要买一个6元的东西。结果是我最多只能买一样。这是数学问题而不是数据库问题。不少时候开发同学怕锁，结果设计了异步或者缓存再或者你想不到的操作。比如拿到了请求，怕对数据库造成锁，进而导致压力，就走消息队列。（然并卵）其实不管你走十八般武艺的技术，最终11>10注定了你有一个失败。如果成功了，那就是呵呵了。其实锁不可怕，锁是防止你数据错乱、数据不一致。我们应该感谢锁的存在。
刚才说的是一个减法，如果是一个变更呢？数据库叫做A，有一个人想把一个商品的价格B改成2，同时另外一个人想把这个商品的价格B改成3.这就是锁了。一定是后面的覆盖了前面一个。如果前面的异步解决不了（注定是解决不了的），这个时候继续脑洞打开，说单体数据库太差了。我们上分布式数据库吧。这个时候数据库有A 变成了A1 A2 A3.结果就是在A1上的B是2 在A2上的B是3. （我们这里先不谈冲突检测）。那这个结果是预期想要的吗？显然不是。分布式数据库是怎么解决的了？那就是所有的写要先进行排队确定先后顺序，然后比如A2 A3上的请求先到A1上集中，都在A1上集中完了，在导A2 A3上去重放。（也许不是全部的分布式数据库都这样，但是至少有的分布式数据库是这样）所以最终只要是要求一致性还是逃不过的。除非你不要一致性。
在一致性的要求前，如果单机还弄明白锁和性能压力这些问题，那遇到分布式的检测，就更加复杂了。就像初中数学都不几个的话，高中的也一样不及格。当你有一块手表时候你知道几点，当有几块手表时候你不知道几点。
