秒杀,高并发,分布式事务

一、秒杀的系统的逻辑架构

 

    通常来说，秒杀系统是独立于其他业务系统之外的

    

 

 

二、秒杀倒计时如何实现

 

    

 

 

三、高并发下如何保证商品数据的一致性（性能、数据安全）

 

    问题：假设有一个商品库存10000件，同时又100000在抢，最后的结果一定是库存变成0，同时生成10000个订单

    

    

 

 

    

 

 

四、分布式事务的实现

 

    为什么需要分布式事务？

        

 

        如上图的微服务架构开发逻辑，一个业务可能会调用多个服务一起完成，每个服务可能都会操作不同的数据库。只所以需要分布式事务，是因为上图中的“事务A”和“事务B”不可能是一个事务，这样一个业务的原子性、一致性等问题就不能得到保证。

 

    分布式事务的解决方案：

        

        1）2pc两端提交协议：

            

            实现逻辑比较简单，但是效率比较差。所以一般互联网项目很少使用。

 

        2）TCC柔性事务：        

            

 

 

        3）基于MQ的数据最终一致性的分布式事务

 

            核心：主事务方将消息放入MQ，通过发送方消息确认，接收方消息确认、消息持久化、队列持久化、补偿机制、集群高可用... 保证消费方一定能在未来的某一刻消费到这条消息。在消费方消费这条消息之前，有可能出现各种问题，这个时候数据库的数据其实处于一个不一致的状态。所以这种方式追求的是最终一致性，允许系统出现一段时间的软状态。

五 高并发的解决方案

前端:

         1.前端页面提供良好的用户反馈,让用户感知到自己的请求已经发送成功,不要再重新发送

         2.提供js手动,控制用户的多次点击行为(比如禁用按钮,弹框提示等)

后端:

1.后端服务器肯定需要进行分布式集群部署,分散请求压力,进行资源隔离.

2.后端入口程序通常通过Nginx进行请求的负载均衡,在Nginx端可以对请求进行分流,限流,整形,过滤,路由,确保后端服务的稳定

3.引入缓存服务器redis,减少数据库的压力,并且可以提高请求的响应速度.提高系统的吞吐量.

4.有些复杂的业务,也可以通过redis的lua脚本进行处理,事后再同步回数据库(在保证效率的前提下,确保消息的一致性和安全性)

5.服务和服务之间有时候可以通过MQ请求削峰处理,减少下游服务器的压力,拉长请求处理的时间,确保下游服务器的稳定,以时间换稳定.

6.业务的分布式处理,可以通过MQ最终一致性分布式事务的方式,这种方式的好处在于,服务和服务之间性能不会产生阻塞影响效率(MQ的最终一致性分布式事务)

7.数据库对于大的数据库最好进行分库分表,并且读写分离,提高系统的吞吐量(最好大部分的请求在redis就处理了)

8.资源请求最好动静态分离,只让Tomcat处理动态请求,静态请求可以部署在静态资源服务器上,比如CDN服务器,Nginx服务器