Proxy下的Prepare透传，让GaussDB(for MySQL)更稳固，性能更卓越
本文分享自华为云社区《Proxy下的Prepare透传，让GaussDB(for MySQL)更稳固，性能更卓越》，作者： GaussDB 数据库 。
1.引言
在很多业务场景下，数据库应用程序处理大量相同的SQL语句——只需更改SQL语句中的文字或变量值。例如：使用相同的SQL模板进行WHERE查询，SET 更新和VALUES 插入等操作。数据库内部收到SQL语句后，需要对语句进行解析，即翻译成机器可执行的语言，对大量相似的语句要做反复的重复翻译。GaussDB(for MySQL)支持Prepare协议，来减少重复翻译的工作量。Prepare协议利用高效的客户端/服务端二进制协议，在预处理语句中使用占位符代替参数值，使每个预处理语句只用解析一次，从而减少数据库的开销。
另外，由于程序员的水平及经验参差不齐，相当大一部分程序员在编写代码的时候，并不会考虑SQL注入风险，使不法分子植入恶意SQL攻击数据库有了可乘之机。SQL注入通过将恶意的SQL查询或更新语句插入到应用的输入参数中，后台数据库做SQL解析时将遭受攻击。由于Prepare协议在输入参数之前已经完成了SQL的预编译，因此将恶意的SQL当做参数插入时，数据库不会重新编译，因此可以防止SQL注入攻击，具备更高的安全性。
综上，Prepare协议可以带来数据库性能和稳固方面的双重收益。
2.Prepare执行流程
Prepare协议分为两个阶段，第一阶段是提交带占位符的预编译SQL，第二阶段是传输数据，将占位符替换为数据进行执行。
Prepare协议应用代码案例：
3.数据库代理(Proxy)场景下的Prepare协议
在“高可用只读，让RDS for MySQL更稳定”一文中，我们曾提及了使用数据库代理（Proxy）实现读写分离及高可靠的方案。GaussDB(for MySQL)同样支持多Proxy，以实现读写分离，自动均衡负载及在只读实例故障时自动路由至其他实例的高可靠和高性能方案。——GaussDB(for MySQL)同样支持多Proxy，以实现读写分离，自动均衡负载及在只读实例故障时自动路由至其他实例，具备高可靠和高性能能力。
数据库代理是位于数据库服务端和应用服务端之间的网络代理服务，其接收应用程序的连接，根据路由情况将SQL请求自动分发到GaussDB(for MySQL)节点上执行。数据库代理（以下简称proxy）具有高可用、高性能、可运维、简单易用等特点，提供自动读写分离、连接池、事务拆分、会话一致性等功能，详细架构图如下：
3.1 Proxy下的Prepare协议实现方案
未采用Proxy时，Prepare协议的两阶段（预编译阶段和执行阶段）直接在数据库节点上执行。Proxy加入后，由于数据库代理会将同一个连接上的不同SQL分发到多个后端数据库上，因此数据库代理需要保存预编译SQL和执行参数的对应关系，并在执行时，传入至数据库节点上执行。目前Proxy场景下的Prepare协议实现方案有两种：
- 文本模式（诞生较早的模式）
- 透传模式（现下流行的模式）
3.1.1 文本模式：
Proxy内部保存预编译SQL的相关信息，将客户端发送的二进制Prepare协议转换为普通文本协议进行传输，即在Proxy侧完成解析和替换，将解析和替换后的SQL发往后端数据库，无需依赖数据库进行解析转换。
优势：
- 实现简单，任何SQL无条件封装成文本SQL直接执行。
- 可以任意路由。
- 当数据库代理和后端数据库连接断开时，客户端无感知，自动兼容容灾场景。
劣势：
- 需要解析类型结构，并拼装原始SQL，对发过来的类型强依赖。例如：执行SELECT * FROM t1 LIMIT ?，当发送String类型数据时，会将其拼接成一个带引号的String值：SELECT * FROM t1 LIMIT ‘10’， 数据库不支持此种SQL语法导致执行报错。
- 由于每条SQL都需要在数据库代理侧进行拼接，且拼接时，Proxy侧需要根据数据类型处理SQL注入问题，代理侧性能损耗严重，容易成为瓶颈。
3.1.2透传模式
透传模式下Proxy侧只做预编译阶段的事情，执行阶段将预编译语句和参数数据直接发往后端数据库。即Proxy侧不执行解析和编译。透传模式有两种实现方式：
广播式透传（多数数据库厂商在用的模式）广播式透传是将客户端发的预编译语句发送到所有的后端数据库节点，即所有后端数据库节点在接收到参数后都可以解析、编译和执行语句。故发送参数时，只需要任意选择一个已发送预编译语句的节点传输即可。
优势：
- Proxy无需拼装解析SQL。
- Proxy无需维护预编译语句和后端数据库节点之间的映射关系，只需要负责广播和转发，实现简单。
劣势：
- 所有数据库节点承受了同等的压力，同一条预编译语句被多个数据库节点执行，资源存在浪费，某个节点压力大时，还会承受编译语句的压力。
- 当多个节点异常后恢复时，Proxy需要在所有恢复的数据库节点上重新执行预编译语句，才能保证参数和预编译语句之间的对应关系，此时会导致代理的压力过大。
单节点透传是数据库代理将预编译语句根据路由发往数据库其中一个节点，并维护预编译语句和数据库节点之间的映射关系，当执行参数数据时，根据映射关系将参数发往指定节点执行。
优势：
- Proxy无需拼装解析SQL。
- 不会导致后端数据库资源浪费和整体压力过大。
劣势：
客户端存储的预编译语句单点透传到了某数据库节点，在执行阶段需要将客户端输入的参数路由到对应的节点， Proxy需要处理此关系，功能实现复杂，给GaussDB(for MySQL)团队编码带来更大挑战。
4.性能对比
我们对Proxy场景下GaussDB(for MySQL)在文本模式和透传模式下的Prepare协议做了性能测试对比。测试显示透传模式下的性能优于文本模式，性能提升约28%。
执行测试的软硬件规格说明如下表所示：
由于现下条件所限，虽然我们没有测试广播透传模式与单点透传模式间的性能对比，但是从前文的方案对比中不难预见，单点透传模式具有更高的稳固性，因为其更不容易在Proxy侧和数据库节点侧产生资源消耗，带来瓶颈。
5.总结
GaussDB(for MySQL) Proxy下的Prepare协议将原本文本模式的处理方式优化为透传模式，其性能得到很大提升，解决了文本模式中对数据类型强依赖的问题。目前业界多采用广播模式的透传，而GaussDB(for MySQL) Proxy侧则将广播模式优化为单点传输模式，降低了数据库的整体性能损耗。
