数据库漫谈（四）----锁

今天来聊一下多PROCESS同时更新一条数据记录时处理方式。

我们先来给今天的问题拆成两个子问题：

1.  只有一台主数据库时多个处理（PROCESS）更新同一条记录。

2.  多主架构时不同的节点上的多个处理（PROCESS）更新同一条记录。

先说第一个问题，这个其实是一个常见的问题，解决方法也是基本相同的，就是给记录加锁，先拿到锁的处理先执行，完成后释放锁，后边的处理再拿锁。

但是具体的处理过程就很有讲究了，因为“锁”分为“悲观锁”和“乐观锁”。

什么是“悲观锁”（Pessimistic Lock）呢？

当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。

这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制【Pessimistic Concurrency Control，缩写“PCC”，又名“悲观锁”】。

悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。

因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。

之所以叫做悲观锁，是因为这是一种对数据的修改持有悲观态度的并发控制方式。总是假设最坏的情况，每次读取数据的时候都默认其他线程会更改数据，因此需要进行加锁操作，当其他线程想要访问数据时，都需要阻塞挂起。

那什么又是“乐观锁”（Optimistic Locking）呢？

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回给用户错误的信息，让用户决定如何去做。乐观锁适用于读操作多的场景，这样可以提高程序的吞吐量。

乐观锁机制采取了更加宽松的加锁机制。乐观锁是相对悲观锁而言，也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。

从上面的说明我们可以明白了，悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。而乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

在明白了上面针对一台主数据库时多个处理（PROCESS）更新同一条记录的处理方式之后，我们把问题再向深推进一下。

当一个系统的并发处理进一步提高，一台主数据库不足以满足要求的时候，就需要对数据库进行横向拓展了。

下面我们用例子说明一下解决这个问题的几个方向。

1.  数据库实例和存储分开，多个实例共用一个存储。

2.  数据库实例和存储不分开，每个数据库实例写自己的存储，然后进行实例间同步。

在第一个方向上做的最成功的就是ORACLE数据库的RAC架构。

ORACLE数据库的RAC架构引入了“内存融合”（Cache Fusion）的概念，简单来说就是在多个数据库实例之间搭建一个高速局域网，用几个特定的PROCESS同步各自的SGA。当然具体的实现方式要复杂得多，可以专门写几篇文章来详述了。

第二个方向上实现的比较好的有两个产品：ORACLE GoldenGate 和 Mysql的双主架构。

先说ORACLE GoldenGate。

GoldenGate最开始并不是ORACLE的产品，而是一个1995年成立在美国旧金山的专门开发计算机容错系统的公司，名字也是来源于旧金山著名的金门大桥。GoldenGate公司于2009年9 月被Oracle收购， 归入融合中间件（ Fusion Middleware ）产品线中，作为ORALCE数据库（或其他数据库）的容灾、复制的解决方案。

上面是从网上找来的介绍GoldenGate的yizhang简单的图片，大家可以先看一下，以后有机会的话我们再写一篇文章来专门聊一下。

然后我们来说一下Mysql的双主架构。

MySQL最早来源于MySQL AB公司前身的ISAM与mSQL项目， 2008年1月，MySQL AB公司被Sun公司以10亿美金收购。 2009年4月，Oracle公司以74亿美元收购Sun公司，自此MySQL数据库进入Oracle时代。
MySQL最成功的地方是SQL实现层和存储引擎分开以及Binlog。

SQL实现层和存储引擎分开的设计使得Mysql可以兼容各种其他公司开发的存储引擎，可以满足各种场景的不同需要。

而Binlog以及传递和复制机制则可以使Mysql设计出各种各样的高可用架构。

上面就是一个最简单的Mysql主从架构。通过这个图片我们可以了解Binlog是如何工作的。

现在我们上面的主从位置颠倒过来再做一遍，即两ge数据库互为主从，就实现了最简单的双主架构。

当然上面的双主架构在自增主键和修改同一记录的更新上还需要一些Application和数据库设计上的支持。具体如何实现我也不是这方面的专家，大家可以多上网学习一下，呵呵。

本文引用了日常更新针对锁的说明和图片，特此感谢！
https://www.jianshu.com/p/d2ac26ca6525