ShardingSphere 的目标是一个生态圈，它由非常著名的 ShardingJDBC、ShardingProxy、ShardingSidecar 3 款独立的产品组成。本文重点普及下 ShardingProxy，另外两个就不展开了。
1. 什么是 ShardingProxy ？
ShardingProxy 属于和 MyCat 对标的产品，定位为透明化的数据库代理端，可以理解成：一个实现了 MySQL 协议的 Server（独立进程），可用于读写分离、分库分表、柔性事务等场景。
对于应用程序或者 DBA 来说，可以把 ShardingProxy 当做数据库代理，能用 MySQL 客户端工具（Navicat）或者命令行和它直接交互，而 ShardingProxy 内部则通过 MySQL 原生协议与真实的 MySQL 服务器通信。
图1：ShardingProxy 的应用架构图
从架构图来看，ShardingProxy 就相当于 MySQL，它本身不存储数据，但是对外屏蔽了 Database 的存储细节，你可以用连接 MySQL 的方式去连接 ShardingProxy（除了端口不同），用你熟悉的 ORMapping 框架使用它。
2. ShardingProxy 的内部架构
再来看下 ShardingProxy 的内部架构，后续源码分析时会涉及到此部分。
图2：ShardingProxy 的内部架构图
整个架构分为前端、核心组件和后端：
前端（Frontend）负责与客户端进行网络通信，采用的是 NIO 框架，在通信的过程中完成对MySQL协议的编解码。
核心组件（Core-module）得到解码的 MySQL 命令后，开始调用 Sharding-Core 对 SQL 进行解析、改写、路由、归并等核心功能。
后端（Backend）与真实数据库交互，采用 Hikari 连接池，同样涉及到 MySQL 协议的编解码。
3. ShardingProxy 的预编译 SQL 功能
本文的 Bug 跟 ShardingProxy 的预编译 SQL 有关，这里单独介绍下此功能以及与之相关的 MySQL 协议，这个是本文的关键，请耐心看完。
熟悉数据库开发的同学一定了解：预编译 SQL（PreparedStatement），在数据库收到一条 SQL 到执行完毕，一般分为以下 3 步：
1、词法和语义解析
2、优化 SQL，制定执行计划
3、执行并返回结果
但是很多情况下，一条 SQL 语句可能会反复执行，只是执行时的参数值不同。而预编译功能将这些值用占位符代替，最终达到一次编译、多次运行的效果，省去了解析优化等过程，能大大提高 SQL 的执行效率。
假设我们要执行下面这条 SQL 两次：
SELECT * FROM t_user WHERE user_id = 10;
那 JDBC 和 MySQL 之间的协议消息如下：
通过上述流程可以看到：第 1 条消息是PreparedStatement，查询语句中的参数值用问号代替了，它告诉 MySQL 对这个SQL 进行预编译；第 2 条消息 MySQL 告诉 JDBC 准备成功了；第 3 条消息 JDBC 将参数设置为 1 ；第 4 条消息 MySQL 返回查询结果；第 5 条和第 6 条消息表示第二次执行同样的 SQL，已经无需再次预编译了。
再回到 ShardingProxy，如果需要支持预编译功能，交互流程肯定是需要变的，因为 Proxy 在收到 JDBC 的PreparedStatement 命令时，SQL 里的分片键是问号，它根本不知道该路由到哪个真实数据库。
因此，流程变成了下面这样：
可以看到，Proxy在收到 PreparedStatement 命令后，并不会把这条消息转发给MySQL，只是缓存了这个 SQL，在收到 ExecuteStatement 命令后，才根据分片键和传过来的参数值确定真实的数据库，并与 MySQL 交互。
03 问题分析
上一章节基本把这个 Bug 相关的原理知识介绍清楚了，下面正式进入问题的分析过程。
最开始拿到这个问题，我也是比较头秃的，尤其看到读者下面这段信息。
当然，我的功力是达不到盲猜水平的，说下我的完整思路。
第 1 步 复现问题
我让读者给我打包发了 Demo 的源代码、数据库脚本以及 ShardingProxy 配置，然后本地安装了 ShardingProxy 4.1.1 版本，再通过 Navicat 连接到 ShardingProxy 执行数据库脚本，环境基本就准备完毕了。
启动 Demo 程序后，通过 Postman 发送请求，问题稳定复现了，确实查不出数据。
第 2 步 确认应用程序是否有BUG
因为整个代码很简单，代码层面唯一有可能存在问题的是 Mybatis 这一层。为了确认这一点，我修改了 SpringBoot 的配置，将 MyBatis 的 debug 日志也打印了出来。再次发起请求后，能从控制台中看到以下详细日志：
日志中没发现异常，而且 PreparedStatement 以及 ExecuteStatement 的参数设置都是正确的，查询结果确实是空。
为了缩小排查范围，我把 dataSource 的 配置改回了直连真实数据库，这样能将 ShardingProxy 这个干扰因素排除在外。改完后的 url 如下：
jdbc:mysql://127.0.0.1:3306/db1?useServerPrepStmts=true&cachePrepStmts=true&serverTimezone=UTC
其中，db1 是真实数据库，3306 也是MySQL 服务器的端口了。然后再次用 Postman 发送请求，可以看到：有正确数据返回了。
通过这一步，我将怀疑对象再次转移到 ShardingProxy 上了，并将 dataSource 配置改回成原样，继续排查。
第 3 步 排查 ShardingProxy
首先，查看 ShardingProxy 的运行日志，没发现任何异常；其次，能看到日志中的 Actual SQL 是正确的，它已经根据分区键正确路由到了 pcsct_prdt_cvr0 这张表：
[INFO ] 17:25:48.804 [ShardingSphere-Command-15]
ShardingSphere-SQL - Actual SQL: ds_0 ::: SELECT
BIZ_DT,ECIF_CUST_NO,DEP_FLG ...
FROM pscst_prdt_cvr0
WHERE ECIF_CUST_NO = ? ::: [10000]
因此可以推断：ShardingProxy 的分库分表配置应该是没有问题的。
我开始怀疑：是否跟 ShardingProxy 所使用的数据库驱动有关？因为这个 Jar 包是应用方选择版本，手动放到 ShardingProxy 安装目录中的。因此，我将驱动版本从 5.1.47 版本改成了 8.0.13 （和 Demo 使用了相同的版本），但是问题仍然存在。
另外，还能想到的是：是否是 ShardingProxy 的这个最新版本引入了 Bug？然后，我又另外安装了它的上一个版本 4.1.0，重新测试了一遍，还是有问题。
这个时候，真感觉没有其他可疑点了，所有能想到的点都排查了一遍。我再次回到了 Demo 程序本身，它和 ShardingProxy 唯一的结合点就在 DataSource 的 url 上。
jdbc:mysql://127.0.0.1:3307/sharding_db?useServerPrepStmts=true&cachePrepStmts=true&serverTimezone=UTC
库名和端口号配置无误，唯一可疑的是另外三个参数: useServerPrepStmts、cachePrepStmts 、serverTimezone。其中，前两个参数和预编译 SQL 有关，是一个组合。
因此，我将这两个参数从 url 中去掉，测试了一下。这个时候奇迹出现了，居然返回了正确数据。至此，基本定位到了问题，但根本原因是什么呢？究竟是不是 ShardingProxy 的 Bug ？
第 4 步 Wireshark 抓包分析 MySQL 协议
找到这个问题的解决方案后，我同步给了读者。与此同时，他也在 ShardingProxy 的 GitHub 上提交了 issue，反馈了这个最新进展。
由于工作原因，这个问题我就暂时放一边了，准备抽空再接着排查。
大概过了一周我想起了这个问题，然后打开 issue 想了解下调查进度，让我非常惊讶的是：官方开发者居然在复现此问题后，主观臆断地认为是应用程序的问题，然后莫名奇妙的把这个 issue 关闭了，他们的答复是这样的：
意思就是：我们针对预编译 SQL 功能做了大量的测试，这个是不可能存在问题的，建议你们更换下应用程序的数据库连接池，抓包继续分析下。（这个说法真让人非常无语，完全不是程序员严谨的思维！）
第二天，我开始用 Wireshark 抓包分析 MySQL 的协议，想弄清楚根本原因到底是什么？同时联系上了官方，让他们 reopen 了这个问题。
Wireshark 如何抓取 MySQL 协议的数据包，这里就不展开了，大家可以网上查下资料。注意将 Wireshark 的过滤条件设置成：
mysql || tcp.port==3307
其中：mysql 表示 ShardingProxy 和 MySQL Server 之间的数据包，tcp.port==3307 表示 Demo 程序和 ShardingProxy 之间的数据包。
启动 Wireshark 抓包后，再次用 Postman 发起请求，触发整个过程，然后就能顺利抓到下面截图的数据包了。
大家关注底色为 深蓝色 的 8 个数据包即可。在本文第 2 章节的原理部分，我已经详细介绍过 ShardingProxy 的预编译功能以及该流程的 MySQL 协议消息，这里的 8 个数据包和原理介绍是完成吻合的。
那接下来如何进一步分析呢？结合 ShardingProxy 的架构图来思考下：Proxy 仅仅作为一个中间代理，介于应用程序和 MySQL Server 之间，它完全实现了 MySQL 协议，以便对 MySQL 命令进行解码和编码，然后加上自己的分库分表逻辑。
如果 ShardingProxy 内部存在 Bug，那一定是某个数据包出现了问题。顺着这个思路，很快就能发现：执行完 ExecuteStatement 后，MySQL Server 返回正确数据包给 Proxy 了，但是 Proxy 没有返回正确的数据包给应用程序。
下面截图的是倒数第 2 个 Response 数据包，由 MySQL Server 返回给 Proxy 的，Payload 中能看到那条记录的数据：
下面截图的是最后 1 个 Response 数据包，由 Proxy 返回给应用程序的，Payload 中只能看到表字段的定义，那条记录已经不翼而飞了。
通过这一步分析，就已经坐实了：ShardingProxy 是有 Bug 的。然后，我将这些依据发给了官方开发者，对方开始重视，并正式进入源码分析阶段。
04 根本原因定位
当天晚上，官方开发者就定位到了根本原因，发出了 Pull Request。我看了下代码改动，仅仅修改了一行代码。
最后
为什么我不完全主张自学？
①平台上的大牛基本上都有很多年的工作经验了，你有没有想过之前行业的门槛是什么样的，现在行业门槛是什么样的？以前企业对于程序员能力要求没有这么高，甚至十多年前你只要会写个“Hello World”，你都可以入门这个行业，所以以前要入门是完全可以入门的。
②现在也有一些优秀的年轻大牛，他们或许也是自学成才，但是他们一定是具备优秀的学习能力，优秀的自我管理能力（时间管理，静心坚持等方面）以及善于发现问题并总结问题。
如果说你认为你的目标十分明确，能做到第②点所说的几个点，以目前的市场来看，你才真正的适合去自学。
除此之外，对于绝大部分人来说，报班一定是最好的一种快速成长的方式。但是有个问题，现在市场上的培训机构质量参差不齐，如果你没有找准一个好的培训班，完全是浪费精力，时间以及金钱，这个需要自己去甄别选择。
我个人建议线上比线下的性价比更高，线下培训价格基本上没2W是下不来的，线上教育现在比较成熟了，此次疫情期间，学生基本上都感受过线上的学习模式。相比线下而言，线上的优势以我的了解主要是以下几个方面：
①价格：线上的价格基本上是线下的一半；
②老师：相对而言线上教育的师资力量比线下更强大也更加丰富，资源更好协调；
③时间：学习时间相对而言更自由，不用裸辞学习，适合边学边工作，降低生活压力；
④课程：从课程内容来说，确实要比线下讲的更加深入。
应该学哪些技术才能达到企业的要求？（下图总结）
线下讲的更加深入。
应该学哪些技术才能达到企业的要求？（下图总结）
[外链图片转存中…(img-Q8j91ayf-1628627160929)]
[外链图片转存中…(img-px9ud4ep-1628627160930)]
1576
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
