Skip to content

Commit 9c2512c

Browse files
committed
📖backtrack
1 parent d240ddc commit 9c2512c

File tree

1,056 files changed

+9990
-9191
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

1,056 files changed

+9990
-9191
lines changed

docs/.DS_Store

0 Bytes
Binary file not shown.

docs/.obsidian/workspace.json

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@
4949
"state": {
5050
"type": "markdown",
5151
"state": {
52-
"file": "data-management/Redis/Redis-Database.md",
52+
"file": "interview/JVM-FAQ.md",
5353
"mode": "preview",
5454
"source": false
5555
}
@@ -142,7 +142,7 @@
142142
"state": {
143143
"type": "backlink",
144144
"state": {
145-
"file": "data-management/Redis/Redis-Database.md",
145+
"file": "interview/JVM-FAQ.md",
146146
"collapseAll": false,
147147
"extraContext": false,
148148
"sortOrder": "alphabetical",
@@ -159,7 +159,7 @@
159159
"state": {
160160
"type": "outgoing-link",
161161
"state": {
162-
"file": "data-management/Redis/Redis-Database.md",
162+
"file": "interview/JVM-FAQ.md",
163163
"linksCollapsed": false,
164164
"unlinkedCollapsed": true
165165
}
@@ -182,7 +182,7 @@
182182
"state": {
183183
"type": "outline",
184184
"state": {
185-
"file": "data-management/Redis/Redis-Database.md"
185+
"file": "interview/JVM-FAQ.md"
186186
}
187187
}
188188
}
@@ -205,8 +205,8 @@
205205
},
206206
"active": "c7c1397df03f59cc",
207207
"lastOpenFiles": [
208-
"data-management/Redis/Redis-Datatype.md",
209208
"data-management/Redis/Redis-Database.md",
209+
"data-management/Redis/Redis-Datatype.md",
210210
"data-management/Redis/Redis-Cluster.md",
211211
"data-management/Redis/Redis 有用指令.md",
212212
"data-management/Redis/ReadRedis.md",

docs/interview/Collections-FAQ.md

Lines changed: 100 additions & 121 deletions
Large diffs are not rendered by default.

docs/interview/Kafka-FAQ.md

Lines changed: 26 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -12,10 +12,12 @@ categories: Interview
1212

1313
### 为什么需要消息队列
1414

15+
消息队列最鲜明的特性是**异步、削峰、解耦**
16+
1517
1. **解耦**: 允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。
1618
2. **冗余**:消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。
1719
3. **扩展性**: 因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。
18-
4. **灵活性 & 峰值处理能力**: 在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。 如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。
20+
4. **峰值处理能力 & 灵活性 **: 在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。 如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。
1921
5. **可恢复性**: 系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。
2022
6. **顺序保证**: 在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。(Kafka 保证一个 Partition 内的消息的有序性)
2123
7. **缓冲**: 有助于控制和优化数据流经过系统的速度, 解决生产消息和消费消息的处理速度不一致的情况。
@@ -634,10 +636,18 @@ Kafka 又是如何做到消息不重复的,也就是:生产端不重复生
634636
> 3. 生产者发送每条消息时,增加一个全局唯一id(类似订单id),消费者消费到时,先**根据这个id去Redis中查询是否消费过该消息**。如果没有消费过,就处理,将id写入Redis;如果消费过了,那么就不处理,保证不重复处理相同消息。
635637
> 4. 基于数据库的**唯一键约束**来保证不会插入重复的数据,当消费者企图插入重复数据到数据库时,会报错。
636638
>
637-
>
639+
> 如果数据量超级大的话,还有种方案使用布隆过滤器 + redis 的方案 + 唯一索引,**层层削流**,就是**确保到达数据库的流量最小化**
640+
>
641+
> 首先,一个请求过来的时候,我们会利用布隆过滤器来判断它有没有被处理过。如果布隆过滤器说没有处理过,那么就确实没有被处理过,可以直接处理。如果布隆过滤器说处理过(可能是假阳性),那么就要执行下一步。
642+
>
643+
> 第二步就是利用 Redis 存储近期处理过的 key。如果 Redis 里面有这个 key,说明它的确被处理过了,直接返回,否则进入第三步。这一步的关键就是 key的过期时间应该是多长。
644+
>
645+
> 第三步则是利用唯一索引,如果唯一索引冲突了,那么就代表已经处理过了。这个唯一索引一般就是业务的唯一索引,并不需要额外创建一个索引。
638646
639647
#### 消费端:不能重复消费消息
640648

649+
比如说你在处理消息完毕之后,准备提交了。这个时候突然宕机了,没有提交。等恢复过来,你会再次消费同一个消息。
650+
641651
为了保证消息不重复,消费端就不能重复消费消息,该如何去实现呢?消费端需要做好如下配置。
642652

643653
第一步,设置 `enable.auto.commit=false`。跟前面一样,这里同样要避免自动提交偏移量。你可以想象这样一种情况,消费端拉取消息和处理消息都完成了,但是自动提交偏移量还没提交消费端却挂了,这时候 Kafka 消费组开始重新平衡并把分区分给另一个消费者,由于偏移量没提交新的消费者会重复拉取消息,这就最终造成重复消费消息。
@@ -658,15 +668,9 @@ processMsg(messages);
658668

659669
### Kafka 如何保证消息的顺序消费?
660670

661-
> 在什么业务场景下,你需要用到有序消息?
662-
>
663-
> 你是如何解决有序消息这个问题的?用的是哪种方案?
664-
>
665671
> 如果你用的是单分区解决方案,那么有没有消息积压问题?如果有,你是怎么解决的?
666672
>
667-
> 如果你用的是多分区解决方案,那么有没有分区负载不均衡的问题?如果有,你是怎么解
668-
>
669-
> 决的?
673+
> 如果你用的是多分区解决方案,那么有没有分区负载不均衡的问题?如果有,你是怎么解决的?
670674
671675
- 1 个 Topic 只创建 1 个Partition(分区),这样生产者的所有数据都发送到了一个 Partition,保证了消息的消费顺序(这样的坏处就是磨灭了 kafka 最优秀的特性。所以可以思考下是不是技术选型有问题, kafka本身适合与流式大数据量,要求高吞吐,对数据有序性要求不严格的场景。
672676

@@ -884,10 +888,12 @@ Kafka目前不支持动态减少分区。这是因为减少分区会涉及到数
884888

885889
### Kafka 为什么能那么快 | Kafka高效读写数据的原因 | 吞吐量大的原因?
886890

891+
**零拷贝、page cache、顺序写、分区、分段与索引、批量处理、压缩**
892+
887893
- partition 并行处理
888894
- 顺序写磁盘,充分利用磁盘特性
889895
- 利用了现代操作系统分页存储 Page Cache 来利用内存提高 I/O 效率
890-
- 采用了零拷贝技术
896+
- 采用了零拷贝技术(所谓的零拷贝,就是指没有 CPU 参与的拷贝)
891897
- Producer 生产的数据持久化到 broker,采用 mmap 文件映射,实现顺序的快速写入
892898
- Customer 从 broker 读取数据,采用 sendfile,将磁盘文件读到 OS 内核缓冲区后,转到 NIO buffer进行网络发送,减少 CPU 消耗
893899

@@ -945,9 +951,17 @@ Kafka目前不支持动态减少分区。这是因为减少分区会涉及到数
945951
}
946952
```
947953

954+
> 这个方案的缺点其实还挺严重的。第一个是延迟时间必须预先设定好,比如只 能允许延迟 1min、3min 或者 10min 的消息,不支持随机延迟时间。不过绝大多数情况下,业务是用不着非得 随机延迟时间的。
955+
>
956+
> 在一些 业务场景下,需要根据具体业务数据来计算延迟时间,那么这个就不适用了。
957+
>
958+
> 第二个是分区之间负载不均匀。比如很多业务可能只需要延迟 3min,那么 1min 和 10min 分区的数据就很少。这会进一步导致一个问题,就是负载高的 分区会出现消息积压的问题。 在这里,很多解决消息积压的手段都无法使用,所以只能考虑多设置几个延迟 时间相近的分区,比如说在 3min 附近设置 2min30s,3min30s 这种分区来分 摊压力。
959+
>
960+
> 还要考虑一致性问题,比如发送延时队列失败、或者转发到业务 topic 时失败,要怎么处理
961+
948962
#### 实现死信队列
949963

950-
死信队列用于处理由于各种原因无法成功处理的消息。实现Kafka死信队列的方法如下
964+
死信队列用于处理由于各种原因无法成功处理的消息。实现 Kafka 死信队列的方法如下
951965

952966
1. **创建死信主题**:创建一个专门的死信主题,如`dead-letter-topic`
953967

@@ -997,7 +1011,7 @@ Kafka目前不支持动态减少分区。这是因为减少分区会涉及到数
9971011

9981012

9991013

1000-
### Kafka 目前有哪些内部topic,他们都有什么特征,各自的作用又是什么
1014+
### Kafka 目前有哪些内部 topic,他们都有什么特征,各自的作用又是什么
10011015

10021016
Kafka的内部主题(Internal Topics)是系统自动创建和管理的,用于维护集群的元数据和协调操作。以下是一些常见的Kafka内部主题及其特征和作用:
10031017

node_modules/.cache/terser-webpack-plugin/content-v2/sha512/00/2e/bf58b1513962f90f986822c52384ce16ecf1c9e60e14c119da5b7533cde3a134fa0f48b67fbebaf0d0ab7c936fba7ea5c118d0f114d1ca99fd69b3800d36

Lines changed: 1 addition & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

node_modules/.cache/terser-webpack-plugin/content-v2/sha512/01/67/308b55bb5829da7e3009fd04abd8310c8f7987f807a8d355c5cddc1ea86c776b83d9b683bd30a62c161d2aae553182dba362e27fe8aff10d9cf99017e596

Lines changed: 1 addition & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

node_modules/.cache/terser-webpack-plugin/content-v2/sha512/02/77/8fc66c6a888cd0c690fe5823083dd25a36fd40ecbb931e0433421024031ffb56fd8222436d0b94f752e9386e438ba931fba3adcd3e008a545eef62214e35

Lines changed: 1 addition & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

node_modules/.cache/terser-webpack-plugin/content-v2/sha512/04/e9/094966155677bb9731c29dc80ebe3daee9c8793f59181e11e082cea2e3555e85225d385f45c0156eb23d512a070fc1eeaafb4a5b369b0faa301f1fe946c5

Lines changed: 1 addition & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

node_modules/.cache/terser-webpack-plugin/content-v2/sha512/05/6b/c0d684062888d90cb16d47e67d5820e90c9e657535e00b1ab00c27136d21db833861da49c442217defaa03d1d6cd4a8a517794c56e8508fc0b0f8f4d7e01

Lines changed: 1 addition & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

node_modules/.cache/terser-webpack-plugin/content-v2/sha512/05/e1/d6d039ed67336ae0d9b262dc1ff0f691946807203f8441de06ec86392a36b6f886adeeec13b5dea1e3f5c7949357ab532a51f4ca3f828327233764e39d4c

Lines changed: 1 addition & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

0 commit comments

Comments
 (0)