4次优化，我把 Redis 性能 “压榨” 到极致！

我就是我 2023-07-17 06:20 1阅读 0赞

公众号后台回复“**面试**”，获取精品学习资料

![format_png][]

扫描下方海报了解**专栏详情**

![format_png 1][]

![format_png 2][]

本文来源：阿飞的博客

**《Java工程师面试突击（第3季）》重磅升级，由原来的70讲增至160讲，内容扩充一倍多，升级部分内容请参见文末**

我们有个这样的需求：每天每一个抢购商品只能买一次，并且全场抢购商品总购买次数不允许超过5次。

那么，整个商品限购的流程大概如下图所示：![format_png 3][]

那么，在每次购买成功商品成功后，发送的MQ大概是这样的（假设当前这笔订单有两件抢购商品）：

[{
        "orderId": "2020020622000001",
        "orderTime": "1581001673012",
        "productId": "599055114591",
        "userId": "860000000000001",
        "merchantCode": "A045"
    }, {
        "orderId": "2020020622000001",
        "orderTime": "1581001673012",
        "productId": "599055114592",
        "userId": "860000000000001",
        "merchantCode": "A045"
    }]

这条消息表示860000000000001这个用户在1581001673012这个时间点（北京时间为2020/02/06 23:07:53）在A045这个商户分别购买了商品ID为599055114591和599055114592两样商品。

那么，当消费这条信息后，更新频控的几条关键Redis命令如下（上面的需求不是重点，优化下面5条命令才是本文的重点）：

命令1：hset mall:sale:freq:ctrl:860000000000001 599055114591 1（hash结构，field表示购买的商品ID，value表示购买次数）
    命令2：hset mall:sale:freq:ctrl:860000000000001 599055114592 2
    命令3：expire mall:sale:freq:ctrl:860000000000001 3127（设置过期时间）
    命令4：set mall:total:freq:ctrl:860000000000001 3
    命令5：expire mall:total:freq:ctrl:860000000000001 3127（设置过期时间）

我们首先了解一下执行一条Redis命令耗时由哪几部分组成：

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

如下图所示：![format_png 4][]

上面的业务总计涉及5条Redis命令，每条命令都需要经过这些步骤，可想而知性能真的弱爆了（可能整个执行过程还不需要10ms，但还是弱爆了）。

*  **第1次优化**

第一次优化非常简单，稍微有点经验就能看出来，利用hmset命令将两条hmset命令合二为一，优化后的Redis命令如下：

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

*  **第2次优化**

第二次优化将set和expire命令合二为一，这个一般对Redis有点了解的也知道如何优化：

hmset mall:sale:freq:ctrl:860000000000001 599055114591 1 599055114592 2
    expire mall:sale:freq:ctrl:860000000000001 3127
    setex mall:total:freq:ctrl:860000000000001 3127 3

*  **第3次优化**

第3次优化需要借助pipeline，简直就是Redis优化的一大杀器。

不过，需要注意的是在**RedisCluster中使用pipeline时必须满足pipeline打包的所有命令key在RedisCluster的同一个slot上**。

如果打包命令的key不在同一个slot上，就会报错。所以我们需要分两批打包：

-- 这两条命令的key都是一样的，肯定在同一个slot上
    pipeline(
    hmset mall:sale:freq:ctrl:860000000000001 599055114591 1 599055114592 2
    expire mall:sale:freq:ctrl:860000000000001 3127
    )
    -- mall:total:freq:ctrl:860000000000001和mall:sale:freq:ctrl:860000000000001两条命令不在同一个slot上，所以需要单独执行下面这条命令
    setex mall:total:freq:ctrl:860000000000001 3127 3

经过第3次的优化后，这些命令还是需要2次网络交互。较劲的我还是不甘心，想要将其优化到只需要一次网络交互即可，有没有办法？

当然有！

*  **第4次优化**

这次优化利用了一个高级特性：**hashtag**

