1.设计难点：并发量大，应用，数据库都承受不了。另外难控制超卖。
2.设计要点：
? ? ? 将请求尽量拦截在系统上游html尽量静态化，部署到cdn上面。按钮及时设置为不可用，禁止用户重复提交请求。
? ? ?设置页面缓存，针对同一个页面和uid一段时间内返回缓存页面。
? ? ?数据用缓存抗，不直接落到数据库。
? ? ?读数据的时候不做强一致性校验，写数据的时候再做。
? ? ?在每台物理机上也缓存商品信息等等变动不大的相关的数据。
? ? 像商品中的标题和描述这些本身不变的会在秒杀开始之前全量推送到秒杀机器上并一直缓存直到秒杀结束。
? ? 像库存这种动态数据会采用被动失效的方式缓存一定时间（一般是数秒）。失效后再去缓存拉取最新的数据。如果允许的话，用异步的模式，等缓存都落库之后再返回结果。
? 如果允许的话，增加验证措施。
3.其他业务和技术保障措施：
? ? ? ? ? ?业务隔离。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上说，卖家报名之后对我们来说就是已知热点，当真正开始时我们可以提前做好预热。
? ? ? ? ? ?系统隔离。系统隔离更多的是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀还申请了单独的域名，目的也是请求到不同的集群中。
? ? ? ? ? 数据隔离。秒杀所调用的数据大部分都是热数据，比如，会启用单独Cache集群或者MySQL数据库来放热点数据，目前也是不想0.01%的数据影响另外99.9%。另外需要复习缓存穿透，雪崩等等问题，主要的流量都落在了缓存数据库上，需要针对缓存数据库的高可用作保障。
?4.短连接生成? 这个应该是比较公认的方案了：
? ?1.分布式ID生成器产生ID
? ?2.ID转62进制字符串
? ?3.? ?记录数据库，根据业务要求确定过期时间，可以保留部分永久链接，主要难点在于分布式ID生成。鉴于短连接一般没有严格递增的需求，可以使用预先分发一个号段，然后生成的方式。看了下新浪微博的短连接，8位，理论上可以保存超过200万亿对关系，具体怎么存储还有待研究。
? ?1.缓存穿透。
? ? ?一般的缓存穿透，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB数据库）。一些恶意的请求会故意查询不存在key，请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。
? ?2.怎么解决？对查询结果为空的情况也进行缓存，缓存时设置短一点，或者该key对应的数据insert之后清理缓存。对一定不存在的key进行过滤。可以把所有的可能存在的key放在一个大的bitmap中，查询是通过该bitmap过滤。
3.缓存雪崩。
当缓存服务器重启或者大量缓存集中在某一时间段失效，这样在失效的时候，会给后端系统带来很大的压力，导致系统崩溃。
4.如何解决？
在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如：
对某个key只允许一个线程查询数据和写缓存，其他线程等待；
做二级缓存，不同的key,设置不同的过期时间，让缓存失效的时间尽量均匀。
??
??