一、电商秒杀系统的设计与实现
1 秒杀系统的应用特征
1 请求量大，请求高并发； 2 用户瞬间活跃量高，要求系统响应快；
3 秒杀商品少，只有少数用户能够买到。
2 电商秒杀系统的设计设计架构
采用分层架构，各层独立开发，独立部署在各层服务集群，应用层与服务层通过zookeeper进行分布式服务协作。
1 系统前端用ngix 做服务的负载均衡，前端应用层部署电商应用服务器集群，页面静态化生成html页面，并使用CDN内容加速器，提高用户响应速度，减轻前端压力。
2 服务层是定义数据层的db操作接口，起到应用层发现与使用数据层服务接口的功能。
3 后端采用zookeeper + 阿里double框架，数据层定义并实现DB操作接口，发布到zookeeper定义的服务列表中。
数据库采用mysql 集群，主从配置，读写分离的方式。
3 秒杀系统的实现。
秒杀开始时，把商品的库存数加入到redis缓存，用户下单请求到达应用层服务器， 把请求加入到redis缓存，商品库存数减1，并把用户请求加入到消息队列中，当商品库存数是0的时候，系统直接对用户请求返回秒杀结束，进入抢购失败页面。系统写个多线程去消息队列处理请求，生成订单，前端异步提示秒杀成功。
场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，然后影响整个业务；
像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务，前面提到的通用方案就无法支撑，并发的时候都是直接命中DB；
设计这块业务的时候就会使用消息队列的，可以将参与用户的信息添加到消息队列中，然后再写个多线程程序去消耗队列，给队列中的用户发放红包；
方案如：定时领取红包
一般习惯使用redis的 list当用户参与活动，将用户参与信息push到队列中然后写个多线程程序去pop数据，进行发放红包的业务这样可以支持高并发下的用户可以正常的参与活动，并且避免数据库服务器宕机的危险
4 秒杀系统独立部署
由于秒杀系统的高并发请求，对系统资源消耗大，为防止对其他正常系统的影响，秒杀系统可独立部署在秒杀服务器。
