Redis里头怎么搞分区和分片，数据多了咋整才好用点

当你的Redis里数据越来越多，感觉一台机器快顶不住了，比如内存不够用了，或者读写的请求多得让它喘不过气来，这时候你就得考虑“分”这个字了，说白了，就是把一大坨数据和一大堆活儿，分摊给好几台Redis服务器去干，这样每台机器的压力就小了，整个系统就能继续又快又稳地跑下去，这里面最常用的两个法子就是分区和分片，很多人会把它们混为一谈,但其实它们侧重点不太一样。

分区这个词更像是一个总称，目标就是把数据分开存，就像你有一个超大的衣柜，衣服太多塞不下了，你就决定再买两个小柜子，把春夏秋冬的衣服分开存放，至于按什么规则来分，那是具体的方法，而分片，就是实现分区最核心、最常用的一种具体技术手段，它指的是按照某种明确的规则（比如根据数据的key算个哈希值），把数据切成一片一片的，然后每一片放到不同的服务器上，我们下面聊的具体做法,其实都是在讲如何实现分片分区。

具体怎么“分”呢？有几种常见的路子,各有利弊。

第一种路子，客户端自己决定。 也就是在你自己写的应用程序代码里，就规定好数据该存到哪台Redis服务器上，你可以想一个简单的规则：所有用户ID是偶数的数据，存到服务器A；用户ID是奇数的，存到服务器B，更常见的做法是用一种叫“一致性哈希”的算法（这是一种聪明的计算方式，能减少增加或减少服务器时数据的搬动量）来计算key应该去哪儿。

• 好处是：简单直接，不需要引入额外的中间软件，性能损耗小,因为客户端直接连对应的Redis服务器。
• 坏处是：规则定死了就不好改，如果你后来觉得两台服务器不够，要加第三台，那麻烦就大了，因为分片规则一变，绝大部分数据可能就找不到原来的位置了，需要把几乎所有的数据重新计算、搬运一遍，这个过程非常痛苦，搞不好服务就得停很久，你得在每个客户端程序里都实现这套分片逻辑,管理起来有点麻烦。

第二种路子，找个代理中间人。 既然客户端直接分片这么麻烦，那就找个专业的中间件来干这个事儿，你不需要修改应用程序代码，应用程序还是像以前一样，连到一个统一的“入口”（也就是代理），这个代理背后连着好多台Redis服务器，它替你操心分片的事儿，你只管把数据扔给它，它根据内置的规则（通常也是一致性哈希）自动把数据转发到正确的Redis实例上，市面上有一些知名的代理软件可以帮你做这个事，比如Twitter开发的Twemproxy，以及更强大一些的Codis（这个是中国团队开发的）。

• 好处是：对应用程序非常友好，应用程序几乎无感知，以为还是在操作一个Redis，分片的管理、扩容等复杂操作都由代理层来处理了,客户端解放了。
• 坏处是：毕竟多了一层，网络通信多了一次，性能上会有那么一点点损失，而且这个代理本身也可能成为瓶颈或者单点故障,需要你做高可用方案来保证它自己别挂掉。

第三种路子，交给Redis服务器集群。 这是Redis官方从3.0版本开始提供的“正统”解决方案，叫做Redis Cluster，它把分片的功能直接做到了Redis服务器本身，你可以启动一个由很多个Redis实例组成的集群，它们自己会通过一种叫Gossip的协议互相通信，来管理数据的分布和故障转移，客户端需要支持Redis Cluster协议，它可以从集群中获取一份“配置图”，知道哪个key大概在哪个节点上,然后直接连接到正确的节点进行读写。

• 好处是：这是官方的方案，兼容性和未来发展有保障，它没有单点的代理，架构上更去中心化，扩展性很好，数据分片、故障恢复这些都是自动化的。
• 坏处是：配置和管理比单机Redis要复杂一些，而且它为了集群功能，牺牲了一些特性，比如不支持跨多个key的事务（因为这几个key可能分布在不同的节点上），也不支持一些复杂的多键操作，客户端的支持也需要留意，不是所有语言的客户端都完美支持Redis Cluster。

数据多了之后，除了分片还能咋整？

分片分区是解决数据量巨大和访问量超高的终极手段，但它也带来了复杂性，比如跨分片的事务难以实现，操作起来也麻烦，所以在走到这一步之前,你应该先想想有没有其他优化空间：

1. 好好清理数据：给数据设置合理的过期时间，别让那些没用的缓存数据一直占着地方，定期检查一下有没有可以精简的大key，比如一个hash里面积压了成千上万个字段,可以考虑拆一拆。
2. 升级硬件：如果预算允许，给Redis服务器加内存是最简单粗暴的办法，这叫“纵向扩展”，虽然最终会有物理上限，但在数据量不是天文数字之前,这能帮你争取很多时间。
3. 优化数据结构：看看你存数据的方式是不是最经济的,比如用hash结构可能比把数据序列化成JSON字符串再存更省空间。

总结一下该怎么选：

• 如果你的业务刚开始，数据量不大，根本不需要分片，用好单机Redis,做好数据清理和备份就行。
• 如果数据量和并发量开始增长，但还没到非常巨大的程度，你又想保持客户端的简单性，可以考虑代理模式,比如Codis。
• 如果业务规模很大，追求长远的可扩展性和高可用，并且能接受Redis Cluster的一些限制，那么Redis Cluster是更标准、更推荐的选择。
• 客户端分片的方式，现在除了在一些非常追求极致性能或者遗留老系统中，已经不太常被推荐了,主要是扩容太麻烦。

最后记住一点，无论用哪种分片方式，一定要提前规划好，最好在项目初期就预估一下数据的增长趋势，选择一种适合未来发展的方案,避免中途换方案导致数据迁移的大动干戈。

（上述方法综合参考了Redis官方文档关于分区和集群的介绍、以及业界常用的Twemproxy和Codis等方案的特性。）