1- 水平分区 VS 垂直分区

分区是分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集。有两种分区方式：水平分区、垂直分区。

1.1 分区的优势与不足

1. 优势

通过利用多台计算机内存的和值，允许我们构造更大的数据库。
通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽

2. 不足

涉及多个key的操作通常是不被支持的：

• 当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
• 涉及多个key的redis事务不能使用。
• 当使用分区时，数据处理较为复杂，比如你需要处理多个rdb/aof文件，并且从多个实例和主机备份持久化文件。
• 增加或删除容量也比较复杂。redis集群大多数支持在运行时增加、删除节点的透明数据平衡的能力，但是类似于客户端分区、代理等其他系统则不支持这项特性。

1.2 水平分区

水平分区是根据一些规则把同一业务单元的Key拆分到不同的Redis实例上。

1. 按Range水平分区

最简单的分区方式是按范围分区，就是映射一定范围的对象到特定的Redis实例
比如，ID从0到10000的用户会保存到实例R0，ID从10001到 20000的用户会保存到R1，以此类推。这种方式是可行的，并且在实际中使用，不足就是要有一个区间范围到实例的映射表。这个表要被管理，同时还需要各种对象的映射表，通常对Redis来说并非是好的方法。优点：规则简单、数据均衡性较好、比较容易扩展；缺点：请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大。

2. 对Key哈希水平切分

按照Key进行Hash，支持任意类型的Key，然后对得到的Hash值进行取模运算，分配到不同Redis实例上。优点：规则简单、数据均衡性较好、请求均匀性较好；缺点是：不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移。

1.3 垂直分区

垂直分区就是把一个Redis实例上的不同业务单元的Key拆分到不同的Redis实例上。

2- 持久化

Redis持久化方案主要有RDB和AOF，两者毫无关系，完全独立运行。

2.1 RDB文件

RDB是整个内存数据的压缩过的某一时刻的Snapshot快照，可以配置复合的触发RDB写的条件，默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

1. RDB写入时，会连内存一起Fork出一个新进程，遍历新进程内存中的数据写文件，这样就解决了些Snapshot过程中又有新的写入请求进来的问题。

2. RDB会先写到临时文件，完了再Rename，这样外部程序对RDB文件的备份和传输过程是安全的。而且即使写新快照的过程中Server被强制关掉了，旧的RDB文件还在。

3. 可配置是否进行压缩，压缩方法是字符串的LZF算法，以及将string形式的数字变回int形式存储。

4. 停止RDB保存规则的方法：redis-cli config set save “”

2.2 AOF文件

操作日志，记录所有有效的写操作，等于mysql的binlog，格式就是明文的Redis协议的纯文本文件。

1. 一般配置成每秒调用一次fdatasync将kernel的文件缓存刷到磁盘。当操作系统非正常关机时，文件可能会丢失不超过2秒的数据。 如果设为fsync always，性能很低，只剩几百TPS。如果设为no，靠操作系统自己的sync同步，Linux系统一般30秒一次。

2. AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件，最后再rename)， 遍历新进程的内存中数据，每条记录的Set语句。默认配置是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M时触发。

3. Redis协议，如set mykey hello， 将持久化成*3 $3 set $5 mykey $5 hello， 第一个数字代表这条语句有多少元，其他的数字代表后面字符串的长度。这样的设计，使得即使在写文件过程中突然关机导致文件不完整，也能自我修复，执行redis-check-aof即可。

2.3 RDB vs AOF

综上：

1. RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

2. 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

3. 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本简单load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。

4. 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。

3- 高可用与故障切换

Master-Slave复制与Fail-Over来实现真正的高可用

3.1 Master-Slave复制

slave可以在配置文件、启动命令行参数、以及redis-cli执行SlaveOf指令来设置自己是奴隶，设置 Slaveof no one，slave会立马变身master；Slave只可以接收客户端的读请求，兼有负载均衡的功能。

1. 复制速度：测试表明同步延时非常小，Master指令一旦执行完毕就会立刻写AOF文件和向Slave转发，除非Slave自己被阻塞住了。

