Redis分布式缓存（持久化、主从集群）

一、单节点redis的问题

• 1.Redis是内存存储，数据容易丢失
• 2.由于是内存存储，且采用单线程 + 多路 I/O 复用模型，避免线程切换开销，redis的并发能力远强于多线程磁盘mysql，但是单结点redis仍无法满足高并发场景
• 3.现代项目对redis依赖非常高，如果redis宕机将造成非常严重的损失，所以需要一种自动的故障恢复手段，单节点redis无法实现。
• 4.redis基于内存存储，单节点存储的数据量难以满足海量数据需求。

二、Redis持久化

1.RDB

将内存中的所有数据记录到磁盘的rdb文件中，当redis重启后，从磁盘读取rdb快照文件，恢复数据。

Redis正常停机时的持久化机制：

• redis在停机前会自动保存rdb数据到磁盘当前项目工作目录下，然后才会执行停机指令。
• 当启动redis时会自动读取当前工作目录下的rdb文件并加载到内存中。

实现数据快照的命令：

• save，save命令由redis主进程来执行，会阻塞所有命令（因为redis是单线程的），适合正常redis手动停机时使用
• bgsave，bgsave命令会开启异步子进程执行持久化，不影响主进程，适合redis运行过程中持久化内存数据（异常停机时缓解数据丢失的解决方案）
• redis的redis.conf配置文件中可以修改 bgsave命令的触发频率：
  • save 900 1 900s内如果至少有1个key被修改
  • save 300 10 300s内如果至少有10个key被修改
  • save 60 10000 60s内如果至少有10000个key被修改，则执行bgsave命令

bgsave 执行流程：

• 1.操作系统fork redis主进程得到一个子进程，与主进程共享内存空间，fork过程中主进程阻塞，子进程创建后主进程正常工作
• 2.子进程读取内存数据写入一个新的rdb文件
• 3.将新的rdb文件覆盖旧的rdb文件

RDB缺点：

• bgsave的触发频率 如果时间设置太短那么频繁创建子进程和写rdb文件非常影响性能；时间设置太长会出现向内存写入数据后触发还未执行redis就宕机，导致数据丢失。

2.AOF

与RDB将内存数据存储到磁盘中不同，AOF是将redis执行的每一条写命令以追加的方式记录在磁盘的aof日志文件中，当服务宕机重启后通过重新执行这些写命令来完成数据恢复，与RDB的bgsave一样也是一种缓解异常停机导致数据丢失的解决方案。

AOF的触发频率在redis.conf中配置：

• appendfsync always：每执行一条写命令，立即写入aof文件中
• appendfsync everysec：将写命令暂存到OS为redis分配的缓冲区，每隔1s将缓冲区的所有命令写入aof文件（默认方案）
• appendfsync no：将写命令暂存到缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

bgrewriteaof命令：

• aof文件会记录一些没有意义的命令，例如对同一个key执行多次set操作，那么所有的set操作都会被记录到aof文件中，但是实际上只有最后一次set才有意义，其余set没必要记录。（有点马后炮的意思）

• bgrewriteaof：可以对aof文件执行重写功能，减少无效命令的记录，也是使用fork开辟异步线程来执行覆写功能，避免影响主线程：
  

• redis的redis.conf配置文件中可以修改 bgrewriteaof命令的触发频率：

  • auto-aof-rewrite-percentage 100 aof文件相比上次触发文件体积增长超过百分之多少才会触发重写
  • auto-aof-rewrite-min-size 64mb aof文件体积达到多少mb以上才触发重写

---

总结：

三、Redis主从集群

由于redis业务读多写少，所以主从集群的多个从节点用来处理读请求，主节点完成写请求，并将数据同步到从节点。