引言：对于使用Redis服务器存储数据的大型网站来说，如果仅仅使用一台Redis服务器的话，不仅数据存储速度得不到保证，而且存在很大的风险，一旦该机出现问题（例如数据丢失，磁盘损坏等），就会对网站运行造成不利影响。搭建Redis服务器集群，可以很好的解决该问题。如果主服务器宕机，只需简单修改Redis配置文件，就可以让从服务器担当数据管理任务。

Redis的持久化模式

从运维角度上看，需要了解Redis的持久化概念。持久化指的是将数据存储到断电后不会丢失的设备中，例如将内存中的数据保存到硬盘中等。Redis支持RDB和AOF两种持久化方式。对于前者来说，是基于内存快照的持久化方式，其工作原理是每隔几分钟或者几次写操作后，在某一瞬间从内存DUMP数据形成RDB文件，并将其压缩保存到指定的目录。因为其存储的是整体内存镜像数据，所以在恢复时速度很快。RDB的配置信息保存在“redis.conf”文件中。

执行“vim redis.conf”命令，其中的“save 900 1”行表示在 900秒内，如果有1条写入则产生快照。

“save 300 1000”行的作用是如果300秒内有1000次数据写入则产生快照。“save 60 10000”行的作用是如果在60秒内有10000次数据写入则产生快照。如果将以上三行配置全部屏蔽，则禁用RBD快照功能。

“stop-writes-onbgsave-error”行的作用是当后台备份进程出错时，主进程是否停止写入，“yes”表示确认，“no”表示否认。

“rdbcompression”行的作用是是否对导出的rdb文件进行压缩。

“Rdbchecksum”行的作用是当导入rbd镜像进行数据恢复时，是否检验rdb的完整性。

“dbfilename”行的作用是指定导出的rdb文件名，“dir”行的作用是指定rdb文件的存储路径，默认放置在当前路径。当Redis服务器运行出现故障时（例如断电等），当重启Redis服务时，其会自动从RDB文件中恢复数据。

使用RDB快照实现数据持久化，存在一个明显的问题。因为其只能在指定的时间间隔内对从内存中DUMP数据形成RDB镜像文件，如果在前一个快照完成但后一个快照没有创建之间突然断电，这期间的数据显然无法保存。

为了实现更加精细的持久化，Redis提供了AOF日志记录功能，可以将所有的操作命令记录下来形成日志文件，这样即使Redis出现异常情况，也可以利用日志进行数据的快速恢复。当然，RDB和AOF两种方案可以并存。

执行“vim redis.conf”命令，将“appendonly”行的值设置为“yes”，表示启用AOF功能，在“appendfilename”栏中可以更改日志文件存储路径。在“appendfsync”栏中设置同步方式，设置为“always”，表示将每一个命令都立即同步到aof日志中。设置为“everysec”表示每秒同步一次，设置为“no”，表示将入同步工作交给操作系统处理，由操作系统判断缓冲区大小并统一写入到aof日志文件中，其特点是同步频率低但速度快。

在“no-appendfsync-onrewrite”栏中设置当正在导出rdb快照的过程中是否停止同步aof日志，在“autoaof-rewrite-percentage 100”栏中设置aof日志重写条件，如果当前的aof文件大小比上次重写时的大小增长率100%时，则执行重写操作。

重写是指把内存中的数据，逆化成命令写入到aof日志中。之所执行重写，为的是避免在aof日志中存储大量的冗余数据。例如对某个变量累加了100次，如果执行重写操作，则只记录最有一次计算结果。利用重写机制，可以大大减小aof文件的体积。在“auto-aofrewrite-min-size”栏中设置执行重写操作时，aof的最小体积。默认为64MB，即当aof文件大于64MB时，必须执行重写操作。

当启动AOF日志记录功能后，当Rides服务出现异常，当重启Redis服务后，可以发现数据得到很好的恢复。同RDB快照机制相比，AOF的数据恢复速度较慢，因为RDB是数据的内存映射，直接载入到内存，而aof是命令记录需要逐条执行。

搭建Redis群集

一般来说，Redis群集结构包括星形和线形等类型。对于前者来说，多台Slave服务器共同为一台Master服务器提供服务。对于后者来说，多台Slave服务器之间也存在着从属关系，例如当 Master宕 机 后，Slave1服务器可以变为主服务器，Slave2自动变为其从服务器。

