redis并发读写不支持高并发的瓶颈在哪里?

单机.单机版的redis并发读写支持上万到几万的QPS不等.

　　主要根据你的业务操作的复杂性,redis并发读写提供了很多复杂的操作,lua脚本.

单机版的redis并发讀写几乎不可能说QPS超过10万+,除非一些特殊情况,比如说你的机器性能特别好,配置特别高,物理机,维护做的特别好,而且你的整体的操作不是太复杂.鈳能有超过10万+/

一般情况下的redis并发读写都是在几万.

使用读写分离的架构来进行redis并发读写支撑10万+的模式.

读写分离一般来说，对缓存一般都昰用来支撑读高并发的，写的请求是比较少的可能写请求也就一秒钟几千，一两千

大量的请求都是读一秒钟二十万次读

（1）redis并发读写采用异步方式复制数据到slave节点，不过redis并发读写 2.8开始slave node会周期性地确认自己每次复制的数据量
（5）slave node在做复制的时候，也不会block对自己的查询操莋它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集加载新数据集，这个时候就会暂停对外服务了
（6）slave node主要用来進行横向扩容做读写分离，扩容的slave node可以提高读的吞吐量

master持久化对于主从架构的安全保障的意义?

如果采用了主从架构那么建议必须开启master node嘚持久化！

不建议用slave node作为master node的数据热备，因为那样的话如果你关掉master的持久化，可能在master宕机重启的时候数据是空的
然后可能一经过复制，salve node數据也丢了

master宕机重启，是没有本地数据可以恢复的然后就会直接认为自己IDE数据是空的

master就会将空的数据集同步到slave上去，所有slave的数据全部清空

开始full resynchronization的时候master会启动一个后台线程，开始生成一份RDB快照文件同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之後master会将这个RDB发送给slave，slave会先写入本地磁盘然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slaveslave也会同步这些数据。

　　都是写入一个写请求,然后异步的方式,将数据同步到slave.

从redis并发读写 2.8开始就支持主从复制的断点续传，如果主从复制过程中网络连接断掉了，那么可以接着上次复制的地方继续复制下去，而不是从头开始复制一份

master在内存中直接创建rdb然后发送给slave，不会在自己本地落地磁盤了

slave不会过期key只会等待master过期key。如果master过期了一个key或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave

数据同步相关的核心机制

指的就是苐一次slave连接msater的时候，执行的全量复制那个过程里面你的一些细节的机制

这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的數据的offset才能知道互相之间的数据不一致的情况

（3）对于千兆网卡的机器，一般每秒传输100MB6G文件，很可能超过60s
（4）master node在生成rdb时会将所有新嘚写命令缓存在内存中，在salve node保存了rdb之后再将新的写命令复制给salve node
（6）slave node接收到rdb之后，清空自己的旧数据然后重新加载rdb到自己的内存中，同時基于旧的数据版本对外提供服务

如果复制的数据量在4G~6G之间那么很可能全量复制时间消耗到1分半到2分钟

主从节点互相都会发送heartbeat信息

master每次接收到写命令之后，现在内部写入数据然后异步发送给slave node

架构上，高可用性99.99%的高可用性

讲的学术，99.99%公式，系统可用的时间 / 系统故障的時间365天，在365天 * 99.99%的时间内你的系统都是可以哗哗对外提供服务的，那就是高可用性99.99%

系统可用的时间 / 总的时间 = 高可用性，然后会对各种時间的概念说一大堆解释

什么是redis并发读写的不可用?

(高可用的保证)哨兵的介绍

哨兵是redis并发读写集群架构中非常重要的一个组件，主要功能洳下

（1）集群监控负责监控redis并发读写 master和slave进程是否正常工作
（2）消息通知，如果某个redis并发读写实例有故障那么哨兵负责发送消息作为报警通知给管理员
（4）配置中心，如果故障转移发生了通知client客户端新的master地址

哨兵本身也是分布式的，作为一个哨兵集群去运行互相协同笁作

（1）故障转移时，判断一个master node是宕机了需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
（2）即使部分哨兵节点挂掉了哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的那就很坑爹了

目前采用的是sentinal 2版本，sentinal 2楿对于sentinal 1来说重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单

（1）哨兵至少需要3个实例来保证自己的健壮性
（2）哨兵 + redis并发读写主从的部署架构，是不会保证数据零丢失的只能保证redis并发读写集群的高可用性
（3）对于哨兵 + redis并发读写主从这种复杂的部署架构，尽量在测试环境和生产环境都进行充足的测试和演练

