秒杀系统总结与思考(一) 架构原则

重温许令波老师的秒杀系统课程 课程链接

架构基本原则: “4要1不要”

1、数据尽量少：数据网络传输，序列化，编码，解压等操作消耗CPU，数据越简单、越小则好
简化秒杀页面大小，去掉不必要的页面装修等
2、请求数量尽量少: 减少额外的请求，TCP等都耗时较多
3、路径尽量短: 远程调用都会创建scoket连接，也会增大服务不可用的可能性的叠加
4、依赖尽量少: 用户访问一个页面所依赖的系统，防止关键系统被弱依赖系统拖累
5、不要单点: 服务单点不可用

最初版本的秒杀系统

把你的商品购买页面增加一个“定时上架”功能，仅在秒杀开始时才让用户看到购买按钮，当商品的库存卖完了也就结束了。这就是当时第一个版本的秒杀系统实现方式

架构改造第一版

1、把秒杀系统独立出来单独打造一个系统，这样可以有针对性地做优化，例如这个独立出来的系统就减少了店铺装修的功能，减少了页面的复杂度；
2、在系统部署上也独立做一个机器集群，这样秒杀的大流量就不会影响到正常的商品购买集群的机器负载；
3、将热点数据（如库存数据）单独放到一个缓存系统中（如Redis），以提高“读性能”；
4、增加秒杀答题，防止有秒杀器抢单。
秒杀详情成为了一个独立的新系统，另外核心的一些数据放到了缓存（Cache）中，其他的关联系统也都以独立集群的方式进行部署。

架构改造第二版

1、对页面进行彻底的动静分离，使得用户秒杀时不需要刷新整个页面，而只需要点击抢宝按钮，借此把页面刷新的数据降到最少；
2、在服务端对秒杀商品进行本地缓存，不需要再调用依赖系统的后台服务获取数据，甚至不需要去公共的缓存集群中查询数据，这样不仅可以减少系统调用，而且能够避免压垮公共缓存集群。
3、增加系统限流保护，防止最坏情况发生。
经过这些优化，系统架构变成了下图中的样子。在这里，我们对页面进行了进一步的静态化，秒杀过程中不需要刷新整个页面，而只需要向服务端请求很少的动态数据。而且，最关键的详情和交易系统都增加了本地缓存，来提前缓存秒杀商品的信息，热点数据库也做了独立部署，等等。

总结

4要1不要的基本架构原则
秒杀系统独立（秒杀详情、秒杀交易），定制优化，与正常业务隔离
热点数据独立的缓存的系统。增加校验防止刷单
页面数据动静分离，静态数据localcache （请求尽量少，数据尽量少）
独立缓存，独立库存热点（依赖尽量少）

关于localcache的问题

1、本地cache用什么实现好呢? 内存实现，如map或gauva
2、通过什么方式往本地cache写数据? 用订阅的方式，初始化加载到内存
3、秒杀系统的及时性很高，把库存写进本地cache，如何及时更新?
有两种方法，一是定时更新取3秒，二是，主动更新，数据库字段更新后发消息更新缓存，这个需要用到一个组件阿里叫metaq就是就是数据库字段更新会产生一条消息。另外cache里库存不需要100%和数据库一致，最下单一致性校验即可