本文内容
- 秒杀业务难点
- 秒杀架构理论
- 业务设计 & 总结
摘录: 生命轮回. 事业, 家庭乃至做的每件事都会有生命周期. 与其想着何时 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 越少越好, 数据连接次数.
访问路径尽量越短, 节点越少, 消耗越少
避免单点故障, 要有备份
资料: 开涛《亿量级流量网站架构设计》
来源: https://www.cnblogs.com/Alandre/p/10522088.html