携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第17天，点击查看活动详情 >>
1.单机版Redis
redis充当缓存
随着业务体量发展，数据逐渐增多，应用越来越依赖于Redis
如果这时候Redis突然宕机：
- 因为Redis充当缓存的时候数据都存在内存中，宕机会丢失数据
- 由于Redis失效，MySQL会承受业务所有的流量，负载变大
如果在Redis宕机前，能够将一些热点数据持久化到磁盘上，Redis宕机重启后就能快速恢复提供服务了。
2. 数据持久化
2.1 AOF和RDB
线性写
- Redis每一次执行写操作，写完内存之后，写一份到磁盘上
- 缺点：耗时太久，影响Redis性能
并发写
-
AOF：主线程写内存，写内存完之后返回客户端结果，然后另起一个线程去写磁盘
-
优点：
- 数据全
-
缺点：
- 文件体积大，数据恢复速度慢；
- 如果Redis对数据找不到的容忍度高，没必要每写一次就持久化
-
-
RDB：数据快照：记录某一个时刻的Redis数据，将这个数据写到磁盘即可
-
优点：
- 数据一次性写入磁盘，其他时间不操作磁盘
- 二进制 + 数据压缩的方式写磁盘，文件体积小，数据恢复速度快
-
缺点：数据不全
-
2.2 总结：
- AOF：每一次写操作都持久到磁盘，适用于业务对数据完整性要求高的情况
- RDB：只持久化某一时刻的数据快照到磁盘上，适用于对数据丢失不敏感的情况
2.3 持久化优化——combine：
假设在因为对数据完整性有要求而使用AOF的业务场景中，会遇到以下问题：
- AOF随着写操作的增多，文件体积会越来越大
- 文件体积的大小影响了数据恢复的时长
可以对AOF进行瘦身，只保留对同一个key最后一次被修改的值，即AOF rewrite
也可以做混合持久化，当 AOF rewrite 时，Redis 先以 RDB 格式在 AOF 文件中写入一个数据快照，再把在这期间产生的每一个写命令，追加到 AOF 文件中。因为 RDB 是二进制压缩写入的，这样 AOF 文件体积就变得更小了。
即使已经把持久化文件压缩到最小，但是宕机后重新恢复数据还是需要一定时间。如果能够部署多个Redis实例，那么其中一个实例宕机，仍有能够继续提供服务的Redis
3. 主从复制
主从架构中，一般得有个主节点进行实时的读写操作，从节点复制实时同步数据。
采用多副本的优势在于：缩短不可用的时间；提升读性能
- 当主节点宕机之后，可以手动地将从节点提升为master继续提供服务
- 让一部分的从节点承担读请求，提升整体性能
但是人为切换很不方便，需要考虑故障的自动切换。
4. 故障自动切换
在主从架构中可以引入一个观察者，实时监测master的健康状态，把这样的观察者定义为哨兵。哨兵会定时询问主节点的状态，发现异常后进行主从切换。
可以部署多个哨兵分布在不同的机器上一起检测master的状态，以避免网络问题引起的误判。
多个哨兵的情况下，共同协商判定master的状态，通过共识算法选出哨兵领导者发起主从切换。
现在在一个Redis实例宕机的时候，通过哨兵+主从模式，可以完成自动的主从切换，保证了系统的稳定性；通过多增加从节点能够读写分离，分担读压力；通过分片集群，分担写请求的压力。
5. 横向扩展
当一个Redis实例承担不住些压力，我们可以增加可以写的Redis节点，让每个节点个字存储一部分的数据。
分片集群根据路由规则所在位置的不同可以分为两大类：
-
客户端分片
- 普通分片，路由逻辑在业务侧
- 集成Redis Cluster：路由逻辑封装在SDK中
-
服务端分片
- 使用代理层Proxy维护数据的路由规则
6.总结
单个Redis只实现了缓存的功能。针对宕机后内存数据丢失恢复时间长的问题，考虑将数据进行持久化。这里介绍了AOF和RDB两种，适用于不同的业务场景。在AOF的基础上可以优化，比如说rewrite+混合RDB的模式。这样就能够宕机后快速恢复，如果再进行优化，则需要进行多副本，哨兵模式，选择主节点进行主要的业务操作，其余节点进行数据的同步和备份。最后为了更高的性能，可以进行分片和添加节点来应对更高读写要求的场景。
