一、主从redis架构进行QPS压测&水平扩容支撑更高QPS
如何对自己刚刚搭建好的redis做一个基准的压测，测一下你的redis的性能和QPS（query per second）
redis自己提供的redis-benchmark压测工具，是最快捷最方便的，当然啦，这个工具比较简单，用一些简单的操作和场景去压测
1、对redis读写分离架构进行压测，单实例写QPS+单实例读QPS
- 进入到redis根目录的src下
./redis-benchmark -h 你的ip
-c <clients> Number of parallel connections (default 50)
#模拟有多少个客户端发送请求
-n <requests> Total number of requests (default 100000)
#总共上面的客户端发送多少请求
-d <size> Data size of SET/GET value in bytes (default 2)
#每个数据的大小
根据你自己的高峰期的访问量，在高峰期，瞬时最大用户量会达到10万+，-c 100000，-n 10000000，-d 50
各种基准测试，直接出来
大部分情况下来说，看你的服务器的机器性能和配置，机器越牛逼，配置越高
单机上十几万，单机上二十万
很多公司里，给一些低配置的服务器，操作复杂度
几万，单机做到，差不多了
redis提供的高并发，至少到上万，没问题
几万~十几万/二十万不等
QPS的两个杀手：
- 一个是复杂操作，lrange，挺多的;
- value很大，2 byte，我之前用redis做大规模的缓存
2、水平扩容redis读节点，提升度吞吐量
就按照上一节课讲解的，再向其他服务器上搭建redis从节点，单个从节点读请QPS在5万左右，两个redis从节点，所有的读请求打到两台机器上去，承载整个集群读QPS在10万+，不行就再加从节点
二、redis主从架构下如何才能做到99.99%的高可用性
0、什么是系统不可用？
1、什么是99.99%高可用？
让系统在全年99.9999%都是可以对外服务，可以用的
架构上，高可用性，99.99%的高可用性
讲的学术，99.99%，公式，系统可用的时间 / 系统故障的时间，
365天，在365天 * 99.99%的时间内，你的系统都是可以哗哗对外提供服务的，那就是高可用性，99.99%
系统可用的时间 / 总的时间 = 高可用性，然后会对各种时间的概念，说一大堆解释
2、redis不可用是什么？单实例不可用？主从架构不可用？不可用的后果是什么？
- redis集群中，master节点宕机代表该redis系统不可用状态，因为master是执行写操作，slave执行读操作，当master宕机，那整个服务中就没有一个能进行写缓存操作，并且不能向其他的slave节点数据复制，一次就相当于整个缓存系统不可用，大量的请求去请求mysql，于是mysql宕机，于是整个系统就宕机死亡
3、redis怎么才能做到高可用？
- 使用redis
哨兵机制来保证
三、哨兵架构的相关基础知识
1、哨兵的介绍
sentinal，中文名是哨兵
哨兵的主要功能如下：
- （1）集群监控，负责监控redis master和slave进程是否正常工作
- （2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
- （3）故障转移，如果master node挂掉了，会自动转移到slave node上
- （4）配置中心，如果故障转移发生了，通知client客户端新的master地址
哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作
- （1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
- （2）即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了
目前采用的是sentinal 2版本，sentinal 2相对于sentinal 1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单
2、哨兵的核心知识
- （1）哨兵至少需要3个实例，来保证自己的健壮性
- （2）哨兵 + redis主从的部署架构，是
不保证数据零丢失的，只保证redis集群的高可用性 - （3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练
3、为什么redis哨兵集群只有2个节点无法正常工作？
哨兵集群必须部署2个以上节点
如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1
Configuration: quorum = 1
master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移
同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移
但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行
4、经典的3节点哨兵集群
Configuration: quorum = 2，majority
如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移
同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移
四、哨兵主备切换的数据丢失问题：异步复制、集群脑裂
1、两种数据丢失的情况
主备切换的过程，可能会导致数据丢失
（1）异步复制导致的数据丢失
因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了
（2）脑裂导致的数据丢失
脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着，因为网络问题获取不到master节点的情况
此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master
这个时候，集群里就会有两个master，也就是所谓的脑裂
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了
因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据
2、解决异步复制和脑裂导致的数据丢失
- redis配置文件中的配置：
min-slaves-to-write 1
min-slaves-max-lag 10 #减少异步复制导致数据丢失影响
#也就是说slave比master数据落后超过10秒钟，超过10秒后master会拒绝写请求保证与slave通过异步复制，数据丢失的量保持在可控的范围内
#上面两个参数的意思是：
# 要求至少有1个slave，数据复制和同步的延迟不能超过10秒
# 如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了
上面两个配置可以减少异步复制和脑裂导致的数据丢失
（1）减少异步复制的数据丢失
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
（2）减少脑裂的数据丢失
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，让master检查他所有下面的slave的数据延迟要求不低于10秒，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求
这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失
上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求
因此在脑裂场景下，最多就丢失10秒的数据
