1. 设计难点： 并发量大，应用、数据库都承受不了。另外难控制超卖。

　　2. 设计要点：

　　- 将请求尽量拦截在系统上游，html尽量静态化，部署到cdn上面。按钮及时设置为不可用，禁止用户重复提交请求。

　　- 设置页面缓存，针对同一个页面和uid一段时间内返回缓存页面。

　　- 数据用缓存抗，不直接落到数据库。

　　- 读数据的时候不做强一致性教研，写数据的时候再做。

　　- 在每台物理机上也缓存商品信息等等变动不大的相关的数据

　　- 像商品中的标题和描述这些本身不变的会在秒杀开始之前全量推送到秒杀机器上并一直缓存直到秒杀结束。

　　- 像库存这种动态数据会采用被动失效的方式缓存一定时间(一般是数秒)，失效后再去Tair缓存拉取最新的数据。 - 如果允许的话，用异步的模式，等缓存都落库之后再返回结果。

　　- 如果允许的话，增加答题教研等验证措施。

　　3. 其他业务和技术保障措施：

　　- 业务隔离。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热。

　　- 系统隔离。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外 99% 分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中。

　　- 数据隔离。秒杀所调用的数据大部分都是热数据，比如会启用单独 cache 集群或 MySQL数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%。另外需要复习缓存穿透、雪崩等等问题，主要的流量都落在了缓存数据库上，需要针对缓存数据库的高可用作保障。

　　4. 短链接生成 这个应该是比较公认的方案了：

　　1. 分布式ID生成器产生ID

　　2. ID转62进制字符串

　　3. 记录数据库，根据业务要求确定过期时间，可以保留部分永久链接 主要难点在于分布式ID生成。鉴于短链一般没有严格递增的需求，可以使用预先分发一个号段，然后生成的方式。看了下新浪微博的短链接，8位，理论上可以保存超过200万亿对关系，具体怎么存储的还有待研究。

上一篇

说说zookeeper的投票机制

下一篇

怎么保证缓存和数据库数据的一致性？