Apache ShardingSphere权威指南
上QQ阅读APP看书,第一时间看更新

2.2 基于SQL的负载均衡层

当前,网络负载均衡层已足够成熟,能够基于协议头标识、加权计算和限流设置对请求进行分发和处理。然而,在数据库行业中,依然没有适用于SQL的负载均衡层,不能对SQL进行解析,这意味着无法满足数据库系统对请求分发粒度的要求。为弥补数据库行业负载均衡层存在的缺陷,解决之道是开发出能够理解SQL的智能SQL负载均衡器。

除了常见的负载均衡器功能(如高性能、流量治理、服务发现和高可用性),智能SQL负载均衡器还具有分析SQL和计算查询开销的功能。

在清楚SQL的特征和查询到开销后,智能SQL负载均衡器接下来采取的措施是给计算节点乃至存储节点指定标签。当然,可使用自定义标签,如SELECT && $cost<3、UPDATE && $transaction=true && $cost<10和(SELECT && GROUP) || $cost>300。

智能SQL负载均衡器可将要执行的SQL同预定义的标签相关联,进而将请求分发给正确的计算节点或存储节点。图2.2展示了智能SQL负载均衡器的部署架构。

图2.2 智能SQL负载均衡器的部署架构

在图2.2中,中间部分是使用智能SQL负载均衡器的分布式数据库集群架构,其中复杂的负载均衡层确保高可用性,这是通过存活(keepalived)消息和虚拟互联网协议(virtual internet protocol,VIP)等组织和管理方法实现的。

右侧部分是智能SQL负载均衡器的内核设计。通过模拟目标数据库协议,智能SQL负载均衡器实现了负载均衡层代理,使得访问智能SQL负载均衡器的方式与直接访问目标数据库(MySQL、PostgreSQL等)的方式是一致的。除了上述理解SQL的功能,节点管理部分还包含其他基本功能,如动态配置、心跳监视器、数据库发现和负载均衡器。

左侧部分是一个标签配置示例,包含计算节点和存储节点的用户定义标签。标签存储在智能SQL负载均衡器的注册中心中,因此计算层和存储层只需负责处理请求。另外,这两层无须为负载均衡功能费心,因此预期的SQL请求返回时间相当接近将请求发送给相应计算节点或存储节点所需的时间。这种改进解决了大规模数据库集群中存在的痛点,具体作用如下:

极大地改善了系统的QoS,让整个集群能够更平稳地运行,并最大程度地降低了出现单节点性能消耗器的可能性;

以更细致的方式有效地隔离了事务计算、分析计算和其他操作,从而让集群资源分配更为合理,用户可方便地根据标签描述定制节点的硬件资源。

接下来将介绍如何使用边车模式来集成负载均衡器,以改善性能和可用性。