Redis 集群高可用

Redis作为主流nosql，想必在使用场景中都会涉及到集群和高可用的问题，下面就简单来介绍一下吧。

持久化

Redis有两种持久化的方式： RDB 和 AOF

RDB - 快照

通过预设频率write on copy来持久化数据（所以内存不宜设置超过物理内存的50%，否则会内存不足引发IO等待，使redis访问速度骤减），占用空间小，恢复速度快，适用于灾难恢复，但是宕机会丢失数据。

AOF - 持久化

默认会将每个收到的写指令通过write函数追加到文本 appendonly.aof 中，通过将新记录追加到文本尾部来持久化数据，占用空间大，恢复速度慢，但是安全性好，可能会丢失一秒的数据。

那在什么情况下用什么样的持久方式会更适合我们呢？

对于Redis的使用场景会有两种策略： 非持久化 - LRU 和 持久化

( 非持久化 - LRU ) 用于临时缓存数据用，这部分数据可以通过数据库再次加载到缓存中，常用于存放热点数据。

( 持久化 ) 用于存放持久化的缓存数据，常用于分布式系统中存放的计数器、统计数值等。PS：单机类型的可以考虑使用google的guava

高可用 非持久化 - LRU

方案：Redis搭建主从，master禁用 RDB 和 AOF ，slave启用 RDB ; M/S切换使用哨兵。

master宕机：切换到从，丢失的数据重新预热即可。

slave宕机：换一个实例同步master即可。

master和slave同时宕机：可以用slave的 RDB 备份还原，丢失部分数据重新预热即可。

持久化

方案：Redis搭建主从，master 禁用 RDB 和 AOF ，slave启用 RDB ，调用一个计划任务定期bgsave维护快照存储，保障本地化数据的完整性; M/S切换使用哨兵。

master宕机：slave保存了完整的数据。

slive宕机：换一个实例同步master即可。

master和slave同时宕机：可以用slave的 RDB 备份还原。

集群

Redis仅支持单实例，内存一般最多10~20GB。对于内存动辄100~200GB的系统，就需要通过集群来支持了。

Redis集群有三种方式： 客户端分片 、 代理分片 、 Redis Cluster

客户端分片

通过业务代码自己实现路由

优势：可以自己控制分片算法、性能比代理的好

劣势：维护成本高、扩容/缩容 等运维操作都需要自己研发

代理分片

代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。使用类似Twemproxy、Codis等中间件实现。

优势：运维方便、程序不用关心如何链接Redis实例

劣势：会带来性能消耗（大概20%）、无法平滑 扩容/缩容 ，需要执行相应的脚本，不方便(PS:Codis在Twemproxy基础上优化并实现了预分片来达到Auto Rebalance)。

Redis Cluster

优势：官方集群解决方案、Redis和客户端直连，性能较好

劣势：方案太重、太新，没有相应成熟的解决案例