转载

秒杀架构设计实践思路

本文内容

秒杀业务难点
秒杀架构理论
业务设计 & 总结

摘录：生命轮回。事业、家庭乃至做的每件事都会有生命周期。与其想着何时 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 越少越好，数据连接次数。
访问路径尽量越短，节点越少，消耗越少
避免单点故障，要有备份

秒杀架构设计实践思路

资料：开涛《亿量级流量网站架构设计》

其他链接

关于本站

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。

问题交流

秒杀架构设计实践思路

推荐阅读

热门推荐

相关文章

说给你听

本文目录

随机标签

书籍教程

近期评论

网站信息

其他链接

关于本站

问题交流