云上RDS架构

╰半橙微兮° 2023-08-17 17:01 86阅读 0赞

## 概述 ##

越来越多的企业选择上云，最基础的云服务就是IaaS(Infrastructure as a Service)服务，直观理解就是虚拟主机，用户不用再自建机房，自己购买服务器，而是直接向云厂商购买虚拟主机服务ECS(Elastic Compute Service)，按时按量付费。对于数据库而言，将数据库能力集成进来，就是DaaS(Database as a Service)服务，我这里主要讨论RDS(Relational Database Service)。因为目前主流云厂商在数据库领域，除了基础的RDS服务，还有新型分布式数据库服务，比如Amazon的Aurora，阿里云的PolarDB等。所以对于用户而言，他们选择在云上使用数据有两种方式，一种是自己买ECS，自己搭建数据库服务；另外一种方式是，直接购买RDS服务。本文主要讨论RDS的链路，RDS链路中的核心组件SLB转发模式，以及RDS中proxy的作用，最后还会提到RDS的高可用解决方案。

## RDS链路 ##

### 1. app+ECS(DB)自建 ###

![176539-20190817220557449-1426418365.png][]

### 2. app+lvs+DB ###

![176539-20190817220621453-1544346420.png][]

![176539-20190817220653510-1619340434.png][]

简单说明下，云上并不提供单独买一个RDS的服务，因为这种场景无法提供高可用能力，所以一般购买数据库服务时，会同时带上SLB作为一套整体解决方案。SLB本质就是基于LVS的改进，LVS工作在IOS七层网络模型的TCP/IP层，属于4层负载均衡。利用IP,Port映射转发能力，提供高可用，负载均衡等能力，RDS正是借助SLB来实现RDS的高可用和负载均衡等能力。LVS主要有几种工作模式，DR模式，NAT模式，FULL-NAT模式，IP-TUN模式以及我们阿里云优化的ENAT模式。

#### 2.1 DR模式(Direct Routing) ####

核心逻辑：本质是2层转发，SLB-Server与RDS共享一个IP，经过SLB-Server时，SLB-Server将mac地址改为目标RDS的mac地址，将请求包转给真实的RDS；回包时不用经过SLB-Server，DR模式要求SLB和RDS需要配置相同的VIP地址。

![176539-20190817221828852-1396394557.png][]

![176539-20190817220837125-2112334818.png][]

#### 2.2 NAT模式(Network Address Translation) ####

![176539-20190817220910016-1409278472.png][]

![176539-20190817220934856-706829981.png][]

核心逻辑：client端不感知RDS真实地址；发包经过SLB时，dip(dest\_ip)会被替换成RDS的ip，请求包返回经过SLB时，再将回包源地址改为vip。对比DR模式，请求和回报都需要经过SLB-Server，RDS的ip不再需要是公网地址；与DR模式相同的是，SLB和RDS需要在同一个局域网内。

#### 2.3 FULL NAT模式 ####

![176539-20190817220958999-1582930817.png][]

核心逻辑：本质是4层转发，请求经过LVS时，LVS请求的(IP,Port)替换成真实RDS的(IP,Port)，回包时，再经过LVS，将回包的源地址改为LVS的(IP,Port)，LVS与RDS不再要求在同一个局域网内。所有请求的来回都要经过LVS，效率比较低。

#### 2.4 ENAT模式(Enhance NAT，三角模式) ####

### ![176539-20190817221018062-1635417397.png][] ###

核心逻辑：ENAT模式解决了来回包都要经过LVS问题，具体而言，LVS接收请求后，修改包地址时，会将用户的CIP地址冗余在网络包中，回包时，将包改为(vip,cip)，这样就不用再经过LVS了。

### 3. app+lvs+proxy+DB ###

![176539-20190817221035651-2053636464.png][]

通过引入SLB，RDS已经具备了高可用的能力，但由于SLB是工作在4层负载均衡，对于应用层协议无法感知，所以当发生主备切换时，所有已经连接在old-master的连接都需要被断掉，对用户来说，就是连接发生了闪断，对于没有重连机制的业务简直就是灾难。引入proxy后，则能有效解决这种问题。切换过程中，对于old-master会等待事务完成，而新的请求则会路由到new-Master。

核心逻辑：本质是7层转发，proxy模拟实现MySQL协议，应用实际是连接proxy，proxy再连接RDS，转发SQL给RDS，并将结果集转发回传给应用。

