之前说了几个高并发的优化点,以及通过一个插件完成session的分布式共享。这次主要说说关于秒杀下单需要注意哪些。
首先先说分布式事务是个很复杂的问题,但是解决方案也很多,能不用分布式尽量不用,如果并发量不是那么大的情况下。
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的方式来不断的提交订单来购票。了解了秒杀的原理,下次说说如何针对秒杀大流量进行控制。
>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:已是最新文章