运维和开发都掉入的Redis使用误区

事务性的操作和存放一些基础数据。

在关系型数据库的上面还有一套 MongoDB，因为 MongoDB 的文档型数据结构，让他们用起来很顺手，同时也可以支撑一定量的并发。

在大部分的情况下，一次大数据量的计算后结果可以重用但会出现细节数据的频繁更新，所以他们又在 MongoDB 上搭建了一层 Redis 的缓存。

这样就形成了 数据库→MongoDB→Redis三级的方式 ，方案本身先不评价不是本文重点，我们来看 Redis 这层的情况。

由于数据量巨大，所以需要 200GB 的 Redis，并且在真实的调用过程中，Redis 是请求量最大的点。 当然如果 Redis 有故障时，也会有备用方案，从后面的 MongoDB 和数据库中重新加载数据到 Redis，就是这么一套 简单的方案 上线了。

当这个系统刚开始运行的时候，一切都还安好，只是运维同学有点傻眼了， 200GB 的 Redis 单服务器去做，它的故障可能性太大了。 所以大家建议将它分片，没分不知道，一分吓一跳，各种类型用的太多了，特别是里面还有一些类似消息队列使用的场景。 由于开发同学对 Redis 使用的注意点关注不够，一味的滥用，一锤了事，所以让事情变的困难了。

有些侥幸不死的想法是会传染，这时的每个人都心存侥幸，懒惰心理，都想着：“这个应该没事，以后再说吧，先做个主从，挂了就起从”，这种侥幸也是对 Redis 的虚伪的信心，无知者无畏。

可惜事情往往就是怕什么来什么，在大家快乐的放肆使用时，系统中重要的节点 MongoDB 由于系统内核版本的 Bug，造成整个 MongoDB 集群挂了！（这里不多说 MongoDB 的事情，这也是一个好玩的哭器）。

当然，这个对天天与故障为朋友的运维同学来说并没什么，对整个系统来说问题也不大，因为大部分请求调用都是在最上层的 Redis 中完成的，只要做一定降级就行，等拉起了 MongoDB 集群后自然就会好了。

但此时可别忘了那个 Redis，是一个 200G 大的 Redis，更是带了个从机的 Redis 。 所以这时的 Redis 是绝对不能出任何问题的，一旦有故障，所有请求会立即全部打向最低层的关系型数据库，在如此大量的压力下，数据库瞬间就会瘫痪。

但是，怕什么来什么，还是出了状况：主从 Redis 之间的网络出现了一点小动荡，想想这么大的一个东西在主从同步，一旦网络动荡了一下下，会怎么样呢？

主从同步失败，同步失败，就直接开启全同步，于是 200GB 的 Redis 瞬间开始全同步，网卡瞬间打满。

为了保证 Redis 能够继续提供服务，运维同学直接关掉从机，主从同步不存在了，流量也恢复正常。不过，主从的备份架构变成了单机 Redis，心还是悬着的。

俗话说，福无双至，祸不单行。这 Redis 由于下层降级的原因并发操作量每秒增加到四万多，AOF 和 RDB 库明显扛不住。 同样为了保证能持续地提供服务，运维同学也关掉了 AOF 和 RDB 的数据持久化，连最后的保护也没有了（其实这个保护本来也没用，200GB 的 Redis 恢复太大了）。 至此，这个 Redis 变成了完全的单机内存型，除了祈祷它不要挂，已经没有任何方法了。

（编辑：张家口站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!