Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

场景20的重现 #22

Open
LiWenGu opened this issue Jul 14, 2020 · 2 comments
Open

场景20的重现 #22

LiWenGu opened this issue Jul 14, 2020 · 2 comments

Comments

@LiWenGu
Copy link

LiWenGu commented Jul 14, 2020

之前线上有过一样的故障异常,后来排查是for循环事务导致的,故障现场精简后如下:

T1 T2
UPDATE test_table SET money = money + 1 WHERE user_id = 5
UPDATE test_table SET money = money + 1 WHERE user_id = 4
UPDATE test_table SET money = money + 1 WHERE user_id = 1
UPDATE test_table SET money = money + 1 WHERE user_id = 2
UPDATE test_table SET money = money + 1 WHERE user_id = 4
UPDATE test_table SET money = money + 1 WHERE user_id = 5

原业务逻辑是这样的:业务端会发送消息,该消息是个 list,里面存放 userId 和 money。消费端在接收的地方加了 @transaction 注解。在高峰情况下,会存在以上的场景,即某两个 userId 存在两个不同的消息中,并一起消费,互相死锁导致的异常。异常日志和 20.md 描述一致。

@Mylog
Copy link

Mylog commented Jan 13, 2021

T1中的第二个语句 UPDATE test_table SET money = money + 1 WHERE user_id = 1
和T2中的第二个预计 UPDATE test_table SET money = money + 1 WHERE user_id = 2
是不影响死锁的产生和判断的,

@LiWenGu
Copy link
Author

LiWenGu commented Jan 14, 2021

T1中的第二个语句 UPDATE test_table SET money = money + 1 WHERE user_id = 1
和T2中的第二个预计 UPDATE test_table SET money = money + 1 WHERE user_id = 2
是不影响死锁的产生和判断的,

是的,这个例子关键在于 T1 的第一条语句和第三条语句与 T2 的第一条语句和第三条语句

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants