本文次要针对 Redis 常见的几种应用形式及其优缺点开展剖析。
一、常见 应用形式
Redis 的几种常见应用形式包含：
• Redis 单正本；
• Redis 多正本（主从）；
• Redis Sentinel（哨兵）；
• Redis Cluster；
• Redis 自研。
二、各种应用形式的优缺点
1、Redis 单正本
Redis 单正本，采纳单个 Redis 节点部署架构，没有备用节点实时同步数据，不提供数据长久化和备份策略，实用于数据可靠性要求不高的纯缓存业务场景。
长处：
• 架构简略，部署不便；
• 高性价比：缓存应用时无需备用节点（单实例可用性能够用 supervisor 或 crontab 保障），当然为了满足业务的高可用性，也能够就义一个备用节点，但同时刻只有一个实例对外提供服务；
• 高性能。
毛病：
• 不保证数据的可靠性；
• 在缓存应用，过程重启后，数据失落，即便有备用的节点解决高可用性，然而依然不能解决缓存预热问题，因而不适用于数据可靠性要求高的业务；
• 高性能受限于单核 CPU 的解决能力（Redis 是单线程机制），CPU 为次要瓶颈，所以适宜操作命令简略，排序、计算较少的场景。也能够思考用 Memcached 代替。
2、Redis 多正本（主从）
Redis 多正本，采纳主从（replication）部署构造，相较于单正本而言最大的特点就是主从实例间数据实时同步，并且提供数据长久化和备份策略。主从实例部署在不同的物理服务器上，依据公司的根底环境配置，能够实现同时对外提供服务和读写拆散策略。
长处：
• 高可靠性：一方面，采纳双机主备架构，可能在主库呈现故障时主动进行主备切换，从库晋升为主库提供服务，保障服务安稳运行；另一方面，开启数据长久化性能和配置正当的备份策略，能无效的解决数据误操作和数据异样失落的问题；
• 读写拆散策略：从节点能够扩大主库节点的读能力，有效应对大并发量的读操作。
毛病：
• 故障复原简单，如果没有 RedisHA 零碎（须要开发），当主库节点呈现故障时，须要手动将一个从节点降职为主节点，同时须要告诉业务方变更配置，并且须要让其它从库节点去复制新主库节点，整个过程须要人为干涉，比拟繁琐；
• 主库的写能力受到单机的限度，能够思考分片；
• 主库的存储能力受到单机的限度，能够思考 Pika；
• 原生复制的弊病在晚期的版本中也会比较突出，如：Redis 复制中断后，Slave 会发动 psync，此时如果同步不胜利，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿；又因为 COW 机制，导致极其状况下的主库内存溢出，程序异样退出或宕机；主库节点生成备份文件导致服务器磁盘 IO 和 CPU（压缩）资源耗费；发送数 GB 大小的备份文件导致服务器进口带宽暴增，阻塞申请，倡议降级到最新版本。
3、Redis Sentinel（哨兵）
Redis Sentinel 是社区版本推出的原生高可用解决方案，其部署架构次要包含两局部：Redis Sentinel 集群和 Redis 数据集群。
其中 Redis Sentinel 集群是由若干 Sentinel 节点组成的分布式集群，能够实现故障发现、故障主动转移、配置核心和客户端告诉。Redis Sentinel 的节点数量要满足 2n+1（n>=1）的奇数个。
长处：
• Redis Sentinel 集群部署简略；
• 可能解决 Redis 主从模式下的高可用切换问题；
• 很不便实现 Redis 数据节点的线形扩大，轻松冲破 Redis 本身单线程瓶颈，可极大满足 Redis 大容量或高性能的业务需要；
• 能够实现一套 Sentinel 监控一组 Redis 数据节点或多组数据节点。
毛病：
• 部署绝对 Redis 主从模式要简单一些，原理了解更繁琐；
• 资源节约，Redis 数据节点中 slave 节点作为备份节点不提供服务；
• Redis Sentinel 次要是针对 Redis 数据节点中的主节点的高可用切换，对 Redis 的数据节点做失败断定分为主观下线和主观下线两种，对于 Redis 的从节点有对节点做主观下线操作，并不执行故障转移。
• 不能解决读写拆散问题，实现起来绝对简单。
倡议：
• 如果监控同一业务，能够抉择一套 Sentinel 集群监控多组 Redis 数据节点的计划，反之抉择一套 Sentinel 监控一组 Redis 数据节点的计划。
• sentinel monitor <master-name> <ip> <port> <quorum> 配置中的 <quorum> 倡议设置成 Sentinel 节点的一半加 1，当 Sentinel 部署在多个 IDC 的时候，单个 IDC 部署的 Sentinel 数量不倡议超过（Sentinel 数量 – quorum）。
• 正当设置参数，避免误切，管制切换灵敏度管制：
a. quorum
b. down-after-milliseconds 30000
c. failover-timeout 180000
d. maxclient
e. timeout
• 部署的各个节点服务器工夫尽量要同步，否则日志的时序性会凌乱。
• Redis 倡议应用 pipeline 和 multi-keys 操作，缩小 RTT 次数，进步申请效率。
• 自行搞定配置核心（zookeeper），不便客户端对实例的链接拜访。
4、Redis Cluster
Redis Cluster 是社区版推出的 Redis 分布式集群解决方案，次要解决 Redis 分布式方面的需要，比方，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载平衡的目标。
Redis Cluster 集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为备用节点，不提供申请，只作为故障转移应用。
Redis Cluster 采纳虚构槽分区，所有的键依据哈希函数映射到 0～16383 个整数槽内，每个节点负责保护一部分槽以及槽所印映射的键值数据。
长处：
• 无核心架构；
• 数据依照 slot 存储散布在多个节点，节点间数据共享，可动静调整数据分布；
• 可扩展性：可线性扩大到 1000 多个节点，节点可动静增加或删除；
• 高可用性：局部节点不可用时，集群仍可用。通过减少 Slave 做 standby 数据正本，可能实现故障主动 failover，节点之间通过 gossip 协定替换状态信息，用投票机制实现 Slave 到 Master 的角色晋升；
• 升高运维老本，进步零碎的扩展性和可用性。
毛病：
• Client 实现简单，驱动要求实现 Smart Client，缓存 slots mapping 信息并及时更新，进步了开发难度，客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 绝对成熟，异样解决局部还不欠缺，比方常见的“max redirect exception”。
• 节点会因为某些起因产生阻塞（阻塞工夫大于 clutser-node-timeout），被判断下线，这种 failover 是没有必要的。
• 数据通过异步复制，不保证数据的强一致性。
• 多个业务应用同一套集群时，无奈依据统计辨别冷热数据，资源隔离性较差，容易呈现相互影响的状况。
• Slave 在集群中充当“冷备”，不能缓解读压力，当然能够通过 SDK 的正当设计来进步 Slave 资源的利用率。
• Key 批量操作限度，如应用 mset、mget 目前只反对具备雷同 slot 值的 Key 执行批量操作。对于映射为不同 slot 值的 Key 因为 Keys 不反对跨 slot 查问，所以执行 mset、mget、sunion 等操作反对不敌对。
• Key 事务操作反对无限，只反对多 key 在同一节点上的事务操作，当多个 Key 散布于不同的节点上时无奈应用事务性能。
• Key 作为数据分区的最小粒度，不能将一个很大的键值对象如 hash、list 等映射到不同的节点。
• 不反对多数据库空间，单机下的 redis 能够反对到 16 个数据库，集群模式下只能应用 1 个数据库空间，即 db 0。
• 复制构造只反对一层，从节点只能复制主节点，不反对嵌套树状复制构造。
• 防止产生 hot-key，导致主库节点成为零碎的短板。
• 防止产生 big-key，导致网卡撑爆、慢查问等。
• 重试工夫应该大于 cluster-node-time 工夫。
• Redis Cluster 不倡议应用 pipeline 和 multi-keys 操作，缩小 max redirect 产生的场景。
5、Redis 自研
Redis 自研的高可用解决方案，次要体现在配置核心、故障探测和 failover 的解决机制上，通常须要依据企业业务的理论线上环境来定制化。
长处：
• 高可靠性、高可用性；
• 自主可控性高；
• 贴切业务理论需要，可缩性好，兼容性好。
毛病：
• 实现简单，开发成本高；
• 须要建设配套的周边设施，如监控，域名服务，存储元数据信息的数据库等；
• 保护老本高。
转载侵删
原文地址
https://developer.aliyun.com/…