故障问题带来的反思

问题描述

由于电源跳闸，导致4台物理服务器宕机，共影响25台虚拟机。其中一台虚拟机为我司的redis服务器，且该缓存服务器为单点。
其中商品中心的价格、商品相关的数据均存放在这台缓存服务器中。

然后就悲剧了4个小时,一大半的交易系统都受到影响.
那么问题来了?

• 这么重要的基础系统为什么会是单点?
• 为什么redis宕机后需要4个小时来解决问题?

胁迫"升级"是不是可行?

历史债带来的问题,公司远古时代,这台redis是作为缓存服务器的,大家随便用,也没有做主从.
后来基础整体框架升级了,缓存采用codis了,然后公司3/4的服务升级了,但是剩下1/4的人还是用的远古redis服务器.
业务繁忙我就不升级,你怎么办吧?

然后就是喜闻乐见的撕逼环节了,甚至让业务写保证书,挂了自己负责.
最后黑天鹅发生了,单点服务事发了.
其实运维逻辑上可以对原有的单点进行高可用转化,但是业务不就是更加没有动力升级了吗?
然后进入两难地步, 运维和业务顶死了.
胁迫升级失败,最后大家抱在一起死了.

架构的合理性

商品数据预热需要3个小时.

另外一个坑,商品的预热的逻辑相当复杂,redis中不是缓存数据,而是持久化数据.
而且还需要大量计算才能推进缓存.这个也是架构规范中所不允许的.

结果

too busy.jpg