Redis单机主从高可用性优化是怎样的
Redis单机主从高可用性优化是怎样的，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
redis是一款高性能的内存数据库，本文侧重描述redis在主从模式下遇到的一些问题以及如何调优，特别是在云环境下遇到的一些特殊问题，至于redis如何使用以及数据结构等，可以百度，网上有大量的资料。
主结点
在非集群环境的情况下，使用redis主从模式来保证业务的高可用性，因此在此种模式下，读写都在主机，要保证主机高性能必须在主机上尽量少的IO操作同时又要兼顾网络导致的主从断链而带来的频繁的fullsync，因此针对主机优化要点如下：
关闭主结点aof
关闭主aof比较简单，可以通过如下命令进行关闭，在主结点上执行
config set appendonly no
关闭主结点save
关闭主上的save原因是避免save的规则导致的bgsave而引起业务波动，bgsave是非常消耗性能的，redis的默认save规则为" 900 1 "," 300 10 ","," 60 10000 ",在此规则下写入量大的情况下会导致主机频繁的bgsave而导致性能急剧下降，可以通过命令config set save关闭主机上因写入而触发的bgsave，数据的完整性交给备机完成，即使这样也无法完全杜绝bgsave，在从机第一连上来或者从机断开过久的情况下还是会触发bgsave
主从同步后key数量不一致问题
因为redis只会在主上进行定期key淘汰并命令传播到从机，因此在key数量很多而且很多key又带有过期时间的情况下，因为淘汰机制问题会导致主从同步后从机的key数量和主机的key数量不一致（过期的key不会同步到从机），而最根本原因是主机在在serverCron函数中进行淘汰的时候一次默认只会淘汰20个key，默认值在redis.h中#define ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 20 /* Loopkups per loop. */定义，解决该问题的方式一是修改该数量重新编译，而是修改redis.conf中的hz属性，加快serverCron执行频率
发送缓冲区满导致主从断开频繁fullsync问题
redis为每一个链接的客户端维护了一个发送缓冲区，并限定了大小（有软硬之分），当发送缓冲区满后（超过了设定的值）redis即会断开该链接从而实现自我保护功能，但是问题也出现，当写入量非常大的时候而该值又设置的不合理会导致主从频繁断连，而且因为写入量巨大新连接上来的从机不能进行部分同步而触发全量同步，因此为了避免该问题可以根据redis实际的写入数据以及网络情况综合来修改参数client-output-buffer-limit，具体修改多大要结合实际写量和网络情况而定，设置方式为：config set client-output-buffer-limit "slave 4295000768 4295000768 0"
slave 表示从机链接，普通客户端为normal，发布订阅客户端为：pubsub
复制积压缓冲区repl-backlog-size
复制积压缓冲区缓存了最近的写命令，在有从机链接的时候创建，该缓冲区大小默认为1M，改值决定了从机断开在重新链接上来后是全量同步还是部分同步，如果复制偏移量在复制积压缓冲区内为部分同步，小于或者大于复制积压缓冲区那么就行全量同步，可以根据实际情况通过config set 命令重新设定repl-backlog-size
节点死活判定
在高可用系统中，节点的死活检查非常重要，检测逻辑要快速发现问题并迅速切换，检测手段也是多重多样， redis检测节点死活采用了进程探测加服务ping的方式进行，进程探测是为了确认目标进程存在，但是目标进程存在也不一定确认服务可用，所以另加了去ping指定服务节点的方式，在实际使用过程中发现某些节点会奇怪的进行切换，而去看机器的内存、网络、以及IO都很低，除了某些CPU核在切换的时刻被跑满，然后分析切换节点的slowlog发现，用户在那个时间点提交了耗时高达几分钟的查询，因为redis是单线程处理，因为某一个耗时高的命令而导致了ping超时导致了切换，优化逻辑就是适当增加ping的耗时和增加ping的次数，这个过程中也要有所取舍，即要很快的发现问题，又不能因为高耗时命令而误判进行切换
从结点
从结点主要用来保证数据安全性，并在主结点死掉后快速恢复成主结点并提供服务，在作为从结点的时候需要打开rdb和aof，并按照一定的时间规则把用户的rdb放入到冷备中心，
在提升为主节点后，相关设置要立刻恢复到和主节点一样的配置
看完上述内容，你们掌握Redis单机主从高可用性优化是怎样的的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！
