如有侵权，请联系～
如有错误，也欢迎批评指正～
本篇文章大部分是来自学习《Redis实战》的笔记

1、扩展读性能

单台Redis服务器针对于流量较小的情况完全没有问题，但是一旦遇到规模比较大的情况，例如超过几十万，甚至上百万的并发量，就超过了单台服务器的承受能力。本节从只读服务器上提升系统处理读查询的性能。
在通过本节的扩展服务器这种方式之前，先看下其他提高性能的方式：

• 使用短结构，例如压缩列表和整数集合。Redis实战-降低内存使用
• 选择合适的查询数据类型
• 将大体积的对象进行压缩，然后再存储到Redis中
• 使用流水线和连接池

提升Redis读取性能最简单的方法就是：添加只读服务器。将一个Redis服务器变成从服务器的方法：

• 只需要在redis配置文件中加一条：slaveof host port语句，这里host port分别是主服务器的IP地址和端口号
• 通过对一个正在运行的Redis服务器发送slaveof host port命令把它配置为从服务器

使用多个Redis从服务器处理读查询时候遇到最棘手的问题就是主服务器临时下线后者永久下线。每当有一个从服务器尝试主服务器建立连接的时候，主服务器会为从服务器创建一个快照，如果在创建快照完毕之前，有多个服务器尝试与主服务器进行连接，那么这些从服务器将接收到同一个快照。效率提升。当然如果是快照创建发送给从服务器完成之后，再有新的从服务器建立连接，则需要重新dump快照。
如果同时有多个从服务器建立快照，主服务器需要同时发送多个快照，有可能将主服务大部分的带宽消耗殆尽，从而使主服务器的延迟变高，甚至导致主服务器已经建立的连接断开。
解决这个从服务器重同步的方法：就是减少主服务器需要传递给从服务器的数量。

针对不同数据中心进行复制的时候，这种拓扑结构就非常有用，因为广域网进行重同步是一件非常耗费资源的工作，这种工作交给中间层的从服务器来完成，解放主服务器，提高主服务器的写能力。当然，这种拓扑结构也增加了维护成本，例如手动和自动处理故障转移的难度。
除了树状结构的从服务器集群外，还可以通过对网络进行压缩，减少数据量的传递。例如带压缩的SSH。

Redis的哨兵模式可以对下线的主服务器进行故障转移。Redis的哨兵是运行在特殊模式的Redis服务器。可以参考：Redis实战-数据安全与性能保障、redis相关问题

2、扩展写性能和内存容量

如果我们用尽了一切方法来降低内存并且提高性能之后，仍然问题没有解决，说明一台机器无法承受，达到了瓶颈。因此需要将数据分片到多台机器上。本节介绍的数据分片的前提是固定Redis服务器数量。

大致分为几步：

• 利用分片函数对关键key进行分片
• 程序中该分片之前已经得到该分片的Redis连接 connectMap<分片id, redis连接>并且不需要更新，则返回连接
• 获取该分片的配置信息【不同分片需要连接的redis服务器配置，例如IP、port】
• 进行Redis服务器连接，然后存储到connectMap并且返回

3、扩展复杂的查询

3.1 扩展联合查询

针对于sunionstore、sinterstore、sdiffstore、zunionstore、zinterstore等命令，不仅需要查询，而且还需要写入数据。但是从服务器只允许读取，不允许写入，怎么办？方法：将从服务器的slave-read-only配置选项的默认值yes修改为no，并且重启机器即可。、
需要注意的是，虽然这种能过在从服务器上写入，但是也仅限于执行这个语句的从服务器有这个写入的数据，其他的从服务器和主服务器都是没有这个写入数据的。

3.2 扩展分片排序

针对于分片的情况，想要获取排名在91-100之间的数据：

• 遍历所有的分片的数据，只需要获取每个分片的前100名数据即可
• 将获取到的所有分片数据合并到一起，进行排序，从而得到91-100的数据