细说分布式Redis架构设计和那些踩过的坑.pdf

细说分布式 Redis 架构设计和那些踩过的坑 Codis 是一个分布式 Redis 解决方案，与官方的纯 P2P 模式不同， Codis 采用的是 Proxy-based 的方案。今天我们 介绍一下 Codis 以及下一个大版本 RebornDB 的设计， 同时 会介绍 Codis 在实际应用场景中的一些 tips 。最后抛砖引玉， 介绍一下我对分布式存储的一些观点和看法。 目录 Redis 、RedisCluster 和 Codis 我们更爱一致性 Codis 在生产环境中的使用的经验和坑们对于分布式数据库和分 布式架构的一些看法答疑记录 1Redis ，RedisCluster 和 Codis 1、Redis ：想必大家的架构中， Redis 已经是一个必不可少 的部件，丰富的数据结构和超高的性能以及简单的协议，让 Redis 能够很好的作为数据库的上游缓存层。但是我们会比 较担心 Redis 的单点问题， 单点 Redis 容量大小总受限于内 存，在业务对性能要求比较高的情况下，理想情况下我们希 望所有的数据都能在内存里面，不要打到数据库上，所以很 自然的就会寻求其他方案。 比如，SSD 将内存换成了磁盘， 以换取更大的容量。 更自然的想法是将 Redis 变成一个可以水平扩展的分布式缓 存服务，在 Codis 之前，业界只有 Twemproxy ，但是 Twemproxy 本身是一个静态的分布式 Redis 方案，进行扩 容/ 缩容时候对运维要求非常高， 而且很难做到平滑的扩缩容。 Codis 的目标其实就是尽量兼容 Twemproxy 的基础上，加 上数据迁移的功能以实现扩容和缩容， 最终替换 Twemproxy 。 从豌豆荚最后上线的结果来看，最后完全替换了 Twem ，大 概 2T 左右的内存集群。 2 、Redis Cluster ：与 Codis 同期发布正式版的官方 cluster ， 我认为有优点也有缺点，作为架构师，我并不会在生产环境 中使用，原因有两个 : cluster 的数据存储模块和分布式的逻辑模块是耦合在一起 的，这个带来的好处是部署异常简单， all-in-the-box ，没有 像 Codis 那么多概念，组件和依赖。但是带来的缺点是，你 很难对业务进行无痛的升级。 比如哪天 Redis cluster 的分布 式逻辑出现了比较严重的 bug ，你该如何升级 ? 除了滚动重 启整个集群，没什么好办法。这个比较伤运维。 对协议进行了较大的修改，对客户端不太友好，目前很多客 户端已经成为事实标准，而且很多程序已经写好了，让业务 方去更换 Redisclient ，是不太现实的，而且目前很难说有哪 个 Rediscluster 客户端经过了大规模生产环境的验证，从 HunanTV 开源的 Rediscluster proxy 上可以看得出这个影响 还是蛮大的，否则就会支持使用 cluster 的 client 了。 3 、Codis ：和