『互联网架构』软件架构-解密电商系统-秒杀下单(78)

之前说了几个高并发的优化点,以及通过一个插件完成session的分布式共享。这次主要说说关于秒杀下单需要注意哪些。

(一)秒杀下单需要注意点

  1. 是否登录session是否存在。
  2. 收货地址是否填写
  3. 商品是否存在
  4. 库存是否够
  5. 有效期判断
  6. 库存的数据修改修改redis,一定要使用redis的原子性操作,不要使用set,使用decr。让并发变成线性化操作,变成队列来进行操作。

(二)分布式事务

首先先说分布式事务是个很复杂的问题,但是解决方案也很多,能不用分布式尽量不用,如果并发量不是那么大的情况下。

1.分布式的由来

例如dubbo服务调用,多个dubbo服务,都不在一个JVM或不在一台机器上,这就是分布式事务。

2.比较稳妥的方式

通过表行锁,或者消息中间件的补偿机制来完成。多个服务读同一个表,多一同统一口径这样完成分布式事务。
消息中间件只有一个JVM消费,这样一个口径消费。

3.二阶段提交

支付宝,淘宝这种公司专门有自己的中间件,开发过程中压根搬砖的程序员压根就不用考虑分布式事务的问题,分布式事务交给了中间价团队,原理就是2阶段提交,分布式事务的中间件作为协调者,比方有2个系统。A系统,B系统,A系统的方法调用了B系统的方法,A系统有个事务TXA,B系统也有自己的事务TXB,A系统方法比较长,它在中间位置需要调用B的方法,B系统方法内容比较短。A方法调用完成B方法完成后在去自己剩余的方法。B结束后是不是把自己的方法提交了,但是B结束事务发给事务的中间件协调者,但是B结束的这部提交没有真正的提交到数据库,它只是提交了一个级别,并没有真正的在数据库那个级别提交(2阶段事务提交),如果没有分布式中间件也就是B结束,B的事务就提交了,但是A的方法还没执行完毕。等待A的方法执行也进行了2阶段的提交,但是A也不是真正提交给数据库。也就是A方法执行完毕,B方法执行完成,然后由分布式事务协调器统一一起提交到数据库。
虽然这2个事务开始是分开的,但是这2个事务到最后汇集到分布式中间件了,分布式中间件把2个事务变成了一个事务。这个其实非常之复杂,我也是只知道原理。

PS:真实的秒杀需要不断的优化,最早的12306没有验证码的时候,很多人都是通过jmeter的方式来不断的提交订单来购票。了解了秒杀的原理,下次说说如何针对秒杀大流量进行控制。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『互联网架构』软件架构-解密电商系统-秒杀下单(78)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注