Redis存储及容灾策略

Redis利用内存发挥的高性能读写在不少场景下大有所为，可是Redis自己毕竟仍是一个单机数据库，若是系统对其属于强依赖，那么仍是必须作好必要的容灾，针对这个问题，有如下几种策略：

1、M/S切换

因为Redis是单机数据库，因此针对MySQL的一些容灾方案也能顺利适用，例如当Redis意外宕机，能够将请求立刻切到备库，同时快速恢复数据。

2、AOF

Redis有两种持久化的方式，分别是SnapShotting和Append-Only File，其原理和特性能够参考《对redis数据持久化的一些想法》一文，总得来讲，快照对性能影响更小，也只会备份须要的数据，但两次快照中间的数据是无法保证必定会持久化的。

相比之下AOF的粒度更细，持久化效果更好，相似于MySQL的BinLog，缺点是会损失一部分性能，并且会记录没必要要的日志，这一点当系统运行时间很长时会特别突出，也许恢复全部数据原本只要1个小时，却可能要花100甚至1000小时去搞。

3、读取数据源直接恢复

这个方案是和业务场景相关的，因为以前某个项目中Redis起到了存放索引的做用，因此利用MySQL的数据能够容易地从新创建Redis的全部内容，这里能够临时搞一个Trigger，不断读MySQL写Redis，利用MySQL的顺序读和Redis高TPS的特性，实践中，能够在几分钟内重建上千万的数据量。

目前Redis在功能上一般仍用于Cache，若是须要保证HA的持久化存储，请考虑具体场景，此外也能够考虑是否可使用原生分布式的memcached或升级硬件（如SSD、Fusion-IO）加强原有DB的性能。

 

 

 

个人应用里为了保证高性能，数据没有作dump，也没有用aof。由于不作dump发生的故障远远低于作dump的时候，即便数据丢失了，自动修复脚本能够立刻数据恢复。毕竟对海量数据redis只能作数据分片，那么落到每一个节点上的数据量也不会不少。

redis的虚拟内存建议也不要用，用redis原本就是为了达到变态的性能，虚拟内存、aof看起来都有些鸡肋。

如今还离不开redis，由于它的mget是如今全部db里性能最好的，之前也考虑过用tokyocabinet hash方式作mget，性能不给力。直接用redis，基本上单个redis节点mget能够达到10W/s

 

http://lkf0217.iteye.com/blog/1076700

从这个图中能够看出：

　　1) 对于没有持久化的方式，读写都在数据量达到800万的时候，性能降低几倍，此时正好是达到内存10G，Redis开始换出到磁盘的时候。而且从那之后再也没办法从新振做起来，性能比Mongodb还要差不少。

　　2) 对于AOF持久化的方式，整体性能并不会比不带持久化方式差太多，都是在到了千万数据量，内存占满以后读的性能只有几百。

　　3) 对于Dump持久化方式，读写性能波动都比较大，可能在那段时候正在Dump也有关系，而且在达到了1400万数据量以后，读写性能贴底了。在Dump的时候，不会进行换出，并且全部修改的数据仍是建立的新页，内存占用比平时高很多，超过了15GB。并且Dump还会压缩，占用了大量的CPU。也就是说，在那个时候内存、磁盘和CPU的压力都接近极限，性能不差才怪。

　　总结一下：

　　1) Redis其实只适合做为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合看成一个普通功能来用。对于这个版本的Redis，不建议使用任何的持久化方式。不然到时候可能会死的比较难看。说白了，指望Redis是memcached的升级版，带有各类数据结构，可是不要指望 Redis来和Mongodb/Kt等来比。

　　2) 对于VM其实也是不建议开启，虽然开启VM可让Redis保存比内存更多的数据，可是若是冷热数据不是很明显的话性能会很是差(个人测试都是随机查询 Key，冷热不明显)。固然，对于冷热明显的状况下能够设置200% - 400%的内存做为VM空间，也不建议设置10倍的内存空间做为VM(像个人配置同样)。

　　3) ServiceStack.Redis客户端好像有几个Bug，首先RedisTypedClient的Dispose竟然没有实现，应该是要调用 client.Dispose()，其次RedisNativeClient的Info属性不是每次都获取最新值的，第三 PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加没看到减的地方，也不知道这是干啥的，其实每次都取第一个不是Active的Client就能够了，PooledRedisClientManager也没有把超时使用的Active的 Client强制回收(避免使用的时候忘记Dispose占用过多的链接)。有关这几点，我会尝试联系ServiceStack.Redis的做者。