docs：提交架构设计文档

Author: 1020325258

docs/.vuepress/config.js

@@ -741,6 +741,15 @@ module.exports = {
  "mianjing/05.携程暑期实习一面.md",
  "mianjing/06.携程暑期实习二面.md",
  ]
+ },
+ {
+ title: "架构设计",
+ collapsable: false,
+ sidebarDepth: 0,
+ children: [
+ "jiagou/01-B站评论系统架构设计.md",
+ "jiagou/02-该从哪些方面提升系统的吞吐量？.md"
+ ]
  }
  ],
  "/md/biz-arch/": [{

docs/md/zqy/面试题/jiagou/01-B站评论系统架构设计.md

@@ -0,0 +1,172 @@
+# 01-B 站评论系统架构设计难点
+
+原文链接：https://mp.weixin.qq.com/s/s99ZWuSi0Lu6ivfpBHvLWQ
+
+这里整理一下在哔哩哔哩技术公众号看到的 B 站评论系统的架构设计文章，自己在学习过程中，对其中感觉比较有帮助的点做一下整理，方便以后查阅，详细版可以点击上方原文链接查看（文中图片均来源于原文）
+
+
+
+## 架构设计
+
+![图片来源于原文](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20240507210217913.png)
+
+
+
+在评论业务中，最为核心的功能是 **发布类接口** 和 **列表类接口** ，数据字段多、依赖服务多、调用关系复杂，因此容易造成系统腐化
+
+
+
+### 接口解耦
+
+这里在设计的时候，将整个业务数据的查询分为了两个步骤：服务编排、数据组装
+
+举个例子：在批量查询评论发布人的粉丝勋章数据之后，将其转换、组装到各个评论卡片中
+
+如果不采用这样的方式，而是在查询评论卡片时，再去查询该评论发布人的粉丝勋章数据，那么会导致【查询评论】和【查询发布人粉丝勋章数据】这两个接口耦合度过高的情况，一旦【查询粉丝勋章数据】接口出现了不可用，会导致【查询评论】功能也会不可用
+
+因此先【查询粉丝勋章数据】，再将数据拼接到评论卡片中，降低两个接口的耦合度，将两个接口之间的强依赖关系变为弱依赖关系，并且可以针对两个接口做 **不同的降级、限流、超时控制**
+
+
+
+### 基础服务 reply-service
+
+![图片来源于原文](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20240507211834709.png)
+
+评论基础服务层（reply-service）专注于评论功能的原子化实现，也是最小粒度的功能，如查询评论、删除评论等功能
+
+该层的接口是需要被其他业务层进行大量调用与业务逻辑组合，因此该层的接口需要保证较高的 **可用性和性能**
+
+因此会集成 **多级缓存、热点探测、布隆过滤器** 等性能优化手段
+
+
+
+### 异步处理 reply-job
+
+![图片来源于原文](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20240507213032626.png)
+
+异步处理层 reply-job 主要作用就是为评论基础功能做一些架构上的补充
+
+#### 缓存更新
+
+缓存更新经常采用的 **缓存旁路模式（Cache Aside）** ，即先读缓存，再读 DB，之后进行缓存的重建
+
+**存在的问题：** 部分缓存数据重建代价较高，比如评论列表（评论列表是分页的，重建时会预加载，加载多页的数据），那么如果短时间内大量请求未命中，就会导致 DB 瞬时压力过大，造成 DB 抖动
+
+**解决方案：** 采用消息队列，保证对单个评论列表，只重建一次缓存
+
+reply-job 的另外一个作用：作为数据库 bin log 的消费者，执行缓存的更新操作
+
+
+
+#### 削峰/异步化处理
+
+reply-job 还负责与 reply-interface 协同，为一些长耗时/高吞吐的调用进行 **异步化/削峰** 处理
+
+比如：**评论发布功能** ，在发布之前，基于安全/策略考量，会有很多前置调用逻辑，导致耗时很长
+
+因此 reply-interface 在处理完一些必要校验逻辑之后，再通过 **消息队列** 送至 reply-job 进行异步处理，包括送审、写 DB、发通知等
+
+这里需要保证单个评论区内的发布评论 **串行** 处理，如果并行处理可能会出现一些数据错乱的风险，因此为了保证串行处理就利用到了 **消息队列的有序性**
+
+
+
+## 存储设计
+
+### 数据库设计
+
+评论功能主要是三张表：评论表+评论区表+评论内容表
+
+因为评论内容的大字段，相对独立，很少修改，因此独立设计成一张表（评论内容表）
+
+**数据库选型：**
+
+刚开始使用 MySQL 分表来实现评论功能，但是很快达到存储瓶颈，从 2020 年起，逐步迁移到 TiDB，从而具备了水平扩容能力
+
+
+
+
+
+### 缓存设计
+
+缓存选用 **Redis** ，主要缓存的信息：
+
+1、评论区的基础信息（redis string 类型，value 使用 JSON 序列化存入）
+
+2、查询 xxx 的评论列表（redis sorted set 类型，member 为评论 id，score 对应 order by 字段）
+
+3、查询 xxx 的评论基础信息（redis）
+
+
+
+缓存的一致性依赖于 binlog 刷新，有以下几处关键细节：
+
+1、binlog 投递到消息队列，需要保证单个评论区以及单个评论更新的 **串行化** （分片 key 选择评论区）
+
+2、数据库更新后，采用删除缓存而非直接更新的方式，避免并发写时的数据错乱
+
+此时会存在大量写操作后， **读操作缓存命中率低的问题** ，利用 singleflight 进行控制，防止 **缓存击穿**
+
+（singleflight 是一种编程模式，用来防止在高并发环境下对于同一资源的重复请求，尤其适用于处理缓存击穿问题。缓存击穿指的是当缓存失效的瞬间，由于并发请求同一数据，导致大量请求直接落到数据库上，从而可能引起数据库的性能问题）
+
+
+
+## 可用性设计
+
+### 写热点和读热点
+
+上边有大量的评论区维度的串行操作，导致 **发布评论** 吞吐量较低，出现热点文章下发布大量评论，就会出现严重延迟
+
+针对吞吐量低的问题，做出如下优化：
+
+1、评论区评论计数的更新：在内存中先合并再更新，减少热点场景下的 SQL 执行次数，评论表的插入也改为批量插入 **（合并是很常见的优化，对于一些实时性要求不强的场景，会将多条数据合并，比如达到几秒合并一次，或者达到多少条数据合并一次，之后通过一次 SQL 完成插入）**
+
+2、非数据库写操作的其他业务逻辑，将这些逻辑从【数据写入主线程】中剥离，交给其他线程并发执行
+
+经过上述优化，热点评论区发布评论 TPS 提升了 10 倍以上
+
+![图片来源于原文](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20240507220810463.png)
+
+
+
+接下来说一下 **读热点问题** 中的典型特征：
+
+1、由于大量接口都需要读取评论区基础信息，存在读放大（在读取数据时，需要关联的读取其他大量数据即为读放大），因此该操作是最先感知到读热点存在的
+
+2、评论业务下游依赖较多，因此对下游来说也是读放大，很多下游依赖是体量相对小的业务单元，难以承载大流量
+
+3、读热点集中在评论列表的第一页，以及热评
+
+4、评论列表的业务数据模型也包含部分个性化信息
+
+基于以上特征， **读热点探测** 放在【读取评论区基础信息】阶段进行，探测到热点之后，在本地缓存中进行热点数据的读取
+
+![image-20240507221540605](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20240507221540605.png)
+
+
+
+**热点探测** 的实现基于单机的滑动窗口+LFU，那么如何定义、计算相应的热点条件阈值呢？
+
+首先，我们进行系统容量设计，列出容量计算的数学公式，主要包括各接口QPS的关系、服务集群总QPS与节点数的关系、接口QPS与CPU/网络吞吐的关系等；然后，收集系统内部以及相应依赖方的一些的热点相关统计信息，通过前面列出的公式，计算出探测数据项的单机QPS热点阈值。最后通过热点压测，来验证相应的热点配置与代码实现是符合预期的。
+
+> 扩展：LFU 和 LRU（Least Recently Used） 的区别：
+
+**LRU** ：LRU是另一种流行的缓存替换策略，它基于数据项的最近访问时间进行缓存管理，最近最少访问的数据项将被首先替换。这种策略假设最近使用过的数据将来很可能再次被使用。
+
+**LFU** ：与LRU基于时间的策略不同，LFU更关注数据项的访问频率。理论上，LFU能更好地识别并保留那些即使不是最近使用但访问频率高的长期热点数据。
+
+
+
+### 冗余与降级
+
+**冗余与降级是保证可用性必不可少的手段**
+
+上边的评论基础服务集成了 **多级缓存** ，那么在上一级缓存不可用时，要求可以降级至下一级缓存，保证功能的可用性
+
+评论系统架构为同城读双活，数据库与缓存均是双机房独立部署的，均支持多副本，具备水平扩容的弹性。针对双机房架构下特有的副机房数据延迟故障，支持入口层切流/跨机房重试/应用层补偿，尽可能保证极端情况下用户无感。
+
+在功能层面，我们做了重要级别划分，把相应的依赖划分为强依赖（如审核）、弱依赖（如粉丝勋章）。对于弱依赖，我们一方面在异常情况下坚决限流熔断，另一方面也通过超时控制、请求预过滤、优化调用编排甚至技术方案重构等方式持续优化提升非核心功能的可用性，为业务在评论区获得更好的曝光展现。
+
+
+
+原文中还有一部分是关于 **热评的设计** ，即对于热评的存储、热评的查询、热评的排序如何进行设计，这一部分较为复杂，如果感兴趣可以查看原文第 7 部分：热评设计
+

docs/md/zqy/面试题/jiagou/02-该从哪些方面提升系统的吞吐量？.md

@@ -0,0 +1,51 @@
+# 02-该从哪些方面提升系统的吞吐量？
+
+我们平时自己做的项目一般没有用户量，都是练手项目，所以并不会在吞吐量上做出很多的优化，但是这样的话，又会导致项目和其他人相比并没有什么亮点，因此可以借鉴一些高吞吐量的架构设计，来为自己的项目添加一些亮点功能，这里总结一下 **B 站千万长连消息系统** 如何提升系统吞吐量！
+
+B 站千万长连消息系统原文链接：https://mp.weixin.qq.com/s/Thw_mkb-aUepzcjd9RCDzw
+
+## 1、负载均衡
+
+负载均衡是比较常用的了，通过负载均衡将请求分发到不同的服务器上处理，分散单个节点上的压力，可以提高系统的扩展性和稳定性。
+
+可以根据实际需求设计负载均衡策略，选择合适的节点进行请求的转发。
+
+负载均衡中比较重要的就是 **节点的动态扩缩容** ，也就是可以实现节点实时增加、减少，这样在高峰期可以增加部分节点来抗下更高的吞吐量，低峰期可以减少部分节点，避免资源浪费。
+
+## 2、消息队列
+
+消息队列也是很常用的一个手段，高并发系统的三把利器：**分流、缓存、异步**
+
+其中分流指的就是将流量分开，对应负载均衡，异步即对应消息队列
+
+**为什么要用消息队列呢？**
+
+一方面是进行业务之间的解耦，另一方面是为了提升系统的性能，通过消息队列可以提升主干流程的响应速度，将一些比较耗时的操作从主干流程中剥离出去。
+
+这里 B 站在设计上增加了 **消息队列和消息分发层** ，如果服务层在执行业务逻辑时，还要去推送大量的消息到各个节点上，比较影响消息的吞吐量，因此通过增加 **消息分发层** 来推送和维护消息，提高了系统的并发处理能力，避免了因消息推送阻塞而导致的性能问题。
+
+## 3、消息聚合
+
+消息聚合也是比较常用的一个手段，我看了 B 站分享出来的技术文章，多次提到了消息聚合。
+
+如果不使用消息聚合，就拿弹幕消息来说，如果一个用户发送一条弹幕消息，那么这条消息需要扩散到同时在线的所有用户，假如说有 1kw 人在线，那么发送的消息数量就是 1kw * 1kw，消息量巨大！
+
+因此，可以根据一定的规则进行消息聚合，批量推送，比如说达到一定时间内推送一次，或者消息数量达到多少就进行推送一次，如下图：
+
+![图片来源于原文](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20240512003048425.png)
+
+根据 B 站统计结果，加入消息聚合后，发送消息的 QPS 下降了 60% 左右，大大减少了发送消息所带来的压力！
+
+
+
+## 4、压缩算法
+
+在消息聚合后，降低了消息的数量，减少了发送次数，但是同时发送消息的体积会增加，影响了写入 IO，因此采用 **压缩算法** 来对消息进行压缩。
+
+市面上常用的两个压缩算法：zlib 和 brotli。
+
+原文对两个压缩算法进行了比较，发现 brotli 算法比较具有优势，因此选择了该算法。
+
+比较结果如下（来自于原文）
+
+![image-20240512003346092](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20240512003346092.png)