redis哨兵、集群、主从复制、持久化

至此，咱们了解并动手实践了redis的安装，redis单点，redis主从，redis 哨兵 sentinel，redis 集群cluster。
咱们来梳理一下redis主从，redis哨兵，redis机器的区别和关系。

redis主从：是备份关系， 咱们操做主库，数据也会同步到从库。 若是主库机器坏了，从库能够上。就比如你 D盘的片丢了，可是你移动硬盘里边备份有。
redis哨兵：哨兵保证的是HA，保证特殊状况故障自动切换，哨兵盯着你的“redis主从集群”，若是主库死了，它会告诉你新的老大是谁。
redis集群：集群保证的是高并发，由于多了一些兄弟帮忙一块儿扛。同时集群会致使数据的分散，整个redis集群会分红一堆数据槽，即不一样的key会放到不不一样的槽中。

主从保证了数据备份，哨兵保证了HA 即故障时切换，集群保证了高并发性。

一切动手作了才会熟悉。。

谈到Redis服务器的高可用，如何保证备份的机器是原始服务器的完整备份呢？这时候就须要哨兵和复制。

1. 哨兵(Sentinel)：能够管理多个Redis服务器，它提供了监控，提醒以及自动的故障转移的功能。
2. 复制(Replication)：则是负责让一个Redis服务器能够配备多个备份的服务器。

Redis正是利用这两个功能来保证Redis的高可用。

哨兵（sentinal）

哨兵是Redis集群架构中很是重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时须要人为干预的问题。

1.Redis哨兵主要功能

（1）集群监控：负责监控Redis master和slave进程是否正常工做

（2）消息通知：若是某个Redis实例有故障，那么哨兵负责发送消息做为报警通知给管理员

（3）故障转移：若是master node挂掉了，会自动转移到slave node上

（4）配置中心：若是故障转移发生了，通知client客户端新的master地址

2.Redis哨兵的高可用

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

1. 哨兵机制创建了多个哨兵节点(进程)，共同监控数据节点的运行情况。
2. 同时哨兵节点之间也互相通讯，交换对主从节点的监控情况。
3. 每隔1秒每一个哨兵会向整个集群：Master主服务器+Slave从服务器+其余Sentinel（哨兵）进程，发送一次ping命令作一次心跳检测。

这个就是哨兵用来判断节点是否正常的重要依据，涉及两个新的概念：主观下线和客观下线。

1. 主观下线：一个哨兵节点断定主节点down掉是主观下线。

2.客观下线：只有半数哨兵节点都主观断定主节点down掉，此时多个哨兵节点交换主观断定结果，才会断定主节点客观下线。

3.原理：基本上哪一个哨兵节点最早判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程。

Redis 复制(Replication)

Redis为了解决单点数据库问题，会把数据复制多个副本部署到其余节点上，经过复制，实现Redis的高可用性，实现对数据的冗余备份，保证数据和服务的高度可靠性。

1.数据复制原理（执行步骤）

①从数据库向主数据库发送sync(数据同步)命令。

②主数据库接收同步命令后，会保存快照，建立一个RDB文件。

③当主数据库执行完保持快照后，会向从数据库发送RDB文件，而从数据库会接收并载入该文件。

④主数据库将缓冲区的全部写命令发给从服务器执行。

⑤以上处理完以后，以后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库。

注意：在Redis2.8以后，主从断开重连后会根据断开以前最新的命令偏移量进行增量复制。

Redis 主从复制、哨兵和集群这三个有什么区别

 

1.主从模式：读写分离，备份，一个Master能够有多个Slaves。

2.哨兵sentinel：监控，自动转移，哨兵发现主服务器挂了后，就会从slave中从新选举一个主服务器。

3.集群：为了解决单机Redis容量有限的问题，将数据按必定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。

哨兵做用于高可用，集群提升并发量，具体Redis集群方案详情，能够参考：高并发架构系列：详解Redis的存储类型、集群架构、以及应用场景

 

 

 

2、持久化        那么这么多，这么重要的数据都存储在内存中，若是忽然断电，岂不是很糟糕，因而就有了数据的持久化机制，这个其实就是把内存中的数据存储到硬盘中，方便数据的持续存在，也能够减小断电形成的损失。        那么咱们怎么持久化数据呢？多长时间进行一次持久化呢？redis 支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另外一种是 Append-only file（缩写 aof）的方式。下面分别介绍：     一)、Snapshotting         快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。能够经过配置设置自动作快照持久化的方式。咱们能够配置 redis在 n 秒内若是超过 m 个 key 被修改就自动作快照，下面是默认的快照保存配置：    save 900 1 #900 秒内若是超过 1 个 key 被修改，则发起快照保存    save 300 10 #300 秒内容如超过 10 个 key 被修改，则发起快照保存    save 60 10000下面介绍详细的快照保存过程：        1.redis 调用 fork,如今有了子进程和父进程。        2. 父进程继续处理 client 请求，子进程负责将内存内容写入到临时文件。因为 os 的实时复制机制（ copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时 os 会为父进程要修改的页面建立副本，而不是写共享的页面。因此子进程地址空间内的数据是 fork时刻整个数据库的一个快照。        3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，而后子进程退出。client 也可使用 save 或者 bgsave 命令通知 redis 作一次快照持久化。 save 操做是在主线程中保存快照的，因为 redis 是用一个主线程来处理全部 client 的请求，这种方式会阻塞全部client 请求。因此不推荐使用。另外一点须要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并非增量的只同步变动数据。若是数据量大的话，并且写操做比较多，必然会引发大量的磁盘 io 操做，可能会严重影响性能。       二)、AOF方式        因为快照方式是在必定间隔时间作一次的，因此若是 redis 意外 down 掉的话，就会丢失最后一次快照后的全部修改。若是应用要求不能丢失任何修改的话，能够采用 aof 持久化方式。下面介绍 Append-only file:aof 比快照方式有更好的持久化性，是因为在使用 aof 持久化方式时,redis 会将每个收到的写命令都经过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会经过从新执行文件中保存的写命令来在内存中重建整个数据库的内容。固然因为 os 会在内核中缓存 write 作的修改，因此可能不是当即写到磁盘上。这样 aof 方式的持久化也仍是有可能会丢失部分修改。不过咱们能够经过配置文件告诉 redis 咱们想要经过 fsync 函数强制 os 写入到磁盘的时机。有三种方式以下（默认是：每秒 fsync 一次）    appendonly yes //启用 aof 持久化方式    # appendfsync always //收到写命令就当即写入磁盘，最慢，可是保证彻底的持久化    appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面作了很好的折中    # appendfsync no //彻底依赖 os，性能最好,持久化没保证        aof 的方式也同时带来了另外一个问题。持久化文件会变的愈来愈大。例如咱们调用 incr test命令 100 次，文件中必须保存所有的 100 条命令，其实有 99 条都是多余的。由于要恢复数据库的状态其实文件中保存一条 set test 100 就够了。为了压缩 aof 的持久化文件。 redis 提供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照相似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。