redis面试篇-02三分钟搞懂Redis架构模式

作为程序员，redis是日常编码使用最多的缓存数据库。然而，你了解redis的架构模式吗？它们都有什么特点？今天带着这个问题，我跟大家分享下redis架构模式，掌握了这些知识，可以让你应付Redis架构模式的面试时，游刃有余。

1.单机模式

部署简单，但是缺乏高可用，缺乏可靠性

2.主从模式

一个master节点，多个slave节点。所有节点都可以负责读，但是只有master节点才能处理写。

主从复制过程：

1.slave向master发送sync命令

2.master节点使用bgsave生成rdb文件快照，发送给slave,并记录生成文件快照后执行的写命令到缓存中

3.slave接受rdb快照文件，抛弃原有数据，载入master发送的数据

4.master继续向slave发送快照生成后的写命令

5.slave节点处理master节点发送的写命令

2.1一主一从

当主节点的写命令并发高，并且需要进行持久化时。可以让master负责负责读写，slave负责对master的数据进行持久化，提高可靠性。

 

2.2 一主多从

针对读操作比较频繁的情况，可以让master负责写操作，将读操作交给slave。

 

2.3树状主从

从上面的主从复制过程，我们知道master需要给slave节点发送文件快照，如果slave节点过多的话，就会导致master节点压力多，所以让master节点先推送到slave1,由slave1节点，代理去同步给slave3与slave4，减轻了slave节点的压力。

 

Redis的主从全量复制数据只发生在master与slave建立连接的初始化阶段。后续网络出现问题，从slave节点再次连master时，master节点补发缺少的数据，每次数据增量同步。

缺点：主从复制缓解了master的读压力，但是没有缓解redis的写压力，写的性能局限于master所在的机器。master宕机后，需要人工手动去修改slave上关于新master的节点ip

3.哨兵模式

哨兵模式（sentinel）是在主从复制的基础上建立的，它有一个或者多个哨兵节点，哨兵节点不存储数据。它会监控主从节点，实现主从节点自动切换，减去人工干预的缓解，但是主从切换比较耗费时间，并且没有解决master节点写压力的问题。

 

 

4.redis-cluster集群模式

集群key空间被分成16384个槽位，key值通过hash算法分布到不同的分片上。读请求分给slave,写请求分给master,数据同步从master同步到slave.可以扩展master节点来分担写压力，也可扩展slave节点来分担读压力。master节点宕机，slave节点会通过选举产生新的master节点。

 

5.面试题集群的槽位为什么是16384

这个问题还真的被问到过，不知道的，可以看看下面这个回答

对于客户端发送的key，redis会通过crc16算法进行hash计算，映射到具体的槽位，crc16算法会产生16bit的hash值，2^16能产生65536个数值，值是分布在0~65536之间，但是作者在做取模运算时，不是mod65536，他的公式是：HashSlot=crc16(key) mod 16384。

因为两个redis节点之间心跳检测会发送ping,pong消息,消息头里面定义了一个char数组，大小为(cluster_slot/8)。如果用65536/8/1024=8K,太大浪费带宽。用16384/8/1024=2K,够用。并且集群节点越多，心跳检测包越大，大于1000时，会造成网络拥堵。

6.Redis持久化模式

6.1 RDB模式

RDB持久化是把当前进程数据生成快照（.rdb）并保存到磁盘的操作，新文件会覆盖老文件内容，手动触发可以用以下两个命令

save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它

bgsave命令：redis进程执行fork操作创建子进程，由子线程完成持久化，不会影响主进程执行，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;

 

6.2 AOF模式

RDB只能记录某一时刻的快照，AOF像mySQL的binlog日志一样，是记录了所有的操作的日志文件，使用它进行数据恢复速度会比较慢、但是AOF的启动优先级要高于RDB。默认不开启，需要修改redis.conf文件，修改属性appendonly为yes。

AOF有三种模式:

always:每次修改同步，性能较差，数据完整性好

everysec:每秒同步一次，每秒一次fsync,丢一秒的数据

no:从不同步

AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite（当AOF文件过大时，会进行重写，进行压缩文件数据）还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。