[原创]Sharding-Sphere之Proxy初探

 

大家好，拓海()今天为大家分享sharding-sphere推出的重磅产品：sharding-proxy！在之前闪亮登场的sharding-sphere 3.0.0.m1中，首次发布了sharding-proxy，这个新产品到底表现如何呢？这次希望通过几个优化实践，让大家管中窥豹，从几个细节的点能够想象出sharding-proxy的全貌。更详细的mysql协议、io模型、netty等议题，以后有机会再和大家专题分享。

sharding-proxy简介

sharding-proxy概览

sharding-proxy是sharding-sphere的第二个产品。它定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前先提供mysql版本，它可以使用任何兼容mysql协议的访问客户端(如：mysql command client, mysql workbench等)操作数据，对dba更加友好。

• 对应用程序完全透明，可直接当做mysql使用。
• 适用于任何兼容mysql协议的客户端。

与其他两个产品（sharding-jdbc、sharding-sidecar）对比：

	sharding-jdbc	sharding-proxy	sharding-sidecar
数据库	任意	mysql	mysql
连接消耗数	高	低	高
异构语言	仅java	任意	任意
性能	损耗低	损耗略高	损耗低
无中心化	是	否	是
静态入口	无	有	无

它们既可以独立使用，也可以相互配合，以不同的架构模型、不同的切入点，实现相同的功能目标，而其核心功能，如数据分片、读写分离、柔性事务等，都是同一套实现代码。举个例子，对于仅使用 java 为开发技术栈的场景，sharding-jdbc 对各种 java 的 orm 框架支持度非常高，开发人员可以非常便利地将数据分片能力引入到现有的系统中，并将其部署至线上环境运行，而 dba 可以通过部署一个 sharding-proxy 实例，对数据进行查询和管理。

sharding-proxy架构

 

整个架构可以分为前端、后端和核心组件三部分来看。前端(frontend)负责与客户端进行网络通信，采用的是基于nio的客户端/服务器框架，在windows和mac操作系统下采用nio 模型，linux系统自动适配为epoll模型。通信的过程中完成对mysql协议的编解码。核心组件（core-module）得到解码的mysql命令后，开始调用sharding-core对sql进行解析、改写、路由、归并等核心功能。后端（backend）与真实数据库的交互暂时借助基于bio的hikari连接池。bio的方式在数据库集群规模很大，或者一主多从的情况下，性能会有所下降。所以未来我们还会提供nio的方式连接真实数据库。

 

这种方式下proxy的吞吐量将得到极大提高，能够有效应对大规模数据库集群。

sharding-proxy功能细节

prepared statement功能实现

我在sharding-sphere的第一个任务就是实现proxy的preparedstatement功能，据说这是一个高大上的功能，能够预编译sql提高查询速度和防止sql注入攻击什么的。一次服务端预编译，多次查询，降低sql编译开销，提升了效率，听起来没毛病。然而在做完之后却发现被坑，sql执行效率不但没有提高，甚至用肉眼都能看出来比原始的statement还要慢。

先抛开proxy不说，我们通过wireshark抓包看看运行preparedstatement的时候mysql协议是如何交互的。

示例代码如下：

 1 for (int i = 0; i < 2; i++) {
 2     string sql = "select * from t_order where user_id=?";
 3     try (
 4         connection connection = datasource.getconnection();
 5         preparedstatement preparedstatement = connection.preparestatement(sql)) {
 6         preparedstatement.setint(1, 10);
 7         resultset resultset = preparedstatement.executequery();
 8         while (resultset.next()) {
 9             ...
10         }
11     }
12 }

代码很容易理解，使用preparedstatement执行两次查询操作，每次都把参数user_id设置为10。分析抓到的包，jdbc和mysql之间的协议消息交互如下：

 