### 4.主要优缺点对比 ###

<table> 
 <tbody> 
 <tr> 
 <td> RDS链路类型 </td> 
 <td> 优势 </td> 
 <td> 缺陷 </td> 
 </tr> 
 <tr> 
 <td> App+ECS(DB)自建 </td> 
 <td> 成本低 </td> 
 <td> 用户个人负责数据库的容灾、备份、恢复、监控、迁移 </td> 
 </tr> 
 <tr> 
 <td colspan="1"> App+lvs+DB </td> 
 <td colspan="1"> 无需经过proxy转发，RT短，具备高可用能力 </td> 
 <td colspan="1"> 无法解决闪断问题，也不容易实现读写分离等高级功能 </td> 
 </tr> 
 <tr> 
 <td colspan="1"> App+lvs+Proxy+DB </td> 
 <td colspan="1"> 功能丰富，包括防SQL注入，读写分离，连接池等。 </td> 
 <td colspan="1"> 多一跳proxy，增加RT。 </td> 
 </tr> 
 </tbody> 
</table>

## Proxy中间件 VS TDDL 中间件 ##

proxy中间件引入使得RDS除了具备必要的高可用能力，还能实现更多的高级功能，包括读写分离，连接池，防SQL注入，防闪断等，这部分能力的获取是通过牺牲一定RT来获得的。实际上，中间件有两种模式，一种是client模式，一种是server模式，集团的TDDL和云上的Proxy就是两种典型代表。client模式要求与语言强绑定，比如TDDL中间件以jar包的模式打进用户的应用，只支持JAVA语言，这对于云上业务肯定是不可行的，毕竟现在用PHP，Python写后端的应用也非常多。另外一点是，client模式会导致连接数随着client的个数同比例增加，这带来的影响是到后端DB的连接数增加，client模式的好处是不用经过proxy这一跳，RT更好；而server模式则能有效控制到后端DB的连接数，但是整个链路增加了一层，也就增加了一层风险，Proxy自身的高可用也需要严格保证，确保整个链路的可用性。至于功能层面的，比如读写分离，连接池，防SQL注入等功能，两种都是可以实现的。

## RDS高可用 ##

云上售卖的数据库都是传统的数据库包括MySQL，PostgreSQL，SQLServer等都是单机数据库，所以数据库的高可用还需要依赖于外部的HA组件。

![176539-20190817221103596-1872389265.png][]

![176539-20190817221139504-1474953971.png][]

## 参考文档 ##

[https://my.oschina.net/yunqi/blog/3069510][https_my.oschina.net_yunqi_blog_3069510]

转载于:https://www.cnblogs.com/cchust/p/11366175.html

[176539-20190817220557449-1426418365.png]: /images/20230808/92f5f2f9d7e541d5952a081e5b159fca.png
[176539-20190817220621453-1544346420.png]: /images/20230808/826be29b24bd42bd910a7df0d4119452.png
[176539-20190817220653510-1619340434.png]: /images/20230808/d84fdf982921492b981b74005948a117.png
[176539-20190817221828852-1396394557.png]: /images/20230808/539014eb4ea94fc58ce6e2bbcc55d0f2.png
[176539-20190817220837125-2112334818.png]: /images/20230808/8da68f1332b94b648f24e098a5ff17a2.png
[176539-20190817220910016-1409278472.png]: /images/20230808/f35c08c94ea3412387c2a90608a62246.png
[176539-20190817220934856-706829981.png]: /images/20230808/6d6752e89ef5497fba9359c5d7a4a8fc.png
[176539-20190817220958999-1582930817.png]: /images/20230808/1fea9cba9b2146bd8c0438eab2f9b72e.png
[176539-20190817221018062-1635417397.png]: /images/20230808/a877b82e12b04f058147eb8c1aa07ba2.png
[176539-20190817221035651-2053636464.png]: /images/20230808/3f8ce60fb3ec464c9ed2f6992892d9c7.png
[176539-20190817221103596-1872389265.png]: /images/20230808/cbebf39ad69848bbb3de9af69aa55098.png
[176539-20190817221139504-1474953971.png]: /images/20230808/179a0c3a52d74eb7830fdbc839f5d01c.png
[https_my.oschina.net_yunqi_blog_3069510]: https://my.oschina.net/yunqi/blog/3069510