场景分析
这里以抢红包场景为例，需求如下：
1.红包有个数限制，假设红包的个数限制为X。
2.红包金额上线限制，假设金额上线为Y。
3.要求用户抢红包的时候，不超过红包的个数限制X。
4.要求用户抢红包的时候，不超过红包的金额Y。
5.每个用户一次红包活动只能抢一个。这里提一下最常见的思路：
1.在用户抢红包时，检查当前发出去红包数量和金额，并加锁。
2.检查红包数量和金额正常的后，随机用户红包金额。
3.然后修改红包发出去的数量和金额，并给用户赠送红包，然后解锁。 1.思路简单
2.编不下去了。。。 1.锁数据回造成大量进程等待，造成浪费资源。
2.锁造成的等待，用户体验奇差。
3.对于锁机制不太了解的同学会产生一定的危险性。先分析，为什么常规思路会慢？
1.在抢红包的时候，每次都需要检查红包的上限 X 和 Y。
2.锁会造成大量进程卡顿。
3.生成红包的金额时还需要检查与上限 X 跟 Y 是否有冲突。例如红包个数上限为X，金额上限为Y。
那么，我在活动进行前就把这 X 个红包插入到数据库
并生成序号：HB1、HB2、HB3。。。。HBX
那么实际上，到时候用户就只需要按照先后顺序去领取这个有序的红包队列了。
这个操作减少了到时候线上所产生的很多的计算量。最重要的是，能够简单且有效的保证了整个活动的可控性。
这里利用到了一个ID生成表，通过建立 user_id 的唯一索引，保证每个人只能拿到一个序号。
1.活动创建之前，创建一张ID生成表，ID从 1 开始自增，且 user_id 唯一。
2.活动开始，用户开始抢红包操作。
3.抢红包之前，先插入ID表，获取插入ID，如果ID > X，通知用户已被抢完。
4.如果 ID <= X，那么恭喜了，去红包表领取序号为 ID 的红包，并走异步发红包过程。
5.活动结束之后，把相关用户领取信息存储在红包表，删除ID生成表。 1.不需要代码实现锁机制。
2.逻辑简单。
3.mysql保证每个用户只能拿到一个，且有序。有些朋友提到，可以用 redis 队列存储红包信息，但是实际上 redis 比较占用内存，需要长期存储数据最好还是放在mysql。实际上，这里可以使用 redis 的 incr 命令，得到类似在上面提到的 ID 生成表的功能，更加快速且严格递增，能够使整个项目的并发性更高。
【相关推荐】
2. MySQL最新手册教程
3. 数据库设计那些事
以上就是使如何使项目的并发性更高？利用ID自增保证排队顺序的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告![ThinkPHP5快速开发企业站点[全程实录]](https://img.php.cn/upload/course/000/000/068/6253d918a3ce7278.png)
收藏
收藏
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
825
