Java 高并发秒杀 API 性能瓶颈分析

业务场景

红色标块 表示可能出现的并发较高的地方，详情页可能会不断刷新，或许系统时间，因为Java `new`一个对象返回并不耗计算时间，这个操作可以1秒完成几亿次，地址暴露接口和执行秒杀接口是性能瓶颈。

秒杀列表页

秒杀详情页

用户会一直刷新秒杀详情页直到有秒杀的按钮为止

针对这种用户行为，设计详情页的静态资源部署在`CDN`上，这样用户就近拿资源，而商品的详情信息则使用Redis内存缓存技术实现从内存中读取，从而减少网络IO时间

这里使用了高性能的序列化方案，protostuff,快速压缩和压缩成尽可能小的字节数组
具体的性能对比可以查看[GitHub](https://github.com/eishay/jvm-serializers/wiki)
这里没有做数据更新修改Redis,只是基于超时的缓存修改

对于秒杀操作分析

一般公司解决方案

本案例中秒杀操作事务分析

针对以上提出简单的优化

将行级锁操作放到插入购买明细后，使得行级锁等待提交事务的时间变少，调换位置并不影响业务流程

以上方案虽然减少了行级锁等待事务完成的时间，但是还是有 Java 服务端到 Mysql 服务端通信的延迟，而且 Java 自身会有 GC 时间，每次 GC 大概是 50ms

以上时间算起来也会在高并发的情况下造成性能瓶颈，那么解决方案是把秒杀操作的执行逻辑放到 Mysql 端，Java 服务端调用存储过程来避免 GC 和延时等待时间

最终大致的优化思路就是这样，以下给出高并发的服务部署方案