同步操作将从 turnon/blog 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
title: 系统架构面试
date: 2020-08-10 10:59:18
categories:
- 设计
- 架构
- 综合
tags:
- 架构
- 面试
permalink: /pages/000a7b/
秒杀的核心问题就是极高并发处理,由于系统要在瞬时承受平时数十倍甚至上百倍的流量,这往往超出系统上限,因此处理秒杀的核心思路是限流和缓存。
秒杀系统具体方案如下:
(1)浏览器、客户端拦截重复请求
基于此,大部分流量已被拦截。
(2)应用层拦截请求
浏览器、客户端拦截重复请求只能应付通过浏览器访问的用户。如果有人通过程序发送 http 请求,则无法拦截。针对这种情况的方案是:
以页面缓存的方式,针对短时间内的同一个访问源(如同一个 IP、同一个 Session、同一个用户 ID 多次发送 HTTP 请求)或同样的查询请求(如大量请求都是查询某类商品的库存),都返回相同的展示页面。
如此限流,又有大部分的流量被拦截
(3)服务层请求拦截与数据缓存
加入有黑客,控制了 10w 台肉鸡(并且假设买票不需要实名认证),前面的的限制都不起作用了。这时应该怎么办?
读请求(查库存) - 对于读请求,直接使用缓存即可,一般缓存服务器单机处理每秒 10w 个请求应该没什么问题。
写请求(下单) - 由于服务层清楚的知道库存数量,所以完全可以根据库存数量进行限流。具体来说,就是把所有下单请求都丢该消息队列中,每次只取有限的写请求去数据层处理。当这些写请求处理完,更新一下缓存中的库存数,再去取下一批写请求,如果库存数不够,则消息队列的写请求全部返回"已售罄"的结果。
参考:
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。