5. 高可用性
高可用性关乎系统出错时到底会丢失多少数据，多久不能服务。要综合考虑持久化，Master-Slave复制及Fail-Over配置，以及具体Crash情形，比如Master死了，但Slave没死。或者只是Redis死了，操作系统没死等等。
5.1 持久化
- 综述： 解密Redis持久化(中文概括版), 英文原版，《Redis设计与实现》： RDB 与 AOF。
- 很多人开始会想象两者是互相结合的，即dump出一个snapshot到RDB文件，然后在此基础上记录变化日志到AOF文件。实际上两者毫无关系，完全独立运行，因为作者认为简单才不会出错。如果使用了AOF，重启时只会从AOF文件载入数据，不会再管RDB文件。
- 正确关闭服务器：redis-cli shutdown 或者 kill，都会graceful shutdown，保证写RDB文件以及将AOF文件fsync到磁盘，不会丢失数据。 如果是粗暴的Ctrl+C，或者kill -9 就可能丢失。
5.1.1 RDB文件
- RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。
- RDB写入时，会连内存一起Fork出一个新进程，遍历新进程内存中的数据写文件，这样就解决了些Snapshot过程中又有新的写入请求进来的问题。 Fork的细节见4.1最大内存。
- RDB会先写到临时文件，完了再Rename成，这样外部程序对RDB文件的备份和传输过程是安全的。而且即使写新快照的过程中Server被强制关掉了，旧的RDB文件还在。
- 可配置是否进行压缩，压缩方法是字符串的LZF算法，以及将string形式的数字变回int形式存储。
- 动态所有停止RDB保存规则的方法：redis-cli config set save “”
5.1.2 AOF文件
- 操作日志，记录所有有效的写操作，等于mysql的binlog，格式就是明文的Redis协议的纯文本文件。
- 一般配置成每秒调用一次fdatasync将kernel的文件缓存刷到磁盘。当操作系统非正常关机时，文件可能会丢失不超过2秒的数据
(更严谨的定义见后)。 如果设为fsync
always，性能只剩几百TPS，不用考虑。如果设为no，靠操作系统自己的sync，Linux系统一般30秒一次。
- AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件，最后再rename，)， 遍历新进程的内存中数据，每条记录有一条的Set语句。默认配置是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M时触发。
- Redis协议，
如set mykey hello， 将持久化成*3 $3 set $5 mykey $5 hello，
第一个数字代表这条语句有多少元，其他的数字代表后面字符串的长度。这样的设计，使得即使在写文件过程中突然关机导致文件不完整，也能自我修复，执行
redis-check-aof即可。
综上所述，RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
5.1.3 读写性能
- AOF重写和RDB写入都是在fork出新进程后，遍历新进程的内存顺序写的，既不阻塞主进程继续处理客户端请求，顺序写的速度也比随机写快。
- 测试把刚才benchmark的11G数据写成一个1.3的RDB文件，或者等大的AOF文件rewrite，需要80秒，在redis-cli info中可查看。启动时载入一个AOF或RDB文件的速度与上面写入时相同，在log中可查看。
- Fork一个使用了大量内存的进程也要时间，大约10ms per GB的样子，但Xen在EC2上是让人郁闷的239ms (KVM和VMWare貌似没有这个毛病)，各种系统的对比，Info指令里的latest_fork_usec显示上次花费的时间。
- 在bgrewriteaof过程中，所有新来的写入请求依然会被写入旧的AOF文件，同时放到buffer中，当rewrite完成后，
会在主线程把这部分内容合并到临时文件中之后才rename成新的AOF文件，所以rewrite过程中会不断打印”Background AOF
buffer size: 80 MB， Background AOF buffer size: 180
MB”，计算系统容量时要留意这部分的内存消耗。注意，这个合并的过程是阻塞的，如果你产生了280MB的buffer，在100MB/s的传统硬盘
上，Redis就要阻塞2.8秒！！！
- NFS或者Amazon上的EBS都不推荐，因为它们也要消耗带宽。
- bgsave和bgaofrewrite不会被同时执行，如果bgsave正在执行，bgaofrewrite会自动延后。
- 2.4版以后，写入AOF时的fdatasync由另一条线程来执行，不会再阻塞主线程。
- 2.4版以后，lpush/zadd可以输入一次多个值了，使得AOF重写时可以将旧版本中的多个lpush/zadd指令合成一个，每64个key串一串。
5.1.4 性能调整
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
如果Enalbe
AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF
rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF
rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值，比如之前的
benchmark每个小时会产生40G大小的AOF文件，如果硬盘能撑到半夜系统闲时才用cron调度bgaofrewrite就好了。
如果不Enable AOF ，仅靠Master-Slave Replication
实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启
动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构，见Tim的博客
5.1.5 Trouble Shooting —— Enable AOF可能导致整个Redis被Block住，在2.6.12版之前
现象描述：当AOF rewrite 15G大小的内存时，Redis整个死掉的样子，所有指令甚至包括slave发到master的ping，redis-cli info都不能被执行。
原因分析：
- 官方文档，由IO产生的Latency详细分析, 已经预言了悲剧的发生，但一开始没留意。
- Redis为求简单，采用了单请求处理线程结构。
- 打开AOF持久化功能后， Redis处理完每个事件后会调用write(2)将变化写入kernel的buffer，如果此时write(2)被阻塞，Redis就不能处理下一个事件。
- Linux规定执行write(2)时，如果对同一个文件正在执行fdatasync(2)将kernel buffer写入物理磁盘，或者有system wide sync在执行，write(2)会被block住，整个Redis被block住。
- 如果系统IO繁忙，比如有别的应用在写盘，或者Redis自己在AOF rewrite或RDB
snapshot(虽然此时写入的是另一个临时文件，虽然各自都在连续写，但两个文件间的切换使得磁盘磁头的寻道时间加长），就可能导致
fdatasync(2)迟迟未能完成从而block住write(2)，block住整个Redis。
- 为了更清晰的看到fdatasync(2)的执行时长，可以使用”strace -p (pid of redis server) -T -e -f trace=fdatasync”，但会影响系统性能。
- Redis提供了一个自救的方式，当发现文件有在执行fdatasync(2)时，就先不调用write(2)，只存在cache里，免
得被block。但如果已经超过两秒都还是这个样子，则会硬着头皮执行write(2)，即使redis会被block住。此时那句要命的log会打
印：“Asynchronous AOF fsync is taking too long (disk is busy?). Writing
the AOF buffer without waiting for fsync to complete, this may slow down
Redis.” 之后用redis-cli INFO可以看到aof_delayed_fsync的值被加1。
- 因此，对于fsync设为everysec时丢失数据的可能性的最严谨说法是：如果有fdatasync在长时间的执行，此时redis
意外关闭会造成文件里不多于两秒的数据丢失。如果fdatasync运行正常，redis意外关闭没有影响，只有当操作系统crash时才会造成少于1秒
的数据丢失。
解决方法：
最后发现，原来是AOF rewrite时一直埋头的调用write(2)，由系统自己去触发sync。在RedHat Enterprise
6里，默认配置vm.dirty_background_ratio=10，也就是占用了10%的可用内存才会开始后台flush，而我的服务器有64G
内存。很明显一次flush太多数据会造成阻塞，所以最后果断设置了sysctl
vm.dirty_bytes=33554432(32M)，问题解决。
然后提了个issue，AOF rewrite时定时也执行一下fdatasync嘛， antirez三分钟后就回复了，新版中，AOF rewrite时32M就会重写主动调用fdatasync。 | 
