高并发实现思路

抢购活动高并发场景*
电商网站做活动卖100个水杯，根据以往活动经验，抢100个水杯的人有10万人，用极低的价格配上短信、App的精准推送让用户尽量多的参数。Redis3、4万QPS(queries per second)还是能顶得住的，再高可能就没办法了。

• 大量的请求进来考虑的点就非常多，缓存雪崩、缓存击穿、缓存穿透这些都可能发生，如果直接访问DB就可能导致用户体验差。
• 超卖 活动数100个，如果超过就麻烦了
• 恶意访问 (防止黄牛)
• 链接暴露（F12查看源码，获取访问地址）
• 数据库 每秒上万甚至十几万QPS直接访问数据库可能404

特点：
时间极短，瞬间用户量大。
解决办法:
服务单一职责：防止秒杀没抗住，服务挂了，也不影响其它的服务。

1. 秒杀单独的服务，就像订订单服务、用户服务一样。使用微服务方式，分布式部署。
2. 创建数据库也就是分库，就像订单服务对应订单库一样，秒杀创建秒杀库
3. 创建相应的索引同进执行expain查看sql的执行计划
   秒杀链接加盐
   避免机器参加，机器可是毫秒级如果参与可能都让机器购买了。就是把URL动态化，就连写代码的人都不知道，你就通过MD5之类的加密算法的随机字符串去做url，然后通过前端代码获取url后台校验才能通过。
   Redis集群
   主从同步、读写分离 采用哨兵，开启持久化
   Nginx
   是一款高性能web服务器，并发随便几万不是问题，平时使用的tomcat只能顶几百的