1355667359866028
1355667359866028_个人页
1355667359866028
文章
0
问答
1
视频
0
个人介绍
暂无个人介绍
擅长的技术
获得更多能力
通用技术能力：
-
Java
高级
能力说明：
精通JVM运行机制，包括类生命、内存模型、垃圾回收及JVM常见参数；能够熟练使用Runnable接口创建线程和使用ExecutorService并发执行任务、识别潜在的死锁线程问题；能够使用Synchronized关键字和atomic包控制线程的执行顺序，使用并行Fork/Join框架；能过开发使用原始版本函数式接口的代码。
云产品技术能力：
暂时未有相关云产品技术能力~
阿里云技能认证
详细说明
暂无更多信息
暂无更多信息
暂无更多信息
-
回答了问题
2019-07-17
关于高并发下单
使用缓存+中间件的目的主要是为了提升下单接口的吞吐能力，至于怎么解决的我们分析下流程，有什么问题在交流不对的地方指正一下。商品详情页-购买-订单确认页（此时还没有生产订单只是商品数据可来自缓存）-提交订单（执行2-7逻辑）-支付页缓存中预热的（提前从数据库中把数据放入缓存）是要参加秒杀商品信息（包括库存数量)，并对商品设置过期时间，这个时间应该是秒杀商品的结束时间,这么做主要是缓解数据库压力提升响应速度。并发秒杀（提交订单）时候先从缓存中查询是否有此商品，没有说明秒杀结束了，有的话去预扣商品的库存数量。如果预扣成功说明库存充足可以下单，响应给前端一个状态，并去发消息到消息中间件，订单服务去消费此消息然后开始真正的数据库库存扣减，扣减成功开始生成订单并入库。异步解耦订单生成逻辑提升下单接口吞吐量。前端订单确认页面可以去轮询查询订单生成结果，一般有三种结果：生成订单失败既秒杀失败或者还未消费到消息（排队中）如果成功则去支付页面。这里的异步生成订单不存在分布式事务问题，因为预扣库存仅仅是去缓存中扣减库存数量，如果此时失败并不会发送消息，如果成功那么消息也应该被消费。由于采用是轮询结果的方式所以即便订单生成失败用户重新下单即可并不是必须要保证最终一致的场景。订单成功后是从数据库获取的订单信息缓存中并没有。赞0 踩0 评论0
滑动查看更多
暂无更多信息