一、Redis的架构：

1、主从复制：

（1）、作用：主从备份，防止节点宕机。使得读写分离，达到负载均衡的目的。

（2）、工作原理：Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。

（3）、全量同步：Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

（1）从服务器连接主服务器，发送SYNC命令；

（2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；

（3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

（4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；

（5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

（6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

（4）、增量同步：Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

（5）、Redis主从同步策略：主从刚刚连接的时候，进行全量同步；全量同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

（6）注意点：如果多个Slave断线了，需要重启的时候，因为只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机。

2、星型架构和线型架构：

（1）、星型模型：

（2）、线型模型：

（3）、区别：星型模型比线型模型效率更高，但是实现HA比线型模型更加复杂。

（4）、过程：主从节点数据同步第一次同步的是RDB，后面的是AOF。注意：一次启动从节点个数不能过多，这样太多从节点从主节点读取数据，会造成主节点压力过大。

（5）、Redis Sentinel：

（1）、作用：主要是redis高可用的实现方案，具有故障发现，故障自动转移，客户端通知，

（2）、Redis Sentinel中的Sentinel节点个数应该是大于等于3且最好为奇数。

（6）、分区：

（1）、顺序分区：按照顺序来分区，比如1-33，34-66，67-100.

（2）、哈希分区：

（1）普通hash分区：hash（key）% nodes

（2）一致性哈希分区：一个节点管理一个范围，按照顺时针存储。

3、Redis Cluster：

（1）、作用：当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构达到负载均衡的目的。

（2）、优势：

（1）、去中心化，集群最大可增加1000个节点，性能随节点增加而线性扩展。

（2）、管理方便，后续可自行增加或摘除节点，移动分槽等等。

（3）虚拟槽分区：每个node负责一定数量的槽，一个 Redis 集群包含16384个哈希槽(slot)， 每个 key 都属于这16384个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。槽(slot)是redis cluster中数据管理和迁移的基本单位，每个节点负责一定数量的槽。

（4）两种分区的对比：

二、Redis的数据结构：让我遇见你。

三、Redis中的持久化：

1、数据的备份：

（1）、save命令：这个命令是同步的命令，首先是client请求redis执行命令save，这个过程会阻塞后面的命令，当这个命令执行完之后，redis会创建一个RDB的二进制文件。如果有老的RDB文件，那么新的会替换掉老的文件。

（2）、bgsave命令：这个是异步的命令，client请求redis的时候，redis会创建一个fork的子进程，来备份数据，从而生成一个RDB文件，这个过程是在后台执行的，后面的命令就不会被阻塞掉。

（3）、区别：

2、RDB：这个持久化需要一定的触发条件：

这是RDB的最佳配置。

见：https://blog.csdn.net/aitangyong/article/details/52045251

3、AOF：

（1）、AOF(Append Only File)，与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。被写人 AOF文件的所有命令都是以Redis的命令请求协议格式保存的，因为Redis的命令请求协议是纯文本格式，所以我们可以直接打开一个AOF文件，观察其中的写命令：

（2）、AOF持久化策略：一共有三种，第一个是always，第二个是everysec，第三个是no，一般选择everysec。

（3）、AOF的重写：重写的目的是减少硬盘的占用量，加快恢复的速度。

4、RDB和AOF的对比：

（1）、区别：

（2）、默认是先加载AOF。

四、Redis中的优化：

1、cpu：

（1）、开销：RDB和AOF文件生成，属于CPU密集型。

（2）、优化：不做CPU绑定，不和CPU密集型部署。

2、内存：

（1）、开销：fork内存开销，copy-on-write

（2）、优化：echo never > /sys/kernel/mm/transpraent_hugepage/enable

3、硬盘：

（1）、开销：AOF和RDB文件写入，可以结合iostat，iotop分析。

五、Redis中的缓存：

1、使用场景：

（1）、降低后端负载。

（2）、加速请求响应。

（3）、大量写合并为批量写。

2、Redis缓存策略：

（1）、LRU、LFU、FIFO。

（2）、超时剔除。

（3）、主动更新。

3、缓存粒度控制：

（1）、通用性：全量属性更好。

（2）、占用空间：部分属性更好。

（3）、代码维护：表面上全量属性最好。

4、缓存穿透问题：

（1）、现象：请求访问redis，redis没有缓存，然后再访问mysql，但是mysql中也没有，下次在请求的时候，redis中也没有，这样就是缓存穿透的问题。

（2）、解决方法：

（1）缓存空对象

（2）布隆过滤器拦截

5、无底洞问题：更多的集器不代表更好的性能。

（1）、命令行的优化，减少慢查询，比如：keys *，hgetall bigkey。

（2）、减少网络通信次数。

（3）、降低接入成本。

6、热点key的重建：

（1）、减少重缓存的次数。

（2）、数据尽可能一致。

（3）、减少潜在危险。

（4）、解决方案：

（1）互斥锁：获取缓存的时候加锁，重建缓存完成之后再解锁。

（2）永不过期：逻辑上设置键是永不过期的。

六、Redis的思维导图：