Linux中间件之redis协议分析

redis 网络层

redis是采用单reactor的网络模型。

reactor网络模型，其组成是IO多路复用+非阻塞IO；IO职责是IO检测和IO操作；事件是异步事件处理流程，先注册事件，然后在事件循环中处理事件，注册事件的时候提供回调函数。

宏观的直接的理解：忽略其他流程，只关注数据包处理流程。

哪条管道先构成一个完整的数据包，谁先得到处理。

1. 一个数据包可能由多个读事件才能组装成。
2. 管道就是连接。
3. U型口相当于网络模型。

redis pipeline

redis pipeline 是一个客户端提供的机制，而不是服务端提供的。pipeline 不具备事务性。

pipeline模式主要针对阻塞IO，和异步处理很像。它的目的是节约网络传输时间。

redis 事务

事务是指用户定义一系列数据库操作，这些操作视为完整的逻辑处理工作单元，要么全部执行，要么全部不执行，是不可分割的工作单元。

MULTI 开启事务，事务执行过程中，单个命令是入队列操作，直到调用 EXEC 才会一起执行。

比如有三个请求R1、R2、R3，那么每个请求都有一个回应，这三个请求之间又有业务逻辑关联，即这三个命令是一个整体，不可分割，这就需要事务。

再比如redis中要给一个string类型的key的value做翻倍操作，首先需要get key得到value，再发送set key 2*value来翻倍，这个过程就需要完整的，过程中不能被其他进程/线程进行set key操作。

什么情况下探讨事务呢？是在并发连接的时候，如果只有一条连接，就不需要事务，因为没有其他连接会干扰数据。

事务执行

（1）MULTI。
开启事务。创建一个队列，将所需要执行的指令放入队列中，等提交队列后再一起执行。
begin / start transaction。
（2）EXEC。
提交事务。commit。
（3）DISCARD。
取消事务，在MULTI和EXEC直接执行DISCARD就会取消事务。rollback。
（4）WATCH。
检测 key 的变动，若在事务执行中，key 变动则取消事务；在事
务开启前调用，乐观锁实现（cas）;若被取消则事务返回 nil 。

事务将MULTI到EXEC之间作为一个整体。

下面是没有使用watch的事务执行：

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> get fly
QUEUED
127.0.0.1:6379(TX)> set fly 10
QUEUED
127.0.0.1:6379(TX)> exec
1) "1000"
2) OK
127.0.0.1:6379> get fly
"10"

使用watch，并且有其他的连接修改了数据时：

127.0.0.1:6379> watch fly
OK
127.0.0.1:6379> get fly
"10"
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set fly 20
QUEUED
127.0.0.1:6379(TX)> exec
(nil)

出现(nil)，事务执行失败。

应用

（1）事务实现zpop。

WATCH zset
element = ZRANGE zset 0 0
MULTI
ZREM zset element
EXEC

（2）事务实现 加倍操作。

WATCH score:10001
val = GET score:10001
MULTI
SET score:10001 val*2
EXEC

ACID特性分析

（1）A， 原子性。
事务是一个不可分割的工作单位，事务中的操作要么全部成功，要么全部失败。redis 不支持回滚；即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止。
（2）C， 一致性。
事务的前后，所有的数据都保持一个一致的状态，不能违反数据的一致性检测；这里的一致性是指预期的一致性而不是异常后的一致性；所以 redis 也不满足；这个争议很大：redis 能确保事务执行前后的数据的完整约束；但是并不满足业务功能上的一致性；比如转账功能，一个扣钱一个加钱；可能
出现扣钱执行错误，加钱执行正确，那么最终还是会加钱成功；系统凭空多了钱。

一致性有类型一致性和逻辑一致性。

127.0.0.1:6379> set fly 1000
OK
127.0.0.1:6379> type fly
string
127.0.0.1:6379> lpush fly 100 100
(error) WRONGTYPE Operation against a key holding the wrong kind of value

这个报错就是redis做了类型一致性检测。

（3）I ，隔离性。
各个事务之间互相影响的程度；redis 是单线程执行，天然具备隔离性。
（4）D， 持久性。
redis 只有在 aof 持久化策略的时候，并且需要在redis.conf 中 appendfsync=always 才具备持久性；实际项目中几乎不会使用 aof 持久化策略。

总结

1. redis事务执行过程中是使用的乐观锁，正常使用会通过lua脚本来执行。

2. redis的事务主要是在并发连接下确保多条指令作为整体一起执行，不被其他干扰

3. 事务通常来讲是一系列的数据库操作，这些操作视为一个完整的逻辑处理工作单元，要么都执行，要么都不执行。