Redis高可用技术方案对比-阿里云开发者社区

Redis高可用技术方案对比

2023-11-13 106

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

Redis 开源版，标准版 2GB

云数据库 Tair（兼容Redis），内存型 2GB

简介： Redis高可用技术方案对比

方式	优点	缺点
Redis 单副本	1. 架构简单、部署方便 2. 高性价比，当缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务 3. 高性能	1. 不保证数据的可靠性 2. 当缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务 3. 高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用memcached替代。
Redis 多副本（主从）	1. 高可靠性，一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服务，保证服务平稳运行。另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题。 2. 读写分离策略，从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。	1. 故障恢复复杂，如果没有RedisHA系统（需要开发），当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其他从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐。 2. 主库的写能力受到单机的限制，可以考虑分片 3. 主库的存储能力受到单机的限制，可以考虑Pika 4. 原生复制的弊端在早期的版本也会比较突出，如：Redis复制中断后，Slave会发起psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿；又由于COW机制，导致极端情况下的主库内存溢出，程序异常退出或宕机；主库节点生成备份文件导致服务器磁盘IO和CPU（压缩）资源消耗；发送数GB大小的备份文件导致服务器出口带宽暴增，阻塞请求。建议升级到最新版本。
Redis Sentinel（哨兵）	1. Redis Sentinel集群部署简单 2. 能够解决Redis主从模式下的高可用切换问题 3. 很方便实现Redis数据节点的线形扩展，轻松突破Redis自身单线程瓶颈，可极大满足对Redis大容量或高性能的业务需求 4. 可以实现一套Sentinel监控一组Redis数据节点或多组数据节点	1. 部署相对Redis 主从模式要复杂一些，原理理解更繁琐 2. 资源浪费，Redis数据节点中slave节点作为备份节点不提供服务 3. Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换，对Redis的数据节点做失败判定分为主观下线和客观下线两种，对于Redis的从节点有对节点做主观下线操作，并不执行故障转移。 4. 不能解决读写分离问题，实现起来相对复杂
Redis Cluster	1. 无中心架构 2. 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布。 3. 可扩展性，可线性扩展到1000多个节点，节点可动态添加或删除。 4. 高可用性，部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。 5. 降低运维成本，提高系统的扩展性和可用性。	1. Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。 2. 节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的。 3. 数据通过异步复制,不保证数据的强一致性。 4. 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。 5. Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率。 6. key批量操作限制，如使用mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于keys 不支持跨slot查询，所以执行mset、mget、sunion等操作支持不友好。 7. key事务操作支持有限，只支持多key在同一节点上的事务操作，当多个key分布于不同的节点上时无法使用事务功能。 8. key作为数据分区的最小粒度，因此不能将一个很大的键值对象如hash、list等映射到不同的节点。 9. 不支持多数据库空间，单机下的redis可以支持到16个数据库，集群模式下只能使用1个数据库空间，即db 0。 10. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。 11. 避免产生hot-key，导致主库节点成为系统的短板。 12. 避免产生big-key，导致网卡撑爆、慢查询等。 13. 重试时间应该大于cluster-node-time时间 14. Redis Cluster不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。
Redis 自研	1. 高可靠性、高可用性 2. 自主可控性高 3. 贴切业务实际需求，可缩性好，兼容性好	1. 实现复杂，开发成本高 2. 需要建立配套的周边设施，如监控，域名服务，存储元数据信息的数据库等 3. 维护成本高

Redis高可用技术方案对比

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

Redis高可用技术方案对比

热门文章

最新文章

相关课程

相关电子书

相关实验场景