问题描述
由于电源跳闸，导致4台物理服务器宕机，共影响25台虚拟机。其中一台虚拟机为我司的redis服务器，且该缓存服务器为单点。
其中商品中心的价格、商品相关的数据均存放在这台缓存服务器中。
然后就悲剧了4个小时,一大半的交易系统都受到影响.
那么问题来了?
- 这么重要的基础系统为什么会是
单点? - 为什么
redis宕机后需要4个小时来解决问题?
胁迫"升级"是不是可行?
历史债带来的问题,公司远古时代,这台redis是作为缓存服务器的,大家随便用,也没有做主从.
后来基础整体框架升级了,缓存采用codis了,然后公司3/4的服务升级了,但是剩下1/4的人还是用的远古redis服务器.
业务繁忙我就不升级,你怎么办吧?
然后就是喜闻乐见的撕逼环节了,甚至让业务写保证书,挂了自己负责.
最后黑天鹅发生了,单点服务事发了.
其实运维逻辑上可以对原有的单点进行高可用转化,但是业务不就是更加没有动力升级了吗?
然后进入两难地步, 运维和业务顶死了.
胁迫升级失败,最后大家抱在一起死了.
架构的合理性
商品数据预热需要3个小时.
另外一个坑,商品的预热的逻辑相当复杂,redis中不是缓存数据,而是持久化数据.
而且还需要大量计算才能推进缓存.这个也是架构规范中所不允许的.
结果
too busy.jpg
网友评论