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

自定义客户端方式与场景配置能力

在支持 Redis 本身的特性的基础上，我们需要通过自定义的客户端来实现一些额外的功能。

支持场景配置，我们考虑根据场景来管控它的场景，客户端每次用 Redis 的时候，必须把场景上 给我，你是在哪里，用这件事儿是干什么的，虽然这个对于开发人员来说是比较累的，他往往嵌在它的任务逻辑里面直接跟进去。曾江场景配置之后，在缓存服务的中心节点，就可以把它分开，同一个应用里面两个比较重要的场景就会不用同一个 Redis，避免挂的时候两个一起挂。

同时也需要一个调度系统，分开之后，不同的 Redis 集群所属的服务器也需要分开。分开以后我的数据怎么复制，出问题的时候我们怎么把它迁移此也需要一个复制和迁移的平台去做。

那么我们就做了，首先它是 Redis 的协议，接下来刚才我们在客户端里面支持的各种场景配置录在 proxy 里面，实现访问通道控制。然后再把 Redis 本身沉在我们 proxy 之后，让它仅仅变成一个储存的节点，proxy 再做一些自己的事情，比如本地缓存及路由。冷热区分方面，在一些压力不大的情况下，调用方看到的还是个 Redis ，但是其实可能数据是存在 RocksDB 里面了。

缓存服务的架构设计

• 多个小集群 + 单节点，我们要小集群的部署和快速的部署，到当时一个集群有问题的时候，快速移到另一个集群。

• 以场景划分集群

• 实时平衡调度数据

• 动态扩容缩容

多协议支持

还有一块老项目是最大的麻烦，同程有很多之前是 memcache 的应用，后来是转到 Redis 去的，但是转出一个问题来了，有不少业务由于本身事情较多没有转换成 Redis，这些钉子户怎么办时维护这两个平台是非常麻烦的，刚才 proxy 就派到用场了。因为 memcache 本身它的数据支持类型是比较少的，因此转换比较简单，如果是一个更复杂的类型，那可能就转不过来了。所以我们 proxy 就把这些钉子户给拆掉了，他觉得自己还是在用 memcache，其实已经被转成了 Redis。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！