Redis版本的EOL策略与升级路径（刷到别划走）

        各位看官，刷到就点进来，大数据已经抓到你喽～😊

前言

        在软件行业做服务端开发的我们，多多少少都会接触到Redis，用它来缓存数据、实现分布式锁等，相关八股文烂熟于心，但是往往会忽略具体的版本维护情况以及升级路径。有网友可能会说：又不是不能用！代码能跑就行！管它啥版本，管那么多干嘛，谁会关心是不是需要升级！😂

开个玩笑，咳咳～ 保持严肃，咱们回归正题：

Redis的EOF（End-of-life）计划

End-of-life 直译为“生命的终结”，此处我们可以简单理解为“终止维护”。对于Redis企业版软件6.2及其之后的版本，每个大版本会在随后的一个大版本正式发布之后的24个月左右以后终止维护。“长难句”可能比较绕，不好理解，举个例子：Redis版本6.2是在2021年8月发布，之后的一个大版本6.4是在2023年2月发布，那么6.2版本的EOF日期是2025年2月28日，就是版本6.4正式发布之后的24个月左右。处于维护期的版本，按月度发布小版本的形式进行维护。所以，说人话就是：Redis的EOL策略实际就是可以给到大家24个月的提前量，让大家在这段时间内，视情况做好准备，按需升级到当前最新可用的版本。

Redis版本升级路径

打绿色小勾勾的版本，是能直接从当前版本升级过来的版本。

打红色叉叉的版本，是不能直接从当前版本升级的，要先升级到一个支持的中间版本。

补充知识：Redis版本号的命名规则

我就不额外进行翻译了，相信刷到本篇文章的兄弟姐妹们，能坚持看到这的，绝对有这个实力看懂。

Redis uses a four-place numbering scheme to designate released versions of its products. The format is “Major1.Major2.Minor-Build”.

• Major sections of the version number represents fundamental changes and additions in capabilities to Redis Enterprise Software. The Major1 and Major2 part of the version number are incremented based on the size and scale of the changes in each release.
• The Minor section of the version number represents quality improvements, fixes to existing capabilities, and new capabilities which are typically minor, feature-flagged, or optional.
• Build number is incremented with any changes to the product. Build number is incremented with each build when any change is made to the binaries.

Redis Enterprise Software typically gets two major releases every year but the product shipping cycles may vary. Maintenance releases, typically available on the last minor release of the current major1.major2 release are typically made available on a monthly cadence, although cycles may vary.

资料来源官网：Redis Enterprise Software product lifecycle | Docs

别跑，都看到这里了，点个赞在走！

欢迎评论区留言讨论～