使用Redis走进误区,该怎么办?

首先是一个产品线开发人员搭建起了一套庞大的价格存储系统,底层是关系型数据库,只用来处理一些事务性的操作和存放一些基础数据;

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

在大部分的情况下,一次大数据量的计算后结果可以重用但会出现细节数据的频繁更新,所以他们又在MongoDB上搭建了一层Redis的缓存,这样就形成了数据库MongoDBRedis三级的方式,方案本身先不评价不是本文重,我们来看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里面,再通过其他程序读取数据并进行分析和计算,用来做数据报表。

当他们做完这个项目之后,这个日志组件让他们觉得用的还很过瘾。他们都觉得这个做法不错,可以轻松地记录日志,分析起来也挺快,还用什么公司的分布式日志服务啊。

于是随着时间的流逝,这个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用不好的误区

这样的乱象一定是不可能继续了,最少在同程这样的使用方式不可以再继续了,使用者也开始从喜欢到痛苦了。

怎么办?这是一个很沉重的事:“一个被人用乱的系统就像一桌烧坏的菜,让你重新回炉,还让人叫好,是很困难的”。关键是已经用的这样了,总不可能让所有系统都停下来,等待新系统上线并瞬间切换好吧?这是个什么活:“高速公路上换轮胎”。

但问题出现了总是要解决的,想了再想,论了再论,总结以下几点:

(1)必须搭建完善的监控系统,在这之前要先预警,不能等到发生了,我们才发现问题;

(2)控制和引导Redis的使用,我们需要有自己研发的Redis客户端,在使用时就开始控制和引导;

(3)Redis的部分角色要改,将Redis由storage角色降低为cache角色;

(4)Redis的持久化方案要重新做,需要自己研发一个基于Redis协议的持久化方案让使用者可以把Redis当DB用;

(5)Redis的高可用要按照场景分开,根据不同的场景决定采用不同的高可用方案。

留给开发同学的时间并不多,只有两个月的时间来完成这些事情。这事其实还是很有挑战的,考验开发同学这个轮胎到底能不换下来的时候到来了。同学们开始研发我们自己的Redis缓存系统,下面我们来看一下这个代号为凤凰的缓存系统第一版方案:

首先是监控系统。原有的开源Redis监控从大面上讲只一些监控工具,不能算作一个完整的监控系统。当然这个监控是全方位从客户端开始一直到反回数据的全链路的监控。

其次是改造Redis客户端。广泛使用的Redis客户端有的太简单有的太重,总之不是我们想要东西,比如,.Net下的BookSleeve和servicestack.Redis(同程还有一点老的.Net开发的应用),前者已经好久没人维护了,后者直接收费了。

好吧,我们就开发一个客户端,然后督促全公司的研发用它来替换目前正在使用的客户端。在这个客户端里面,我们植入了日志记录,记录了代码对Redis的所有操作事件,例如耗时、key、value大小、网络断开等,我们将这些有问题的事件在后台进行收集,由一个收集程序进行分析和处理,同时取消了直接的IP端口连接方式,通过一个配置中心分配IP地址和端口。

当Redis发生问题并需要切换时,直接在配置中心修改,由配置中心推送新的配置到客户端,这样就免去了Redis切换时需要业务员修改配置文件的麻烦。

另外,把Redis的命令操作分拆成两部分:安全的命令和不安全的命令。对于安全的命令可以直接使用,对于不安全的命令需要分析和审批后才能打开,这也是由配置中心控制的,这样就解决了研发人员使用Redis时的规范问题,并且将Redis定位为缓存角色,除非有特殊需求,否则一律以缓存角色对待。

最后,对Redis的部署方式也进行了修改,以前是Keepalived的方式,现在换成了主从+哨兵的模式。另外,我们自己实现了Redis的分片,如果业务需要申请大容量的Redis数据库,就会把Redis拆分成多片,通过Hash算法均衡每片的大小,这样的分片对应用层也是无感知的。

