不支持事务

我们继续上一章节的内容，大家应该记得我们 Lua 代码中是如何完成 ngx_postgres 模块调用的。我们把它简单改造一下，让它更接近真实代码。

  1.     local json = require("cjson")
  3.     function db_exec(sql_str)
  4.         local res = ngx.location.capture(
  5.             '/postgres',
  6.             { args = {sql = sql_str } }
  7.         )
  9.         local status = res.status
  10.         local body   = json.decode(res.body)
  12.         if status == 200 then
  13.             status = true
  14.         else
  15.             status = false
  16.         end
  17.         return status, body
  18.     end
  20.     -- 转账操作，对 ID=100 的用户加 10，同时对 ID=200 的用户减 10。
  21. ?    local status
  22. ?    status = db_exec("BEGIN")
  23. ?    if status then
  24. ?        db_exec("ROLLBACK")
  25. ?    end
  26. ?
  27. ?    status = db_exec("UPDATE ACCOUNT SET MONEY=MONEY+10  WHERE ID = 100")
  28. ?    if status then
  29. ?        db_exec("ROLLBACK")
  30. ?    end
  31. ?
  32. ?    status = db_exec("UPDATE ACCOUNT SET MONEY=MONEY-10  WHERE ID = 200")
  33. ?    if status then
  34. ?        db_exec("ROLLBACK")
  35. ?    end
  36. ?
  37. ?    db_exec("COMMIT")

后面这部分有问题的代码，在没有并发的场景下使用，是不会有任何问题的。但是这段代码在高并发应用场景下，错误百出。你会发现最后执行结果完全摸不清楚。明明是个转账逻辑，一个收入，一直支出，最后却发现总收入比支出要大。如果这个错误发生在金融领域，那不知道要赔多少钱。

如果你能靠自己很快明白错误的原因，那么恭喜你！你对数据库连接，Nginx 机理都是比较清楚的。如果你想不明白，那就听我给你掰一掰这面的小知识。

数据库的事务成功执行，事务相关的所有操作是 必须执行在一条连接上 的。SQL 的执行情况类似这样：

  1. 连接：`BEGIN` -> `SQL(UPDATE、DELETE... ...)` -> `COMMIT`。

但如果你创建了两条连接，每条连接提交的 SQL 语句是下面这样：

  1. 连接1：`BEGIN` -> `SQL(UPDATE、DELETE... ...)`
  2. 连接2：`COMMIT`

这时就会出现连接 1 的内容没有被提交，行锁产生。连接 2 提交了一个空的 COMMIT。

说到这里你可能开始鄙视我了，谁疯了非要创建两条连接来这么用 SQL 啊。又麻烦，又不好看，貌似从来没听说过还有人在一次请求中创建多个数据库连接的，简直就是非人类嘛。

或许你不会主动、显式的创建多个连接，但是刚刚的示例代码，高并发下这个事务的每个 SQL 语句都可能落在不同的连接上。

为什么呢？这是因为通过 ngx.location.capture 跳转到 /postgres 后，Nginx 每次都会从连接池中挑选一条空闲连接，而当时哪条连接是空闲的，完全没法预估。所以上面的第二个例子，就这么静悄悄的发生了。如果你不了解 Nginx 的机理，那么它肯定会一直困扰你。为什么一会儿好，一会儿不好。

同样的道理，我们推理到 DrizzleNginxModule、RedisNginxModule、Redis2NginxModule，他们都是无法做到在两次连续请求落到同一个连接上的。

由于这个 Bug 藏得比较深，并且不太好讲解，所以我觉得生产中最好用 lua-resty-* 这类的库，更符合标准调用习惯，直接可以绕过这些坑。不要为了一点点的性能，牺牲了更大的蛋糕。看得见的，看不见的，都要了解用用，最后再做决定，肯定不吃亏。