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的操作。
缺点：因为是在内存中，一旦机器宕机，就完蛋了。
