高性能零售IT系统的建设07-通过一次重大危机感受Redis从使用到失智到理性的治理

介绍

       在2020年年初我接手的一座“屎山”里含有Redis框架和机制，它使用的是sentinel模式。其实sentinel模式并不是重点，按照我的经验，每天单店10万单也一样可以使用Redis Sentinel。只有到达新浪微博啦、头条啦这种大厂才有必要去架设redis cluster。但是当时我碰到了一个极端，那就是整体零售系统的底层框架内有redis，但实际业务代码对redis的使用率不足3%。

       所以我在一开始改造这座“屎山”时，就注意着各种零售业务场景有针对性的最大化的利用redis。要知道任何现有生产环境即：current product engineering上的更新是最困难的，因为你不可能：

1. 推翻式再造；
2. 为了性能、安全等非功能性需求而去影响核心零售日常经常业务需求的迭代；

       这需要高超的技巧、极大的耐心、极其科学严谨的基于数据的判断以及敏捷的思维。在之前我们的博客中我对这句话的描述体现在了好几个“微操”的实例中。

       但有一种情况，在这种情况下容不得我们慢嚼细咽的去仔细考虑，这种情况在每个业务大量暴发的单位都会存在。我们就经历过这么一个阶段。

       那是。。。在2021年12月左右的圣诞大促，流量直接比之前乘以了一个2。各位知道流量的概念，我在这个系列的第一篇中设计了6道防线，对着流量进行层层削峰是为了什么？因为流量的暴发是不可