InceptionSQL里实现的技术需求（再续）

InceptionSQL里实现的技术需求（再续）

在RDS或者云数据库体系中proxy的作用不可小视，它充当了用户和后台数据库之间的桥梁，是数据库运维体系中的重要一环，特别是在类似MySQL这样的开源数据库维护中，由于没有license的费用，我们在实际工作中会充分采用数据库拆分的思想把单个数据库实例的绝对数据量变小，从而演变成维护大量的数据库实例的庞大集群。

在数据库运维中proxy的作用大致上有以下几点：

1. 连接管理

proxy是用户访问数据库的入口，接受用户的连接，然后把查询信息直接转发或者处理之后转发到后面的数据库层。在这个过程中，连接协议最好完全兼容MySQL，并能支持所有的MySQL语法，同时可以管理连接池，以及管理后台数据库的长连接。

2. 安全管理

正如第一条所示，proxy可以管理连接。判断连接的合法性在数据库里至关重要，这就要求proxy支持安全管理，另外，在proxy中配置白名单和黑名单都是必须要支持的特性，以方便灵活运维，降低风险。

3. SQL转发

proxy接到的SQL最终是要交给后台数据库执行的，SQL转发是必须的功能。由于proxy背后的数据库集群通常情况下是大规模的分库分表的，proxy拿到SQL之后一般情况下需要判断路由，根据可以配置的路由算法或者哈希算法，判断要把SQL转发到哪个节点。

4. 读写分离

由于proxy承载了SQL转发的功能，因此它就很容易做到把读写的SQL分开，精准地做读写分离。在这样的需求下，往往是通过SQL解析，根据关键词判断SQL语句的类型，例如：select,update,delete,insert 以及for update和alter 等DDL语句。当然这时候也需要根据session或者事务情况判断是否需要把纯读的语句分发到master节点。支持可以配置读写目的也是在运维过程中常见的需求。

5. 负载均衡

在proxy分发SQL的时候，可以根据实际情况确定分发的目的数据库，特别是read的分发目的数据库，以实现负载均衡。在MySQL的大部分的方案中，对写的需求一般都是到主库，很少有支持多写的情况，当然，galera除外。这个以后再讨论。

proxy均衡负载判断的凭据有：

（1）预先的配置，例如我们假设有三台服务器，我们会配4：4：2.其中有个2的比例，还可以分担在线备份，分析查询等其他查询。

（2）后台数据库实际压力的反馈信息，可能通过监控手段获取实时信息，通过监控信息实时判断数据库负载情况，动态决定分发查询的目的，调节数据库压力。

（3）通过临时配置，主动改变目的数据库的地址，例如临时添加配置把来自某个IP地址，或者某种类型的SQL转到响应的地方。

6. 维护切换

有的时候我们需要主动下线或者上线某类数据库，通过proxy的控制，可以很方便的实现。如果再搭配galera cluster的话，可以做到对业务的0影响。注意，这里说的0影响是传统的vip的模式不能实现的，因为在vip的切换过程中，不可避免的会对切换时刻的连接产生影响，从而影响业务。

7. 故障切换

有了常规的维护切换的支持，在故障发生的时候，只要监控以及监控反馈系统做得好（我有空说说我们的分布式监控哨兵），可以很容易的做failover，实现秒级的故障处理。

8. 状态维护

数据库连接是有状态的，这包括连接参数，session信息等等，在需要转发连接的时候，是需要考虑是否需要维护这些状态，以保证状态的一致性。

9. 在线操作

在运维中遇到的各种DDL和DML的手工操作，都可以通过proxy来实现，这里可以继承我们的InceptionSQL，实现审核，执行，备份，回滚一条龙的需求。

以上所列，看似跟Inception没太大关系，其实，这在Inception里都不是梦。

给生活加点料