《Redis设计与实现》笔记<4-其他独立功能>

《Redis设计与实现》笔记<4-其他独立功能>

5 2019-04-15 14:43:14

## 发布订阅
Redis的发布订阅功能可以实现一个简单的消息队列。
Redis客户端可以通过命令`SUBSCRIBE`、`PSUBSCRIBE`等命令实现订阅频道，成为该消息队列的消费者，在Redis中对该频道建立或添加一个链表保存该客户端节点。其中`SUBSCRIBE`是直接添加客户端到对应的频道链表中，而`PSUBSCRIBE`是添加到pattern链表中，在产生消息时通过正则匹配确认是否是消费者。
当订阅该频道的客户端执行`PUBLISH`命令，会在频道中产生消息，发送给所有订阅该频道的消费者。

## 事务
`MULTI`命令会启用该客户端的事务队列，后续该客户端的合法命令都会入队列但不执行。当执行`EXEC`命令时，服务器执行该客户端队列的所有已入队命令，中途不会切换处理其他客户端命令，保证事务的原子性。
事务中任何一个命令执行失败，不会影响其前后命令的执行，不会引起事务回滚。
如果客户端有执行`WATCH`命令监视一些key，那么在`EXEC`命令执行前会检查其监视的key在`WATCH`期间是否被其他客户端修改过。一旦任何key被修改过，可认为事务不再安全，整个事务将不会执行。
Redis事务的ACID：
- `原子性`：命令执行失败不会引起事务中断，其他命令仍然会执行。事务的前置条件有问题，那么事务不会执行。要么全执行，要么全不执行
- `一致性`：Redis在入队、执行时都检查了命令，且故障时可通过RDB或AOF文件恢复，数据库中不会保存错误、不合法的数据
- `隔离性`：Redis是单线程处理事件的，在事务执行期间不会中断事务去执行其他客户端的命令，保证事务之间是隔离的
- `耐久性`：Redis基本没提供相应的保证

---
**为什么 Redis 不支持回滚（roll back）**
如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点：

- Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
- 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 `INCR key` 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 `INCR key` ， 回滚是没有办法处理这些情况的。

鉴于没有任何机制能避免程序员自己造成的错误， 并且这类错误通常不会在生产环境中出现， 所以 Redis 选择了更简单、更快速的无回滚方式来处理事务。

## Lua脚本
Redis服务器给Lua脚本预留了一个伪客户端，Lua脚本的命令会在服务器内置的Lua环境中执行。
其中Lua脚本通过`redis.call`或`redis.pcall`调用Redis命令时，Lua环境将命令发送给伪客户端，由伪客户端请求Redis服务端，执行结果也是通过伪客户端返回给Lua环境，最后返回脚本调用方。
Lua脚本及SHA1都会保存在Redis服务器的lua_scripts字典中，在数据同步时也会发送给从服务器。

## Bit数组
结论：Redis使用的BIT相关命令效率非常高，大多数直接使用C语言内置位操作实现，其中`BITCOUNT`命令使用了variable-precision SWAR算法，比直接遍历每个bit位快32倍，效率仍然非常高。

## 慢查询日志
`SLOWLOG GET`命令可以获取慢查询日志，慢查询日志在Redis服务器中以链表结构保存，因此应该也可以被故障恢复。
日志结构说明：
```shell
1) 1) (integer) 0	# id
   2) (integer) 1553501216	# timestamp
   3) (integer) 84342	# cost millis
   4) 1) "PSYNC"	# command and args
      2) "?"
      3) "-1"
```

## 参考资料
[事务（transaction） — Redis 命令参考](http://redisdoc.com/topic/transaction.html)