redis实战笔记（10）-第10章 扩展Redis
本章主要内容
扩展读性能
扩展写性能以及内存容量
扩展复杂的查询
随着Redis的使用越来越多， 只使用一台Redis服务器没办法存储所有数据或者没办法处理所有读写请求的问题迟早都会出现， 这时我们就需要使用一些方法对Redis进行扩展， 让它能够满足我们的需求。
我们首先要做的， 就是在Redis能够存储所有数据并且能够正常地处理写查询的情况下， 让Redis的读查询处理能力超过单台Redis服务器所能提供的读查询处理能力。
10.1 扩展读性能
在对读查询的性能进行扩展， 并将额外的服务器用作从服务器以提高系统处理读查询的性能之前， 让我们先来回顾一下提高性能的几个途径。
(1)在使用第9章中介绍的短结构时， 请确保压缩列表的最大长度不会太大以至于影响性能。
(2)根据程序需要执行的查询的类型， 选择能够为这种查询提供最好性能的结构。 比如说， 不要把列表当作集合使用； 也不要获取整个散
(3)列然后在客户端里面对其进行排序， 而是应该直接使用有序集合；诸如此类。
(4)在将大体积的对象缓存到Redis里面之前， 考虑对它进行压缩以减少读取和写入对象时所需的网络带宽。 对比压缩算法lz4、 gzip和
bzip2， 看看哪个算法能够对被存储的数据提供最好的压缩效果和最好的性能。
(5)使用第4章中介绍的流水线（流水线是否启用事务性质由具体的程序决定） 以及连接池。
提升Redis读取能力的最简单方法， 就是添加只读从服务器。
用户可以运行一些额外的服务器， 让它们与主服务器进行连接， 然后接受主服务器发送的数据副本并通过网络进行准实时的
更新（具体的更新速度取决于网络带宽） 。 通过将读请求分散到不同的从服务器上面进行处理， 用户可以从新添加的从服务器上获得额外的读查询处理能力。
记住： 只对主服务器进行写入 在使用只读从服务器的时候， 请务必记得只对Redis主服务器进行写入。
在默认情况下， 尝试对一个被配置为从服务器的Redis服务器进行写入将引 发一个错误（就算这个从服务器是其他从服务器的主服务器， 也是如此） 。 10.3.1节将介绍通过设置配置选项使从服务器也能执行写入操作的方法， 不过由于这一功能通
常都处于关闭状态， 所以对从服务器进行写入一般都会引 发错误。
1.要将一个Redis服务器变为从服务器， 我们只需要在Redis的配置文件里面， 加上一条slaveofhost port语句， 并将host和port两个参数的值分别替换为主服务器的IP地址和端口号就可以了。
2. 除此之外， 我们还可以通过对一个正在运行的Redis服务器发送SLAVEOF host port命令来把它配置为从服务
器。
3.需要注意的一点是， 当一个从服务器连接至主服务器的时候， 从服务器原本存储的所有数据将被清空。 最后， 通过向从服务器发送SLAVEOF no one命令， 我们可以让这个从服务器断开与主服务器的连接。
使用多个Redis从服务器处理读查询时可能会遇到的最棘手的问题，就是主服务器临时下线或者永久下线
每当有从服务器尝试与主服务器
建立连接的时候， 主服务器就会为从服务器创建一个快照， 如果在快照创建完毕之前， 有多个从服务器都尝试与主服务器进行连接， 那么这些从服务器将接收到同一个快照。 从效率的角度来看， 这种做法非常好，因为它可以避免创建多个快照。 但是， 同时向多个从服务器发送快照的多个副本， 可能会将主服务器可用的大部分带宽消耗殆尽。 使主服务器的延迟变高， 甚至导致主服务器已经建立了连接的从服务器断开
(1)解决从服务器重同步（ resync） 问题的其中一个方法， 就是减少主服务器需要传送给从服务器的数据数量， 这可以通过构建一个如图10-1所示的树状复制中间层来完成， 这个图最早曾在第4章中展示过。
从服务器树非常有用， 在对不同数据中心（ data center） 进行复制的时候， 这种从服务器树甚至是必需的： 通过缓慢的广域网（ WAN） 连接进行重同步是一件相当耗费资源的工作， 这种工作应该交给位于中间层的从服务器去做， 而不必劳烦最顶层的主服务器。 但是另一方面， 构建从服务器树也会带来复杂的网络拓扑结构（ topology） ， 这增加了手动和自 动处理故障转移的难度
(2)除了构建树状的从服务器群组之外， 解决从服务器重同步问题的另一个方法就是对网络连接进行压缩， 从而减少需要传送的数据量。 一些Redis用户就发现使用带压缩的SSH隧道（ tunnel） 进行连接可以明显地降低带宽占用， 比如某个公司就曾经使用这种方法， 将复制单个从服务器所需的带宽从原来的21 Mbit降低为1.8 Mbit（ http://mng.bz/2ivv） 。 如果读者也打算使用这个方法的话， 那么请记得使用SSH提供的选项来让SSH连接在断线后自 动进行连接。
Redis Sentinel
Redis Sentinel可以配合Redis的复制功能使用， 并对下线的主服务器进行故障转移。 Redis Sentinel是运行在特殊模式下的Redis服务器， 但它的行为和一般的Redis服务器并不相同。 Sentinel会监视一系列主服务器以及这些主服务器的从服务器， 通过向主服务器发送PUBLISH命令和SUBSCRIBE命令， 并向主服务器和从服务器发送PING命令
各个Sentinel进程可以自 主识别可用的从服务器和其他Sentinel。 当主服务器失效的时候， 监视这个主服务器的所有Sentinel就会基于彼此共有的信息选出一个Sentinel， 并从现有的从服务器当中选出一个新的主服务器。 当被选中的从服务器转换成主服务器之后， 那个被选中的Sentinel就会让剩余的其他从服务器去复制这个新的主服务器（在默认设置下，Sentinel会一个接一个地迁移从服务器， 但这个数量可以通过配置选项进行修改） 。
10.2 扩展写性能和内存容量
随着被缓存的数据越来越多， 当数据没办法被存储到一台机器上面的时候， 我们就需要想办法把数据分割存储到由多台机器组成的群组里面。
扩展写容量 尽管这一节中讨论的是如何使用分片来增加可用内存的总数量， 但是这些方法同样可以在一台Redis服务器的写性能到达极
限的时候， 提升Redis的写吞吐量。
额，redis3.0以下用的是客户端（redis sharding）分片，如jedis的客户端分片api，勇一致性哈希算法平分数据到redis服务器，redis3.0后服务端分片已经实现（redis cluster），一致性哈希槽
10.3 扩展复杂的查询
在对各式各样的Redis服务进行扩展的时候， 常常会遇到这样一种情况： 因为服务执行的查询并不只是获取值和设置值那么简单， 所以只对数据进行分片并不足以达到对其进行扩展的目 的。 本节将对一个易于扩展的问题和两个较难扩展的问题进行讨论。
10.3.1 扩展搜索查询量
我们迟早会遇到一台机器每秒执行的查询数量无法满足程序要求的问题。 为了解决这个问题， 本节将会介绍如何通过添加查询从服务器（ query slave） 来提高系统处理搜索请求的能力。
10.3.2 扩展搜索索引 大小
10.3.3 对社交网站进行扩展