当然重客户端方式不好,并且我们要做的是缓存不仅仅是单单的Redis,于是我们会做一个Redis的Proxy,提供统一的入口点,Proxy可以多份部署,客户端无论连接的是哪个Proxy,都能取得完整的集群数据,这样就基本完成了按场景选择不同的部署方式的问题。

这样的一个Proxy也解决了多种开发语言的问题,例如,运维系统是使用Python开发的,也需要用到Redis,就可以直接连Proxy,然后接入到统一的Redis体系中来。做客户端也好,做Proxy也好,不只是为代理请求而是为了统一的治理Redis缓存的使用,不让乱象的出现。

让缓存有一个可管可控的场景下稳定的运维,让开发者可以安全并肆无忌惮继续乱用Redis,但这个“乱”是被虚拟化的乱,因为它的底层是可以治理的。

图15-1 系统架构图

当然以上这些改造都需要在不影响业务的情况下进行。实现这个其实还是有不小的挑战,特别是分片,将一个Redis拆分成多个,还能让客户端正确找到所需要的key,这需要非常小心,因为稍有不慎,内存的数据就全部消失了。在这段时间里,我们开发了多种同步工具,几乎把Redis的主从协议整个实现了一遍,终于可以将Redis平滑过渡到新的模式上了。

本文来自企鹅号 - java交流学习媒体

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

Go 语言构建高并发分布式系统实践

你知道互联网最抢手的技术人才有哪些吗?最新互联网职场生态报告显示,最抢手的十大互联网技术人才排名中Go语言开发人员位居第三,从中不难见得,Go语言的渗透率越来越...

4424
来自专栏Java架构师历程

WebBuilder —— Web 开发平台

WebBuilder是一款跨平台、数据库和浏览器的可视化Web应用开发平台,使用了多项最新的技术,使Web应用的开发更快捷和简单。

1.1K4
来自专栏胡彬的专栏

腾讯云分布式数据库 DCDB 架构解密

腾讯云金融级数据库 CDB for TDSQL (Cloud DataBase for Tecent Distribute SQL)是一个适用于 OLTP 场景...

6030
来自专栏Java技术栈

聊聊微服务架构及分布式事务解决方案!

分布式事务场景如何设计系统架构及解决数据一致性问题,个人理解最终方案把握以下原则就可以了,那就是:大事务=小事务(原子事务)+异步(消息通知),解决分布式事务的...

1444
来自专栏数据和云

PayPal Oracle数据库的隐含参数

在这篇小文中,我和大家分享一下PayPal数据库的隐含参数,注意,本文参考资料来自网络OOW公开文档,只是我也是首次注意到这些设置。 在图中架构,可以看到Pay...

3008
来自专栏Golang语言社区

Go 语言构建高并发分布式系统实践

你知道互联网最抢手的技术人才有哪些吗?最新互联网职场生态报告显示,最抢手的十大互联网技术人才排名中Go语言开发人员位居第三,从中不难见得,Go语言的渗透率越来越...

5319
来自专栏杨建荣的学习笔记

Oracle,MySQL迁移整合的问题总结(r10笔记第99天)

最近负责了一起数据迁移的项目,因为机器硬件过保,因为资源存在冗余,因为。。。总之话还没说完,就得到了项目组的支持,所以迁移的需求是明确的。 那么涉及的服务器数量...

4059
来自专栏北京马哥教育

远离故障的十大原则

故障是运维人员永远的痛。相信每一个运维人员的KPI中都有一项:可用性。可用性高就是不出故障,各个公司对可用性和故障评级的标准都不相同,但是避免故障的方法却是殊途...

3076
来自专栏ThoughtWorks

TW洞见 | 邱俊涛:快速搭建IE测试环境(Virtualbox+ievms)

IE下的测试 作为一个有追求的程序员,应该尽可能的远离Windows系统。不论从专业开发者的角度,还是仅仅作为最终用户从使用体验上来说,Windows都可以算...

3767
来自专栏月色的自留地

K60平台智能车开发工作随手记

2054

扫码关注云+社区

领取腾讯云代金券