sentinel

sentinel 1很多Bug,被官方弃用,用redis2.8以及sentinel 2

主从切换配置要加上

sentinel can-failover server1 yes

twemproxy

及时感知死掉的 server

server_retry_timeout: 加大
server_failure_limit: 0

第一个代表的是发现故障后,恢复连接间隔时间,不是内部重试机制

第二个容忍的错误数可以设置成0容忍,就是说有错误立马摘掉这个机器

持久化

备份有rdb和aof两种格式

rdb

rdb 是内存数据二进制镜像

aof类似mysql的binlog

rdb在数据非常多情况下,比aof占更少磁盘,也更适合远程数据备份,一旦创建完毕就不会再被修改

重放aof命令会很耗时

只用rdb,一旦发生事故,最近一段时间内的写请求的数据就会丢失

rdb保存时,fork子进程创建临时文件,保存完后删除老文件并把新的文件rename为老文件的名字

aof

三种保存策略

  • 无fsync

即不保存数据,把redis作为一个cache)

  • 每秒钟进行一次fsync(默认)
  • 每次写请求都执行fsync

每秒fsync最多就丢一秒

一般安全点的方法就是两种文件保存方法并用

如果正在执行rdb保存任务,而用户发了BGREWRITEAOF ,则会把任务排队,返回ok给client,redis执行完毕rdb任务的时候才会执行aof任务

redis启动执行recovery时,优先用aof,因为aof数据总比rdb新

一主一从 or 一主多从

一个redis instance可用一主一从的串联模式,也可用一主多从的级联模式,后者可提高整个instance的读性能。但实践过程中,会发现后者问题很多

如果master宕机,可能其中一个slave变成了新的master,但是另一个slave并不会变成新的master的slave,《Redis Sentinel机制与用法(一)》一文解释道:

当将一个slave选举为master并发送SLAVE OF NO ONE`后,即使其它的slave还没针对新master重新配置自己,failover也被认为是成功了的,然后所有sentinels将会发布新的配置信息。

而且不要关闭master的rdb或者aof的磁盘持久化功能,因为master一旦崩溃且瞬间自动重启后其数据为空,sentinel可能觉察不到这个现象,而slave则因为数据同步而导致自己的数据也丢失了

codis

codis改进的redis点:

1 redis数据量太大的话(22G以上),处理性能就开始下降

2 无法区分冷热数据,内存浪费严重

3 RDB Block住整个服务

4 写操作太频繁,AOF刷盘太多,很容易rewrite

redis-tool-set

https://github.com/AlexStocks/redis-tool-set