kingSolider的博客

许令波大神的秒杀系统架构设计是经过淘宝实战得出来的经验，值得大家去学习；但是我们不能简单的依葫芦画瓢，要理解他解决问题的方式，做到触类旁通的，这样才能极大的提升自己的能力。好的算法是基于实践的，好的架构是基于场景的，脱离了实际去谈架构就有些扯淡了。经典物理学是解决不了量子物理的问题的，所以在构建系统架构之前是要去分析场景的。秒杀活动会带来什么问题或者痛点？秒杀意味着活动时间短，商品优惠度大有很多用户进行抢单，后果是造成服务器关于秒杀活动商品的请求短时间出现峰值。服务器必须在高流量下保证服务的可用性。初始

高可用建设应该从哪里着手 1. 架构阶段：架构阶段主要考虑系统的可扩展性和容错性，要避免系统出 现单点问题。例如多机房单元化部署，即使某个城市的某个机房出现整体故障，仍然不会影响整体网站的运转2. 编码阶段：编码最重要的是保证代码的健壮性，例如涉及远程调用问题时，要设置合理的超时退出机制，防止被其他系统拖垮，也要对调用的返回结果集有预期，防止返回的结果超出程序处理范围，最常见的做法就是对错误异常进行捕获，对无法预料的错误要有默认处理结果。3. 测试阶段：测试主要是保证测试用例的覆盖度，保

减库存有哪几种方式1.下单减库存2.付款减库存3.预扣库存减库存可能存在的问题 1.采用“下单减库存”的方式，即用户下单后就减去库存，正常情况下，买家下单后付款的概率会很高，所以不会有太大问题。但是有一种场景例 外，就是当卖家参加某个活动时，此时活动的有效时间是商品的黄金售卖时间， 如果有竞争对手通过恶意下单的方式将该卖家的商品全部下单，让这款商品的库 存减为零，那么这款商品就不能正常售卖了。要知道，这些恶意下单的人是不会 真正付款的，这正是“下单减库存”方式的不足之处。.

排队要对流量进行削峰，最容易想到的解决方案就是用消息队列来缓冲瞬时流量，把 同步的直接调用转换成异步的间接推送，中间通过一个队列在一端承接瞬时的流 量洪峰，在另一端平滑地将消息推送出去。在这里，消息队列就像“水库”一 样， 拦蓄上游的洪水，削减进入下游河道的洪峰流量，从而达到减免洪水灾害 的目的。但是，如果流量峰值持续一段时间达到了消息队列的处理上限，例如本机的消息 积压达到了存储空间的上限，消息队列同样也会被压垮，这样虽然保护了下游的 系统，但是和直接把请求丢弃也没多大的区别。就像遇到洪

为什么要关注热点 我们一定要关注热点，因为热点会对系统产生一系列的影响。 首先，热点请求会大量占用服务器处理资源，虽然这个热点可能只占请求总量的 亿分之一，然而却可能抢占 90% 的服务器资源，如果这个热点请求还是没有价值的无效请求，那么对系统资源来说完全是浪费。其次，即使这些热点是有效的请求，我们也要识别出来做针对性的优化，从 而用更低的代价来支撑这些热点请求。什么是“热点”热点分为热点操作和热点数据。所谓“热点操作”，例如大量的刷新页面、大量的添加购物车、双十一零点大量的下.

何为动静数据“动态数据”和“静态数据”的主要区别就是看页面中输出的数据是否和 URL、浏览者、时间、地域相关，以及是否含有 Cookie 等私密数据。静态数据，不能仅仅理解为传统意义上完全存在磁 盘上的 HTML 页面，它也可能是经过 Java 系统产生的页面，但是它输出的页面 本身不包含上面所说的那些因素。也就是所谓“动态”还是“静态”，并不是说 数据本身是否动静，而是数据中是否含有和访问者相关的个性化数据。缓存静态数据策略第一，你应该把静态数据缓存到离用户最近的地方。第二.

今天被问到秒杀系统的设计，说实话没做过这个东西，就简单的按照处理高并发的后台逻辑进行回答的，答了个寂寞，就收集相关的资料整理一下，看看秒杀系统的演变过程。架构原则：1.数据量尽量少 在网络上传输数据是需要时间的，数据量少网络传输时间就少；服务端处理数据也是要时间的； 2.请求数量尽量少 每个请求都要通过三次握手来建立连接；要是页面有连接数限制的话，有些请求需要等待执行；要是不同请求的域名存在不同的情况，还涉及到dns解析； ...