- 因为RDB文件只用作后背用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留
save 900 1这条规则 - 如果Enable AOF,好处是在最恶劣情况下,也只会丢失不超过两秒数据,启动脚本较简单只load自己的aof文件就可以了.代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的.只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64m太小了,可以设到5G以上.默认超过原大小100%时重写,可以该带适当的数值
- 如果不Enable AOF,仅靠Master-Slave Replication实现高可用性也可以.
能省掉一大笔IO也减少了rewrite时带来的系统波动.代价是如果Master和Slave同时挂掉,会丢失十几分钟的数据,启动脚本也要比较两个Master和Slave中的RDB文件,载入较新的那个.新浪微博就选用了这种架构
我自己角色既然使用了redis就是为了它的(A)高可用性和(P)分区容忍性,至于数据一致性(C)就可以暂时放一放了,如果真的对高一致性有要求,那就说明该业务不适合放在redis上去使用
- Cosistency 高一致性
- Availability 高可用性
- Tolerance to network Partitions 分区容忍性
