为什么在 Redis 实现 Lua 脚本事务？

在刚过去的几个月中，我一直在构思并尝试在 redis 中实现 lua 脚本的事务功能。没有多少人理解我的想法，所以我将通过一些历史为大家做下解释。

MySQL 与 Postgres

在 1998-2003 年间，如果你想运行一个正规的数据库驱动的网站/服务，但又没有足够的资金购买微软或 Oracle 的数据库，你可以选择 MySQL 或 Postgres 。很多人都选择了 MySQL，因为它速度较快——主要是因为 MyISAM 存储引擎没有提供事务功能以此来换取性能，但速度确实很快。另一些人转向 Postgres，因为虽然在相同硬件上其性能明显低于 MySQL，但 Postgres 不会丢失数据（说实话，MySQL 数据丢失的情况非常少见，但丢了可不是闹着玩的）。

就这样凑合着过了很久；MySQL 将其默认的存储引擎从 MyISAM 过渡到了 InnoDB （其实很早就有了），这样它的存储引擎也得到了完整的事务支持和其他功能。与此同时，Postgres 也变快了，并添加了一个持续扩展的功能列表来使自己与众不同。现在对于 MySQL 与 Postgres 的选择只看个人的体验与偏好，除了有时业务需要或领导决定使用其他选择。

数据完整性

从很多方面来看，Redis 很像当初采用 InnoDB 前的 MySQL。而 Redis 采用了一种很合理的方式来保证数据完整性(复制，AOF 等)，并且从 Redis2.6 开始引入的 Lua 脚本在功能与易用性方面为 Redis 的成长提供了很大助力。

相对来说，Lua 脚本与其他数据库中的存储过程很相似，但脚本的执行有些许不同。在本文中最重要的一点就是一旦将脚本写入数据库，它会一直执行直到以下任一种情况出现：

1. 完成所有工作，所有写操作处理完成后脚本会自动退出。
2. 脚本运行时出错并中途退出，所有以前执行的写操作都已发生，但不会再有其他写操作。
3. Redis 通过 SHUTDOWN NOSAVE 关闭时(不保存)。
4. 你附加了调试器来“使”脚本完成 #1 与 #2 (或其他手段来保证不会丢失数据)。

对于使用数据库开发软件的人，我想你也认同只有情景 #1 是最理想的。情景 #2，#3，#4 都会导致数据异常（#2 与 #4）和/或数据丢失（#3 和 #4）。如果你很重视数据，你应该尽可能地阻止数据异常与丢失。这不是哲学，而是工作(This is not philosophy, this is doing your job)。但很遗憾目前的 Redis 也帮不了你多少。所以我决定改变这种情况。

实现 Lua 脚本事务

我尝试解决上面列表中的 #2，#3，#4 问题，最终像下面这样：

脚本完成所有的工作，处理完写操作后正常退出

脚本执行过程中遇到错误退出，不更改任何数据（所有写操作都回滚）

无论有没有写入数据，都不会有数据丢失。这应该是所有的数据库都希望做到的，我打算把这个加到 Redis 中，因为我们都希望 Redis有 这个功能。

目前的 pull request 只是一个概念性的证明。也就是说，为了避免数据丢失，你要么 a） 显式使用事务的变体运行脚本，要么 b） 强制所有 Lua 脚本调用带配置选项的事务语义。

文章转载自 开源中国社区 [http://www.oschina.net]