针对读多写少的业务场景，云原生内存数据库Tair推出了读写分离架构，提供高可用、高性能、灵活的读写分离服务，满足热点数据集中及高并发读取的业务需求。同时，读写分离架构实例由阿里云Tair团队自研的Proxy组件进行数据分发、故障切换等服务，为您降低了运维成本。
组件介绍
读写分离架构主要由主节点、只读节点、代理节点（Proxy）和高可用系统等组成，架构图如下。
图 1. 云原生版读写分离架构
图 2. 经典版读写分离架构（已停售）
组件 | 云原生版读写分离架构（推荐） | 经典版读写分离架构 |
主节点（Master node） | 承担写请求的处理，同时和只读节点共同承担读请求的处理。 | |
只读节点（Read replicas） | 承担读请求的处理，特点如下：
| 承担读请求的处理，特点如下：
|
备节点（Replica node） | 无冷备节点，任一只读节点均可作为备节点。当主节点发生异常时，可以将请求切换至任一只读节点。 由于无需该组件，在同样性能下，云原生读写分离架构的价格更低。 | 冷备节点，作为数据备份使用，不对外提供服务。当主节点发生异常时，会将请求切换至该节点。 |
代理节点（Proxy server） | 客户端和代理节点建立连接后，代理节点会自动识别客户端发起的请求类型，按照权重分发流量（各节点权重相同，且不支持自定义权重），将请求转发到不同的数据节点中。例如将写请求转发给主节点，将读请求转发给主节点和只读节点。 说明
| |
高可用系统（HA system） | 自动监控各节点的健康状态，异常时发起主备切换或重搭只读节点，并更新相应的路由及权重信息。 | |
云原生读写分离架构（推荐） | 经典读写分离架构 |
主、备可用区都提供服务，最少配置：
将分别提供主、备可用区的连接地址，均支持读、写操作。每个可用区的读请求会路由到本可用区的主节点或只读节点中，实现就近访问；而写请求均会路由到主可用区的主节点中。架构图如下：  说明 推荐主、备节点均配置2节点以上：
| 主节点与只读节点都部署在主可用区，仅将冷备节点部署在备可用区，作为数据备份，不对外提供服务。当主节点发生异常时，会将请求切换至该节点。 |
特点
透明兼容
标准架构可以直接升级到读写分离架构，由于读写分离架构使用Proxy server进行转发，在升级后，您可以直接使用支持Redis的任何客户端访问读写分离架构实例，无需进行业务改造。读写分离架构完全兼容Redis协议命令，但部分命令存在一些限制，更多信息请参见读写分离架构命令限制。
高可用
通过阿里云自研的高可用系统自动监控所有数据节点的健康状态，为整个实例的可用性保驾护航。主节点不可用时自动选择新的主节点并重新搭建复制拓扑。某个只读节点异常时，高可用系统能够自动探知并重新启动新节点完成数据同步，下线异常节点。
代理节点会实时感知每个只读节点的服务状态。在某个只读实例异常期间，代理节点会自动降低该节点的服务权重，发现只读节点连续失败超过一定次数以后，会停止异常节点的服务权利，并具备继续监控后续重新启动节点服务的能力。
高性能
读写分离架构可以通过扩展只读实例个数使整体实例性能呈线性增长，同时基于源码层面对Redis复制流程的定制优化，可以最大程度地提升线性复制的系统稳定性，充分利用每一个只读节点的物理资源。
使用场景
读取请求QPS（Queries Per Second）压力较大的场景。
Tair标准架构无法支撑较大的QPS，如果业务类型是读多写少类型，需要采用多个只读节点的部署方式来突破单节点的性能瓶颈，相比标准版最高可以将QPS提升近9倍。
由于数据同步至只读节点存在一定延迟，选用此架构时，业务需要能接受一定程度的脏数据。如果对数据一致性要求较高，推荐选用集群架构。
建议与使用须知
当一个只读节点发生故障时，请求会转发到其他节点；如果所有只读节点均不可用，请求会全部转发到主节点。只读节点异常可能导致主节点负载提高、响应时间变长，因此在读负载高的业务场景建议使用多个只读节点。
只读节点发生异常时，高可用系统会暂停异常节点的服务，重新挂载一个可用的只读节点。该过程涉及资源分配、实例创建数据同步以及服务加载，消耗的时间与业务负载及数据量有关。云原生内存数据库Tair不承诺只读节点的恢复时间指标。
某些场景会触发只读节点的全量同步，例如在主节点触发高可用切换后。全量同步期间只读节点不提供服务并返回
-LOADING Redis is loading the dataset in memory\r\n信息。更多关于路由转发的规则，请参见Tair Proxy特性说明。