玩转 Redis缓存 集群高可用
Redis作为主流nosql，在高并发使用场景中都会涉及到集群和高可用的问题，有几种持久化？场景下的缓存策略怎么选？高可用方案怎么实现？集群有哪几种？跟着这几个问题，结合一些自己使用的经验来简单分析一下。
一.有哪些持久化
Redis有两种持久化的方式：`RDB` 和 `AOF`
- RDB - 快照
通过预设频率write on copy来持久化数据（所以内存不宜设置超过物理内存的50%，否则会内存不足引发IO等待，使redis访问速度骤减），占用空间小，恢复速度快，适用于灾难恢复，但是宕机会丢失数据。
- AOF - 持久化
默认会将每个收到的写指令通过write函数追加到文本 appendonly.aof 中，通过将新记录追加到文本尾部来持久化数据，占用空间大，恢复速度慢，但是安全性好，可能会丢失一秒的数据。
二.怎么选择适合的持久化策略
对于Redis的使用场景会有两种策略：`LRU缓存（临时缓存）` 和 `持久化缓存`。
用于存放持久化的缓存数据，常用于分布式系统中存放的计数器、统计数值等。配置类的缓存可以考虑使用google的guava
- LRU缓存（临时缓存）
用于临时缓存数据用，这部分数据可以通过数据库再次加载到缓存中，常用于存放热点数据。
- 持久化缓存
三.如何实现高可用
对于需要到线上运行的项目，单点问题肯定是个躲不开的话题，这个时候该如何解决？
1.LRU缓存（临时缓存）高可用
方案：Redis搭建主从，master禁用RDB和AOF，slave启用RDB; M/S切换使用哨兵。
- master宕机：切换到从，丢失的数据重新预热即可。
- slave宕机：换一个实例同步master即可。
- master和slave同时宕机：可以用slave的
RDB备份还原，丢失部分数据重新预热即可。
2.持久化缓存高可用
方案：Redis搭建主从，master禁用RDB和AOF，slave启用RDB，master调用一个计划任务定期bgsave维护快照存储并通过scp传输到slave保存，保障master本地化数据完整性的同时也避免了开启持久化策略带来的性能损失; M/S切换使用哨兵。
- master宕机：slave保存了完整的数据。
- slive宕机：换一个实例同步master即可。
- master和slave同时宕机：可以用slave的
RDB备份还原。
四.集群怎么做
Redis仅支持单实例，内存一般最多10~20GB。对于内存动辄100~200GB的系统，就需要通过集群来支持了。
Redis集群有三种方式：客户端分片、代理分片、Redis Cluster
- 客户端分片
通过业务代码自己实现路由
优势：可以自己控制分片算法、性能比代理的好
劣势：维护成本高、扩容/缩容 等运维操作都需要自己研发
- 代理分片
代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。使用类似Twemproxy、Codis等中间件实现。
优势：运维方便、程序不用关心如何链接Redis实例
劣势：会带来性能消耗（大概20%）、无法平滑扩容/缩容，需要执行脚本迁移数据，不方便(Codis在Twemproxy基础上优化并实现了预分片来达到Auto Rebalance)。
- Redis Cluster
优势：官方集群解决方案、无中心节点，和客户端直连，性能较好
劣势：方案太重、无法平滑扩容/缩容，需要执行相应的脚本，不方便、太新，没有相应成熟的解决案例
