浅谈小白如何读懂Redis高速缓存与持久化并存及主从高可用集群

Redis是一个基于键值（K-V）的高速缓存软件，和他具有相同功能的软件有memcached，但其支持更为复杂的数据结构，例如：List,set,sorted set,同时redis具有持久性功能。redis究竟是什么？对于不同的应用场合，对redis的理解也不相同，如下有三种不同的理解。  

    ①key value store(键值存储),是一个以键值形式存储的数据库，用来作为唯一的存储系统，同时借助于sentinel实现一定意义上的高可用。

    ②memory cached(内存缓存),是一个把数据存储在内存中的高速缓存，在应用中用来实现高效的响应用户请求。

    ③data structrue server(数据结构服务),支持对复杂数据库结构的高速操作例如：list,string,hash,set,stored等，提供某特殊业务操作。

redis的优势：

    ①丰富的操作，例如：hash,list,set,stored,sets.

    ②内建复制(replication)及其集群(cluster)

    ③就地更新操作，而无需停机重启生效

    ④支持持久缓存，常用的有RDB和AOF

基本架构图：  

原理：redis工作时，将启动一个fork函数创建一个子进程，复制当前进程，存为副本，父进程任然接受并处理客服端请求，而子进程则将内存中的数据文件写入磁盘中的临时文件，当子进程完成所有的写入操作时会将原来的件替换成最新生成的临时文件。

redis持久性分为两种：RDB(Redis datebase)和AOF(append only file),同时，RDB和AOF可同时使用，但BGSAVE和BGWRITEAOF不会同时执行，在redis服务器启动用于恢复数据时将会优先使用AOF。持久的功能是用于恢复，但持久本身不能取代备份，还应该制定备份策略，对redis进行数据库备份，保证数据的完整性。

RDB:此方式基于快照实现，该持久化方式是在redis内部有一个定时器，每隔固定时间去检查当前数据发生改变的次数与时间是否满足配置的持久性触发的条件，如果满足则通过操作系统启动一个fork函数调用来创建出一个字进程，这个子进程默认会与父进程共享相同的地址空间，这时就可以通过子进程来遍历整个内存来进行存储操作，而主进程则仍然可以提供服务，当有写入时由操作系统按照内存页(page)为单位来进行copy-on-write保证父子进程之间不会互相影响。该持久化的主要缺点是定时快照只是代表一段时间内的内存映像，所以系统重启会丢失上次快照与重启之间所有的数据。

编辑/etc/redis.conf可查看相应的配置参数及其意义

AOF:redis主进程通过fork创建子进程，子进程根据redis内存中的数据库重构后将此存储于临时文件中，父进程继承客服端的请求，并会把这些请求中的操作继续追加至原来的AOF文件，额外的这些新的写请求还会被放置于一个缓冲队列中，父进程把缓冲中的命令写到临时文件中，子进程重写完成会通知父进程，父进程用临时文件替换原来的AOF老文件。

AOF方式实际类似mysql的基于语句的binlog方式，即每条会使Redis内存数据发生改变的命令都会追加到一个log文件中，也就是说这个log文件就是Redis的持久化数据。

AOF的方式的主要缺点是追加log文件可能导致体积过大，当系统重启恢复数据时如果是aof的方式则加载数据会非常慢，几十G的数据可能需要几小 时才能加载完，当然这个耗时并不是因为磁盘文件读取速度慢，而是由于读取的所有命令都要在内存中执行一遍。另外由于每条命令都要写log,所以使用aof 的方式，Redis的读写性能也会有所下降。

AOF对日志文件的写入操作时采用追加的模式进行，因此写入的过程中如果发生断电，机器宕机等情况发生，也不会对已存在数据文件造成破坏。

Redis持久化磁盘IO方式及其带来的问题

有Redis线上运维经验的人会发现Redis在物理内存使用比较多，但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题，有人认为是基于快照方式持久化的fork系统调用造成内存占用加倍而导致的，这种观点是不准确的，因为fork用的copy-on-write机制是基于操作系统页这个单位的，也就是只有有写入的脏页会被复制，但是一般你的系统不会在短时间内所有的页都发生了写入而导致复制，那么是什么原因导致Redis崩溃的呢？

