Redis如何能支撑高并发的架构:
1、主从架构:这也就是支撑10万,20万,50万的并发量,redis属于企业级的毫秒级的nosql数据库。只要涉及到企业级相关的一定要安装到linux系统上,因为linux系统上有epoll模型,多路复用,来提高整个的高并发的性能。因为Linux是天生的服务器。
2、redis在什么情况下出现性能急速下降
①、value的值过大
②、逻辑处理比较复杂, lpush:像队列上推进去,不像set一样。
3、如何设计Redis缓存架构能够处理20W+QPS.
主从:MasterNode SlaveNode
Master节点不能处理20万的请求量,然后可以把其下的请求量分发到slave节点上。
我们用到缓存就用到它的读,这里就涉及到并发,读请求能够达到20万的QPS。
4、如果是写的操作每一秒的操作要达到20wQPS的话需要多创建几个主从节点。多主多从的结构上面的主从架构是在生产环境下的。如果是同一台的主从的话有可能出现单机 故障,一旦这台机器出现故障,整个的主从架构就死掉了。
5、如果这里有5台服务器,那么Master节点的服务器挂掉的话没有关系,因为在master和slave的架构下面可以用哨兵机制对其故障的转移。哨兵机制实现主备切换,这时就可以实现高可用。
6、如果还想要做更大量的QPS的话可以从主从架构变为读写分离的主从架构,这时性能会更高。利用2,8原则把所有的读的请求放到slave,写的请求放到master,写入到master中的数据通过异步的发送到全部的slave节点上面去,让所有的slave节点同步。
7、一旦搭建了主从的架构的话,虽然达到了20W甚至上百万的QPS的请求,持久化 的机制还需要注意:
①、因为主节点要将所有的数据同步到所有的slave节点上,而且要与slave节点保持心跳的过程。最好将master节点的持久化开启,不要关,一旦master出现问题,如果继续还有数据往master节点上去写的话,master还没有来的及同步到slave节点上的时候,如果master节点宕机后,这时数据不完整,在没有加哨兵的情况下一旦Master宕机掉,如果没有做持久化,这时数据就完全丢失了。
②、因为当master节点启动好以后,这时slave节点会继续与master节点保持联系,还没有做主从切换的时候保持联系在重新启动的时候会在Master节点下有一个runId,如果run-id和原先的run-id保持不一致的话,这时会做全量的复制,明明master节点的数据已经丢失了,做全量复制的话,这时会把空 的数据集rdb文件发送到所有的slave端。这时所有的slave端会同步的空的数据集的rdb文件中的数据,这时slave上的数据也会丢失。
主从的架构做一个深入的刨析:
1、主从架构的核心原理
①、当启动一个slave node的时候,它会发送一个PSYNC9(会将当前机器的ip地址+slave节点的run-id,如果发现和master节点的run-id不一致会做全量的复制)命令给master node,第一次与master建网络连接的时候也会做一次全量的复制。
②、如果这时slave node重新连接master node,那么master node仅仅会复制给slave部分缺少的数据(增量复制); 否则如果是slave node第一次连接master node,那么会触发一次full resynchronization(把整个的这个时刻的redis中的rdb文件及其内存中的数据进行一个同步到自己的slave节点上去)。
③、开始full resynchronization的时候,master会启动一个后台线程,开始生成一份RDB快照文件,同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后,master会将这个RDB发送给slave(master和slave之间是建立网络连接的,其实就是socket连接),slave会先写入本地磁盘,然后再从本地磁盘加载到内存中。
④、slave node如果跟master node有网络故障,断开了连接,会自动重连。master如果发现有多个slave node都来重新连接,仅仅会启动一个rdb save操作(重新生成一个rdb文件,然后分发给所有的slave),用一份数据服务所有slave node。在这里连接的时候会有一个延迟,延迟大概5秒左右,然后把rdb文件分发给其下的所有的slave节点。等待的原因是想要等待更多的连接过来,不想来一个就发一个,这很浪费时间。
2、主从复制的断点续传
①、rdb文件是几小时,几天才生成一个rdb文件,不会一直在变的,从redis 3.8开始,就支持主从复制的断点续传,如果主从复制过程中,网络连接断掉了,那么可以接着上次复制的地方,继续复制下去,而不是从头开始复制一份(增量复制)当offset相等的时候会进行一个增量的复制。
②、如果发现offset不一样的话,这时不会断点续传,而是全量复制,这时将原先的offset重置为0,然后再一次进行全量复制,默认的复制:先与slave建立网络连接,然后将master下的数据生成一份快照,这就是所谓的rdb,一般情况下都是rdb文件,它会使用一个异步的线程将这个rdb文件发送给slave,然后slave拿到这个rdb文件并不是直接去使用了,而是持久化到slvae这台机器的磁盘上,然后slave进行同步的时候,然后slave将磁盘中的数据加载到slave的内存里面去。虚线代表异步。
③、master一直在接收数据,所以没有转成rdb文件,这时slave中的数据和mster的数据就不一样,那么如何去保证数据是一样的呢:他会将master中的写的指令统统的发送给slave,然后slave去执行这些写的指令,这时master和slave就同步了。
3、无磁盘化复制:这时就不会生成一个具体的文件
master在内存中直接创建流文件rdb,然后发送给slave,不会在自己本地落地磁盘了,不用持久化了。
repl-diskless-sync repl-diskless-sync-delay
等待一定时长再开始复制,因为要等更多slave重新连接过来, 无计可施了情况下需要再次优化性能,可以配置上面参数了。想要快速操作,不想在传输rdb文件中的过程中io操作导致性能降低,因为持久化就会有io的操作。
缺点:因为是在内存中,一旦机器宕机,就完蛋了。