将TiDB换成MySQL之后，我踩了一个坑

在之前的文章《MySQL 分库分表与 TiDB，如何选择？》中，提到了TiDB与MySQL的高度兼容性，以及可以平滑迁移替换MySQL数据库的优势。正是因为这个优势，我们的一个项目踩到了一个坑。

事情的经过是这样的：在项目初期，经过评估和方案确认，我们决定采用TiDB作为数据库。由于TiDB与MySQL的高度兼容性，我们在开发环境中使用MySQL，而在测试环境中使用TiDB。在切换数据库时，我们只需要更换连接地址即可。然而，由于某些原因，在项目临近投产时，我们决定改为使用MySQL高可用集群。在灰度发布阶段，一切看起来都很顺利。然而，当第一轮灰度测试结束后，我们发现某个用户有一笔重复订单！

于是，我们开始分析原因。一开始怀疑是针对用户的分布式锁未生效，因此我们对代码进行了复查和测试，但没有发现问题。经过一番思考后，我将问题分析的方向转向了TiDB和MySQL高可用集群的差异上。TiDB是一款分布式数据库产品，采用了基于NewSQL理论的新一代分布式技术架构，具备数据强一致、水平弹性扩缩容、金融级高可用等优点。而MySQL高可用集群则是一个主从复制的三个节点结构，使用组复制技术将数据从主节点复制到从节点，采用的是异步复制方式。

为了找出问题所在，我将日志中与重复订单相关的关键时间点列出来，发现这笔重复订单与正常订单之间的时间相差不到1秒。结合MySQL集群的特点，我终于明白了问题所在：登记订单时访问的是主库，而查询订单以检查是否重复下单时访问的是从库。由于主从复制受到网络等各因素的影响，可能会导致延迟较久，从而无法查询到订单，导致未检查到重复。

由于异步复制的延迟是不可避免的，解决方案之一可以是检查重复下单时查询主库。不过，为了避免给主库增加查询压力，并结合业务特性，最终的解决方案是：交易结束后不主动释放用户分布式锁，而是让锁超时自动释放。