内容简要：
一、Redis集群架构
二、Redis存储介质
三、从社区到企业版
一、Redis集群架构
如上图所示，Redis集群架构分为两大类：标准版与集群版。
标准版是最原始的Redis单进程模式，标准版细分为双副本、单副本、读写分离三个类别。
集群版分为代理模式与直连模式。业务从标准版迁移到集群版时的可能存在Redis命令不兼容，代理模式可以通过Proxy帮业务解决这方面问题。直连模式中，Redis Client通过Redis Cluster模式直连Redis DB节点，做到减少网络时延，提升一定的性能。这两种连接模式下分别支持了双副本跟单副本两种数据形态。
（一）标准版
如上图所示，标准版的拓扑结构是业务在ECS直接通过SLB连接到后端的Redis节点。这里Redis节点会有两种情况，第一种情况是左图的一组一备，进程B是一个热备，主备之间数据直接进行同步。第二种情况是右图的冷备，只有在主节点挂掉以后，冷备会被拉起，这个时候数据是空的。
● 使用场景：
1. 对Redis协议兼容性要求较⾼的业务；
2. 单个Redis性能压⼒可控的场景；
3. Redis命令相对简单，排序和计算之类的命令较少的场景。
标准版细分为：双副本、单副本和读写分离三种形态，下面逐一介绍。
1.标准版- 双副本
标准版-双副本模式采用主从（Master-Replica）模式搭建。主节点提供日常服务访问，备节点提供HA高可用，当主节点发生故障，系统会自动在30秒内切换至备节点，保证业务平稳运行。
● 特点：
1. 可靠性：采用双机主从（Master-Replica）架构，主从节点位于不同物理机。主节点对外提供访问，用户可通过Redis命令行和通用客户端进行数据的增删改查操作。当主节点出现故障，自研的HA系统会自动进行主从切换，保证业务平稳运行。
2. 数据可靠：默认开启数据持久化功能，数据全部落盘。支持数据备份功能，用户可以针对备份集回滚实例或者克隆实例，有效地解决数据误操作等问题。同时，在支持容灾的可用区（例如杭州可用区H+I）创建的实例，还具备同城容灾的能力。
两个副本之间的数据实时异步同步，切换主备时可能存在延迟情况。当主节点宕机的时候，可能存在一部分数据没有同步到B进程（即备节点）上，此时如果进行主备切换，B进程相对于A进程有同步延迟，可能存在部分数据丢失。
此外，在双副本中可以做数据的克隆，即备份机，备份到另一个地方做数据持久化。当业务需要做数据回滚时，可以从备份机上进行恢复。
2.标准版– 单副本
标准版-单副本采用单个数据库节点部署架构，没有可实时同步数据的备用节点，不提供数据持久化和备份策略，使用于数据可靠性要求不高的纯缓存业务场景使用。
● 特点：
1. 纯缓存类业务使用，单副本只有一个在线数据节点，性价比高；
2. 阿里云自研HA高可用系统，异常30秒自动切换。
单副本在使用时需要注意，当高可用节点A宕机后，需要先对B节点进行缓存的预热，避免切换后发现B节点无数据可用。
3.读写分离
针对读多写少的业务场景，云数据库Redis推出了读写分离版的产品形态，提供高可用、高性能、灵活的读写分离服务，满足热点数据集中及高并发读取的业务需求，最大化地节约运维成本。
ECS实例通过Proxy节点，可以将读写请求分发到主节点数据分片，并将部分读请求分发到其他只读节点。
● 使用场景：
1. 读取请求QPS压力较大：适合读多写少型业务；
2. 对Redis协议兼容要求较高的业务。
● 建议与使用须知：
1. 非特殊需求不建议使用，QPS压力大的业务建议使用集群版；
2. 当一个只读节点发生故障时，请求会转发到其他节点；如果所有只读节点均不可用，请求会全部转发到主节点，导致主节点压力过大；
3. 只读节点发生异常时，高可用系统会暂停异常节点服务进行重搭恢复，但不承诺只读节点的恢复时间指标；
4. 只读节点数据旧于主节点且落后时间可能很长。
（二）集群版
● 使用场景：
1. 数据量较大的场景；
2. QPS压力较大的场景；
3. 吞吐密集型（网络带宽较大）应用场景。
1.集群版– 双副本
云数据库Redis版提供双副本集群版实例，可轻松突破Redis自身单线程瓶颈，满足大容量、高性能的业务需求。集群版支持代理和直连两种连接模式。
● 使用场景：
1. 数据量大：相比Redis标准版，集群版可以有效地扩展存储量，最大可达4098 GB，能有效的满足业务扩展的需求；
2. QPS压力较大：标准版Redis无法支撑较大的QPS，需要采用多分片的部署方式来突破Redis单线程的性能瓶颈；
3. 吞吐密集型应用：相比Redis标准版，集群版的内网吞吐限制相对较低，可以更好地支持热点数据读取、大吞吐类业务；
4. 对Redis协议兼容性不敏感的应用：集群版对Redis协议支持上相比标准版本有一定的限制。
● 特点：
代理模式因所有请求都需要通过代理服务器转发，代理模式在降低业务开发难度的同时也会小幅度影响Redis服务的响应速度，如果业务响应速度的要求非常高，可以选择直连模式，绕过代理服务器直连后端数据分片，从而降低网络开销和服务响应时间，直连模式适用于对响应要求较高的业务。
2.集群版 – 命令限制
● 不支持命令
1. SWAPDB
2. CLIENT ID
3. SORT (BY和GET)
● 受限命令
在集群模式下如果需要执行受限制的命令，需要使用HashTag确保所要操作的Key在同个Hash Slot中，Hash Tag的详细用法参见Redis官方文档。
可以看到，许多受限命令为多Key命令，为什么多Key命令会受到限制？
因为集群版会根据数据的Key做一次性Hash，分散到不同的数据节点上，这些涉及到多Key的命令，key经过Hash后如果分布在不同的节点上，命令就不能在一个单数据节点里面完成，这些命令会直接返回错误。
如果要使用这些多Key命令，需要每一个Key准确Hash到同一个Slot上。Redis的Key可以添加一个Hash Tag，相同的Tag会被Hash到同一个Slot上，在同一个Slot中，这些受限的命令就可以支持。
● Lua脚本使用限制：
1. 所有Key都应该由KEYS数组来传递；
2. 所有Key必须在同一个Slot上；
3. 调用必须要带有Key；
4. 不支持发布订阅消息；
5. 不支持UNPACK函数；
6. 其他详细限制参见Redis官方文档。
3.集群模式如何选型
● 选型时应注意以下两点：
1. 评估QPS和容量时⼀定要为未来留有余量；
2. 不同架构间存在一定的兼容性问题，业务允许的情况下尽量使用不同架构命令支持集合的交集，以便后续架构切换。
如上图所示，简言之，如果业务qps低且容量低（小于32GB）选择标准版，否则选择集群版。
在选择标准版的情况下，根据数据可靠性与读写情况可再进行细分。
如果业务数据单纯作为缓存加速或数据可丢，可以选择单副本，减少一半的成本。如果要求数据在异常情况下不能全部丢失，对可靠性要求较高的情况下，此时要根据读写情况进行选择。
如果读写情况没有明显差异，可以选择双副本，如果读请求数量远大于写请求，可以选择读写分离。但是除去特殊情况，读写分离有诸多限制，大多数情况下不是一个很好的选择，我们还是建议考虑集群的模式。
如果用户原本使用标准版，随着业务的发展QPS容量上升，需要由标准版切换成集群版，根据命令兼容性可选择不同模式。
如果用户业务代码有太多需要修改，或者不想修改代码，对命令兼容性要求较高，可以选择代理模式，兼容性问题由阿里云提供的Proxy解决。如果业务对兼容性要求较低，或者新业务在开发时本就是按照集群版标准进行，则可选择直连模式。
模式选择完之后，可根据业务对数据可靠性的要求，进一步选择单副本或双副本。此处的单双副本使用注意事项，与标准版类似。
二、Redis存储介质
购买Redis时还需选择存储介质，目前阿里云提供四种存储介质，分别为内存型、持久内存型、容量存储型和混合存储型。
内存型为我们常见的纯内存，混合存储型正逐步被持久内存型与容量存储型替代，下面重点介绍持久内存型与容量存储型。
（一）持久内存型
Redis企业版持久内存型（简称持久内存型）基于Intel 傲腾™数据中心级持久内存（AEP），为用户提供大容量、兼容Redis的内存数据库产品。单实例成本对比Redis社区版最高可降低30%，且数据持久化不依赖传统磁盘，保证每个操作持久化的同时提供近乎Redis社区版的吞吐和延时，极大提升业务数据可靠性。
● 特点：
1. 超高性价比：相同容量下对比阿里云Redis社区版本，价格降低30%左右；
2. 大规格优化：解决AOF的造成的性能开销，无需在性能和持久化之间取舍；
3. 掉电数据不丢失：每个写操作都同步持久化；
4. 高兼容性：兼容现有阿里云Redis数据库体系。
（二）容量存储型
Redis企业版容量存储型（简称容量存储型）基于云盘ESSD研发，兼容Redis核心数据结构与接口，可提供大容量、低成本、强持久化的数据库服务。容量存储型在降低成本和提升数据可靠性的同时，也解决了原生Redis固有的Fork命令而预留部分内存的问题。适用于兼容Redis、需要大容量且较高访问性能的温冷数据存储场景。
● 特点：
1. 兼容性：兼容大部分原生Redis命令；
2. 成本：最低为Redis社区版的15%。
三、从社区到企业版
（一）阿里云集群能力
阿里云Redis与开源版Redis集群能力对比
（二）开源Redis集群实现
● 实现细节：
1. 通过Gossip使所有Redis节点彼此相互心跳探活，使用内部的二进制协议优化传输速度和带宽；
2. 节点Fail时通过集群中超过半数节点探活协商确定失败，如果集群较大则会拉长协商时间；
3. 节点间数据迁移是按照Key的粒度进行的，迁移过程中一个Slot的数据会分布在两个节点上。
● 优点：
使用Gossip协议无中心控制，无额外控制节点。
● 缺点：
1. 无中心控制，集群状态更新慢，故障HA慢；
2. 探活方式单一，受慢查询干扰，容易误切换；
3. 按Key迁移，大Key迁移造成服务卡顿；
4. 迁移异常中断，无法自动恢复；
5. 迁移期间多Key命令失败；
6. 迁移依赖外部组件。
（三）阿里云Redis集群实现
● 实现细节：
1. 中心控制节点采用自研的多因子进行准确的探活；
2. 数据迁移采用Slot粒度Precopy的方式，迁移快速，异常可回滚。
● 优点：
1. 准确快速的探活，保障服务质量(SLA<15s)；
2. 同时支持直连模式和代理模式；
3. 扩缩容业务无感知（大Key，多key，Lua），不断连接；
4. 迁移流量在节点间直接传输，不需要外部组件中转。
