第一章学习总结——概览https://time.geekbang.org/column/article/40153
1.秒杀主要解决问题——并发读和并发写。并发读的核心优化理念是尽量减少用户到服务端来读取数据，或者让他们读更少的数据。并发写的处理原则是在数据库层面独立出一个库，做特殊的处理。另外针对秒杀系统做一些保护，针对意料之外的情况设计兜底方案，以防止最坏的情况发生。
2.从一个架构师的角度来看，要想打造并维护一个超大流量并发读写、高性能、高可用的系统，在整个用户请求路径上从浏览器到服务端我们要遵循几个原则，就是要保证用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少，并且不要有单点。
3.秒杀的整体架构可以概括为“稳、准、快”（高可用、一致性、高性能）几个关键字。
所谓“稳”，就是整个系统架构要满足高可用，流量符合预期时肯定要稳定，就是超出预期时也同样不能掉链子，你要保证秒杀活动顺利完成，即秒杀商品顺利地卖出去，这个是最基本的前提。
“准”，就是秒杀 10 台 iPhone，那就只能成交 10 台，多一台少一台都不行。一旦库存不对，那平台就要承担损失，所以“准”就是要求保证数据的一致性。
“快”，“快”其实很好理解，它就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化，每个地方快一点，整个系统就完美了。
所以从技术角度上看“稳、准、快”，就对应了我们架构上的高可用、一致性和高性能的要求。
高性能：
秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。主要包含数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这 4 个方面。
一致性：
秒杀中商品减库存的实现方式同样关键。有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性。
高可用：
现实中总难免出现一些考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个 PlanB 来兜底，以便在最坏情况发生时仍然能够从容应对。
——————————————————————————————————————————————————————————————————————————————————
第二章学习总结——设计秒杀系统应该注意的五个（4要1不要）架构原则。https://time.geekbang.org/column/article/40726
1.数据量尽量少：请求数据和返回数据都要尽量少，以减少CPU使用。
2.请求数要尽量少：减少额外请求，如合并js、css等，首屏HTML内联所需的CSS、JS。
3.路径要尽量短：减少节点数，相互强依赖的应用合并部署。节点越少出错概率就越小，可用性就越高。所以缩短请求路径不仅可以增加可用性，同样可以有效提升性能（减少中间节点可以减少数据的序列化与反序列化），并减少延时（可以减少网络传输耗时）。
4.强依赖尽量少：给数据重要性分等级，尽量减少所要加载的数据。
5.不要有单点，要有备份，如设计分布式系统，关键点是把服务无状态话，避免将服务的状态和机器绑定，使服务可以在机器中随意移动。
架构是一种平衡的艺术，而最好的架构一旦脱离了它所适应的场景，一切都将是空谈。所以设计架构时上面几点只是方向，应该根据实际情况适当取舍。
补充：
答疑：
1 .本地cache用什么实现好呢？
本地cache一般就是用内存实现，如java用集合类型就行
- 通过什么方式往本地cache 写数据呢？
用订阅的方式，在初始化时加载到内存
- 秒杀系统的及时性非常高，把库存写进cache ，怎么及时更新呢？
有两种方法，一是定时更新取3秒，二是，主动更新，数据库字段更新后发消息更新缓存，这个需要用到一个组件阿里叫metaq就是就是数据库字段更新会产生一条消息。另外cache里库存不需要100%和数据库一致，最终强一致性即可
4.各QPS级别架构可能瓶颈点？
不同QPS量级下瓶颈也会不一样，10w级别可能瓶颈就在数据读取上，通过增加缓存一般就能解决，如果要到100w那么，可能服务端的网络都是瓶颈，所以要把大部分的静态数据放到cdn上甚至缓存在浏览器里。
5.单点是什么？
单点就是一个状态值存储在一台机器上，这台机器挂了，这个状态就丢了，导致整个服务不可用。最常用的就是本机存储数据，而这个数据没有备份的情况
架构示例：
1-10万QPS级别架构设计示例图：
原文地址：https://www.cnblogs.com/ryanlamp/p/10133713.html