jdbc向mysql进行了两次查询（query），mysql返回给jdbc两次结果（response），第一条消息就不是我们期望的preparedstatement，select里面也没有问号，说明prepare没有生效，至少对mysql服务来说没有生效。对于这个问题，我想大家心里都有数，是因为jdbc的url没有设置参数useserverprepstmts=true，这个参数的作用是让mysql服务进行prepare。没有这个参数就是让jdbc进行prepare，mysql完全感知不到，是没有什么意义的。接下来我们在url中加上这个参数：

jdbc:mysql://127.0.0.1:3306/demo_ds?useserverprepstmts=true

交互过程变成了这样：

 

初看这是一个正确的流程，第1条消息是preparedstatement，select里也带问号了，通知mysql对sql进行预编译。第2条消息mysql告诉jdbc准备成功。第3条消息jdbc把参数设置为10。第4条消息mysql返回查询结果。然而到了第5条，jdbc怎么又发了一遍preparedstatement？预期应该是以后的每条查询都只是通过executestatement传参数的值，这样才能达到一次预编译多次运行的效果。如果每次都“预编译”，那就相当于没有预编译，而且相对于普通查询，还多了两次消息传递的开销：response(prepare ok)和executestatement(parameter = 10)。看来性能的问题就是出在这里了。

像这样使用preparedstatement还不如不用，一定是哪里搞错了，于是拓海开始阅读jdbc源代码，终于发现了另一个需要设置的参数：cacheprepstmts。我们加上这个参数看看会不会发生奇迹：

jdbc:mysql://127.0.0.1:3306/demo_ds?useserverprepstmts=true&cacheprepstmts=true

果然得到了我们预期的消息流程，而且经过测试，速度也比普通查询快了：

 

从第5条消息开始，每次查询只传参数值就可以了，终于达到了一次编译多次运行的效果，mysql的效率得到了提高。而且由于executestatement只传了参数的值，消息长度上比完整的sql短了很多，网络io的效率也得到了提升。原来cacheprepstmts=true这个参数的意思是告诉jdbc缓存需要prepare的sql，比如"select * from t_order where user_id=?"，运行过一次后，下次再运行就跳过preparedstatement，直接用executestatement设置参数值。

明白原理后，就知道该怎么优化proxy了。proxy采用的是hikari数据库连接池，在初始化的时候为其设置上面的两个参数：

1 config.adddatasourceproperty("useserverprepstmts", "true");
2 config.adddatasourceproperty("cacheprepstmts", "true");

这样就保证了proxy和mysql服务之间的性能。那么proxy和client之间的性能如何保证呢？

proxy在收到client的preparedstatement的时候，并不会把这条消息转发给mysql，因为sql里的分片键是问号，proxy不知道该路由到哪个真实数据库。proxy收到这条消息后只是缓存了sql，存储在一个statementid到sql的map里面，等收到executestatement的时候才真正请求数据库。这个逻辑在优化前是没问题的，因为每一次查询都是一个新的preparedstatement流程，executestatement会把参数类型和参数值告诉客户端。

加上两个参数后，消息内容发生了变化，executestatement在发送第二次的时候，消息体里只有参数值而没有参数类型，proxy不知道类型就不能正确的取出值。所以proxy需要做的优化就是在preparedstatement开始的时候缓存参数类型。

 

完成以上优化后，client-proxy和proxy-mysql两侧的消息交互都变成了最后这张图的流程，从第9步开始高效查询。

hikari连接池配置优化

proxy在初始化的时候，会为每一个真实数据库配置一个hikari连接池。根据分片规则，sql被路由到某些真实库，通过hikari连接得到执行结果，最后proxy对结果进行归并返回给客户端。那么，数据库连接池到底该设置多大？对于这个众说纷纭的话题，今天该有一个定论了。你会惊喜的发现，这个问题不是设置“多大”，反而是应该设置“多小”！如果我说执行一个任务，串行比并行更快，是不是有点反直觉？

