redis生产环境配置 redis timeout配置文件

案例一:一个产品线开发人员搭建起了一套庞大的价格存储系统 。底层是关系型数据库 。只用来处理一些事务性的操作和存放一些基础数据 。
在关系型数据库的上面还有一套 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 变成了完全的单机内存型 。除了祈祷它不要挂 。已经没有任何方法了 。
这事悬着好久 。直到修复 MongoDB 集群才了事 。如此的侥幸 。没出大事 。但心里会踏实吗?回答是不会 。
在这个案例中主要的问题在于:对 Redis 过度依赖 。Redis 看似为系统带来了简单又方便的性能提升和稳定性 。但在使用中缺乏对不同场景的数据的分离造成了一个逻辑上的单点问题 。
当然这问题我们可以通过更合理的应用架构设计来解决 。但是这样解决不够优雅也不够彻底 。也增加了应用层的架构设计的麻烦 。
Redis 的问题就应该在基础缓存层来解决 。这样即使还有类似的情况也没有问题 。
因为基础缓存层已经能适应这样的用法 。也会让应用层的设计更为简单(简单一直是架构设计所追求的 。Redis 的大量随意使用本身就是追求简单的副产品 。那我们为什么不让这简单变为真实呢?)
案例二:我们再来看第二个案例 。有个部门用自己现有 Redis 服务器做了一套日志系统 。将日志数据先存储到 Redis 里面 。再通过其他程序读取数据并进行分析和计算 。用来做数据报表 。
当他们做完这个项目之后 。这个日志组件让他们觉得用的还很过瘾 。他们都觉得这个做法不错 。可以轻松地记录日志 。分析起来也挺快 。还用什么公司的分布式日志服务啊?

推荐阅读