秒杀系统

目前内容来自敖丙。

场景：商家划出100份小龙虾到秒杀系统，等待5月6号零点开启秒杀。

特点：时间短，瞬时访问量巨大。

原则：

1. 链接不能提前被暴露，避免有心人利用。
2. 底层数据库要保护好避免打死。

做法：

1. 服务单一原则，设计一个单独的高并发高可用的秒杀服务，与主要业务隔离，同时拥有单独的秒杀数据库。
2. 秒杀链接加盐，把URL动态化，直到秒杀开始了才知道能下单的秒杀链接，例如做一个MD5之类加密算法加密随机的字符串去做URL，然后前端代码获取URL后台校验才能通过。个人认为，一次秒杀也是一次活动，秒杀时间一到，就生成一个有效活动token，前端发现本地没有的话就根据活动id去请求获取token，秒杀时候带上它就好了。
3. 请求/返回的数据简单，提高带宽效率和计算力。
4. Redis集群，面向读多写少，主从同步，读写分离，哨兵模式，持久化。
5. Nginx，一台tomcat就几百访问，但是Nginx可以几万，所有利用Nginx负载均衡到各tomcat，租用多些服务器应对秒杀。同时也可以对单个用户过度请求做限制。
6. 资源静态化，像商品和页面模板都比较固定，可以使用CDN或者Redis缓存它们，当然要单独开一个请求库存的接口让前端获取，因为页面上的库存有变化才比较友好。
7. 按钮控制，不到秒杀开启按钮都是置灰，点击一次秒杀就置灰一会，例如穗康小程序抢口罩，增加5秒倒计时。这个不采用用户端的时间，由前端不断获取后端服务器的时间来判断是否开启秒杀。
8. 限流。前端限流如上面说的5秒倒计时，后端限流，流入秒杀商品卖光了，后端直接返回false也是限制了用户请求，当然还有hystrix之类的限流组件。
9. 库存预热，库存提前放置到redis中，前端请求库存也是从redis从库中读取。扣取库存则需要从redis主库进行，这个时候用lua脚本，把读库存和扣库存组成一个事务。
10. 限流、降级、熔断、隔离。
11. 削峰填谷，下单到库的动作走MQ。像能成功扣库存，生成订单，返回前端说商品抢到了，可以去付钱，同时发起一个MQ下单到数据库去，前端付钱时先询问订单是否已经持久化，持久化了就可以调支付网关，支付网关返回给订单接口成功或失败标识，前端不断请求询问是否付款成功，直到支付网关对订单状态设置成功。