RDS 循序渐进 – 闪断篇

阿里云关系型数据库服务（后简称RDS） 为用户提供的诸多功能中，其中有一个最基本也最为重要的特性：快速为用户部署一个“高可用”的数据库环境。本篇我们主要一起来探讨RDS“高可用”的实现方案以及在此方案中出现的“闪断”情况。

RDS高可用实现方案

RDS 为保证高可用服务，为每个用户购买的实例在后端提供了两个节点，正常情况下某一时刻只由主节点（下图中的节点A）提供读写服务，而备节点（下图中的节点B）负责数据同步；当A发生（硬件）故障时， HA控制器（代号：AURORA）会在30秒内将服务切换到B节点上面，通过这种机制来保证数据库实例的高可用性。

RDS 简易链路访问图

进行主备切换后，真正生效的服务节点为B。为了主备切换对用户和应用透明，我们使用VIP技术来提供数据服务。用户在程序里只要配置VIP地址，不管后端节点切换到哪里，都不需要变更数据库连接地址，即可继续与数据库服务建立会话并完成请求。

虽然RDS在发生主备切换后，应用程序与数据库可以建立新会话（SESSION），但在切换前APP与RDS建立好的会话（保存在A节点）已经断开，对程序来说这部分会话已经失效，这时候需要程序有能力重新建立会话以恢复正常请求。

RDS 闪断，是指APP与RDS之间的网络链路在短时间内（一般不超过三十秒）发生了中断，需要应用重新建立连接即可恢复；虽然是通过VIP提供服务，但APP与数据库的连接是保存在A节点上面，在发生切换后，APP与A节点建立的物理链接也会被中断，导致APP需要与B节点重新建立链接；这就是闪断发生的整个过程。

如何应对“闪断”

处理闪断其实很简单，有两种常见方法：

1）  使用“短连接”模式向数据库发起请求

短连接模式，是指与数据库建立会话后，只进行一次请求，完成后该会话即被关闭；

不过短连接模式下，每个请求都需要向数据库认证账号与密码，每个认证过程至少6次网络交互，效率较低；适合于请求量较小的应用或网站采用。

2）  配置连接池，使其消除掉有问题的连接（推荐模式）

大多数连接池均包含链接有效性探测，适当配置后即可消除连接闪断对应用的影响，比如适用于JAVA语言的CP30、DBCP、Druid等连接池，均可通过以下几个参数设置(需要充分测试以确定可能的性能开销)：

当然技术总是需要不断进步的。RDS 内核团队正在研究一种”桥接”技术，当发生节点A到节点B的切换时，可以自动让APP与节点B建立连接，做到对APP完全透明。该技术成功突破后，数据库的重连机制会由底层统一实现，不再需要大家去重复敲相同的代码，那将是开发者的一大福音。