Redis命令性能优化及事务使用过程

场景

`假设有这样一个使用场景，依次执行下面的5条命令
命令1：hset mall:sale:freq:ctrl:860000000000001 599055114591 1（hash结构，field表示购买的商品ID，value表示购买次数）
简单说明： mall:sale:freq:ctrl:860000000000001是一个hash表;599055114591表示key;1表示key对应的value
命令2：hset mall:sale:freq:ctrl:860000000000001 599055114592 2
命令3：expire mall:sale:freq:ctrl:860000000000001 3127（设置过时时间）
简单说明：给hash表mall:mall:sale:freq:ctrl:860000000000001设置过时时间
命令4：set mall:total:freq:ctrl:860000000000001 3
简单说明:set key vlaue
命令5：expire mall:total:freq:ctrl:860000000000001 3127（设置过时时间）
简单说明: set key 过时时间`

优化原因

执行一条命令 经历的过程

• 发送命令网络传输时间
• 命令在Redis服务端队列中等待的时间
• 命令执行的时间（Redis中的slowlog只是检测这一步骤的时间）
• 结果返回的Redis客户端的时间

`执行一条命令 就须要通过上面的过程，发送命令－〉命令排队－〉命令执行－〉返回结果
那么执行5条命令，可想而知，性能优化的空间仍是蛮大的，
下面我们来进行优化一下吧`

优化

第一次优化：利用hmset命令将两条hmset命令合二为一

`命令1和命令2 合二为一
hmset mall:sale:freq:ctrl:860000000000001 599055114591 1 599055114592 2
expire mall:sale:freq:ctrl:860000000000001 3127
set mall:total:freq:ctrl:860000000000001 3
expire mall:total:freq:ctrl:860000000000001 3127`

第二次优化：将set和expire命令合二为一

`将命令4和命令5合二为一
命令a： hmset mall:sale:freq:ctrl:860000000000001 599055114591 1 599055114592 2
命令b: expire mall:sale:freq:ctrl:860000000000001 3127
命令c: setex mall:total:freq:ctrl:860000000000001 3127 3`

第三次优化：使用pipeline

须要注意：RedisCluster中使用pipeline时必须知足pipeline打包的全部命令key在RedisCluster的同一个slot上

分析下是否在同一个slot上

slot原理简介

`Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每一个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪一个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每一个节点负责处理一部分哈希槽。
举个例子， 一个集群能够有三个哈希槽， 其中：
节点 A 负责处理 0 号至 5500 号哈希槽。
节点 B 负责处理 5501 号至 11000 号哈希槽。
节点 C 负责处理 11001 号至 16384 号哈希槽。
这种将哈希槽分布到不一样节点的作法使得用户能够很容易地向集群中添加或者删除节点。 好比说：
若是用户将新节点 D 添加到集群中， 那么集群只须要将节点 A 、B 、 C 中的某些槽移动到节点 D 就能够了。
与此相似， 若是用户要从集群中移除节点 A ， 那么集群只须要将节点 A 中的全部哈希槽移动到节点 B 和节点 C ， 而后再移除空白（不包含任何哈希槽）的节点 A 就能够了。
由于将一个哈希槽从一个节点移动到另外一个节点不会形成节点阻塞， 因此不管是添加新节点仍是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会形成集群下线。`

结论

`由此可知 命令a和命令b在同一个slot上，命令c在另一个slot上
因此命令a和命令b用pipline来处理`

如何使用pipline

• 先建立一个txt文件

`vim pipeline.txt
hmset mall:sale:freq:ctrl:860000000000001 599055114591 1 599055114592 2
expire mall:sale:freq:ctrl:860000000000001 3127`

• 格式化 使得 这个文本文件中每一行都必须以\r\n而不是\n结束

须要安装下dos2unix

a、brew install dos2unix

b、unix2dos pipeline.txt

• 命令执行

cat pipeline.txt | redis-cli --pipe

第四次优化 使用 高级特性：hashtag

由 CRC16(key) % 16384 来计算键 key 属于哪一个槽 可知，key决定了存储在哪一个slot上，那么使用hashtag可使得 知足部分key一致的全部key都存储在同一个slot上

好比

mall:sale:freq:ctrl:{860000000000001} 只要key中有{860000000000001}这一部分，就必定落在同一个slot上

**注意：使用hashtag特性 不能把key的离散性变得很是差 **

• 离散性好

mall:sale:freq:ctrl:{860000000000001} 这种key仍是与用户相关

• 离散性差

`mall:{sale:freq:ctrl}:860000000000001
全部的key都会落在同一个slot上，致使整个Redis集群出现严重的倾斜问题`

通过这4次优化 perfect ==> 5条Redis命令压缩到3条Redis命令，而且3条Redis命令只须要发送一次，而且结果也一次就能所有返回

pipline

• 未使用pipline

• 使用了pipline

• 性能对比

这是一组统计数据出来的数据，使用Pipeline执行速度比逐条执行要快，特别是客户端与服务端的网络延迟越大，性能体能越明显

性能测试代码

pipeline 实现 mdel

redis提供了mset、mget方法 但没有提供mdel方法 能够借助pipeline实现

将不一样类型的操做命令合并提交

原生批命令(mset, mget)与Pipeline对比

• 原生批命令是原子性，pipeline是非原子性

  (原子性概念:一个事务是一个不可分割的最小工做单位,要么都成功要么都失败。原子操做是指你的一个业务逻辑必须是不可拆分的. 处理一件事情要么都成功，要么都失败，原子不可拆分)

• 原生批命令一命令多个key, 但pipeline支持多命令（存在事务），非原子性
• 原生批命令是服务端实现，而pipeline须要服务端与客户端共同完成

使用pipeline组装的命令个数不能太多，否则数据量过大，增长客户端的等待时间，还可能形成网络阻塞，能够将大量命令的拆分多个小的pipeline命令完成

事务

• redsi事务

• discard事务

• 命令错误，语法不正确，致使事务不能正常结束

• 运行错误，语法正确，但类型错误，事务能够正常结束

• watch命令

`使用watch后， multi失效，事务失效
WATCH的机制是：
在事务EXEC命令执行时，Redis会检查被WATCH的key，
只有被WATCH的key从WATCH起始时至今没有发生过变动，EXEC才会被执行。
若是WATCH的key在WATCH命令到EXEC命令之间发生过变化，则EXEC命令会返回失败。`

源码地址

https://gitee.com/pingfanrenbiji/springboot-jedisCluster/blob/master/demo/src/main/java/com/example/pipline/PipelineTest.java

参考文档

`https://www.jianshu.com/p/884...
http://www.gxlcms.com/redis-3...
https://blog.csdn.net/huangba...
https://blog.csdn.net/w1lgy/a...
官方文档 ：
http://redisdoc.com/topic/clu...`

本文使用 mdnice 排版