为什么要改写？上面这个面向逻辑库与逻辑表的SQL，并不能够直接在真实的数据库中执行，SQL改写的作用就是把逻辑SQL改写为可以在真实库中正确执行的真实SQL。真实库和真实表我们之前已经知道了，所以直接把SQL改写为这样。并不是所有SQL的改写都这么简单，比如聚合函数怎么改写，包含LIMIT的SQL怎么改写，什么时候需要补列，这些都是改写引擎需要处理的事情。

下面介绍两个早期开发时遇到的问题，实现起来不难，但是原理值得研究一下。这是我在自己电脑上测试的一个场景，使用5个JDBC客户端连接Proxy，每个客户端查询出15万条数据。可以看到，Proxy的内存在一直增长，即使GC也回收不掉。这是因为在收到全部15万条数据之前，JDBC ResultSet的get()方法是阻塞的。简单说，就是JDBC在没收到全量结果之前，是不让用户读数据的，这是ResultSet的默认提取数据方式。会导致Proxy缓存大量临时数据。那么，有没有一种办法，能让ResultSet一收到结果就立即给用户消费呢？

从Connector/J文档上可以找到两种解决方法：

一种是流式结果集：只要把Statement的FetchSize设置成这个值，JDBC就会使用流式ResultSet处理返回结果，让用户能够一边接收数据一边消费数据，而不需要全部接收完再消费。

另一种方式是基于游标的流式结果集：设置JDBC参数useCursorFetch=true，表示要使用游标。设置FetchSize，指示每次返回数据的行数。

这种方式效率很低，要谨慎使用。通过抓包可以发现，客户端每次读取数据都会向服务端发送Request Fetch Data这个请求，在网络上的时间开销是非常大的。

Proxy采用的是第一种方案，可以看到内存已经恢复正常了。流式结果集是流式归并的前提条件，流式归并还要满足SQL条件和连接数条件，比较复杂，这里就不详细介绍了。这个内存使用效果是在最理想的情况下产生的，也就是客户端从Proxy消费数据的速度，大于等于Proxy从MySQL消费数据的速度。

如果客户端由于某种原因消费变慢了，或者干脆不消费了，会发生什么呢？通过测试发现，内存使用量直线飙升，比刚才那张图还夸张。我们来研究下为什么会产生这种现象。这里加上了几个主要的缓存，SO_RCVBUF和SO_SNDBUF，他们是TCP的缓存。

ChannelOutboundBuffer是Netty写缓存。在结果数据回传的过程中，如果Client阻塞，那么他的SO_RCVBUF会瞬间被数据填满，触发TCP的滑动窗口去通知Proxy不要再发送数据了。与此同时，数据就会积压到Proxy端，所以Proxy端的SO_SNDBUF也同时被填满了。Proxy的SO_SNDBUF满了之后，Netty的ChannelOutboundBuffer就会像一个无底洞一样，吞掉所有MySQL发来的数据，因为在默认情况下ChannelOutboundBuffer是无界的。由于Netty在消费，所以Proxy的SO_RCVBUF一直是空的，导致MySQL可以一直把数据发送过来，而Netty则不停的把数据存到ChannelOutboundBuffer，直到内存耗尽。

找到根本原因之后，我们需要做的就是当Client阻塞的时候，不让Proxy再接收MySQL的数据。Netty通过水位参数来控制写缓冲区，当buffer大小超过高水位线，我们就控制Netty不再往里面写，当buffer大小低于低水位线的时候，才允许写入。设置完水位线后，当ChannelOutboundBuffer满时，Proxy的SO_RCVBUF自然也满了，触发TCP滑动窗口通知MySQL停止发送数据。在这种情况下，Proxy所消耗的内存只是ChannelOutboundBuffer高水位线的大小。我们的目的就达到了。

