redisCluster数据持久化

Redis的数据回写机制

Redis的数据回写机制分同步和异步两种，

1. 同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。
2. 异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。方法２采用fork主进程的方式很拙劣，但似乎是唯一的方法。内存中的热数据随时可能修改，要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会 导致假死。 fork一个新的进程之后等于复制了当时的一个内存镜像，这样主进程上就不需要冻结，只要子进程上操作就可以了。在小内存的 进程上做一个fork,不需要太多资源，但当这个进程的内存空间以Ｇ为单位时，fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢？肯定会报内存无法分配的。更可气的是，越是改动频繁的主机上fork也越频繁，fork操作本身的代价恐怕也不会比假死好多少。找到原因之后，直接修改/etc/sysctl.conf内核参数vm.overcommit_memory= 1 ，sysctl -p  ，Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。

1. 如果 vm.overcommit_memory = 1，直接放行
2. vm.overcommit_memory = 0：则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap，决定是否放行。
3. vm.overcommit_memory= 2：则会比较进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上swap，决定是否放行。
4. AOF的完全持久化方式带来的问题：
   比如我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。
   因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
   为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。
   收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的增长。
   由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
   对应的设置参数为:
   $ vim /opt/redis/etc/redis_6379.conf

   no-appendfsync-on-rewrite yes   #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
   auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
   auto-aof-rewrite-min-size 64mb  #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

5. 二、灾难恢复模拟:目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。

6. 即Master上Snapshot和AOF都不做，来保证Master的读写性能，而Slave上则同时开启Snapshot和AOF来进行持久化，保证数据的安全性

7. 数据持久化的优化：
       使用Replication机制，结合使用rdb和aof方式，Master主节点负责读操作，Slave从节点负责写数据，选择    
       Replication机制的其中一种方式，将数据保存在Slava节点，然后利用Slave从节点的rdb文件和aof文件去恢复被
       kill掉的Master节点。
       这种集群Master节点的配置文件的主要部分：
       |----------------------------------------------------------------------------------------------------------------------------------------
       |#save 900 1 #禁用Snapshot                
       |#save 300 10                        
       |#save 60 10000                        
       |#appendonly no #禁用AOF                    
       |----------------------------------------------------------------------------------------------------------------------------------------
       Slave节点的配置文件的主要部分：
       |----------------------------------------------------------------------------------------------------------------------------------------
       |save 900 1 #启用Snapshot                
       |save 300 10                        
       |save 60 10000                        
       |appendonly yes #启用AOF                    
       |appendfilename appendonly.aof #AOF文件的名称    
       |# appendfsync always                    
       |appendfsync everysec #每秒钟强制写入磁盘一次        
       |# appendfsync no                      
       |no-appendfsync-on-rewrite yes   #在日志重写时，不进行命令追加操作
       |auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程
       |auto-aof-rewrite-min-size 64mb  #启动新的日志重写过程的最小值
       |----------------------------------------------------------------------------------------------------------------------------------------
   3、持久化过程：
       在确认主节点Master已经失效的前提下，打包（tar）Slaver结点的rdb和aof文件；将其上传到Master节点下的文
       件夹，同时删除Master目录下初始化Slave的数据文件；然后解压刚才上传的tar包；最后再次启动被kill的Master
       节点，至此，Maste节点的数据白恢复。
   4、主从配置：
       集群怎样把从节点变成主节点，当Master节点失效的时候。
   5、集群的可用性
       Redis集群通过分区来提供一定程度的可用性：即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理
       命令请求