并发冲突似乎是个大家都在谈，但是很少有人真的去当回事的东西。 典型的如 innodb 的 mvcc 就是用乐观锁的方式去处理并发冲突，你可以通过设置不同的隔离级别让 innodb 在检测到并发修改的时候选择不同的处理方式。 在业务开发中，当用户并发修改某条数据的时候，我们也可以通过类似的方式去防止或协调冲突。 那么问题来了，在实际工作你们真的去这么做了吗？如果没有这样实践的话是啥原因呢？就我个人的经验而言，好像很少有人真的这么干。
我的实际工作中，只要可能存在并发冲突的时候，在数据库层面我几乎都会使用乐观锁处理，但几乎很少使用悲观锁。 但是，但是，但是， 在数据库操作之前，我一般会使用其他手段，前置处理并发，比如使用 redis 做分布式锁、比如使用消息队列消费再写数据库等。 数据库层面使用乐观所或者悲观锁是我的最后一道防线，前置的分布式、内存锁、队列等都是为了从宏观上更高效的防止并发冲突。 一个不恰当的例子： 宇宙飞船是密封的，但是更保险的是穿上宇航服，因为有可能宇宙飞船被撞出一个洞，也可能宇航员要出仓执行任务，虽然有各种外层防御措施，但宇航服是最后一道防线。
