postgres -- 一个问题引发的事务探究（一）

最近刚把婚假休完，博客一直没有更新，，刚休假回来就碰到了个线上问题，郁闷之极，不能怪别人了，只能怪自己代码写的不够好，经不起测试啊。。。。。

背景是这样的，微信支付接口调用时会出现connection time out，但是支付宝访问是正常的，因此差不多排除了代码的问题，而且之前已经上线过微信支付，所以基本确定是微信那边的问题造成的，但是无奈人家牛逼啊，这种问题反映过去，想都没想，肯定石沉大海，因此只能留待观察。

但是基于connection  time out基础上，代码出现了问题，本该读出一条数据的代码段读取出2条数据，扯淡了~~~~~~~~~~~~~~~~~~~~~~~~

问题排查不难，

1.很快发现，系统内 redis 锁的失效时间 是设置的 3s，但是 微信的time out时间是5s，而且这块代码本来是想加锁避免并发情况下造成的数据读取错误，但是此处明显没有锁成功。

2.另外这个代码内存在这样的操作， delete(pk,userId = 3)  insert(pk,userId = 3),就是先删除 userId是3的所有数据，再增加 userId是3的数据，这段是老代码，就凑合着用了，但是在新业务里面 我又加了一个 read (userId = 3) 的操作，insert操作理论上只能增加1条，因此read操作理论上也只是读取一条，但是异常情况下read出2条，导致代码出错。

来分析分析为什么：

其实理解起来不难，因为同时存在了事务A和事务B，对同一个表的同一组数据的同一个删除操作，不知道说起来拗不拗口，就是这么个情况。

假设现在存在一条数据pk =1，userId =3

事务A delete(pk,userId=3), insert(pk=2,userId=3),read(userId=3)  

事务B delete(pk,userId=3),insert(pk=3,userId=3),read(userId=3)

1. 首先数据库内有条数据，PD017

2. 执行事务A的delete和insert操作，注意没有Commit，可以看见delete成功了一条数据，可以知道肯定是PD017，随后成功新增了一条数据PD018，但是因为此时没有Commit，数据库内的数据仍然是PD017.

3.此时执行事务B的delete和insert操作，可以发现语句其实被阻塞了，没有执行。这是因为事务A没有提交，事务B的delete操作就阻塞在其中，

因为这其中存在了事务A和事务B都同时在操作同一条或者几条数据，因此被阻塞了，但是如果事务B中没有事务A的堆同一条数据的操作，它是可以执行的，不被阻塞。

4.当事务Acommit掉之后，发现PD017的数据被删除了，增加了PD018的数据

5.此时发现事务B的delete操作其实是无效的，但是insert是有效的，这是因为数据库事务的特性造成的，待会儿再分析

6.数据变成2条了。代码导致问题的地方就在这边。

代码修改策略比较简单，其实不难，只要控制住并发就行，至于这边的数据，反正业务只能这么实现，暂时不关注了。

那么问题出现了，自己对数据库事务了解有多少？好像是迷迷糊糊的感觉，不靠谱，去看看，研究研究吧，事务这边还是挺重要的。

下一篇继续，这一篇记录问题~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~