同程旅游缓存系统设计:如何打造Redis时代的完美体系(含PPT)

导读：高可用架构 7 月 30 日在上海举办了『互联网架构的基石』专题沙龙，进行了闭门私董会研讨及对外开放的四个专题的演讲，期望能促进业界对互联网基础服务及工具的讨论，本文是王晓波分享同程旅游缓存系统架构经验。

王晓波，同程旅游首席架构师，专注于高并发互联网架构设计、分布式电子商务交易平台设计、大数据分析平台设计、高可用性系统设计，基础云相关技术研究，对 Docker 等容器有深入的实践。另对系统运维和信息安全领域也大量的技术实践。曾设计过多个并发百万以上、每分钟 20 万以上订单量的电商交易平台，熟悉 B2C、B2B、B2B2C、O2O 等多种电商形态系统的技术设计。熟悉电子商务平台技术发展特点，拥有十多年丰富的技术架构、技术咨询经验，深刻理解电商系统对技术选择的重要性。

旅游大家现在比较熟悉，同程旅游涵盖的业务比较多，从火车票到住宿都有。今天我们讲一下同程旅游的缓存系统，包括整个缓存架构如何设计。先来看一下缓存我们走过了哪些历程。

• 从 memcache 开始使用缓存

• 再从 memcache 转到 Redis

• 从单机 Redis 升级到集群 Redis

• 从简单的运维升级到全自动运维

• 重开发 Redis 客户端

• 开发 Redis 调度治理系统

• Redis 部署全面 Docker 化

旅游是比较复杂的业务，住、吃、玩相关功能都会压到平台上，整个在线旅游应用量非常大，酒店、机票，或者是卖一个去泰国旅行团，业务逻辑完全不一样，因此众多业务会带来大量系统的访问压力。

Redis 遍地开花的现状及问题

Redis 集群的管理

所有互联网的应用里面，可能访问最多的就是 cache。一开始时候一些团队认为 cache 就像西游记里仙丹一样，当一个系统访问过大扛不住时，用一下 Redis，系统压力就解决了。在这种背景下，我们的系统里面 Redis 不断增多，逐渐增加到几百台服务器，每台上面还有多个实例，因此当存在几千个 Redis 实例后，可能运维也很难说清楚哪个 Redis 是什么业务。

单点故障

这种背景下会存在什么样痛苦的场景？正常情况下 cache 是为了增加系统的性能，是画龙点睛的一笔，但是当时我们 cache 会是什么样？它挂了就可能让我们整个系统崩溃。比如说 CPU 才 5%，也许就由于缓存问题系统就挂了。

高可用与主从同步问题

因为 cache 有单点，我们想放两个不就好了吗，所以就做了主从。这时候坑又来了，为什么呢？比如有些 Redis 值非常大，如果偶尔网络质量不太好，就会带来主从不同步，当两边主和从都死或者出问题的时，重启的时间非常长。

监控

为了高可用，我们需要全面的监控。当时我们做了哪些监控呢？

• connected_clients : 已连接客户端的数量

• client_longest_output_list : 当前连接的客户端当中，最长的输出列表

• client_longest_input_buf : 当前连接的客户端当中，最大输入缓存

• blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量

• used_memory_human : 以人可读的格式返回 Redis 分配的内存总量

• used_memory_rss : 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和