Redis版本升级实践

字数 3100阅读 729评论 0赞 0

内容摘要：

Redis版本升级实践：认知对齐、升级收益评估、自身能力评估和建设、持续升级经过、稳定性话题。

当前摘要为AI生成

Redis版本选择和升级“很麻烦”，一旦决策不当可能会引起较大的稳定性问题。最近稳定性话题很热，我也来蹭个热度，聊一聊Redis版本升级的“最佳实践”。

虽然本文聊的是Redis版本升级，但是我觉得可能对其他产品升级也有借鉴意义。

#### 一、认知对齐

一般认为，数据库产品求稳不求新，我想原因大概2点：
* 可能费力不讨好：新版本不稳定、没拿到什么收益。
* 升级困难：不丢数据、平滑迁移、迁移效率高。
我觉得上述也不无道理，如果没有好的收益且可能产生稳定性问题，最后真可能费力不讨好。但是我又不完全同意，如果有足够的收益且相关能力能对新版本有足够把握是一定要升级的，下图是一份Redis版本调查问卷(6.0 release是在2020年4月)
![](/home/attachment/202312/20/923323_170305910032734.png)

#### 二、升级收益评估

我会持续关注release note、阅读新版本代码变化、github社区相关issue，从功能、成本、性能、稳定性、兼容性5个方面进行评估：

##### 1. 功能 ：
* 新的数据结构：例如Redis 3.2的GEO、Redis 5.0的stream等
* 新的命令：各类数据结构一些新的命令(例如Redis 7.0增加了很多用户侧命令)
* 新的架构: redis cluster、RDB-AOF、多线程、muti-part AOF、ARM
* 特殊的功能：function、module、向量等
##### 2. 成本：最简单的方法用标准数据集进行测试
* 基础数据结构：例如Redis 3.2拆分了SDS、Redis 4.0简化了复杂数据结构中的robj、Redis 7.0 dict相关优化
* 压缩数据结果：ziplist、quicklist、intset是否有新的参数或者优化
* 数据清理优化：Redis 6.0 过期键过期优化、内存碎片整理。
##### 3. 性能：
* 使用redis-benchmark、memtier_benchmark进行压测绘图对比。
* 使用自定义压测工具(公司标准数据集)进行压测绘图。
##### 4. 稳定性
* 难题是否解决：Redis 4.0异步删除、Redis 6.2解决了非渐进式逐出、rehash。
* 一般经验是7-8个小版本后可以考虑使用，Redis整体还是比较稳定
##### 5. 兼容性
* 持久化文件格式变化：AOF基本不变，RDB经常变(如果周边平台或者工具与RDB有关需要关注)
* 命令兼容性：上下兼容性。
* 配置兼容性：比如之前遇到save配置的坑[Redis 6.2&7 save配置的一个坑]

#### 三、自身能力评估和建设

##### 1. 配置兼容
(1) 兼容新的配置选项：平台应该具备版本配置模版功能，每个版本有自己的配置模版：
![](/home/attachment/202312/20/923323_170305913784962.png)

(2) 老配置：需要测试老配置在新版本是否还生效(除了测试，跟踪release note和读源码也是一种方式)
例如不配置save配置，在Redis 6.2之前是等同于空、但是Redis 6.2后会使用默认配置实现auto save，那就是灾难性的。
    不配置save = save 3600 1 300 100 60 10000
详见：[Redis 6.2&7 save配置的一个坑]
##### 2.监控兼容
(1) 新的选项：例如Redis 7.0中有个P50 P99耗时统计、memory相关指标越来越全，监控平台能持续兼容。
(2) 改名字：例如Redis 5.0中Redis 4.0关于最大客户端缓冲区的名字是不同的。
4.0
    client_longest_output_list  
client_biggest_input_buf
5.0
    client_recent_max_input_buffer  
client_recent_max_output_buffer
##### 3. 升级工具完备
    有关升级工具本文不详细展开，后续单独写一篇
(1) 兼容性
RDB格式从Redis 4.0(version 8)到Redis 7.2(version 11)一共经历了4个版本的变化。如果你的Redis运维体系和RDB有关，相关工具必须具备兼容性，例如我们在redis-migrate-tool上持续迭代，除了新加的各种功能以外，完全兼容了RDB的各个版本，为我们做集群升级做了非常必要的准备。
(2) 效率
平滑升级(业务无感知、效率高、数据无损)相关工具或者平台
(3) 可回滚
工具和平台具备回滚能力：一旦升级失败可立刻回滚。
#### 四、持续升级
经过收益评估、性能测试、功能测试、稳定性测试、平台建设、工具建设后，等到Redis的小版本基本稳定(经常观测release note和github issue)，我们可以开始升级工作，一般我会分为四个阶段。
##### 1. 线上引流测试：观察1-2周
使用类似tcpcopy的工具将一部分线上流量引入到新版本，观察收益、稳定性、性能、兼容性等。
##### 2. 内存系统测试：观察1-2周
组内会有一些平台组件用到Redis：**Eating your own dog food**
##### 3. 业务开发测试集群：观察2-3周
业务测试或者开发用的集群：此时主要关注业务侧耗时变化、性能变化是否符合预期。
##### 4.线上典型场景：：观察3-4周
* 成本收益类：例如Redis 7.0在小hash、set、zset上是有成本优化的。
* 稳定性收益类：例如Redis 6.2解决了rehash、大批量evict带来的稳定性问题
* 功能性：例如业务用新的命令、新的数据结构，新的module（例如json）
##### 5.持续升级：时间和规模有关
* 譬如业务主动要求。
* 譬如业务扩容。
* 譬如机房整体搬迁
### 五、总结
* Redis稳定性：Redis整体还是非常稳定的，也不用过于担忧(遵循7-8个小版本以后)。
* Redis版本升级不难也难：升级准备是否充足、升级计划是否合理，只要安排合理可以慢慢那结果。
* 我经历过3次Redis升级：
  * Redis 3->4：2019年开始，耗时2年升级完100万实例
  * Redis 4->6：2021年开始，耗时2年升级完160万实例
  * Redis 6->7：预期也需要两年
  * 为什么没升级Redis 6.2，看起来稳定性收益很大 ？？
![](/home/attachment/202312/20/923323_170305916890910.png)

### 六、多说两句稳定性
最近稳定性话题比较热，我也有一点简单感悟分享下：
* 稳定性不是喊口号，是对线上的敬畏，是每天扎实的工作和思考。
* 稳定性和上新不是对立的，只要规划合理，两者皆可得。
* 你的上下游都是“不可靠的”：要多琢磨不可靠怎么解决。
* 所有变更必须是：灰度、可观测、可回滚的。

附图：
![](/home/attachment/202312/20/923323_170305919232393.png)

Redis

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

Redis版本升级实践

添加新评论0 条评论

文章目录展开目录

作者其他文章

相关文章

相关问题

相关资料