MySQL 5.5 Community Server MySQL 5.6 Community Server Percona Configuration Wizard XtraBackup 搭建主从复制 Great Sites on MySQL Percona MySQL Performance Blog Severalnines 推荐管理工具 Sequel Pro phpMyAdmin 推荐书目 MySQL Cookbook
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
这是一个创建于 3045 天前的主题，其中的信息可能已经有所发展或是发生改变。
遇到的问题
假设拿医院系统的药品部分举例, 药品表结构大概如下:
现在有多个地方可能会去操作药品的数量:
- 护士生成请领单 (减存库数量,加冻结数量),可能会涉及到一堆表,那么这些操作都会在一个事务里,在操作存库的时候会把操作的行自动锁定起来,等待事务结束才会释放
- 手工划价药品 (直接减库存数量) 同上,会操作很多表的数据,一样会锁操作的行
- 药房发药 (减冻结数量) 同上,会操作很多表的数据,修改请领单状态等等,一样会锁操作的行
- ......
因为在系统里可能某些药的使用频率是非常高的,比如一些生理盐水、葡萄糖之类的。那么就经常会遇到，护士在生成请领单事务还没完成，药房正在发的药中也含有这些药，这样互相等待直接就被 mysql 的死锁检测机制检测到。
想请问大家遇到这种问题一般会采用什么样的方案来解决？
自己想到的方法以及问题
- 大事务拆各个小事务,比如药房发药,新事务->首先修改请领单状态->提交。新事务->再去减存库->提交。但是这样如果在减存库的地方异常了,不就不会回滚到 请领单状态
- 使用同步,我们首先尝试在生成请领单的方法上加上同步,这样多个护士在同时生成请领单的时候的确是不会遇到问题了,但是生成请领单又可能和发药死锁。如果加到减库存的方法，那似乎没什么用？就算减存库同步执行了，但是上层事务还没跑完 也会遇到这问题吧？
- 使用队列，因为我们现在多项目同时运行,并且都可能去操作存库,所以考虑过使用队列,把所有操作存库都丢到队列去单线程执行。但是改动速度有点大。
不知大家是否还有其他比较好的解决方案
 | 1 henry19890701 2017-06-21 22:20:50 +08:00  1 保证加锁顺序就可以了，代码应该不怎么需要改 |
 | 2 letitbesqzr OP @henry19890701 那其实也就只有让他同步,单线程的去减存库? |
 | 3 Mirana 2017-06-21 22:56:27 +08:00 1 加锁失败回滚 然后重试 |
 | 4 wind3110991 2017-06-21 23:10:05 +08:00 1 感觉这个最主要的问题并不是事务或者是锁，而是你的流程问题： 为什么操作失败就要 回滚到 请领单状态？ 建议如果并发量大容易锁，流程中可以穿插多个原子事务，失败回滚到一个中间状态，而不是后台一个接口大包大揽。 事务不是万能的，要符合你的当前使用场景才行 |
 | 5 billlee 2017-06-21 23:12:37 +08:00 1 @letitbesqzr #2 这个肯定是要同步的。别说是数据库，就算是内存里的变量，多线程操作也要加锁进临界区啊。 |
 | 6 cjyang1128 2017-06-21 23:18:21 +08:00 1 一般死锁问题都是通过保证加锁顺序实现的。除了楼主提的几个方案之外，可以把某些数据存储在 redis 中，因为 redis 是单线程的，所以不存在竞争问题。因为你本质上是 id=>数量的一个映射，所以也可以考虑一下。 |
| 7 letitbesqzr OP @wind3110991 就比如发药 1. 将请领单状态设置为已发药 2. 各种计费改状态 3. 减少存库 4. 写存库流水 5. 记录日志 那么某一步失败肯定需要回滚到第一个状态，实际情况一个事务里还会做更多的操作，业务非常复杂 |
| 8 letitbesqzr OP @wind3110991 意思就是，其实大事务拆成一个个短事务是比较常见的做法？ |
 | 9 3dwelcome 2017-06-21 23:50:29 +08:00 1 如果是我的话，就用单线程队列。拆分事务只能让逻辑变复杂。代码应该多遵循 KISS 原则，能简单处理的问题，别复杂化。 |
 | 10 ebony0319 2017-06-21 23:57:52 +08:00 via Android 1 如果是我我会采取队列方式。谁先就应该给谁，不应该抢资源。 |
| 11 letitbesqzr OP |
 | 12 ryd994 2017-06-22 01:06:51 +08:00 via Android 1 一种药一个事务 A 药开不出和 B 药没有联系，不需要锁一起 |
 | 13 reus 2017-06-22 08:21:30 +08:00 1 手工上锁 + 事务 |
 | 14 msg7086 2017-06-22 10:01:20 +08:00 1 上锁超时跳过，回头来重试呗。 万一某个药没货了，病人别的药也不让吃了么…… |
 | 15 jianzhiyao020 2017-06-22 15:29:57 +08:00 1 如果， 并发量不是特别大的话， 可以选择序列化事务隔离级别， 绝对不会死锁。 但是伴随来说， 速度会相应降低， 但是应该总比死锁好。 |
| 16 letitbesqzr OP @jianzhiyao020  试过，但是预算了一下，病人得排队到马路上。 |
| 17 jianzhiyao020 2017-06-22 15:40:32 +08:00 @letitbesqzr 那就要概念 hack 了， 例如葡萄糖放在一个地方， 大家都去拿，那是否是会增加堵塞的概率， 可以护士那里放一点， 药房那里放一点， 是不是就不会那么堵塞了， 好了， 我说那么多， 其实就是将葡萄糖分开几个记录存取。 |
| 18 wind3110991 2017-06-22 22:13:37 +08:00 @letitbesqzr 如你说的，回滚没有必要从滚到 1 之前啊 比如你在 5 出错了，滚到 4 不就好了，记录下当前状态，在队列等待就好了啊 |
| 19 ebony0319 2017-07-06 23:31:56 +08:00 via Android 最近又查了一些资料，好像都不满意，想问问你这个问题你们目前的思路么。 |
| 20 letitbesqzr OP 1 @ebony0319 1. 减短事务 2. 使用了 mq 队列进行增删存库 目前采用上面两种方案已经能够满足目前的请求量了，下面一个预备的方案 3. 存库的数量都丢到 redis 中 程序只是操作 redis 里面的存库 定期同步到数据库 |
Select Language