近来一直在折腾redis高可用的方案，以及优缺点以及如何选择合适的方案线上使用，

刚好看到这篇，分享下

Redis常见的几种主要使用方式：

• Redis 单副本

• Redis 多副本（主从）

• Redis Sentinel（哨兵）

• Redis Cluster

• Redis 自研

Redis各种使用方式的优缺点：

1 Redis单副本

Redis 单副本，采用单个Redis节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。

优点：

1、架构简单、部署方便

2、高性价比，当缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务。

3、高性能

缺点：

1、不保证数据的可靠性

2、当缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务。

3、高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用memcached替代。

2 Redis多副本（主从）

Redis 多副本，采用主从（replication）部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。

优点：

1、高可靠性，一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服务，保证服务平稳运行。另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题。

2、读写分离策略，从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。

缺点：

1、故障恢复复杂，如果没有RedisHA系统（需要开发），当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其他从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐。

2、主库的写能力受到单机的限制，可以考虑分片

3、主库的存储能力受到单机的限制，可以考虑Pika

4、原生复制的弊端在早期的版本也会比较突出，如：Redis复制中断后，Slave会发起psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿；又由于COW机制，导致极端情况下的主库内存溢出，程序异常退出或宕机；主库节点生成备份文件导致服务器磁盘IO和CPU（压缩）资源消耗；发送数GB大小的备份文件导致服务器出口带宽暴增，阻塞请求。建议升级到最新版本。

3 Redis Sentinel（哨兵）

Redis Sentinel是社区版本推出的原生高可用解决方案，Redis Sentinel部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群，其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群。可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。

优点：

1、Redis Sentinel集群部署简单

2、能够解决Redis主从模式下的高可用切换问题

3、很方便实现Redis数据节点的线形扩展，轻松突破Redis自身单线程瓶颈，可极大满足对Redis大容量或高性能的业务需求。

4、可以实现一套Sentinel监控一组Redis数据节点或多组数据节点

缺点：

1、部署相对Redis 主从模式要复杂一些，原理理解更繁琐

2、资源浪费，Redis数据节点中slave节点作为备份节点不提供服务

3、Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换，对Redis的数据节点做失败判定分为主观下线和客观下线两种，对于Redis的从节点有对节点做主观下线操作，并不执行故障转移。

4、不能解决读写分离问题，实现起来相对复杂

建议：

1、如果监控同一业务，可以选择一套Sentinel集群监控多组Redis数据节点的方案，反之选择一套Sentinel监控一组Redis数据节点的方案

2、sentinel monitor <master-name> <ip> <port> <quorum> 配置中的<quorum>建议设置成Sentinel节点的一半加1，当Sentinel部署在多个IDC的时候，单个IDC部署的Sentinel数量不建议超过（Sentinel数量 – quorum）。

3、合理设置参数，防止误切，控制切换灵敏度控制

1. quorum

2. down-after-milliseconds 30000

3. failover-timeout 180000

4. maxclient

5. timeout

4、部署的各个节点服务器时间尽量要同步，否则日志的时序性会混乱

5、Redis建议使用pipeline和multi-keys操作，减少RTT次数，提高请求效率

6、自行搞定配置中心（zookeeper），方便客户端对实例的链接访问

4 Redis Cluster

Redis Cluster是社区版推出的Redis分布式集群解决方案，主要解决Redis分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster能起到很好的负载均衡的目的。Redis Cluster集群节点最小配置6个节点以上（3主3从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0～16383个整数槽内，每个节点负责维护一部分槽以及槽所印映射的键值数据。

优点：

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产生的场景。

5 Redis自研 推荐

Redis 自研的高可用解决方案，主要体现在配置中心、故障探测和failover的处理机制上，通常需要根据企业业务的实际线上环境来定制化。

优点：

1、高可靠性、高可用性

2、自主可控性高

3、贴切业务实际需求，可缩性好，兼容性好

缺点：

1、实现复杂，开发成本高

2、需要建立配套的周边设施，如监控，域名服务，存储元数据信息的数据库等。

3、维护成本高

内容来源地址：https://mp.weixin.qq.com/s/BoLsVKYyu8yRXZbxd1uuQw

Redis高可用技术解决方案大全相关推荐

