Thanks to visit codestin.com
Credit goes to github.com

Skip to content

shaokaiyang/GeekTimeSpikeSystemNotes

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 
 
 

Repository files navigation

GeekTimeSpikeSystemNotes

记录在《极客时间》平台上《如何设计一个秒杀系统》专栏的学习笔记
作者信息:许令波(君山) 前阿里巴巴高级技术专家

目录

正文

开篇词

1. 秒杀系统主要解决两个问题:并发读和并发写 - 并发读的核心优化理念是尽量减少用户到服务端来“读”数据,或者让他们读更少的数据。 - 并发写的处理原理也是一样,要求在数据库层面独立出来一个库做特殊处理。 - 此外还要针对秒杀系统做一些保护,针对意料之外的情况设计兜底方案,防止最坏情况发生。 - 从架构师的角度来看打造一个高性能的并发系统需要遵循几个原则:用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少、不单点。 2. 秒杀系统可以用“稳、准、快”几个关键字来概括 - 稳:保证系统架构的高可用性,流量在符合或超出预期的前提下要稳定,保证秒杀商品顺利卖出去,这是基本前提。 - 准:准就是要保证数据的一致性,保证库存和售卖出去的商品数量相同。 - 快:系统的性能要足够高,服务端要做极致的性能优化,整个请求链路上也要做协同优化。 3. 秒杀系统的架构特性 - 高性能:秒杀系统的高并发访问很关键,可以从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化来实现; - 一致性:秒杀减库存方案的设计与实现; - 高可用:针对一些特殊情况设计备用方案来兜底。

第一讲 设计秒杀系统时注意的5个架构原则

秒杀系统本质上就是一个满足高并发、高性能和高可用的分布式系统。架构是一种平衡的艺术,要与应用场景相结合。 1. 数据要尽量少 - 用户请求的数据要尽量少,包括上传给系统的数据和系统返回的数据。原因:数据在网络上传输需要时间;数据在写网络做压缩和字符编码耗CPU。简化秒杀界面 - 系统依赖数据尽量少。调用其他服务涉及到数据的序列化和反序列化耗CPU,增加延时; 2. 请求数尽量少 - 请求页面返回的渲染等额外请求要少。原因:建立连接需要三次握手;页面依赖或连接数限制;串行加载;DNS解析; - 常用实践:将多个JS文件合并为一个文件,在URL中用逗号隔开; 3. 路径尽量短 - 路径是用户发出请求到返回数据过程中需要经过的中间节点数; - 缩短请求路径可以增加可用性、提升性能(减少数据的序列化和反序列化)、减少延时; - 实践:将多个相互强依赖的应用合并部署在一起,把远程过程调用(RPC)变成JVM内部之间的方法调用; 4. 依赖尽量少 - 依赖指要完成一次用户请求必须依赖的系统或者服务; - 实践:给系统进行分级,例如0级、1级……0级系统若是重要系统则其强依赖的系统也是重要系统,尽量减少0级系统对1级系统的强依赖,防止重要的系统被不重要的系统拖垮; 5. 不要有单点 - 避免将服务的状态和机器绑定,将服务无状态化,这样服务可以在机器中随意移动; - 通过把和机器相关的配置动态化(通过配置中心来动态推送)来实现服务状态和机器的解耦; - 对于存储服务这样很难无状态化的服务,通过冗余多个备份来解决单点问题; 6. 不同场景下的架构案例 - 简单的秒杀系统:在商品购买页增加一个“定时上架”功能,在秒杀开始时用户才可以看到,商品卖完秒杀结束; - 请求10W/S量级优化: - 将秒杀系统独立成一个单独的系统,方便优化; - 系统部署上独立做一个机器集群; - 将热点数据单独放到一个缓存系统中,提高“读性能”; - 增加秒杀答题,防止有秒杀器抢单; - 请求100W/S量级优化: - 对页面进行彻底的动静分离,用户秒杀不需要刷新整个页面; - 在服务端对秒杀商品进行本地缓存; - 增加系统限流保护,防止最坏情况发生;

第二讲 如何做好动静分离

让系统快起来:一是提高单次请求的效率;二是减少没必要的请求; 1. 动静数据介绍 动态数据和静态数据的主要区别就是看页面中输出的数据是否和URL、浏览器、时间、地域相关以及是否含有cookie等私密数据。 - 对静态数据做缓存的方式 - 将静态数据缓存到离用户最近的地方。常见的缓存方式有三种:用户的浏览器里、CDN上和服务端的cache中。 - 静态化改造直接缓存HTTP连接。 - 确定缓存静态数据对象。Java系统本身有弱点(不擅长处理大量连接请求、每个连接消耗的内存较多,Servlet容器解析HTTP协议较慢),可以不再Java层做缓存而在web层缓存; 2. 动静分离改造 以典型的商品详情系统为例来详细介绍。 - URL 唯一化。唯一化是进行HTTP连接缓存的基础。 - 分离浏览者相关的因素。将用户的登录信息、登录身份等单独拆分出来,通过动态请求来获取。 - 分离时间因素。服务端输出的时间也通过动态请求的方式进行获取; - 异步化地域因素。详情页面上与地域相关的因素做成异步方式获取; - 去掉cookie。指在缓存的静态数据中不含有cookie; - 动态内容的处理方案:ESI方案(SSI):在web代理服务器上做动态内容请求,并将请求插入到静态页面中;CSI方案:单独发起一个异步的JS请求,向服务端获取动态内容; 3. 动静分离的接种架构方案 - 实体机单机部署。 - 将虚拟机改为实体机以增大cache,采用一致性hash分组来提高命中率(命中率和访问热点的平衡)。 - 优点:没有网络瓶颈而且可以使用大内存;提升命中率减少Gzip压缩;减少cache失效压力; - 缺点:浪费CPU;实体机上部署Java应用又作为cache来使用,造成运维上的高度复杂; - 统一cache层。 - 将单机的cache统一分离出来,形成一个单独的cache集群; - 优点:减少多个应用接入时使用cache的成本;更易于维护;可以共享内存,最大化利用内存,不同系统的内存可以动态切换; - 缺点:cache层内部交换网络成为瓶颈;缓存服务器的网卡会成为瓶颈;机器少风险较大; - 上CDN - 需要解决问题:失效问题:保证CDN可以在秒级时间内让全国各地的cache同时失效;命中率问题:cache分散会导致命中降低;发布更新问题:发布系统必须足够简洁高效,支持快速回滚和排查; - 选择若干节点来进行缓存:靠近访问量比较集中的地区;离主站相对较远;节点到主站间的网络稳定;节点容量比较大,不占资源;节点不要太多; - CDN部署方案特点:把整个页面缓存在用户浏览器中;强制刷新整个页面也会请求CDN;实际有效请求,只是用户对“刷新抢宝”的点击;

第三讲 二八原则:有针对性地处理好系统的“热点数据”

第四讲 流量削峰

第五讲 影响性能的因素及改进策略

第六讲 秒杀系统“减库存”设计的核心逻辑

第七讲 如何设计兜底方案

第八讲 缓存失效的策略应该怎样定

相关技术参考

1. CSS 2. JavaScript 3. Socket 4. RPC 5. JVM 6. CDN 7. Ajax请求 8. Cache 9. 序列化和反序列化 10. Cookie 11. Nginx 12. Gzip

完结

觉得有价值 感谢支持

赞赏码

About

"Spike System design" notes in geek time

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published