postgres -- 一个问题引发的事务探究(一)
2017-09-01 16:38
357 查看
最近刚把婚假休完,博客一直没有更新,,刚休假回来就碰到了个线上问题,郁闷之极,不能怪别人了,只能怪自己代码写的不够好,经不起测试啊。。。。。
背景是这样的,微信支付接口调用时会出现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
![](https://img-blog.csdn.net/20170901162102567?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMzI5MjQzNDM=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
2. 执行事务A的delete和insert操作,注意没有Commit,可以看见delete成功了一条数据,可以知道肯定是PD017,随后成功新增了一条数据PD018,但是因为此时没有Commit,数据库内的数据仍然是PD017.
![](https://img-blog.csdn.net/20170901162239216?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMzI5MjQzNDM=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
3.此时执行事务B的delete和insert操作,可以发现语句其实被阻塞了,没有执行。这是因为事务A没有提交,事务B的delete操作就阻塞在其中,
因为这其中存在了事务A和事务B都同时在操作同一条或者几条数据,因此被阻塞了,但是如果事务B中没有事务A的堆同一条数据的操作,它是可以执行的,不被阻塞。
![](https://img-blog.csdn.net/20170901162346606?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMzI5MjQzNDM=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
4.当事务Acommit掉之后,发现PD017的数据被删除了,增加了PD018的数据
![](https://img-blog.csdn.net/20170901163426117?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMzI5MjQzNDM=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
5.此时发现事务B的delete操作其实是无效的,但是insert是有效的,这是因为数据库事务的特性造成的,待会儿再分析
![](https://img-blog.csdn.net/20170901163449551?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMzI5MjQzNDM=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
6.数据变成2条了。代码导致问题的地方就在这边。
![](https://img-blog.csdn.net/20170901163611792?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMzI5MjQzNDM=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
代码修改策略比较简单,其实不难,只要控制住并发就行,至于这边的数据,反正业务只能这么实现,暂时不关注了。
那么问题出现了,自己对数据库事务了解有多少?好像是迷迷糊糊的感觉,不靠谱,去看看,研究研究吧,事务这边还是挺重要的。
下一篇继续,这一篇记录问题~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
背景是这样的,微信支付接口调用时会出现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条了。代码导致问题的地方就在这边。
代码修改策略比较简单,其实不难,只要控制住并发就行,至于这边的数据,反正业务只能这么实现,暂时不关注了。
那么问题出现了,自己对数据库事务了解有多少?好像是迷迷糊糊的感觉,不靠谱,去看看,研究研究吧,事务这边还是挺重要的。
下一篇继续,这一篇记录问题~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
相关文章推荐
- postgres -- 一个问题引发的事务探究(二)
- c语言由一个小问题引发的关于gets和scanf的探究
- 一个由JIT优化引发的问题
- 由一个简单的String c=a+b的Java问题引发一点想法 推荐
- WinForm:一个登陆窗体引发的问题系列(二):用户名文本框的输入限制
- C++流实现内幕---由boost::lexical_cast引发的一个问题
- 一个var引发的技术问题
- 由一个问题引发的思考
- 由一个#符号引发的一系列问题
- 由一个简单的String c=a+b的Java问题引发一点想法
- 由一个#符号引发的一系列问题[转载]
- 一个回车符引发的问题思考
- 安装SQL Server2K可能引发一个严重问题(2)
- 一个不小心引发的问题,installation failed invalid argument
- 一个鼠标移出事件引发的问题
- 关于一个需求引发的事务操作和锁-记录解决过程和思路
- 关于事务的一个问题
- 一个简单的跨库事务问题
- 一个简单的跨库事务问题
- 一个多线程问题引发的血案-(代码段执行完毕,子进程未执行完毕导致段错误)