[分布式]事务处理的常见方法

欢迎关注个人微信公众号：pengjun0308123，最实在的干货分享。

处理事务的常见方法有排队法、排他锁、读写锁、MVCC等方式。

排队法

        事务处理中最重要也是最简单的方案是排队法，单线程地处理一堆数据。

在Redis中，如果数据全部在内存中，那么单线程处理所有Put、Get操作效率最高。原因在于多线程的本质是CPU模拟多个线程，这种模拟是以上下文切换为代价，这种上下文切换是需要额外开销的，而对于内存的数据库来说，没有上下文切换时效率最高。因此，单个CPU绑定一块内存的数据，针对这块数据做多次读写操作时都是在单个CPU上完成的，单线程处理方式在内存的情况是效率是最优的。

        那么什么时候事务需要用到多线程呢？这个问题的本质取决于下层所使用的存储，如果是内存操作，则可以动态地申请和销毁

内存块；而磁盘的IOPS很低，但吞吐量很高。

        如果一个场景涉及多次读写操作，单线程可以很高的效率对于内存进行读写操作；但是，由于磁盘的IOPS仅为内存的几千分之

一，如果依旧用操作内存的方式操作磁盘，那系统的整体性能将会很低，这意味着必须将大量的读写操作聚合成一个Batch后再提交

时才能达到较好的性能。而将大量请求攒到一起的方式一是异步，也就是请求本身和线程不绑定，线程可以不Block（本质来说还是

一种多线程的方式），处理完一个线程后再处理其他线程。这种做法的核心是将大量不同的请求提交到一个Buffer中，再由该Buffer

统一读取或者写入磁盘，从而提高效率。在慢速设备中，多线程或异步非常常见，在设计系统时，面对磁盘、网络、SSD等慢速设

备必须考虑使用多线程。

排它锁

        有些场景不适合用单线程操作，可以利用排他锁的方式来快速隔离并发读写事务。

        若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。

读写锁

        数据库中有一些事务单元是共享的，如果是一个只读的事务，例如只对数据进行查询操作，在该过程中数据一定不被修改，因此多个查询操作可以并行执行，因此一种针对读读场景的优化自然而然产生——读写锁。读写锁的核心是在多次读的操作中，同时允许多个读者来访问共享资源，提高并发性。

MVCC

        在最初的数据库事务实现中是不存在MVCC的，它是Oracle在八十年代新加的功能，本质是Copy On Write，也就是每次写都是以重新开始一个新的版本的方式写入数据，因此，数据库中也就包含了之前的所有版本。在数据读的过程中，先申请一个版本号，如果该版本号小于正在写入的版本号，则数据一定可以查询到，无需等到新版本完全写完即可返回查询结果。这种方式可以在读读不阻塞的前提下，实现读写/写读不阻塞，尽可能保证所有的读操作并行，而写操作串行。