Redis在分布式存储系统里到底是怎么跑起来的那些事儿

要搞清楚Redis在分布式系统里怎么跑起来，我们得先明白一个事儿：单个Redis再快，它也有极限，就像一家店生意再好，一个柜台一个伙计总有个服务上限，客人（客户端）多了要排队，存的货（数据）多了柜台放不下，这时候，老板就想开分店了，Redis的分布式,其实就是开分店的学问。

这门学问主要解决两个核心问题：第一，数据怎么分到各个分店（分片）？第二，某个分店万一垮了怎么办（高可用）？

先说说数据分片，也就是数据怎么分家。

最直接的想法是，老板自己记个账本，来了客人，根据客人要存或取的东西，查一下账本，告诉客人该去几号分店，这在Redis里就叫客户端分片，我规定，所有以字母a-f开头的key去第一家店，g-p的去第二家，q-z的去第三家，这个规则写在每个客人的脑子里（也就是客户端代码里），好处是直接，不用经过中间人，但坏处也很明显，要是我想增开一家分店或者关掉一家，这个分店的规则一变，所有客人都得重新学习新规则（更新客户端代码），非常麻烦,容易出错。

更常见的做法是请一个“大堂经理”，这就是代理分片，代表性的就是Twitter开源的Twemproxy和Codis，所有客人来了，都不直接去分店，而是先找这位大堂经理，经理手里有张全部分店的路由表，客人说要存一个key叫“user:123”，经理根据一套算法（比如一致性哈希）算出这个key应该去3号店，然后就告诉客人：“请去3号店”，客人再去和3号店直接打交道，这样做的好处是，客人不用关心分店规则，规则变了只需要经理自己更新路由表就行，但坏处是多了一层，经理可能成为瓶颈，而且经理自己要是挂了，整个系统就瘫痪了，所以通常还得给经理配个副经理（部署多个代理做高可用）。

Redis在3.0版本后，自己推出了一套官方的“连锁店管理模式”，叫Redis Cluster，它既不用客户死记硬背，也不用额外请大堂经理，它采用的是去中心化的方式，你可以把它想象成一家家分店形成了一个联盟，每家店不仅管着自己的货，还知道整个联盟的布局（存储了完整的集群元数据），当一个客人连上任意一家分店，说要访问key="apple"时，这家店会自己计算一下，发现这个key不归我管，是属于斜对面那家5号店的，它不会让客人自己跑过去，而是直接告诉客人：“你要的数据在5号店，这是它的地址，你直接去找它吧。”然后客人会重定向到5号店进行操作，这种方式减轻了单点压力，扩展性更好，但实现起来也更复杂，比如它需要额外的端口让分店之间互相通信，同步元数据,管理集群状态。

再来看看第二个问题，高可用，也就是分店垮了怎么办。

生意再好，也怕意外，万一3号店着火了（服务器宕机），里面的数据岂不是全丢了？客人来了也找不到东西，为了解决这个问题，Redis用了主从复制的办法，就是给每个分店（现在叫主节点）配一个或多个学徒店（从节点），学徒店会实时地、一字不差地抄写主店的账本（复制数据），平时，客人只跟主店做生意，学徒店只负责抄写，不接待客人（读操作默认也不支持，但可以配置），这样，一旦主店出了事，监控系统（比如Redis的哨兵Sentinel，或者Cluster自身的管理机制）就会马上发现，然后推举一个最优秀的学徒店“转正”成为新的主店，并通知所有客人和其它分店：“以后3号店的业务找这位新老板”，这样，服务就几乎不中断了，等原来的主店修好了，它回来会作为新的学徒店,从新的主店那里重新同步数据。

总结一下，Redis在分布式系统里跑起来,核心就是两套机制在协同工作：

1. 分片机制（Redis Cluster、Codis等）：像一张大地图，把海量数据合理地分摊到多台机器上，解决的是“容量”和“并发”的问题。
2. 复制/高可用机制（主从复制+哨兵或Cluster的故障转移）：像一套备份和应急预案，确保任何一台机器宕机，数据不丢，服务不停，解决的是“可靠性”的问题。

这两者结合，就让Redis从一个单打独斗的快手，变成了一个能够支撑大规模互联网应用的、既快又稳的分布式缓存和数据存储系统，它不像有些数据库（比如MongoDB）那样一开始就为分布式设计，而是通过后来的演进，用相对简单直观的方式,解决了分布式的主要痛点。

（主要参考来源：Redis官方文档关于复制和Redis Cluster的说明，以及《Redis设计与实现》一书中对集群和哨兵的讲解）