锐客网

  1. 首页 > 睿知 > >

redis生产环境配置 redis timeout配置文件( 二 )

生活知识经验知识


随着时间的流逝 。这个 Redis 上已经悄悄地挂载了数千个客户端 。每秒的并发量数万 。系统的单核 cpu 使用率也接近 90% 了 。此时这个 Redis 已经开始不堪重负 。
终于 。压死骆驼的最后一根稻草来了 。有程序向这个日志组件写入了一条 7MB 的日志（哈哈 。这个容量可以写一部小说了 。这是什么日志啊） 。
于是 Redis 堵死了 。一旦堵死 。数千个客户端就全部无法连接 。所有日志记录的操作全部失败 。
其实日志记录失败本身应该不至于影响正常业务 。但是由于这个日志服务不是公司标准的分布式日志服务 。所以关注的人很少 。
最开始写它的开发同学也不知道会有这么大的使用量 。运维同学更不知有这个非法的日志服务存在 。
这个服务本身也没有很好地设计容错 。所以在日志记录的地方就直接抛出异常 。结果全公司相当一部分的业务系统都出现了故障 。监控系统中“5XX”的错误直线上升 。
一帮人欲哭无泪 。顶着巨大的压力排查问题 。但是由于受灾面实在太广 。排障的压力是可以想像的 。
这个案例中看似是一个日志服务没做好或者是开发流程管理不到位 。而且很多日志服务也都用到了 Redis 做收集数据的缓冲 。好像也没什么问题 。
其实不然 。像这样大规模大流量的日志系统从收集到分析要细细考虑的技术点是巨大的 。而不只是简单的写入性能的问题 。
在这个案例中 Redis 给程序带来的是超简单的性能解决方案 。但这个简单是相对的 。它是有场景限制的 。
在这里 。这样的简单就是毒药 。无知的吃下是要害死自己的 。这就像“一条在小河沟里无所不能傲慢的小鱼 。那是因为它没见过大海 。等到了大海……” 。
在这个案例的另一问题：一个非法日志服务的存在 。表面上是管理问题 。实质上还是技术问题 。
因为 Redis 的使用无法像关系型数据库那样有 DBA 的监管 。它的运维者无法管理和提前知道里面放的是什么数据 。开发者也无需任何申明就可以向 Redis 中写入数据并使用 。
所以这里我们发现 Redis 的使用没这些场景的管理后在长期的使用中比较容易失控 。我们需要一个对 Redis 使用可治理和管控的透明层 。
两个小例子中看到在 Redis 乱用的那个年代里 。使用它的兄弟们一定是痛的 。承受了各种故障的狂轰滥炸：
Redis 被 Keys 命令堵塞了
Keepalived 切换虚 IP 失败 。虚IP被释放了
用 Redis 做计算了 。Redis 的 CPU 占用率成了 100% 了
主从同步失败了
Redis 客户端连接数爆了
……
如何改变 Redis 用不好的误区？
这样的乱象一定是不可能继续了 。最少在同程 。这样的使用方式不可以再继续了 。使用者也开始从喜欢到痛苦了 。
怎么办？这是一个很沉重的事情：“一个被人用乱的系统就像一桌烧坏的菜 。让你重新回炉 。还让人叫好 。是很困难的” 。
关键是已经用的这样了 。总不可能让所有系统都停下来 。等待新系统上线并瞬间切换好吧？这是个什么活：“高速公路上换轮胎” 。
但问题出现了总是要解决的 。想了再想 。论了再论 。总结以下几点：
必须搭建完善的监控系统 。在这之前要先预警 。不能等到发生了 。我们才发现问题 。
控制和引导 Redis 的使用 。我们需要有自己研发的 Redis 客户端 。在使用时就开始控制和引导 。
Redis的部分角色要改 。将 Redis 由 Storage 角色降低为 Cache 角色 。
Redis 的持久化方案要重新做 。需要自己研发一个基于 Redis 协议的持久化方案让使用者可以把 Redis 当 DB 用 。
Redis 的高可用要按照场景分开 。根据不同的场景决定采用不同的高可用方案 。
留给开发同学的时间并不多 。只有两个月的时间来完成这些事情 。这事还是很有挑战的 。考验开发同学这个轮胎到底能不换下来的时候到来了 。
同学们开始研发我们自己的 Redis 缓存系统 。下面我们来看一下这个代号为凤凰的缓存系统第一版方案：
首先是监控系统 。原有的开源 Redis 监控从大面上讲只是一些监控工具 。不能算作一个完整的监控系统 。当然这个监控是全方位从客户端开始一直到返回数据的全链路的监控 。
其次是改造 Redis 客户端 。广泛使用的 Redis 客户端有的太简单 。有的太重 。总之不是我们想要的东西 。
比如 .Net 下的 BookSleeve 和 servicestack.Redis（同程还有一点老的 .Net 开发的应用） 。前者已经好久没人维护了 。后者直接收费了 。

推荐阅读


上一篇：自助唱歌房怎么样？如何用手机点歌呢？

下一篇：被精神控制的人有哪些特征？