即使是单核cpu的计算机也能“同时”支持数百个线程。但我们都应该知道这只不过是操作系统用“时间片”玩的一个小花招。事实上，一个cpu核心同一时刻只能执行一个线程，然后操作系统切换上下文，cpu执行另一个线程，如此往复。一个cpu进行计算的基本规律是，顺序执行任务a和任务b永远比通过时间片“同时”执行a和b要快。一旦线程的数量超过了cpu核心的数量，再增加线程数就只会更慢，而不是更快。一个对oracle的测试()验证了这个观点。测试者把连接池的大小从2048逐渐降低到96，tps从16163上升到20702，平响从110ms下降到3ms。

当然，也不是那么简单的让连接数等于cpu数就行了，还要考虑网络io和磁盘io的影响。当发生io时，线程被阻塞，此时操作系统可以将那个空闲的cpu核心用于服务其他线程。所以，由于线程总是在i/o上阻塞，我们可以让线程（连接）数比cpu核心多一些，这样能够在同样的时间内完成更多的工作。到底应该多多少呢？postgresql进行了一个benchmark测试：

 

tps的增长速度从50个连接的时候开始变慢。根据这个结果，postgresql给出了如下公式： connections = ((core_count * 2) + effective_spindle_count)

连接数 = ((核心数 * 2) + 磁盘数)。即使是32核的机器，60多个连接也就够用了。所以，小伙伴们在配置proxy数据源的时候，不要动不动就写上几百个连接，不仅浪费资源，还会拖慢速度。

结果归并优化

目前proxy访问真实数据库使用的是jdbc，很快netty + mysql protocol异步访问方式也会上线，两者会并存，由用户选择用哪种方法访问。

在proxy中使用jdbc的resultset会对内存造成非常大的压力。proxy前端对应m个client，后端又对应n个真实数据库，后端把数据传递给前端client的过程中，数据都需要经过proxy的内存。如果数据在proxy内存中呆的时间长了，那么内存就可能被打满，造成服务不可用的后果。所以，resultset内存效率可以从两个方向优化，一个是减少数据在proxy中的停留时间，另一个是限流。

我们先看看优化前proxy的内存表现。使用5个客户端连接proxy，每个客户端查询出15万条数据。结果如下图，以后简称图1。

 

可以看到，proxy的内存在一直增长，即时gc也回收不掉的。这是因为resultset会阻塞住next()，直到查询回来的所有数据都保存到内存中。这是resultset默认提取数据的方式，大量占用内存。那么，有没有一种方式，让resultset收到一条数据就可以立即消费呢？在connector/j文档()中有这样一句话： if you are working with resultsets that have a large number of rows or large values and cannot allocate heap space in your jvm for the memory required, you can tell the driver to stream the results back one row at a time. 如果你使用resultset遇到查询结果太多，以致堆内存都装不下的情况，你可以指示驱动使用流式结果集，一次返回一条数据。激活这个功能只需在创建statement实例的时候设置一个参数：

stmt.setfetchsize(integer.min_value);

这样就完成了。这样proxy就可以在查询指令后立即通过next()消费数据了，数据也可以在下次gc的时候被清理掉。当然，proxy在对结果做归并的时候，也需要优化成即时归并，而不再是把所有数据都取出来再进行归并，sharding-core提供即时归并的接口，这里就不详细介绍了。下面看看优化后的效果，以下简称图2。

 

数据在内存中停留时间缩短，每次gc都回收掉了数据，内存效率大幅提升。看到这里，好像已经大功告成了，然而水还很深，请大家穿上潜水服继续跟我探索。图2是在最理想的情况产生的，即client从proxy消费数据的速度，大于等于proxy从mysql消费数据的速度。

 

如果client由于某种原因消费变慢了，或者干脆不消费了，会发生什么呢？通过测试发现，内存使用量直线拉升，比图1更强劲，最后将内存耗尽，proxy被ko。下面我们就先搞清楚为什么会发生这种现象，然后介绍对resultset的第2个优化：限流。下图加上了几个主要的缓存，so_rcvbuf/ so_sndbuf是tcp缓存、channeloutboundbuffer是netty写缓存。

 

