奈学百万业务架构师

爱分享 爱生活 加油 2021

百度网盘

提取码：qhhv 

概述

整理了一些常见的架构设计面试题，主要记录关键点，具体细节就不详细叙述了，案例慢慢补充。目前想起如下问题：

• 秒杀系统
• 短连接生成
• 高并发的红包系统
• 分布式ID生成
• 分布式限流
• 分布式定时任务
• 新浪微博怎么推送微博
• 大文件有限内存排序

秒杀系统

秒杀系统基本面试被问烂了，网上资料也不少，基本整理了内容以下：

设计难点：并发量大，应用、数据库都承受不了。另外难控制超卖。

设计要点：

• 将请求尽可能拦截在系统上游，html尽可能静态化，部署到cdn上面。按钮及时设置为不可用，禁止用户重复提交请求。
• 设置页面缓存，针对同一个页面和uid一段时间内返回缓存页面。
• 数据用缓存抗，不直接落到数据库。
• 读数据的时候不作强一致性教研，写数据的时候再作。
• 在每台物理机上也缓存商品信息等等变更不大的相关的数据
• 像商品中的标题和描述这些自己不变的会在秒杀开始以前全量推送到秒杀机器上并一直缓存直到秒杀结束。
• 像库存这种动态数据会采用被动失效的方式缓存必定时间（通常是数秒），失效后再去Tair缓存拉取最新的数据。
• 若是容许的话，用异步的模式，等缓存都落库以后再返回结果。
• 若是容许的话，增长答题教研等验证措施。

其余业务和技术保障措施：

• 业务隔离。把秒杀作成一种营销活动，卖家要参加秒杀这种营销活动须要单独报名，从技术上来讲，卖家报名后对咱们来讲就是已知热点，当真正开始时咱们能够提早作好预热。
• 系统隔离。系统隔离更可能是运行时的隔离，能够经过分组部署的方式和另外 99% 分开。秒杀还申请了单独的域名，目的也是让请求落到不一样的集群中。
• 数据隔离。秒杀所调用的数据大部分都是热数据，好比会启用单独 cache 集群或 MySQL 数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%。

另外须要复习缓存穿透、雪崩等等问题，主要的流量都落在了缓存数据库上，须要针对缓存数据库的高可用做保障。

短连接生成

这个应该是比较公认的方案了：

1. 分布式ID生成器产生ID
2. ID转62进制字符串
3. 记录数据库，根据业务要求肯定过时时间，能够保留部分永久连接

主要难点在于分布式ID生成。鉴于短链通常没有严格递增的需求，可使用预先分发一个号段，而后生成的方式。

看了下新浪微博的短连接，8位，理论上能够保存超过200万亿对关系，具体怎么存储的还有待研究。

红包系统

红包系统其实很像秒杀系统，只不过同一个秒杀的总量不大，可是全局的并发量很是大，好比春晚可能几百万人同时抢红包。

主要技术难点也相似，主要在数据库，减库存的时候会抢锁。另外因为业务需求不一样，没办法异步，也不能超卖，事务更加严格。

不能采用的方式：

• 乐观锁：手慢会失败，DB 面临更大压力，因此不能采用。
• 直接用缓存顶，涉及到钱，一旦缓存挂掉就完了。

建议的方式：

• 接入层垂直切分，根据红包ID，发红包、抢红包、拆红包、查详情详情等等都在同一台机器上处理，互不影响，分而治之。
• 请求进行排队，到数据库的时候是串行的，就不涉及抢锁的问题了。
• 为了防止队列太长过载致使队列被降级，直接打到数据库上，因此数据库前面再加上一个缓存，用CAS自增控制并发，过高的并发直接返回失败。
• 红包冷热数据分离，按时间分表。

分布式ID

分布式ID生成大概也算老生常谈的问题了，主要关键在因而否须要严格递增，严格递增的话效率必然大降。

不须要递增的话比较简单:

• 一种方式是预先分片，好比十台机器，每台先分一千个ID，一号机从0开始，二号从1000开始等等。缺点是大体上能够被人看出来业务量。
• 另外一种方式是相似雪花算法，每一个机器有个id，而后基于时间算一个id，再加上一个递增id。好比以下美团的方案。缺点是机器的时间戳不能回拨，回拨的话会出现问题。