用户您好!请先登录!

分类目录电商秒杀系统

继续扯一扯秒杀系统设计

秒杀系统的关键点:

秒杀系统其实主要解决2个问题,一个是并发读,一个是并发写。整体概况为“稳、准、快”

  • 高性能。 秒杀涉及大量的并发读和并发写,因此支持高并发访问这点非常关键。本文将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这 4 个方面重点介绍。
  • 一致性。 秒杀中商品减库存的实现方式同样关键。可想而知,有限数量的商品在同一时刻被很多倍的请求同时来减库存,减库存又分为“拍下减库存”“付款减库存”以及预扣等几种,在大并发更新的过程中都要保证数据的准确性,其难度可想而知。
  • 高可用。 虽然介绍了很多极致的优化思路,但现实中总难免出现一些我们考虑不到的情况,所以要保证系统的高可用和正确性,我们还要设计一个 PlanB 来兜底,以便在最坏情况发生时仍然能够从容应对。

 

1. 设计秒杀系统时应该注意的5个架构原则

总结来说就是“4 要 1 不要”

  • 数据要尽量少。 所谓“数据要尽量少”,请求的数据包括请求包体和返回包体,字段精简。不管是请求数据还是返回数据都需要服务器做处理,而服务器在写网络时通常都要做压缩和字符编码,这些都非常消耗 CPU,所以减少传输的数据量可以显著减少 CPU 的使用。数据库也容易成为一个瓶颈,所以和数据库打交道越少越好,数据越简单、越小则越好。
  • 请求数要尽量少。 这里的请求数包括了页面依赖的 CSS/JavaScript、图片、加载这些文件都需要建立连接要做三次握手,另外,如果不同请求的域名不一样的话,还涉及这些域名的 DNS 解析,可能会耗时更久。所以,减少请求数可以显著减少以上这些因素导致的资源消耗。

阅读更多

12306的抢票秒杀,如何优化?

高并发场景,三类业务的架构挑战不一样:

  • QQ类业务,用户主要读写自己的数据,访问基本带有uid属性,数据访问锁冲突较小
  • 微博类业务,用户的feed主页由别人发布的消息构成,数据读写有一定锁冲突
  • 12306类业务,并发量很高,几乎所有的读写锁冲突都集中在少量数据上,难度最大

那么对于秒杀类业务,系统上业务上分别能如何优化呢,这是本文要讨论的问题。

系统层面,秒杀业务的优化方向如何?

主要有两项:

(1)将请求尽量拦截在系统上游,而不要让锁冲突落到数据库。

传统秒杀系统之所以挂,是因为请求都压到了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,访问流量大,下单成功的有效流量小。

一趟火车2000张票,200w个人同时来买,没有人能买成功,请求有效率为0。

画外音:此时系统的效率,还不如线下售票窗口。

阅读更多