同程旅游缓存系统（凤凰）打造 Redis 时代的完美平台实践

缓存大家比较熟悉，在各种场景下也用得很多，在同程旅游也一样，缓存是一个无处不在的精灵，也是抗并发压力的核心系统之一。今天我们来讲一下同程旅游在缓存方面的经验。先来看一下我们的缓存走过了哪些历程。最早我们在应用中使用内存对象来存放变化比较小的数据，慢慢发现在应用本地的内存量不足以这样折腾，很是精贵，所以开始使用从 MemCache 来将缓存从应用中分离出来。之后缓存的场景变得更多了，MemCache 的一些不足之处开始显现，如支持的数据结构单一等。于是开始使用 Redis ，对于 Redis 的使用也从单机开始转向分片／集群的方式。Redis 虽然是一个非常优秀的缓存中间件系统，但当应用使用量越来越多时发现新的问题也来了，首先是对于应用代码在一起的 Redis 客户端不是太满意，于是我们重写了客户端。接着在数千个 Redis 实例（目前我们线上有4千多个部署实例）在线上工作起来如何低成本地高效运维起是一个大挑战。于是我们做了针对它的智能化运维平台。但是这些多不是重大难题，最大难题是因为 Redis 太好用了以致于在应用项目中大量使用，但是往往这些是没有好好思考和设计过的，这使得缓存的使用混乱且不合理，也使原本健壮成缓存变的脆弱的病秧子。所以我们开始开发 Redis 调度治理系统来治理缓存。如今我们开始更加关注整个缓存平台的高效和低成本，在平台的 Redis 部署全面 Docker 化，并开始在缓存中使用比内存廉价的 SSD。

现在让我们来看一看这个名叫“凤凰”的缓存平台是怎么从火中重生的。

Redis 遍地开花的现状及问题

Redis 集群的管理

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

故障

这种背景下会存在什么样痛苦的场