In the last blog, we talked about the basic concepts and basic operations of redis. In this article, we will have a deeper understanding of some redis operations and concepts. We will learn about redis from three aspects: red master-slave synchronization, redis sentinel mode and redis cluster. database
1. Master-slave synchronization
Like MySQL, redis supports master-slave synchronization, and also supports one master, multiple slaves and multi-level slave structures. The master-slave structure is, firstly, for pure redundancy backup, and secondly, to improve read performance. For example, the performance-consuming SORT can be borne by the slave server. The master-slave synchronization of redis is performed asynchronously.
1. Master-slave synchronization principle
从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个从服务器。2. Deploy master-slave synchronization (one master and two slaves)
Deployment environment
192.168.91.5 redis-master
192.168.91.149 redis-slave-1
192.168.91.150 redis-slave-2
关闭防火墙和selinux
systemctl stop firewalld
systemctl disable firewalld #关闭防火墙
setenforce 0 #关闭selinuxModify master configuration file
# vim /usr/local/redis/redis.conf
bind 0.0.0.0
protected-mode noModify slave configuration file
#vim /usr/local/redis/redis.conf
bind 0.0.0.0
protected-mode no
replicaof 192.168.91.5Restart the redis service and check the port with netstat -nlpt
2. Sentry Mode
Sentinel mode is a tool used to monitor the Master status in redis master-slave replication, so our sentinel mode is based on master-slave replication.
1.Function
检测Master状态，如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave， Master-Slave切换后，sentinel的监控目标会随之调换 2. Working mode
1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线。
3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
ps:quorum 的值一般设置为哨兵个数的二分之一加1，例如 3 个哨兵就设置 2。3. Subjective offline and objective offline
主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel(哨兵) 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover(故障转移)4. Configure Sentry Mode
vim /usr/local/redis/sentinel.conf
daemonize yes #设置哨兵放后台运行
logfile "/var/log/sentinel.log" #设置哨兵日志
sentinel monitor mymaster 192.168.91.5 6379 2 #当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了。 (slave上面写的是master的ip，master写自己ip)
protected-mode no #将加密保护关闭
sentinel down-after-milliseconds mymaster 3000 #单位毫秒
sentinel failover-timeout mymaster 10000 #若sentinel在该配置值内未能完成failover(故障转移)操作（即故障时master/slave自动切换），则认为本次failover失败。
[root@redis-master redis]# ./src/redis-sentinel sentinel.conf #开启哨兵模式3. redis cluster
1. Reasons for using redis cluster
1.首先Redis单实例主要有单点，容量有限，流量压力上限的问题。
Redis单点故障，可以通过主从复制replication，和自动故障转移sentinel哨兵机制。但Redis单Master实例提供读写服务，仍然有容量和压力问题。
2.并发问题
redis官方声称可以达到 10万/每秒,每秒执行10万条命令
假如业务需要每秒100万的命令执行呢？
解决方案如下
正确的应该是考虑分布式，加机器，把数据分到不同的位置，分摊集中式的压力。那么一堆机器做一件事.还需要一定的机制保证数据分区，并且数据在各个主Master节点间不能混乱。
总结:
redis cluster:主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster2.Redis cluster features
1.所有的redis节点彼此互联(PING-PONG机制)。
2.客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
3.节点的fail是通过集群中超过半数的节点检测失效时才生效。
4.Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。3. Data distribution storage principle
Redis 集群使用数据分片来实现：Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数(集群使用公式 CRC16(key) % 16384)，这样每个key 都会对应一个编号在 0-16384 之间的哈希槽，那么redis就会把这个key 分配到对应范围的节点上了。同样，当连接三个节点任何一个节点想获取这个key时，也会这样的算法，然后内部跳转到存放这个key节点上获取数据。4. Cluster deployment
Prepare environment
1.准备三机器，关闭防火墙和selinux
2.制作解析并相互做解析。
注:规划架构两种方案，一种是单机多实例，这里我们采用多机器部署:
三台机器，每台机器上面两个redis实例，一个master一个slave，第一列做主库，第二列做备库
#记得选出控制节点
redis-cluster1 192.168.91.5 7000、7001
redis-cluster2 192.168.91.149 7002、7003
redis-cluster3 192.168.91.150 7004、7005Install redis (all three machines need to be operated)
yum -y install gcc automake autoconf libtool make #安装编译工具
wget https://download.redis.io/releases/redis-6.2.0.tar.gz #下载
tar xzvf redis-6.2.0.tar.gz -C /usr/local #解压
mv /usr/local/redis-6.2.0 /usr/local/redis #改名
cd /usr/local/redis
make #编译
mkdir /usr/local/redis/data #创建存放数据的目录Create node directory: Create the corresponding directory (named with the port number) in the installation directory of each redis node according to the plan
[root@redis-cluster1 redis]# pwd
/usr/local/redis
[root@redis-cluster1 redis]# mkdir cluster #创建集群目录
[root@redis-cluster1 redis]# cd cluster/
[root@redis-cluster1 cluster]# mkdir 7000 7001 #创建节点目录
[root@redis-cluster2 redis]# mkdir cluster
[root@redis-cluster2 redis]# cd cluster/
[root@redis-cluster2 cluster]# mkdir 7002 7003
[root@redis-cluster3 redis]# mkdir cluster
[root@redis-cluster3 redis]# cd cluster/
[root@redis-cluster3 cluster]# mkdir 7004 7005Copy the configuration file to the node directory
[root@redis-cluster1 cluster]# cp /data/redis/redis.conf 7000/
[root@redis-cluster1 cluster]# cp /data/redis/redis.conf 7001/
[root@redis-cluster2 cluster]# cp /data/redis/redis.conf 7002/
[root@redis-cluster2 cluster]# cp /data/redis/redis.conf 7003/
[root@redis-cluster3 cluster]# cp /data/redis/redis.conf 7004/
[root@redis-cluster3 cluster]# cp /data/redis/redis.conf 7005/Modify the cluster redis configuration file. (Mainly port, ip, pid files, same operation on three machines)
[root@redis-cluster1 7000]# vim redis.conf
bind 192.168.116.172 #每个实例的配置文件修改为对应节点的ip地址
port 7000 #监听端口，运行多个实例时，需要指定规划的每个实例不同的端口号
daemonize yes #redis后台运行
pidfile /var/run/redis_7000.pid #pid文件，运行多个实例时，需要指定不同的pid文件
logfile /var/log/redis_7000.log #日志文件位置，运行多实例时，需要将文件修改的不同。
dir /data/redis/data #存放数据的目录
appendonly yes #开启AOF持久化，redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中，当redis重新启动时，会从该文件恢复出之前的状态。
appendfilename "appendonly.aof" #AOF文件名称
appendfsync everysec #表示对写操作进行累积，每秒同步一次
以下为打开注释并修改
cluster-enabled yes #启用集群
cluster-config-file nodes-7000.conf #集群配置文件，由redis自动更新，不需要手动配置，运行多实例时请注修改为对应端口
cluster-node-timeout 5000 #单位毫秒。集群节点超时时间，即集群中主从节点断开连接时间阈值，超过该值则认为主节点不可以，从节点将有可能转为master
cluster-replica-validity-factor 10 #在进行故障转移的时候全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了导致数据过于陈旧，不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。
cluster-migration-barrier 1 #一个主机将保持连接的最小数量的从机，以便另一个从机迁移到不再被任何从机覆盖的主机
cluster-require-full-coverage yes #集群中的所有slot（16384个）全部覆盖，才能提供服务Note: When modifying all node configuration files, remember the IP, port, and pid files that need to be modified... to avoid conflicts. Make sure all machines are modified.
Start each node on the three machines
[root@redis-cluster1 src]# ./redis-server ../cluster/7000/redis.conf
[root@redis-cluster1 src]# ./redis-server ../cluster/7001/redis.conf
[root@redis-cluster2 7003]# cd /data/redis/src/
[root@redis-cluster2 src]# ./redis-server ../cluster/7002/redis.conf
[root@redis-cluster2 src]# ./redis-server ../cluster/7003/redis.conf
[root@redis-cluster3 7005]# cd /data/redis/src/
[root@redis-cluster3 src]# ./redis-server ../cluster/7004/redis.conf
[root@redis-cluster3 src]# ./redis-server ../cluster/7005/redis.confView port
netsata -lnpt #查看端口
After viewing this information, it means that our redis cluster has been successfully built.
4. Summarize the classic problems of redis in operation and maintenance
一、如何解决Redis，mysql双写一致性？
1.最经典的缓存+数据库读写的模式:
读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
更新的时候，先更新数据库，然后再删除缓存。
2.给缓存设置过期时间，这种方案下，可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。
二、缓存雪崩
数据未加载到缓存中，或者缓存同一时间大面积的失效，从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机。
产生雪崩的简单过程：
1、redis集群大面积故障
2、缓存失效，但依然大量请求访问缓存服务redis
3、redis大量失效后，大量请求转向到mysql数据库，mysql的调用量暴增，很快就扛不住了，甚至直接宕机
4、由于大量的应用服务依赖mysql和redis的服务，这个时候很快会演变成各服务器集群的雪崩，最后网站彻底崩溃。
解决问题：
1.缓存的高可用性
缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。
2.缓存降级
可以利用ehcache等本地缓存(暂时支持)，主要还是对源服务访问进行限流、资源隔离（熔断）、降级等。
当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。
降级的最终目的是保证核心服务可用，即使是有损的。
在进行降级之前要对系统进行梳理，比如：哪些业务是核心(必须保证)，哪些业务可以容许暂时不提供服务(利用静态页面替换)等，以及配合服务器核心指标，来后设置整体。
3.Redis备份和快速预热
1)Redis数据备份和恢复
2)快速缓存预热
4.提前演练
最后，建议还是在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前预演，提前发现问题。
三、缓存穿透
缓存穿透是指查询一个一不存在的数据。例如：从缓存redis没有命中，需要从mysql数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。
解决问题：
如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库。设置一个过期时间或者当有值的时候将缓存中的值替换掉即可。
四、redis有哪些好处
(1) 速度快，因为数据存在内存中.
(2) 支持丰富数据类型，支持string，list，set，sorted set，hash
(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
redis相比memcached有哪些优势
(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
(2) redis可以持久化其数据
redis常见性能问题和解决方案
(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库