单点redis的问题
- 数据丢失问题：Redis是内存存储，服务重启可能会丢失数据。解决：数据持久化
- 并发能力问题：单节点并发能力不足。解决：主从集群，读写分离。
- 故障恢复：需要自动的故障恢复手段。解决：Redis哨兵，实现健康检测和自动恢复。
- 存储能力问题：单节点Redis难以满足海量数据存储。解决：搭建分片集群，利用插槽机制动态扩容。
Redis持久化
RDB持久化
RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。 简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。
快照文件称为RDB文件，默认是保存在当前运行目录。
RDB执行时机：
- Redis停机时会执行一次RDB。 （save命令由Redis主进程来执行RDB，会阻塞所有命令；bgsave命令则开启子进程执行RDB，是异步的，避免主进程受到影响）
- Redis内部有触发RDB的机制，可以在redis.conf文件中找到。
异步持久化bgsave原理
RDB方式bgsave的基本流程？
1. fork主进程得到一个子进程（复制页表），共享内存空间 2. 子进程读取内存数据并写入新的RDB文件 3. 用新RDB文件替换旧的RDB文件。（更新备份文件）
fork采用的是copy-on-write技术：
当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。极端情况：主进程把所有原数据都分别进行了一次修改，产生了两倍大的内存占用（一份原，一份副本），很耗内存。
save一般在redis服务结束的时候使用。
bgsave一般在redis服务使用时。
RDB会在什么时候执行？save 60 1000代表什么含义？ 默认是服务停止时执行。也可以配置config文件触发执行。 save 60 1000代表60秒内至少执行1000次修改则触发RDB
RDB的缺点？ RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险（相当于每次变化只是努力存最终版的样子，如果未来得及存，就丢失了） fork子进程、压缩、写出RDB文件都比较耗时
AOF持久化
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。
RDB和AOF比较
