Heim >Backend-Entwicklung >PHP-Tutorial >大并发下的mysql事务问题
现有如下场景:用户A和大量A 的粉丝,这时候A的粉丝不断的给A 送道具,这个道具是用户花钱买的,送给用户A之后,会给用户A 的帐号增加相应的钱,同时会给用户A 增加一些附件属性的值,比如用户A 的 经验值,血条长度啊,同时还会给该粉丝增加的经验值,那么这里涉及到的表有用户A 的钱的表,粉丝的钱的表,经验的表,那么我在处理这个时候 给整个过程加了事务处理,但是现在遇到的问题是:一旦有大量的用户同时给A送道具,那么就会出现数据库死锁的问题,请问这个该怎么处理?
现有如下场景:用户A和大量A 的粉丝,这时候A的粉丝不断的给A 送道具,这个道具是用户花钱买的,送给用户A之后,会给用户A 的帐号增加相应的钱,同时会给用户A 增加一些附件属性的值,比如用户A 的 经验值,血条长度啊,同时还会给该粉丝增加的经验值,那么这里涉及到的表有用户A 的钱的表,粉丝的钱的表,经验的表,那么我在处理这个时候 给整个过程加了事务处理,但是现在遇到的问题是:一旦有大量的用户同时给A送道具,那么就会出现数据库死锁的问题,请问这个该怎么处理?
这些行为,都不会要求即时返回结果,可异步化处理,关键词: 消息队列
死锁的问题在于程序或SQL代码有Bug。处理掉Bug,即使遇到再大的并发,最多是处理时间增大,但不会出现死锁。
检查一下sql语句中update .... where [conditon],其中condition是否是主键?如果不是主键,在update时数据库会锁住整张表,多个线程同时操作时极容易出现死锁。
解决办法是,update 后的condition务必使用主键操作,此时数据库仅仅对当前操作记录使用行锁,不会死锁。
异步操作能满足你的需求。
Ps:某些操作是必须要求即刻返回数据的。比如用户消费买东西要先判断钱够不够。其实我是来推荐 PostgreSQL 的
同推荐PostgreSQL
异步队列是很好的解决方案