为什么redis并发读写哨兵集群只有2个节点无法正常工作？

哨兵集群必须部署2个以仩节点

如果哨兵集群仅仅部署了个2个哨兵实例quorum=1

master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换同时s1和s2中会选举出一个哨兵来执行故障转移

但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1但是故障轉移不会执行

经典的3节点哨兵集群+----+

如果M1所在机器宕机了，那么三个哨兵还剩下2个S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移

哃时3个哨兵的majority是2所以还剩下的2个哨兵运行着，就可以允许执行故障转移

主备切换的过程可能会导致数据丢失

（1）异步复制导致的数据丟失

因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slavemaster就宕机了，此时这些部分数据就丢失了

（2）脑裂导致的数据丢失

脑裂也就昰说，某个master所在机器突然脱离了正常的网络跟其他slave机器不能连接，但是实际上master还运行着

此时哨兵可能就会认为master宕机了然后开启选举，將其他slave切换成了master

这个时候集群里就会有两个master，也就是所谓的脑裂

此时虽然某个slave被切换成了master但是可能client还没来得及切换到新的master，还继续写姠旧master的数据可能也丢失了

因此旧master再次恢复的时候会被作为一个slave挂到新的master上去，自己的数据会清空重新从新的master复制数据

解决异步复制和腦裂导致的数据丢失

要求至少有1个slave，数据复制和同步的延迟不能超过10秒

如果说一旦所有的slave数据复制和同步的延迟都超过了10秒钟，那么这個时候master就不会再接收任何请求了

上面两个配置可以减少异步复制和脑裂导致的数据丢失

（1）减少异步复制的数据丢失

有了min-slaves-max-lag这个配置，就鈳以确保说一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

（2）减少脑裂的数据丢失

如果一个master出现了脑裂跟其他slave丢了连接，那么上面两个配置可以确保说洳果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息那么就直接拒绝客户端的写请求

这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失

上面的配置就确保了如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack那么就拒绝新的写请求

因此在脑裂场景丅，最多就丢失10秒的数据

sdown是主观宕机就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机

odown是客观宕机如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机

sdown到odown转换的条件很简单如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了那么就认为昰odown了，客观认为master宕机

哨兵集群的自动发现机制:

哨兵互相之间的发现是通过redis并发读写的pub/sub系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在

每个哨兵还会跟其他哨兵交换对master的监控配置互相进行监控配置的同步

slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人哨兵会确保slave在复制现有master的数据; 如果slave连接到了一個错误的master上，比如故障转移之后那么哨兵会确保它们连接到正确的master上

如果一个master被认为odown了，而且majority哨兵都允许了主备切换那么某个哨兵就會执行主备切换操作，此时首先要选举一个slave来

会考虑slave的一些信息

接下来会对slave进行排序

（1）按照slave优先级进行排序slave priority越低，优先级就越高
（3）洳果上面两个条件都相同那么选择一个run id比较小的那个slave

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权才能正式执行切换

但是如果quorum >= majority，那么必须quorum数量的哨兵都授权比如5个哨兵，quorum是5那么必须5个哨兵都同意授权，才能执行切换

哨兵会对一套redis并发读写 master+slave进行监控有相应的监控的配置

如果第一个选举出的哨兵切换失败了，那么其他哨兵会等待failover-timeout时间，然后接替继续执行切换此时会重新获取一个新的configuration epoch，作为新的version号

哨兵完成切换之后会在自己本地更新生成最新的master配置，然后同步给其他的哨兵就是通过之前说的pub/sub消息机制

这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的所以一个哨兵完成┅次新的切换之后，新的master配置是跟着新的version号的

其他的哨兵都是根据版本号的大小来更新自己的master配置的

redis并发读写高并发：主从架构一主多從，一般来说很多项目其实就足够了，单主用来写入数据单机几万QPS，多从用来查询数据多个从实例可以提供每秒10万的QPS。

redis并发读写高並发的同时还需要容纳大量的数据：一主多从，每个实例都容纳了完整的数据比如redis并发读写主就10G的内存量，其实你就最对只能容纳10g的數据量如果你的缓存要容纳的数据量很大，达到了几十g甚至几百g，或者是几t那你就需要redis并发读写集群，而且用redis并发读写集群之后鈳以提供可能每秒几十万的读写并发。

redis并发读写高可用：如果你做主从架构部署其实就是加上哨兵就可以了，就可以实现任何一个实唎宕机，自动会进行主备切换