Update 秒杀架构.md

xbox1994 · web-flow · commit f5cc1ce3e4b6 · 2019-12-03T20:27:36.000+08:00
diff --git a/MD/秒杀架构.md b/MD/秒杀架构.md
@@ -36,24 +36,24 @@
 1. 如果在秒杀的过程中由于服务崩溃导致秒杀活动中断，那么没有好的办法，只能立即尝试恢复崩溃服务或者申请另寻时间重新进行秒杀活动
 2. 如果在下订单的过程中由于用户的某些限制导致下单失败，那么应该回滚事务，立即告诉用户失败原因
 
-### 难点+坑+复盘优化
+### 总结
 #### 原则
 业务优化思路：业务上适当规避  
 技术优化思路：尽量将请求拦截在数据库的上游，因为一旦大量请求进入数据库，性能会急剧下降  
-架构原则：合适、简单、演化  
+架构原则：合适、简单、演化（以上内容是最终版本，初版可以说没有用到队列，直接使用缓存-数据库这样的架构）  
 
-## 难点
-1. 将高并发大流量一步步从业务和技术方面有条不紊地应对过来
-2. 代码中异常情况的处理与应急预案的准备
+#### 难点
+1. 如何将高并发大流量一步步从业务和技术方面有条不紊地应对过来
+2. 如何在代码中处理好异常情况以及应急预案的准备
 
-## 坑
+#### 坑
 1. 以上的解决方案能通过利用Redis与消息队列集群来承载非常高的并发量，但是运维成本高。比如Redis与消息队列都必须用到集群才能保证稳定性，会导致运维成本太高。所以需要有专业的运维团队维护。
 2. 避免同一用户同时下多个订单，需要写好业务逻辑或在订单表中加上用户ID与商品ID的唯一索引；避免卖超问题，在更新数量的sql上需要加上>0条件
 
-## 优化
+#### 优化
 1. 将7层负载均衡Nginx与4层负载均衡LVS一起使用进一步提高并发量
 2. 以上是应用架构上的优化，在部署的Redis、消息队列、数据库、虚拟机偏向选择带宽与硬盘读写速度高的
 3. 提前预热，将最新的静态资源同步更新到CDN的所有节点上，在Redis中提前加载好需要售卖的产品信息
-4. 使用分布式限流减少Redis访问压力，在Nginx中配置并发连接数与速度限制，但如果有很多不同的活动同时进行则不适用
+4. 使用分布式限流减少Redis访问压力，在Nginx中配置并发连接数与速度限制
 
 欢迎光临[我的博客](http://www.wangtianyi.top/?utm_source=github&utm_medium=github)，发现更多技术资源~