1. 这可能是目前最全的Redis高可用技术解决方案

   转自:https://mp.weixin.qq.com/s/Z-PyNgiqYrm0ZYg0r6MVeQ 原作者:张东洪 常见的使用方式 Redis的几种常见的使用方式包括: Redis 单副本 Re ...

2. Redis 高可用篇：你管这叫主从架构数据同步原理？

   高可用有两个含义:一是数据尽量不丢失,二是服务尽可能提供服务. AOF 和 RDB 保证了数据持久化尽量不丢失,而主从复制就是增加副本,一份数据保存到多个实例上.即使有一个实例宕机,其他实例依然可以提 ...

3. 这可能是史上最全 Redis 高可用解决方案总结

   转载自  这可能是史上最全 Redis 高可用解决方案总结 本文主要针对 Redis 常见的几种使用方式及其优缺点展开分析. 一.常见使用方式 Redis 的几种常见使用方式包括: Redis 单副本 ...

4. Redis高可用详解：持久化技术及方案选择

   文章摘自:https://www.cnblogs.com/kismetv/p/9137897.html 前言 在上一篇文章中,介绍了Redis的内存模型,从这篇文章开始,将依次介绍Redis高可用相关 ...

5. Redis高可用解决方案：sentinel（哨兵模式）和集群

   一. redis高可用方案–sentinel(哨兵模式) 当我们搭建好redis主从复制方案后会发现一个问题,那就是当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力, ...

6. Redis高可用方案-哨兵与集群

   祝大家每日进步,有技术问题多多交流,同时欢迎大家关注我的头条号:IT人孙会良 Redis高可用方案 一.名词解释 二.主从复制 Redis主从复制模式可以将主节点的数据同步给从节点,从而保障当主节点不 ...

7. Redis 高可用特性之 “持久化” 详解

   在之前的文章中,介绍了<Redis的内存模型>,从这篇文章开始,将依次介绍 Redis 高可用相关的知识--持久化.复制(及读写分离).哨兵.以及集群. 本文将先说明上述几种技术分别解决了 ...

8. (转)Oracle与DB2在数据库高可用技术上的相同与差异探讨

   原文:http://www.talkwithtrend.com/Article/178339 数据库建设过程中,高可用是每一个企业数据中心数据库建设过程中至关重要的一个关注点,直接关系到业务连续性和稳 ...

9. Redis数据库（二）——Redis高可用、持久化及性能管理

   Redis数据库(二)--Redis高可用.持久化及性能管理 一.Redis 高可用 主要的高可用技术 二.Redis 持久化 1.持久化的功能 2.两种持久化方式 3.RDB 和 AOF 的区别 ① ...

最新文章

1. Python的最佳学习方式
2. blockboard vs canvas
3. r语言 C4.5 剪枝是用什么算法_决策树，逻辑回归，PCA算法面经
4. python写入mysql数据库_python调用http接口,数据写入mysql数据库并下载录音文件
5. Python天天美味(4) - isinstance判断对象类型
6. 工具类篇——时间处理Calendar类
7. 绝对的干货大放送：常用正则表达式收集大全
8. kaggle注册没有验证码
9. 前端基础（HTML，CSS，JavaScript）知识笔记，附：前端基础面试题！！
10. 【十三】python面向对象之类和对象
11. android apk是什么文件,apk是什么文件?apk文件肿么打开?
12. dropout层加在哪里_Nomaomi
13. “华为“和“荣耀”区别日益明显，荣耀传递潮流价值观
14. PTA-天梯赛-7-8 GOGO冲
15. layui使用模板渲染数据
16. 四缸汽油机曲轴及凸轮轴信号生成（基于STM32）
17. Java Web关键字填空
18. 微信接口验证类php,微信公众平台消息接口校验与消息接口响应实例
19. 使用 vue-direction-key 快速切换 input 的焦点 focus
20. Redim preserve

热门文章

1. Redis学习（自用）
2. C语言中一维数组和二维数组的寻常遍历用指针的遍历
3. 不服就开干，手撕智能助手背后的自然语言处理技术
4. Python3中模拟打印机效果
5. CentOS6安装dovecot并提供sasl功能
6. 今天上午跟同事去一个小区做地推
7. PHP和Java的区别和用处？答案在这里
8. saf disaulgh flkas.M f；lxm lkdf,vlk,.
9. DHtml真的很吊！！！
10. 感谢您关注梦想天空博客！为我投上您宝贵的一票！