共计 1083 个字符，预计需要花费 3 分钟才能阅读完成。
各位小伙伴面试的时候，常常会碰到面试官问一些高并发相干的业务场景，这篇文章帮忙进入开发行业不久的程序猿理解如何简略实现抢购相干的业务流程，帮忙大家梳理下思路。
上面以 CRMEB 开源商城为例，理解下秒杀流动的创立流程。
首先通过数据验证后，接下来开启事务来保证数据的一致性，而后创立秒杀商品，之后将库存写入 Redis 缓存中，这块前面优化思路外面会提到。
用户下单时同样先开启事务，进行原子性操作，通过库存检测等验证后，创立胜利后预扣除库存、积分抵扣等操作。
后续会进行创立后置事件，例如订单记录、音讯推送、订单超时主动勾销、计算订单佣金、领取揭示等性能都能够放在后置事件中。
上面从几个方面简略说下优化思路：
1. 数据库作为最终数据存储的中央，数据的准确性是放在第一位的，为了避免商品呈现超卖的状况，个别会通过锁来解决，乐观锁 / 乐观锁，配合事务来一起应用，数据量大的状况下能够思考读写拆散，上云数据库。
2. 为了缓解网络 IO 和服务器压力，还能够将商品、库存等信息放在缓存中搭配应用，这样既能进步用户拜访体验，还能加重数据库拜访压力，后续扣库存能够搭配音讯队列来进行解决。
3. 能够部署多台服务器独特承当压力，无效升高服务器故障几率，保障秒杀业务统的高可用。
4. 能够通过 CDN 过滤大量的动态文件申请，服务端提前将数据放入缓存进行预热，加大服务器的吞吐量。
5. 作为电商我的项目，其中秒杀模块一种常见的促销形式，罕用于刺激用户生产，往往商品一上架就被抢购一空。这类流动的特点就是用时比拟短，刹时并发量高，相似的还有 12306 抢票，淘宝双十一等。
6. 服务器的解决资源是无限的，为了避免出现超载导致服务器宕机，访问量过高导致服务器被压垮，这种状况下除了部署多台服务器以外还能够进行限流操作，避免歹意攻打和刷单，这块罕用的有令牌桶算法和漏桶算法，相对来说令牌桶算法会尽可能的压迫服务器性能，倡议优先应用令牌桶算法进行限流。
7. 为了应答短时间大量的读写顶峰，能够思考退出音讯队列来进行削峰、解耦，业务线能够进行拆分，积分、库存、优惠券等操作能够放入不同的音讯队列中进行异步生产，升高申请耗时，来进步服务吞吐量。
有不懂不明确之处能够在下方留言
源码附件曾经打包好上传到百度云了，大家自行下载即可～
链接: https://pan.baidu.com/s/14G-b…
提取码: yu27
百度云链接不稳固，随时可能会生效，大家放松保留哈。
如果百度云链接生效了的话，请留言通知我，我看到后会及时更新～
GIT 我的项目举荐：蕴含多端免受权可商用
附件地址：http://github.crmeb.net/u/defu