2. 复制过程：先执行一次Master快照RDB的全同步 — slave请求Master的一个RDB Snapshot文件，slave接收完毕后，清除掉自己的旧数据，然后将RDB载入内存。**再进行增量同步 **— master作为一个普通的client连入slave，将所有写操作转发给slave，没有特殊的同步协议

详细步骤：
1） 在Slave启动并连接到Master之后，它将主动发送一个SYNC命令。
2）此后Master将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。
3） 而Slave服务器在接收到数据库文件数据之后将其存盘并加载到内存中。
4）此后，Master继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在依次执行这些数据修改命令，从而达到最终的数据同步。
5）如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。

3. 特点

• 同一个Master可以同步多个Slaves。
• Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。
• Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
• SlaveServer同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。
• 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高。
• Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。

4. 潜在的问题
   Slave从库在连接Master主库时，Master会进行内存存盘生成快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，这会给整个集群搭建带来非常多的问题。比如Slave由于网络或者其它原因与Master断开了连接，那么当 Slave进行重新连接时，需要重新获取整个Master的内存快照，Slave所有数据跟着全部清除，然后重新建立整个内存表，一方面Slave恢复的时间会非常慢，另一方面也会给主库带来压力。

3.2 Fail-Ove（sentinel）

Redis-sentinel是2.6版开始加入的另一组独立运行的节点，提供自动Fail Over的支持

3.2.1 发现 master/slave及其他sentinel

1. master地址在sentinel.conf里, sentinel会每10秒一次向master发送INFO，知道master的slave有哪些。

2. 如果master已经变为slave，sentinel会分析INFO的应答指向新的master。
3. 另外，sentinel会在master上建一个pub/sub channel，名为”sentinel:hello”，通告各种信息，sentinel们也是通过接收pub/sub channel上的sentinel的信息发现彼此，因为每台sentinel每5秒会发送一次自己的host信息，宣告自己的存在。

3.2.2 监测与切换过程：

1. Sentinel每秒钟对所有master，slave和其他sentinel执行Ping，redis-server节点要应答。

2. 如果某一台Sentinel没有在30秒内(可配置得短一些哦)收到上述正确应答，它就会认为master处于sdown状态(主观Down)，它向其他sentinel询问是否也认为该master倒了（SENTINEL is-master-down-by-addr ）;
3. 如果quonum台(默认是2)sentinel在5秒钟内都这样认为，就会认为master真是odown了(客观Down)。
4. 此时会选出一台sentinel作为Leader执行fail-over, Leader会从slave中选出一个提升为master(执行slaveof no one)，然后让其他slave指向它(执行slaveof new master)。

3.3 Redis高可用与故障转移架构设计

基于Sentinel + master/slave

上面虽然在server端完成了故障转移，但是对于客户端程序来说，Master切换后client并不知道新Master的IP地址，一种办法是client在访问Server之前都要询问一下Sentinel，获取Master的最新IP。但是明显获取一次数据需要访问两次，网络资源还是比较宝贵的，有一种对client无感更经济实惠的切换方法：VIP漂移。

基于Sentinel + master/slave + VIP漂移

VIP方案是，redis系统对外始终是同一ip地址，当redis进行故障转移时，需要做的是将VIP从之前的redis服务器漂移到现在新的主redis服务器上。

故障前

当前redis系统中主redis的ip地址是192.168.56.101，那么VIP（192.168.56.250）指向192.168.56.101，客户端程序用VIP（192.168.56.250）地址连接redis，实际上连接的就是当前主redis，这样就避免了向sentinel发送请求。

故障后

当主redis宕机，进行故障转移时，192.168.56.102这台服务器上的redis提升为主，这时VIP（192.168.56.250）指向192.168.56.102，这样客户端程序不需要修改任何代码，连接的是192.168.56.102这台主redis。

如何实现VIP漂移？

1. 以使用redis sentinel的一个参数client-reconfig-script，这个参数配置执行脚本，sentinel在做failover的时候会执行这个脚本。

2. 漂移VIP也可以使用keepalived软件来实现。