redis

灵魂拷问1：如何保证redis高并发/支撑10万+的并发，应该怎么做？

单机redis，能够承载的QPS大概在上万到几万不等。如果是十几万，就不行啦。

方案：用主从模式实现读写分离。
一般来说，对于缓存，都是读的高并发，写是比较少的。
架构是主从架构，一主多从，主负责写，并把数据同步复制到其他的slave节点，slave节点只负责读。
如果读的请求量增加，继续增加redis slave即可，水平扩容。

灵魂拷问2：redis的主从复制（redis replication）原理？

2.1 主从架构的整体框架

2.1.1 redis采用异步的方式复制数据到slave，redis 2.8 之后，slave node 会周期性确认自己复制的数据量。
2.1.2 一个master可以配置多个slave node
2.1.3 slave node 可以连接 奇特slave node
2.1.4 slave node做复制，不会block master的正常写操作的
2.1.5 slave node做复制，也不会block自己的查询服务，会有旧的数据，复制完成之后，需要加在新的数据的时候，是会暂停对外服务的
2.1.6 slave node主要做横向扩容，做读写分离，提高读的吞吐量

2.2 主从架构的核心原理

1.在本地保存master node 的host 和 IP
2.slave内部有定时任务，检查是否有master要连接，如果发现，就跟master node 建立socket 连接
3.如果master配置了认证，则slave发送口令认证
4.第一次连接，会全量复制（紫色部分），否则用异步的方式同步数据（橙色部分）

2.3 主从架构的断点续传

如果在主从复制的过程中，网络断掉了，那么一旦重新建立连接，是可以继续从上次复制的地方继续下去的。
（1）、offset
master和slave都会维护一个offset，slave每秒上报自己的offset给master。master和slave都要知道自己数据的offset，才能知道数据不一致的情况。
（2）、backlog
master node 里有backlog，给slave同步数据的时候，也会在backlog里写一份，主要是用来做全量复制过程中的增量复制的。

2.4 无磁盘复制

可以把RDB放在内存里，发送给slave。

2.5 过期key处理

slave是不会主动处理过期key的，都是master处理了之后，发送一个del的命令给slave。

2.6 heartbeat

主从节点互相都会发送heartbeat信息，master默认每隔10s发一次，slave 每隔1s发送一次。

灵魂拷问3：主从架构下如何保证高可用？

slave 故障时，对系统是没有影响的。
但是当master故障时，写功能将无法实现，则会导致整体不可用。
故障转移，也叫做主备切换。master node 故障时，自动检测，并且将某个slave node 自动切换为 master node。
通过哨兵实现高可用。

灵魂拷问4：redis的哨兵原理 sentinel

4.1 哨兵的主要功能

（1）、集群监控，负责监控redis master和slave进程是否工作
（2）、消息通知，如果实例有故障，则哨兵负责将消息报警通知给管理员
（3）、故障转移，如果master挂了，自动转移到slave node
（4）、配置中心，如果故障转移发生了，通知client客户端新的master地址
哨兵本身也是分布式的。
（1）、故障转移时，master 宕机了，需要大部分哨兵共同投票选举。
（2）、部分哨兵节点挂掉了，集群也可以是正常工作的，哨兵是保证redis高可用的，如果哨兵挂掉了，那就很不好了。

4.2 哨兵的核心知识

哨兵至少有三个。
why？如果是两个哨兵，那么2的大部分是2，如果master node所在的机器直接挂掉了，那么哨兵1也就挂掉了，只剩下一个哨兵2，数量<2，则永远无法满足故障转移的条件。

如果是三个哨兵，那么只要数量大于2就可以进行故障转移，那么挂掉一个也是可以执行的。

4.3 哨兵+主从 导致的数据丢失问题

（1）、异步复制导致的数据丢失问题
数据写入到master之后，还未同步，master挂掉了，那么哨兵把slave提升成master了，但是数据还是丢了的。

（2）、脑裂导致的数据丢失
slave和哨兵在一个网络里，master在一个网络里，当因为网络故障等原因，哨兵联系不到master了，以为master挂掉了，把slave提升成master了。 但其实master并没有挂，用户很有可能写了一些数据进去，当网络恢复时，master可能会自己变成slave，挂在新的master下，那么，网络故障时写入的数据就会丢失。

4.3.1 如何解决呢？

两个参数。
min-slaves-to-write 1 //至少有1个slave
min-slaves-to-lag 10 //数据复制和同步的延迟不能超过10s
如果所有的slave的延迟都超过了10s，那么master将不再接收写请求。客户端遇到这种情况，可以临时将数据写在其他地方。

4.4 哨兵的原理

4.4.1 sdown和odown

sdown 主观宕机，一个哨兵觉得master宕机了，就是主观宕机；
odown 客观宕机，quonum数量的哨兵都觉得master宕机了，就是客观宕机。

4.4.2 哨兵和slave集群的自动发现机制

哨兵互相之间的发现，都是通过redis的pub/sub系统实现的，每个哨兵都会往自己监控的节点上发送消息，其他哨兵也都会监听到。

4.4.3 slave配置的自动纠正

哨兵把slave提升master，它会通知剩余的slave更新配置，连接到新的master。

4.4.4 slave->master选举算法

（1）、判断slave与master断开连接的事件，如果时间大于配置的时间乘以10+master宕机的时间，则不予考虑
down-after-millisecond * 10 + millisecond_since_master_is_in_SDOWN_state
（2）、按照slave的优先级排序 slave priority越低，优先级越高
（3）、优先级相等，看replica offset，offset越靠后（复制的数据多），优先级越高
（4）、如果都相等，则比较run id，小的则优先级越高

4.4.4 quonum和majority

quonum < majority , majority为标准。比如有5个哨兵，quonum = 2，majority = 3，那么3个以上的哨兵都同意，才能sdown转odown，也才能正式切换。
quonum >= majority，quonum为标准。比如有5个哨兵，quonum = 5，majority = 3，那么5个哨兵都同意，才能sdown转odown，也才能正式切换。

4.4.4 configuration epoch

哨兵会对一套master+slave进行监控，切换时，生成的版本号都是唯一的。

4.4.4 configuration 传播

哨兵切换完成以后，会在自己本地生产更新最新的master配置，然后同步给其他哨兵，每个哨兵都根据版本号大小同步最新的配置。