答案是Redis的持久化使用了Buffer IO造成的，所谓Buffer IO是指Redis对持久化文件的写入和读取操作都会使用物理内存的Page Cache,而大多数数据库系统会使用Direct IO来绕过这层Page Cache并自行维护一个数据的Cache，而当Redis的持久化文件过大(尤其是快照文件)，并对其进行读写时，磁盘文件中的数据都会被加载到物理内 存中作为操作系统对该文件的一层Cache,而这层Cache的数据与Redis内存中管理的数据实际是重复存储的，虽然内核在物理内存紧张时会做 Page Cache的剔除工作，但内核很可能认为某块Page Cache更重要，而让你的进程开始Swap ,这时你的系统就会开始出现不稳定或者崩溃了。我们的经验是当你的Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了。

redis主从复制和大部分主从类似，一个master可以有多个slave，支持链式复制，master以非阻塞的方式同步数据至slave。启动一个slave后，slave会向主发送同步命令，请求同步主库上的数据，master将启动一个后台的子进程，将数据快照保存至在数据文件中，把数据文件发送给slave，slave将数据文件保存至本地中，在本地重建数据库后载入内存，同步完成。   

redis主从的特点：

1、redis使用异步复制，从服务器会以每秒一次的频率向主服务器报告复制流的处理进度

2、一个主服务器可以有多个从服务器，从服务器也可以有自己的从服务器(级联复制)

3、复制功能不会阻塞主服务器，即使一个或多个从服务器正在进行初次同步，主服务器也可以继续处理命令请求

4、复制功能可以用于数据冗余，也可以通过让多个从服务器处理只读命令请求来提升扩展性

5、Redis从节点默认为只读，无须手动配置,redis的主从集群可以实现分担压力的效果，但是无法做到高可用，如果master宕掉，服务就不可用了，所以使用redis的sentinel可以实现HA的功能。

主从实战配置：

编辑/etc/redis.conf配置文件，将bind改为本机IP地址，重启服务即可。

主节点相关配置参数如下：

配置node2为从节点，并打印相关信息

在主中插入数据，查看从中是否已经同步完成

Sentinel是一个管理redis实例的工具，它可以对现有的redis进行监控、通知、故障自动转移，sentinel不断的检测redis实例是否可以正常的工作，通过API向其他程序报告redis的转台，如redis master不能工作，则会自动启动故障转移进程，将其中一个slave提升为master，其他slave将从新设置新的master服务器，而故障的master再次启动后会被sentinel自动降级为slave。

基本架构图：

Sentinel作用如下：

1、监控：sentinel会不断的检查你的主服务器和从服务器是否运行正常

2、当被监控的某个redis服务器出现问题时，sentinel可以通过API向管理员或者其他应用程序发送通知

3、故障自动转移：当一个主服务器不能正常工作时，sentinel会开始一次自动故障转移操作，他会将其中一个从服务器升级为新的主服务器，并将其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

redis sentinel在监控redis实例时有两种redis宕机状态S_DOWN和O_DOWN：

S_DOWN:当sentinel在指定的超时时间内没有收到一个正确的ping回复值，则认为是S_DOWN

O_DOWN:O_DOWN的条件是有足够多的sentinel认为该redis实例是S_DOWN。

注意：O_DOWN只能是发生在主服务器，sentinel和其他从服务器不会发生O_DOWN

Sentinel监控管理redis实战配置：

本实验在一台服务器上可完成实验，本实验使用node1附加上面配合的主从完成sentinel高可用测试实验。

分别使用不同的配置文件启动redis服务

使用slaveof命令把主节点设置为本机的6381端口

启动sentinel监控器节点状态

模拟redis-server 6381除故障可以将此进程kill掉，查看主节点是否转移

查看redis-server的6380端口是否成为主节点

总结：Redis持久性中的RDB是基于快照方式，意外重启会丢失数据，而AOF对日志文件的写入操作时采用追加的模式进行，因此写入的过程中如果发生断电，机器宕机等情况发生，也不会对已存在数据文件造成破坏。在考虑数据的完整性可根据自己的业务可同时使用AOF和RDB，保证了数据的完整性，但是redis持久性并不代表备份，还需制定相关的备份方案，对redis已有的数据进行备份。重新启动Redis，在redis服务器启动用于恢复数据时，会优先考虑使用AOF。

作者：小耳朵

来源：http://purify.blog.51cto.com/10572011/1882941