更高的并发：改进PostgreSQL锁机制

在PostgreSQL中，借助于并发性的改进，通过减少锁及加速执行得到若干令人满意的特性。

一般推荐的做法是：在解决锁问题之前，无论如何先要检查出在你的PostgreSQL数据库服务器上正在运行的是什么，这非常有必要。我建议参考pg_stat_statements并仔细地检查系统瓶颈（bottleneck）。下面是给出的是其运行机制：

改进SELECT FOR UPDATE语句

假设两人同时试图修改数据库中同一行的内容，每个用户会首先选择（SELECT）一行来检查它的内容，然后开始更新。令人讨厌的事情是：这两个用户很可能会找到原来的行并且覆盖彼此做的改变。这是一个经典的竞态事件。

在现实生活中，这样会导致恶劣的后果：例如两个人也许会预定了同一架飞机的同一个航班；或者取款时取出的钱可能会比帐户中实际的数额更多。这显然不是我们想要的。

再拿前面的航班机票预定为例，假设有人想要预定飞机的某一座位：

SELECT ...  FROM table  WHERE class = 'economy'  AND empty = true  LIMIT 1  FOR UPDATE

现在的麻烦是：如果另外一个人也试图抢占一个座位，他会发现该座位已经被第一个人选择。但是，这一行是被锁定的。第二个人的SELECT FOR UPDATE操作必须等到第一个人的事务处理完成。值得提醒的是，乘客可能非常乐意接受该航班上的其它任意座位，所以没有必要等待某个特定的座位。

PostgreSQL 9.5将会解决这一问题。下面是一种新的读取行的方式：

SELECT ...  FROM table  WHERE class = 'economy'  AND empty = true  LIMIT 1  FOR UPDATE SKIP LOCKED

这里的巧妙之处在于PostgreSQL将会简单地忽略被锁定的行，并返回一个没有被别人锁定的行。这样是非常有意义的，因为100个同时在查看一个免费座位的用户会得到100个不同的行。这样的结果是你没有死守一个CPU，而是巧妙地横向扩展了系统中的所有CPU。由于冲突不再发生，没有人必须等其他人。

SELECT FOR SHARE

还有一种可以使PostgreSQL提供更高并发的方法。看下面的例子：

SELECT *  FROM account AS a, currency AS c  WHERE a.currency = c.id  AND a.account = 4711  FOR UPDATE

在这个例子中，某人想查看他的银行账户。现在主要的问题是：哪些行是被锁定的？答案是：account和currency。仅仅因为一个人想从ATM中取钱而锁定整个currency表显然并不是个好办法，而应该让很多人可以同时取钱，在这一问题上，PostgreSQL r的解决方法是提前告知需要更新哪张表。

方法很简单：

FOR UPDATE OF account FOR SHARE OF currency

通过告诉PostgreSQL我们要做的事情，PostgreSQL数据库会在currency表上使用一个无害的锁。这样大部分人可以同时查看相同的currency而无需相互锁定，同时又保证了account表的安全。

并发就是一切

请记住：如果你只有单个CPU，并发将会是问题。因此，多个CPU能够同时进行资源共享在某种程上来讲是很有必要的。

原文链接：More Concurrency: Improved Locking In PostgreSQL（译者/牛亚真 审校/朱正贵 责编/仲浩）

译者简介：牛亚真，中科院计算机信息处理专业硕士研究生，关注大数据技术和数据挖掘方向。

本文为ImapBox编译整理，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)