泥瓦匠：秒杀架构设计实践思路（一）
摘要: 原创出处 https://www.bysocket.com 「公众号：泥瓦匠BYSocket 」欢迎关注和转载，保留摘要，谢谢！
本文内容
- 秒杀业务难点
- 秒杀架构理论
- 业务设计 & 总结
摘录：生命轮回。事业、家庭乃至做的每件事都会有生命周期。与其想着何时 Ending，不如脚踏实地，思考未来，活在当下。
From 小弟泥瓦匠思考录
一、前言
一提到秒杀，都会想到高性能、高并发、高可用、大流量...。在电商体系中，交易系统占据了环节中的半壁江山。比如里面特别迷人的秒杀系统，那秒杀涉及到什么架构设计？会涉及到什么业务？
泥瓦匠自言自语：秒杀这个东西，一篇文章也说不完。我这一篇起个头，实践系列还在后面，敬请期待。
二、秒杀业务难点
秒杀业务难点，总结为两点
- 并发多读
- 并发少写
这不同于一些场景，优惠营销系统，只会是一个用户读多个数据，但也会大流量的读操作。但没有啥写操作。
并发多读，多用户并发读一个数据。比如华为手机只有一个库存，活动秒杀。那可能几千万的人一起抢这个库存数据。还不包含很多肉机在狂刷。很多用户都在读一个商品 + 这个商品库存的数据。
并发少写，少用户并发写一个数据。比如一起抢，如何限流，因为只有少量写请求操作数据层？只有一个人才能抢到，如何解决超卖问题？
例如，12306 抢票，抢红包啥，瞬间流量更大。那这种系统更加难设计
三、秒杀架构理论
想起了架构一些定律：墨菲定律、康威定律等。任何的设计实践肯定来自某些理论和定律。
秒杀的一些架构理论（我认为的）：
- 高并发原则
- 高可用原则
- 一致性设计
a、高并发原则
1、服务化
服务化老生常谈，选型也有 Spring Cloud 、阿里开源的 Dubbo 等一整套服务化解决方案。考虑服务隔离、限流、超时、重试、补偿等
2、缓存
层层考虑。常见的考虑三层：用户层、应用层、数据层等。
用户层：DNS 缓存、APP 缓存（图片等）
应用层：静态化页面、MQ、Redis 等
数据层：NoSQL、MySQL 自带 Query Cache
思考：缓存不是万能的，肯定是优化各种请求数据、请求节点、请求依赖等
3、拆分
分久必合、合久必分。各种拆分：
- 系统维度：根据业务模块。如电商系统中的交易系统、商品系统等
- 功能维度：根据功能模块。如交易系统中的下单系统、退款系统等
- 读写维度：根据读写比例。如商品系统中的商品写服务和商品读服务等
- 模块维度：根据代码特征。如分库分表、项目 moudle、代码分三层架构等
思考：就想 MyCat 等分库分表组件，天然支持了读写分离...
4、并发化
串行换并行。具体实践，具体场景分析然后优化。
b、高可用原则
1、降级
用于服务依赖隔离、fallback降级，防止雪崩效应。具体选型：hystrix 等
另外，可以做配置化，开关服务降级。核心功能保证，次功能优化为异步或屏蔽。例如：双十一的时候，会关闭某些评价等功能。
2、限流
防止请求攻击或者超出系统峰值。具体可以参考一些限流算法 Guava 的 RateLimiter。还写具体手段：恶意流量访问到 Cache 等
3、可回滚
发布版本失败或者有线上问题故障，第一时间会退到上一个稳定版本。思考：那一般运维团队，会有整套的灰度发布、回滚机制。
四、业务设计 & 总结
秒杀业务涉及也得考虑以下几点（重要的）：
- 幂等
- 防重
- 数据一致性
- 数据动静分离
- 请求削峰
- 备份
这篇思路整理，起个头。也就是大致几个方向：
- 请求数据尽量少，网络 IO 越少越好。包括请求数据 + 返回数据；压缩；数据服务 RT 越少越好，数据连接次数。
- 访问路径尽量越短，节点越少，消耗越少
- 避免单点故障，要有备份
资料： 开涛《亿量级流量网站架构设计》
（关注微信公众号，领取 Java 精选干货学习资料）
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