要想搭建Redis集群，必须了解集群的主从通信原理，即主动服务器之间是如何进行同步的。当Slave服务器启动后，确定了其从属的Master服务器，其会自动连接到Master主机，并发出同步请求，Master主机通过Dump操作从内存中抓取RDB镜像，并将其该RDB镜像传送给Slave主机，Slave主机直接在内存中恢复该镜像，这样两者的内存数据实现了同步。

当 然，Master主 机 的Redis中的命令和数据是不断变化的，这些数据会缓存到内存中的AOF队列中，之后将AOF数据同步到Slave主机上。这样，就实现了主从复制操作。以后当Mater主机数据发生变动后，就会通过ReplicationFeedSlaves进程通知Slave主机及时进行同步。

在本例中，使用了星形的群集结构，一台名为Master的服务器，两台名称分别为Slave1和Slave2的从服务器。在这三台主机上都安装好Redis。

在Slave1上 执 行“vim redis.conf” 命 令，打开其配置文件，在其中的“dbfilename”栏中可以更改RDB文件的存储路径。删除“slave of ”一行前面的“#”字符，激活其从服务器功能，并将其修改为“slave of 192.168.1.10 6379”，其 中 的“192.168.1.10”为Master服务器的IP，TCP 6379为通讯端口。在“slave-read-only” 行 中确保其值 为“yes”，即 让Slave1处于只读状态。将“appendonly”行的值修改为“no”，禁止其执行AOF日志功能。其余的设置保持不变，保存该配置文件。在Slave2上执行同样的命令，对Redis配置文件进行同样的修改，所不同的是，需要将其中的“save 900”，“save 300 10”，“save 60 3000”等 行的前面添加“#”符号，将其屏蔽掉，这样就关闭了其RDB功能，即不允许其抓起内存快照。

因为创建RDB快照比较消耗IO资源，既然Slave1已经默认开启了创建RDB快照的功能，Slave2就没有必要执行相同的操作了。这样，两台从服务器就配置完成了。对于Master服务器来说，执行“vim redis.conf”命令，按照同样的方法，禁用RDB功能，因为创建RDB快照的功能已经交由Slave1完成。在主从服务器上分别执行“./bin/redisserver redis.conf”命令，来启动Redis服务。这样，Redis群集就已经开始运作了。之后可以对其进行测试，在Master上 执 行“./bin/redis-cli”命令，连接完成后，执行“set name xxx”命令，创建一个Key变量。当连接到上述Slave服务器，执行“keys *”命令，可以发现上面建立的Key值。

但是，当试图在从服务器上对指定的Key值进行修改时，系统会显示“(error)Readonly You cant’t write against a read only slave”内容，禁止执行写操作，防止主从服务器之间出现数据不一致的情况。由此看出，Redis群集的搭建可谓简单，对于Master服务器来说，可以关闭RDB快照功能，将数据备份工作交给从服务器完成，可以根据需要开启AOF日志功能。

对于Slave从服务器来说，需要声明其从属身份，针对某个Slave主机开启RDB快照功能，并将其设置为只读功能。

为了提高安全性，可以根据需要为群集配置密码。其方法是在主从服务器上分别打开Redis配置文件，将其中的“requirepass foobared”行前面的“#”符号删除，激活其密码保护功能，将默认的“foobared”的密码修改为所需的密码。

设置了密码后，当连接到主Redis服务器后，需要执行“Auth xxxx”命令，其中的“xxxx”表示具体的密码，授权通过后，才可以执行各种指令。对于从服务器来说，则直接使用该密码和主服务器进行通讯。

对于Redis群集来说，其实际上是存在某些缺陷的。即当Slave主机因为各种原因和主服务器断开后，当其再次连接Master主机时，都要再次通过Dump操作从Master主机内存中抓取RDB镜像，并将其该RDB镜像传送给Slave主机，Slave主机直接在内存中恢复该镜像。同时将Master主机上AOF数据同步到Slave主机上。

在这种情况下，不要将所有的Slave服务器全部启动起来，否则很可能导致Master主机的IO吞吐量剧增，处理方法是分时逐台启动Slave服务器，以降低Master主机的工作压力。