鲁达 原创作者：张永伦
在经过一系列紧锣密鼓的筹备后，Sharding-Sphere 3.0.0.M2 终于在2018.8.8正式跟大家见面了。发版之前我们解决了几个棘手的问题，今天拓海与大家分享其中一个：MySQL协议相关的一个bug。在bug的定位过程中，小伙伴们会了解到一些MySQL协议的基本知识和调试方法。
Bug描述
关于bug的描述，这里使用了项目的issue模板，大家在提bug的时候也请一定遵循这个模板。在本文中使用中文描述，但大家提issue的时候记得用英文，毕竟老外也会来看的。
Which version of Sharding-Sphere do you using?
3.0.0.M2-SNAPSHOT
Which project do you using? Sharding-JDBC or Sharding-Proxy?
Sharding-Proxy
Expected behavior
持续正常的INSERT数据。
Actual behavior
循环插入200万数据，当插入到100万左右的时候，客户端无响应。
Reason analyze
客户端无响应可能是Proxy阻塞引起的，也可能是Proxy导致客户端阻塞引起的。
Steps to reproduce the behavior
持续插入数据到100万条以上即可复现。
Bug初步定位
经过初步分析，Proxy日志正常，MySQL里也能查到用户插入的最后一条数据。那么，问题应该就出在最后一条数据插入成功之后。可能有两种情况：1. 插入数据成功后，MySQL返回的消息被Proxy错误解码，导致Proxy异常；2. Proxy返回给客户端的消息编码错误，导致客户端异常。
第一种情况，如果Proxy解码错误，Netty会抛异常，TCP连接断开，Proxy会把异常打印到日志，所以这种情况可能性不大。第二种情况可能性较大，需要分析Proxy和客户端之间的消息交互，进一步定位。
MySQL协议
准确的说应该是MySQL Client/Server协议，另一个叫X Protocol的暂不涉及。任何MySQL客户端（CLI、GUI、MySQL驱动）与MySQL服务器通信，都需要使用这个协议。这个协议包含一系列的命令消息（COM）和响应消息（Response）、编解码方式和交互流程。
上图展示了绝大多数协议消息的交互过程：对于DQL，服务器会返回FIELD_COUNT（列数）、FIELD（列的描述信息，如类型等）、ROW（每一行数据的值）、EOF（结束标志）；而对于DML，只需要返回OK或者ERR，通知客户端命令执行成功或失败。
经过之前的分析，我们可以把范围缩小到OK_Packet这条响应消息上，这条消息由服务器发送给客户端，表示一条命令的成功执行。也就是说，在插入数据成功后，MySQL服务器会发送OK_Packet给Proxy，后者又会把这条消息发送给客户端。消息格式如下：
这个表格看起来有点抽象，我们可以先用Wireshark抓个真实包看看，解析出来会直观一些：
做协议开发永远离不开Wireshark，后面拓海会手把手教你使用Wireshark进行网络抓包。真实的数据看起来就简单明了一些了，有包长度、包序号、影响行数、最后插入id、服务器状态等信息。我们找一个字段，来说明其编解码方式。例如last_insert_id，它的类型是int<lenenc>，值为1083。
MySQL协议里存储数据的方式是小端字节序，这是什么意思呢？比如一个值0x1234，采用大端字节序的存储方式就是0x1234，而小端方式则是0x3412。MySQL采用这样的字节序很不友好，对于一个通信协议，应该使用网络字节序传输数据，而不是机器字节序。
回到协议，int<lenenc>是变长编码的整数类型，不同范围的数值使用不同的长度来编码：
由上可知，1083这个值应该是0xfc 加上2个字节来表示：
1083 = 0x043b，小端字节序就是0x3b04。有了这些基础，我们就可以通过抓包来分析产生bug的根本原因了。
Bug最终定位
以下就是当时抓到的包，看起来非常的“正常”，插入一条数据，返回一条成功的响应，Wireshark也没有解析出错。看现象就是客户端停止了插入数据。
经过多次试验，最后一条INSERT总是卡在t_order_item这个表上，它与t_order表有什么本质区别呢？了解Sharding-Sphere-Example的同学对这两个表应该很熟悉，t_order使用的是雪花算法生成的分布式主键，值很大，而t_order_item使用的是MySQL自增主键。为什么主键值小的表会卡住？
又经过一系列调查，发现t_order_item表也不是每次都卡住，这个表有两个分片，在其中一个分片上永远没问题，而另一个分片上只要插入数据就会卡。这两个表又有什么区别呢？其实，由于分片的不均匀，一个表的数据量多，另一个数据量少，除此之外没什么不同。数据量多的表大概6万多条数据。
在拓海百思不得其解的时候，亮神和赵帅看出了些端倪：
最后一条OK_Packet的Last INSERT ID值太大了，一个表不可能有这么多数据。通过观察发现，表的数据量已经大于65535，应该使用3个字节存储
然而程序里却使用了四个字节。四个字节的编码在协议里是不存在的，这必然导致客户端jdbc解析出错。至于为什么wireshark没有解析出错，那一定是因为它的解析逻辑错了。
使用Wireshark分析MySQL协议
Wireshark可以理解为是一个带图形界面的tcpdump，同时集成了非常多的协议解析插件，可以帮助我们方便的抓取和分析MySQL协议。需要注意的是，Wireshark只能抓网络协议包，但MySQL协议还有其他通信方式，如Shared memory，Named pipes，这些是抓不到的，最好不要开这些参数。
Linux命令行环境下：可以先用tcpdump抓包，然后将包发送到本地，使用Wireshark解析。命令如下：
tcpdump -i any port 3307 -w
any: 表示所有网络接口。
port: tcp端口，Proxy的默认端口是3307，如果你关心MySQL的包，就改为3306。
pcap: 一种通用的数据流格式，Wireshark可以直接打开。
用Wireshark打开，你会发现除了MySQL协议，还显示很多TCP协议的ACK消息：
在过滤器中输入mysql，进行过滤即可：
Windows环境下：直接使用Wireshark抓包，一边抓包一边解析。本地的测试环境往往会同时运行客户端、Proxy和MySQL服务器，它们的通信在同一台机器上是不走网卡的，然而windows系统又没有提供本地回环网络的接口，所以这种情况下是什么也抓不到的。
为了解决这个问题，我们需要把Wireshark在Windows系统上默认的抓包工具WinPcap替换为Npcap，在这里下载：。
安装前先在Wireshark的安装目录下卸载WinPcap。安装时勾选如下选项：
安装完成再次启动Wireshark时，就会看到在网络接口列表中，多了一项Npcap Loopback adapter，这个就是来抓本地回环包的网络接口了：
小结
Sharding-Sphere自2016开源以来，不断精进、不断发展。越来越多的企业和个人认可、加入到Sharding-Sphere的开源项目中，为它的成长和发展贡献了巨大力量。
我们从未停息过脚步，聆听伙伴的需求和建议，不断开发新的强大功能，不断使其健壮可靠！
开源不易, 我们却愿向着最终的目标，步履不停！