是啥子意思呢？我们知道，RedisCluster总计有16\*1024=16384个slot。那么执行一条Redis命令时，其key对应的是哪个slot呢？是利用这样一个计算公式得到的：**slot = CRC16(key)%16384**

示意图如下：![format_png 5][]

也就是说，默认情况下，key在哪个slot上，与key有关。那么，我们能否只**让key在哪个slot上与部分key有关**呢？

当然可以，这就是hashtag特性。用法非常简单，假设一个key是mall:sale:freq:ctrl:860000000000001，我们只需要用\{\}将key中我们需要的那部分包括起来即可。

例如，我们只想让其根据用户IMEI计算即可，那么key是这样的：mall:sale:freq:ctrl:\{860000000000001\}。只要key中有\{860000000000001\}这一部分，就一定落在同一个slot上。

所以，第四次优化以后的命令执行如下所示：

pipeline(
    hmset mall:sale:freq:ctrl:${860000000000001} 599055114591 1 599055114592 2
    expire mall:sale:freq:ctrl:${860000000000001} 3127
    setex mall:total:freq:ctrl:${860000000000001} 3127 3
    )

![format_png 6][]优化后，5条Redis命令压缩到3条Redis命令，并且3条Redis命令只需要发送一次，并且结果也一次就能全部返回。简直**完美！**！

*  **注意事项**

我们在使用hashtag特性时，一定要注意，**不能把key的离散性变得非常差**。

以本文为例，没有利用hashtag特性之前，key是这样的：mall:sale:freq:ctrl:860000000000001，很明显这种key由于与用户相关，所以离散性非常好。

而使用hashtag以后，key是这样的：mall:sale:freq:ctrl:\{860000000000001\}，这种key还是与用户相关，所以离散性依然非常好。

我们千万不要这样来使用hashtag特性，例如将key设置为：mall:\{sale:freq:ctrl\}:860000000000001。

这样的话，无论有多少个用户多少个key，其\{\}中的内容完全一样都是sale:freq:ctrl，也就是说，所有的key都会落在同一个slot上，导致整个Redis集群出现严重的倾斜问题。

**END**

《Java工程师面试突击第三季》加餐部分大纲：（注：1-66讲的大纲请扫描文末二维码，在课程详情页获取）

![format_png 7][]![format_png 8][]![format_png 9][]

**详细的课程内容，大家可以扫描下方二维码了解：**

![format_png 10][]

[format_png]: /images/20230528/2c27dc7afb5040bc927f6b6c5c4f52f2.png
[format_png 1]: /images/20230528/606e68335f674a15bd1117ed119429dd.png
[format_png 2]: /images/20230528/1d889f09b07d47659adcc7ed8a70b1d6.png
[format_png 3]: /images/20230528/a42a5caeb5eb4e9b8ca3f7b0e1f055c0.png
[format_png 4]: /images/20230528/e4dabe63cb234547a39deabc7edf5766.png
[format_png 5]: /images/20230528/eddb1f9b6d4249fcb80b534a523403fc.png
[format_png 6]: /images/20230528/ad03ca7879aa49788b2ae14683dec356.png
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy8xSjZJYkljUENMYkdwTXM1MGROUWh0Tms5VThRWDFaOUFJbUZVdlRSajVvN2ZMZlpKbDNzOXlwa2MyWW9QZHYyWmV4VEg2MG9pYTk3TjdpY2g2aWFSb01oUS82NDA?x-oss-process=image/format,png
[format_png 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy8xSjZJYkljUENMYkdwTXM1MGROUWh0Tms5VThRWDFaOVd2OFFuZXJaak5LSUtBaWJXaWNBYU5xbUh0cUIxV1hpYTRsMzhvZWtBQ3dTS1FENGsyQTlHUkQ1Zy82NDA?x-oss-process=image/format,png
[format_png 9]: /images/20230528/df0dd4d299f04214adf3329e4710de14.png
[format_png 10]: /images/20230528/5c1a475e07ec4c4aa1e347a3f8b17a90.png