Redis高可用技术方案总结

本文主要分析了Redis的几种常见的使用方式及其优缺点。一、常用的使用方法Redis的几种常用的使用方法包括：Redis单副本；Redis多副本（主从）；Redis哨兵（哨兵）；集群；Redis自研。二、各种使用方式的优缺点1、Redis单副本Redis单副本采用单Redis节点部署架构。没有备份节点实时同步数据，不提供数据持久化和备份策略。适用于数据可靠性要求不高的场合。纯缓存业务场景。优点：架构简单，部署方便；性价比高：使用缓存时不需要备节点（单实例的可用性可以通过supervisor或者crontab来保证），当然为了满足业务的高可用，也可以牺牲一个备节点，但一次只有一个实例对外提供服务；高性能。缺点：数据可靠性无法保证；使用缓存并重新启动进程后数据丢失。即使有备用节点解决高可用，仍然无法解决缓存预热问题，不适合对数据可靠性要求高的业务；高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU是主要瓶颈，适合操作命令简单、排序少、计算量少的场景。您也可以考虑改用Memcached。2、Redis多副本（master-slave）Redis多副本采用master-slave（replication）部署结构。与单副本相比，最大的特点是主从实例之间的数据实时同步，并提供数据持久化和备份策略。主从实例部署在不同的物理服务器上。根据公司基础环境配置，可同时对外提供服务和读写分离策略。优点：可靠性高：一方面采用双机主备架构，当主库出现故障时可以自动切换主备，并推动从库为主库提供服务，保证服务的顺利运行；另一方面，启用数据持久化优化功能，合理配置备份策略，有效解决数据误操作、数据异常丢失等问题；读写分离策略：从节点可以扩展主库节点的读能力，有效应对大并发读操作。缺点：故障恢复复杂。如果没有RedisHA系统（需要开发），当主库节点出现故障时，需要手动提升一个从节点为主节点，需要通知业务方更改配置，其他从库节点需要复制新的主库节点需要全程人工干预，比较繁琐；主库写入能力受限于单机，可以考虑分片；主库存储容量受限于单机，可以考虑鼠兔；nativereplication的缺点在早期版本中也会更加突出，例如：Redis复制中断后，Slave会发起psync。如果此时同步不成功，则会进行全量同步。主库进行全量备份时，可能会造成毫秒级或秒级的卡顿；并且由于COW机制，极端情况下主库内存溢出，程序异常退出或崩溃；主库节点生成的备份文件导致服务器磁盘IO和CPU（压缩）资源的消耗；发送几千兆的备份文件，导致服务器出口带宽激增，请求受阻。建议升级到最新版本。3、Redis哨兵（Sentinel）Redis哨兵是社区版推出的原生高可用解决方案。其部署架构主要包括两部分：RedisSentinel集群和Redis数据集群。其中，RedisSentinel集群是由多个Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。RedisSentinel的节点数要满足2n+1的奇数（n>=1）。优点：RedisSentinel集群部署简单；可以解决Redis主从模式下的高可用切换问题；非常方便的实现Redis数据节点的线性扩展，轻松突破Redis自身的单线程瓶颈，可以极大的满足Redis业务的大容量或者高性能需求；可以实现一组Sentinel来监控一组Redis数据节点或者多组数据节点。缺点：部署较Redis主从模式复杂，原理理解较繁琐；资源浪费，Redis数据节点中的slave节点作为备份节点，不提供服务；RedisSentinel主要是针对Redis数据节点中master节点的高可用切换，Redis数据节点的故障判断有两种：主观下线和客观下线。对于Redis从节点，对节点进行主观下线操作，不进行故障转移。不能解决读写分离的问题，实现起来也比较复杂。建议：如果要监控同一个业务，可以选择Sentinel集群监控多组Redis数据节点，或者选择Sentinel方案监控一组Redis数据节点。sentinelmonitor建议将配置中的设置为Sentinel节点的一半加1。当Sentinel部署在多个IDC时，部署的Sentinel数量不建议单个IDC超过（哨兵数量-法定人数）。合理设置参数，防止误切，控制开关灵敏度控制：a．法定人数。毫秒后下降30000c.故障转移超时180000d。最大客户。Redis推荐使用pipeline和multi-key操作来减少RTT时间，提高请求效率。自行获取配置中心（zookeeper），方便客户端链接访问实例。4、RedisClusterRedisCluster是社区版推出的Redis分布式集群解决方案，主要解决Redis分布式方面的需求。比如在遇到单机内存、并发、流量等瓶颈时，RedisCluster可以很好的起到负载均衡的作用。RedisCluster集群节点最低配置6个节点以上（3主3从）。主节点提供读写操作，从节点作为备份节点。它不提供请求，仅用于故障转移。RedisCluster使用虚拟槽分区。根据哈希函数，所有键都映射到0到16383整数槽。每个节点负责维护一部分槽位和槽位映射的key-value数据。优点：无中心架构；数据按槽位分布在多个节点存储，节点间数据共享，数据分布可动态调整；可扩展性：线性扩展到1000个以上节点，节点可以动态添加或删除；高可用：当部分节点不可用时，集群仍然可用。通过添加Slave作为备用数据副本，可以实现故障自动转移，节点间通过gossip协议交换状态信息，利用投票机制完成从Slave到Master的角色提升；降低运维成本，提高系统的可扩展性和可用性。缺点：Client实现复杂，驱动需要SmartClient实现，slot映射信息缓存更新及时，增加开发难度，客户端不成熟影响业务稳定性.目前只有JedisCluster比较成熟，异常处理部分还不完善，比如常见的“maxredirectexception”。节点会因为某种原因被阻塞（阻塞时间大于clutser-node-timeout），判断为下线。这种故障转移是不必要的。数据是异步复制的，不保证数据的强一致性。当多个业务使用同一套集群时，无法通过统计区分冷热数据，资源隔离性差，容易相互影响。Slave在集群中充当“冷备”，无法缓解读取压力。当然，通过SDK的合理设计，可以提高Slave资源的利用率。Key批量操作限制，比如使用mset和mget目前只支持批量操作相同槽值的Key。对于映射到不同slot值的Keys，由于Keys不支持跨slot查询，所以进行mset、mget、sunion等操作并不友好。对Key事务操作的支持是有限的。仅支持同一节点上多个key的交易操作。当多个key分布在不同节点时，交易功能无法使用。Key作为数据分区的最小粒度，不能将hash、list等大key-value对象映射到不同节点。不支持多个数据库空间。单机下的redis最多可以支持16个数据库，集群模式下只能使用一个数据库空间，即db0。复制结构只支持一层，从节点只能复制主节点，并且不支持嵌套树复制结构。避免产生热键，导致主库节点成为系统的短板。避免生成big-key，造成网卡爆裂，查询慢。重试时间应大于集群节点时间。RedisCluster不推荐使用pipeline和multi-key操作来减少maxredirect产生的场景。5、Redis自研Redis自研高可用方案主要体现在配置中心、故障检测和故障转移处理机制上，通常需要根据企业业务的实际线上环境进行定制。优点：高可靠、高可用；自主可控性高；贴合实际业务需求，扩展性和兼容性好。缺点：实现复杂，开发成本高；需要建立配套的外围设施，如监控、域名服务、存储元数据信息的数据库等；维护成本高。