这个非常炫酷的界面来自Skywalking。他监控到了Sharding-Proxy中，执行一条SQL的完整调用链，而且对Proxy的代码没有任何侵入。他是怎么做到的呢？说道对代码没有侵入，大家首先想到的可能就是钩子。没错Skywalking就是使用的Instrument Agent实现的自动探针。目前已经支持的探针达几十种，涵盖了很多主流应用。如果把SkyWalking部署在一个真正的业务系统上，你看到的调用链会更加丰富。核心原理部分就介绍到这里。

我在这里总结了一下常见的性能问题，有想提交代码的同学可以重点留意一下，避免出现相同的问题。

第一类是代码类问题。第一个例子：

大家看一下这个函数，有什么问题吗？入参如果是LinkedList，可能会产生什么后果？LinkedList是链表，如果用下标get，时间复杂度是O(n)。循环n次，整个时间复杂度是O(n方）。换成for each遍历遍历就可以了。

这个之前有社区的同学测试过，50000个元素，执行时间相差1000多倍。

第二个例子：

如果把Properties当做整个系统的全局变量来使用，系统中大量并发调用getProperty()。Properties是Hashtable的子类，Hashtable的读写都是同步的。所以并发读会被串行处理。使用其他数据保存全局变量，比如ConcurrentHashMap。

第二类是额外非预期SQL。第一个例子：

最近有一个PR，在每次执行SQL的时候调用了JDBC 的这个接口提取用户名。JDBC会利用select user()这个SQL，到数据库去查询用户名。导致在不知情的情况下，你认为执行了一个SQL，实际上执行了两个。优化方式就是把UserName缓存。性能可以提升32%。

第二个例子：

另外一个非预期SQL问题与我们之前使用的流式ResultSet有关。

这是我从JDBC 5.1.0的Release Notes上截的图。每创建一个流式ResultSet，JDBC都会设置一次网络超时时间。导致网络上有大量的 SET net_write_timeout 请求。

解决方式是手动把这个参数的值设为0。经过测试，性能提升33%。可见额外SQL对性能影响非常大，大家一定要注意。

第三类涉及到比较底层的IO和系统调用。

Netty中发送数据分为两步：write()和flush()。Write()把数据写入netty的缓存中，flush()把数据发送出去。之前的实现是，每次从MySQL收到一条结果数据，就立刻flush一次把它发送到客户端。这样的用法效率很低。诺曼在《Netty In Action》里提到要尽量减少flush()的调用次数，因为系统调用的代价非常高。

其实不止系统调用代价高，网络利用率也很低。我们可以算一下，TCP每次发送数据，各种包头加起来要54字节（MAC头：14字节 + IP头：20字节 + TCP头：20字节），可能比你真正传输的数据都多。频繁的flush，单位时间内传输的有效数据肯定会变小。优化方式是多条结果调用一次flush()，性能提升达到50%。

最后一类是全路由问题。(这张图是京东数科内部的链路监控工具SGM，是对接京东白条现场的截图)

本来预期路由到单个节点的SQL，被路由到了n个节点。一般是由解析问题引起的。导致响应时间指数级增长。定位这类问题可以使用Java性能监控工具定位，例如JMC、JProfiler。或者APM工具SkyWalking、SGM等等。利用他们跟踪路由相关的函数，检查调用次数是否正确。

为了能够即时发现性能问题，我们会对每个合并的PR进行性能测试，把问题定位在最小的范围内。

比如这次构建，性能明显下降，通过构建序号就能找到Github的提交记录。

与性能测试不同，压力测试侧重于真实业务，每天进行长时间的压测，保证当天代码的稳定性。

目前每天压测10小时左右，像内存泄漏这种问题就能够测出来。这个压测的页面以后会放到官网上。大家提完PR后，第二天就可以看到效果。

Sharding-Proxy在经历了一年多的磨练后已经走向成熟，开始逐渐被部署到生产环境使用。欢迎感兴趣的小伙伴试用，使用过程中有什么问题可以加微信群讨论。如果大家有什么想法、意见和建议，也欢迎留言与我们交流，更欢迎加入到ShardingSphere的开源项目中。