泥瓦匠:秒杀架构设计实践思路(一)

  • 时间:
  • 浏览:0
  • 来源:大发时时彩_时时彩官方网_大发时时彩官方网

摘要: 原创出处 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、可回滚

发布版本失败原应有线上大问题故障,第一时间会退到上有一有另一个 稳定版本。思考:那一般运维团队,会有整套的灰度发布、回滚机制。

四、业务设计 & 总结

秒杀业务涉及也得考虑以下几点(重要的):

  • 幂等
  • 防重
  • 数据一致性
  • 数据动静分离
  • 请求削峰
  • 备份

这篇思路派发,起个头。也好多好多 大致哪多少方向:

  1. 请求数据尽量少,网络 IO 越少越好。包括请求数据 + 返回数据;压缩;数据服务 RT 越少越好,数据连接次数。
  2. 访问路径尽量越短,节点越少,消耗越少
  3. 出理 单点故障,要有备份

资料: 开涛《亿量级流量网站派发》

(关注微信公众号,领取 Java 精选干货学习资料)