如果对性能要求较高,在master最好不要做持久化,可以在某个slave开启aof备份数据,策略设置为每秒同步一次即可。
如果你的Redis采用如下模式,就会发生数据丢失问题:
1、写crontab定时调度脚本,每小时都copy一份rdb或aof文件到另一台机器中,保留最近48小时的备份。
2、每天都保留一份当日的数据备份,到一个目录中,可以保留最近一个月的备份。
3、每次copy备份的时候,都把太旧的备份删除。
如果Redis主节点有很多从节点,在某一时刻如果所有从节点都同时连上主节点,那么主节点会同时吧内存快照RDB发给多个从节点,这样会导致Redis主节点压力过大,这就是所谓的Redis主从复制风暴问题。
这个问题我们对Redis主从架构做一些优化得以避免,比如可以做下面这种树形复制架构。
因为新的master的选举需要大于半数的集群master节点同意才能选举成功,如果只有两个master节点,当其中一个挂了,是达不到选举master条件的。
奇数个master节点可以在满足选举条件的基础上,节省一个节点,比如三个master和四个master相比,都挂了一个master,都可以选举,都挂了两个就都不能选举了。所以技术的master节点更多的是从节省机器资角度出发的。
对于类似mset、mget这样多个key的原生批操作命令,redis集群只支持所有key落在同一个solt的情况,入股分布在多个solt就会报错,如果在key前面加上{XXX},这样参数数据分片hash计算的时候只会是大括号里的值,这样就确保不同的key在同一个slot中。
mset {user}:1:name wqx {user}:1:age:18