王晓波
同程旅行 机票事业群 CTO
读完需要
4
分钟速读仅需 2 分钟
本章和大家分享一下同程凤凰缓存系统在基于 Redis 方面的设计与实践。如何改变 Redis 不好用的误区
本文节选自中生代技术社区出品图书《深入分布式缓存》
接上文《同程旅行王晓波：同程凤凰缓存系统在基于 Redis 方面的设计与实践（上篇）》
这样的乱象一定是不可能继续了，最少同程这样的使用方式不可以再继续了，使用者也开始从喜欢到痛苦了。怎么办？
这是一个很沉重的事：“一个被人用乱的系统就像一桌烧坏的菜，让你重新回炉，还让人叫好，是很困难的。”
关键是已经用成这样了，总不可能让所有系统都停下来，等待新系统上线并瞬间切换吧？这是个什么活？高速公路上换轮胎！
但问题出现了总是要解决的，想了再想，论了再论，总结了以下几点：
必须搭建完善的监控系统，在这之前要先预警，不能等到发生了，我们才发现问题。
控制和引导 Redis 的使用，我们需要有自己研发的 Redis 客户端，在使用时就开始控制和引导。
Redis 的部分角色要改，将 Redis 由 storage 角色降低为 cache 角色。
Redis 的持久化方案要重新做，需要自己研发一个基于 Redis 协议的持久化方案，让使用者可以把 Redis 当 DB 用。
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 所示
图 15-1 系统架构图
当然以上这些改造都需要在不影响业务的情况下进行。实现这个其实还是有不小的挑战，特别是分片，将一个 Redis 拆分成多个，还能让客户端正确找到所需要的 key，这需要非常小心，因为稍有不慎，内存的数据就全部消失了。在这段时间里，我们开发了多种同步工具，几乎把 Redis 的主从协议整个实现了一遍，终于可以将 Redis 平滑过度到新的模式上了。（未完待续）
想要加入中生代架构群的小伙伴，请添加群合伙人大白的微信
申请备注（姓名+公司+技术方向）才能通过哦！
阿里技术精彩文章推荐
往期推荐
阿里文娱技术专家战獒: 领域驱动设计详解之What, Why, How?
蚂蚁集团沈凋墨：Kubernetes-微内核的分布式操作系统
支付宝研究员兼OceanBase总架构师杨传辉：我在数据库梦之队的十年成长路
蚂蚁资深算法专家周俊：从原理到落地，支付宝如何打造保护隐私的共享智能？
蚂蚁科技 Service Mesh 落地实践与挑战 | GIAC 实录
蚂蚁集团涵畅：再启程，Service Mesh 前路虽长，尤可期许
阿里P8架构师：淘宝技术架构从1.0到4.0的架构变迁！12页PPT详解
阿里技术专家甘盘：浅谈双十一背后的支付宝LDC架构和其CAP分析
阿里高级技术专家至简: Service Mesh 在超大规模场景下的落地挑战
END
#架构师必备#
点分享点点赞点在看