在之前的文章《MySQL 分库分表与 TiDB,如何选择?》中,提到了TiDB与MySQL的高度兼容性,以及可以平滑迁移替换MySQL数据库的优势。正是因为这个优势,我们的一个项目踩到了一个坑。
事情的经过是这样的:在项目初期,经过评估和方案确认,我们决定采用TiDB作为数据库。由于TiDB与MySQL的高度兼容性,我们在开发环境中使用MySQL,而在测试环境中使用TiDB。在切换数据库时,我们只需要更换连接地址即可。然而,由于某些原因,在项目临近投产时,我们决定改为使用MySQL高可用集群。在灰度发布阶段,一切看起来都很顺利。然而,当第一轮灰度测试结束后,我们发现某个用户有一笔重复订单!
于是,我们开始分析原因。一开始怀疑是针对用户的分布式锁未生效,因此我们对代码进行了复查和测试,但没有发现问题。经过一番思考后,我将问题分析的方向转向了TiDB和MySQL高可用集群的差异上。TiDB是一款分布式数据库产品,采用了基于NewSQL理论的新一代分布式技术架构,具备数据强一致、水平弹性扩缩容、金融级高可用等优点。而MySQL高可用集群则是一个主从复制的三个节点结构,使用组复制技术将数据从主节点复制到从节点,采用的是异步复制方式。
为了找出问题所在,我将日志中与重复订单相关的关键时间点列出来,发现这笔重复订单与正常订单之间的时间相差不到1秒。结合MySQL集群的特点,我终于明白了问题所在:登记订单时访问的是主库,而查询订单以检查是否重复下单时访问的是从库。由于主从复制受到网络等各因素的影响,可能会导致延迟较久,从而无法查询到订单,导致未检查到重复。
由于异步复制的延迟是不可避免的,解决方案之一可以是检查重复下单时查询主库。不过,为了避免给主库增加查询压力,并结合业务特性,最终的解决方案是:交易结束后不主动释放用户分布式锁,而是让锁超时自动释放。