当client阻塞的时候，它的so_rcvbuf会被瞬间打满，然后通过滑动窗口机制通知proxy不要再发送数据了，同时proxy的so_sndbuf也会瞬间被netty打满。proxy的so_sndbuf满了之后，netty的channeloutboundbuffer就会像一个无底洞一样，吞掉所有mysql发来的数据，因为在默认情况下channeloutboundbuffer是*的。由于有用户(netty)在消费，所以proxy的so_rcvbuf一直有空间，导致mysql会一直发送数据，而netty则不停的把数据存到channeloutboundbuffer，直到内存耗尽。

搞清原理之后就知道，我们的目标就是当client阻塞的时候，proxy不再接收mysql的数据。netty通过水位参数write_buffer_water_mark来控制写缓冲区，当buffer大小超过高水位线，我们就控制netty不让再往里面写，当buffer大小低于低水位线的时候，才允许写入。当channeloutboundbuffer满时，proxy的so_rcvbuf被打满，通知mysql停止发送数据。所以，在这种情况下，proxy所消耗的内存只是channeloutboundbuffer高水位线的大小。

proxy的两种模式

在即将发布的sharding-sphere 3.0.0.m2版本中，proxy会加入两种代理模式的配置：

memory_strictly: proxy会保持一个数据库中所有被路由到的表的连接，这种方式的好处是利用流式resultset来节省内存。

connection_strictly: 代理在取出resultset中的所有数据后会释放连接，同时，内存的消耗将会增加。

简单可以理解为，如果你想消耗更小的内存，就用memory_strictly模式，如果你想消耗更少的连接，就用connection_strictly模式。

memory_strictly的原理其实就是我们上一节介绍的内容，优点已经说过了。它带来的一个副作用是，流式resultset需要保持对数据库的连接，必须与所有路由到的真实表成功建立连接后，才能够进行即时归并，进而返回结果给客户端。假设数据库设置max_user_connections=80，而该库被路由到的表是100个，那么无论如何也不可能同时建立100个连接，也就无法归并返回结果。

connection_strictly就是为了解决以上问题而存在的。不使用流式resultset，内存消耗增加。但该模式不需要保持与数据库的连接，每次取出resultset内的全量数据后即可释放连接。还是刚才的例子max_user_connections=80，而该库被路由到的表是100个。proxy会先建立80个连接查询数据，另外20个连接请求被缓存在连接池队列中，随着前面查询的完成，这20个请求会陆续成功连接数据库。

如果你对这个配置还感到迷惑，那么记住一句话，只有当max_user_connections小于该库可能被路由到的最大表数量时，才使用connection_strictly。

小结

sharding-sphere自2016开源以来，不断精进、不断发展，被越来越多的企业和个人认可：在github上收获5000+的star，1900+forks，60+的各大公司企业使用它，为sharding-sphere提供了重要的成功案例。此外，越来越多的企业伙伴和个人也加入到sharding-sphere的开源项目中，为它的成长和发展贡献了巨大力量。

未来，我们将不断优化当前的特性，精益求精；同时，大家关注的柔性事务、数据治理等更多新特性也会陆续登场。sharding-sidecar也将成为云原生的数据库中间件！

愿所有有识之士能加入我们，一同描绘sharding-sidecar的新未来！

愿正在阅读的你也能助我们一臂之力，转载分享文章、加入关注我们！

关于sharding-sphere

sharding-sphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由sharding-jdbc、sharding-proxy和sharding-sidecar这3款相互独立的产品组成。他们均提供标准化的数据分片、读写分离、柔性事务和数据治理功能，可适用于如java同构、异构语言、容器、云原生等各种多样化的应用场景。

亦步亦趋，开源不易，您对我们最大支持，就是在github上留下一个star。

项目地址：

更多信息请浏览官网：