面试 on 小盒子的技术分享

昨天面试官问我：一个 Prompt 进入大模型后，内部到底发生了什么？

Fri, 06 Mar 2026 03:44:58 +0000

昨天面试时，面试官抛给我一道很典型的问题：

“描述一下一个请求 prompt 经过 LLM 直到返回结果，这中间的推理过程，越详细越好。”

这类题看起来开放，实际上很考验基本功。

因为它不是在问你会不会背几个名词，而是在看你是否真的理解：

●一个请求在系统里是怎么流动的

●进入模型之后到底算了什么

●为什么大模型是一个 token 一个 token 地往外生成

●为什么会有 prefill、decode、KV cache、sampling 这些概念

●为什么工程侧还要引入 batching、FlashAttention、continuous batching 之类的优化

如果回答得太浅，就会变成泛泛而谈；如果一上来就扎进公式，又很容易失去结构。

我后来复盘了一下，觉得这道题最好的答法，不是“想到哪说到哪”，而是按一条完整链路去讲：服务层怎么处理请求，LLM 内部怎么做前向计算，生成阶段又是如何一步步产出结果的。这也是 GPT-3 所代表的自回归语言模型在推理时的基本工作方式：它不会在一次请求里更新参数，而是在固定权重下做前向传播，并逐 token 预测后续内容

一个高分回答，最好先把整体框架立住

如果让我在面试里先用一句话概括，我会这样回答：

一个 prompt 从输入到输出，大体会经历 6 个阶段：请求封装、tokenization、推理调度、prefill、decode、结果反解码返回。其核心本质是：模型先并行“读懂”整段输入，建立上下文状态和 KV cache，然后再进入自回归生成循环，每次只预测下一个 token。这种“自回归 + 不做本次梯度更新”的推理方式，正是 GPT 类语言模型的基本范式；而 Transformer 则提供了它内部 attention 和前馈网络的计算骨架。

这句话为什么重要？

因为它先把系统层和模型层分开了，也先把prefill和decode分开了。很多人答这道题失分，不是因为不会，而是因为把所有层次混在一起，听起来就没有脉络。

第一阶段：用户输入的 Prompt，并不是模型真正看到的内容

我们在聊天框里看到的是自然语言，但模型真正接收到的，通常不是这段原始文本本身。

在送入模型之前，服务层一般会先把 system、user、assistant 等多轮消息按固定模板组织起来，再补上一些特殊标记。随后，文本会经过 tokenizer，被切成 token 序列。像 OpenAI 开源的 tiktoken 就明确说明，它是一个用于模型的 BPE tokenizer。也就是说，对模型来说，文本首先会被变成一串离散的 token IDs，而不是“句子”本身。

这一层很多人容易忽略，但它很关键。

因为后面所有推理，都是建立在 token 序列上的。你输入的是一句中文、一段英文、还是一段代码，对模型来说，第一步都得先转换成 token IDs。

第二阶段：请求不会立刻进模型，而是先进入推理服务和调度层

在真实工程系统里，一个请求到达后，通常不会马上冲进 GPU 执行。

它往往还要经过一层推理服务框架，比如 TGI、vLLM 这一类系统。它们会负责请求排队、动态 batching、缓存管理、流式返回等工作。Hugging Face 的 TGI 文档明确把 continuous batching、token streaming、Flash Attention、Paged Attention 等列为核心特性；而 Transformers 的 continuous batching 文档也说明，这种动态调度的目的是提高 GPU 利用率、降低延迟，并允许请求在每一步动态加入和退出批次。

所以，从系统视角看，链路通常是这样的：

用户输入 → prompt 模板展开 → tokenization → 请求调度 / batching → 送入模型

这一步的意义在于：

模型推理不是单个请求的“裸跑”，而是和其他请求一起，由推理引擎统一组织和优化的。

我们上一阶段说的 tokenization ，严格来说，不属于 Transformer 前向推理本身，模型只接收 input_ids。但在现代推理服务里，tokenizer 往往和 serving 引擎绑定在一起，所以工程上看起来像是推理引擎在处理原始字符串。像 vLLM 就同时支持 text prompt 和 pre-tokenized prompt，两种模式都能跑。

用户通常把原始字符串发给后端；后端中的推理服务通常持有 tokenizer，先把字符串编码成 token IDs，再交给模型执行 prefill/decode。只有在某些架构下，tokenization 才会提前在客户端或独立预处理层完成。

第三阶段：进入模型后，token 会先变成向量表示

真正进入 LLM 后，第一步不是“开始回答”，而是把 token IDs 映射成高维向量。

这一步叫 embedding lookup。每个 token 都会查一张巨大的 embedding 表，得到自己的向量表示。到这时，模型才真正进入连续空间的数值计算。Transformer 的基础论文《Attention Is All You Need》所定义的，就是这样一种基于 attention 的序列建模方式。

不过只有 token 向量还不够，因为模型还得知道“谁在前、谁在后”。

早期 Transformer 使用位置编码，后来很多大模型会用 RoPE（Rotary Position Embedding）。RoPE 的核心价值，是把位置信息融入 attention 计算中，让模型在处理 token 时同时保留相对位置信息。

第四阶段：真正的“推理核心”发生在一层层 Transformer Block 里

这是这道题最核心的部分。

如果面试官说“越详细越好”，你就必须把 Transformer Block 讲清楚。

一个典型的 decoder-only LLM，每一层大体都会做两件事：

●第一，Self-Attention

●第二，FFN / MLP（前馈网络）

中间再配合残差连接和归一化。Transformer 论文给出的主体结构就是这样。

你可以把它想成：

●attention 负责“读群聊”

●FFN 负责“自己想一想、整理一下”

Self-Attention 在干什么？

可以把它理解成：当前位置的 token，要去看上下文里哪些 token 最相关。

模型会把当前隐藏状态投影成 Query、Key、Value 三组向量，然后通过 Query 和所有 Key 的相似度算出注意力权重，再对 Value 做加权求和。Transformer 论文把它定义为 Scaled Dot-Product Attention。

对于生成式语言模型，还有一个必须强调的点：causal mask。

也就是当前位置只能看见自己和前面的 token，不能偷看未来。这一点决定了模型天然是自回归生成的：它永远只能基于已有上下文，去预测下一个 token。GPT-3 论文里所讨论的 few-shot/in-context learning，本质上也是建立在这种自回归预测机制之上的。

关于 Q、K、V，可以简单这样理解：

Q = 我现在想找什么

K = 每个词身上贴的“索引标签”

V = 每个词真正携带、可被取走的信息。

最通俗的比喻是“图书馆检索”：

你现在脑子里有一个问题，这就是 Q（Query）；书架上每本书卡片上的主题标签，是 K（Key）；书里真正的内容，是 V（Value）。系统先拿你的问题 Q 去和所有标签 K 比一比，看看“像不像、相关不相关”；相关度高的那些书，它们的内容 V 就会被更多地取出来，最后合成当前这一步该看的信息。Transformer 论文对 attention 的定义，本质上就是“一个 query 对一组 key-value 对做匹配，输出是 values 的加权和”。

FFN 又在干什么？

如果说 attention 负责“从上下文搬运信息”，那么 FFN 更像是“对当前位置做进一步加工”。

它不会跨位置交互，而是对每个 token 的表示单独做非线性变换，把特征进一步提纯和增强。Transformer 论文把它称为 position-wise feed-forward network。

所以一个 Transformer Block 可以粗略理解成：

先决定我该关注上下文里的谁，再把取回来的信息做一轮更深的特征变换

注意在整个流程中，prefill 和 decode 阶段，都要做 self-attention 和 FFN。

但要分清楚：“都要做”不等于“做法完全一样”。

●Prefill 把整段 prompt 一次性送进去。这时每一层都会对这批 token 做 masked self-attention，然后再过 FFN。因为整段 prompt 一开始就都已知，所以这一步可以在单个请求内部并行处理很多 token。Hugging Face 对 prefill 的描述也是：prefill 会处理整段输入，并建立 KV cache。

●Decode 开始一个 token 一个 token 往后生成。这时每生成一个新 token，它仍然要在每一层里经过：一次 self-attention，一次 FFN

decode 不是把旧 token 全部再跑一遍 attention 和 FFN。有了 KV cache 后，旧 token 的 K/V 会被缓存起来；新 token 到来时，只需要为这个新 token 计算当前层需要的表示，再和历史 K/V 做注意力计算，然后继续过 FFN。Hugging Face 官方缓存文档明确说了：后续生成时，只传入尚未处理的新 token，并把 key/value 写入和读取自 cache。

FFN 就是 Transformer 每层里、紧跟在 self-attention 后面的前馈网络，本质上是对每个 token 单独做的 MLP 加工。在标准 LLM 里，prefill 和 decode 两个阶段都要经过 self-attention 和 FFN；区别只是 prefill 处理整段已知 token，decode 只处理当前新 token，并复用历史 KV cache

第五阶段：Prefill——先把整段 Prompt “读完”

很多人会误以为模型一进来就开始逐字生成。

其实不是。生成前通常会先有一个很重要的阶段：Prefill。

Prefill 的意思是：

先把整段 prompt 一次性跑完整个前向过程。

在这个阶段，模型会为输入中的所有 token 计算各层隐藏状态，并且生成后面 decode 要用到的 KV cache。Hugging Face 的缓存文档明确指出，KV cache 会把注意力层中之前 token 产生的 key-value 对存下来，后续生成时直接复用，从而避免重复计算。

Prefill 的一个重要特点是：

它通常可以高度并行。

因为整段输入已经完整给定了，GPU 能把很多矩阵操作一起做完。所以 prefill 更像“先整体读题”，吞吐通常更高。vLLM 文档也明确把 prefill 归类为更偏 compute-bound 的阶段

你可以把 prefill 想象成一个正在考试的人，prefill 就是他正在读题，把题目先读到脑子里，填充好上下文，然后再开始做答（输出 token）

第六阶段：KV Cache——为什么不会每次都重算全文

这部分是面试里非常加分的点。

因为它体现你不只懂“算法”，还懂“推理为什么能跑得起来”。

如果没有 KV cache，那么每生成一个新 token，模型都要把整个历史上下文从头再算一遍，成本会非常高。

而有了 KV cache 后，历史 token 在每层 attention 中算出的 K 和 V 都会被缓存起来。下一个时间步只需要为新 token 计算新的 Query、Key、Value，再用新的 Query 去和历史缓存里的 Key 做匹配即可。Hugging Face 的官方文档把这一点解释得很清楚：KV cache 的目标就是消除重复计算，加速自回归生成。

一句话说明就是：

●没有 KV cache，像每次都重读整篇文章

●有 KV cache，则像前文已经做好笔记，现在只补最后一句。

为什么 KV cache 只缓存 K 和 V，而不缓存 Q？

一个东西值不值得缓存，不看它“重不重要”，而看它“后面还会不会再次被用到”。

KV cache 只缓存 K 和 V，不缓存 Q，不是因为 Q 不重要，而是因为 Q “只在当前这一步有用一次”；而 K、V 会在后面每一步继续被反复用到。这正是 Hugging Face 官方对缓存机制的解释：过去 token 的 K 和 V 可以缓存并复用，而在推理时，只需要“最后一个 token 的 query”来计算当前步的表示。

第七阶段：Decode——开始逐 token 生成答案

当 prefill 完成后，模型已经“读懂”了整段输入。

接下来，系统会取最后一个位置的隐藏状态，通过输出层映射成整个词表上的 logits，也就是“下一个 token 的打分”。随后再通过 softmax 和解码策略，决定下一个 token 输出什么。Transformer 的输出逻辑与 Hugging Face 的生成文档都说明了这一点。

这里又有一个容易被问到的点：

下一个 token 是怎么选出来的？

并不是只有“选概率最大”这一种方式。常见解码策略包括 greedy、sampling、top-k、top-p 等。不同策略会影响文本的稳定性、多样性和创造性。Hugging Face 的生成策略文档对此有系统说明。

然后，流程进入一个循环：

●把刚生成的 token 接到上下文后面

●复用 KV cache

●只为这个新 token 跑一遍前向计算

●再得到新的 logits

●再生成下一个 token

这就是为什么你看到的大模型回答，总是一个 token 一个 token 流式地吐出来，而不是整段瞬间出现。

为什么“第一个字慢，后面快”？

这也是一个非常像面试 follow-up 的问题。

很多候选人知道 prefill 和 decode，但解释不清为什么两者速度特征不同。

vLLM 的优化文档明确提到，prefill 更偏 compute-bound，decode 更偏 memory-bound。

原因在于：prefill 可以把整段输入并行做大矩阵乘法，吃满 GPU 算力；而 decode 虽然每步只算一个 token，但它强依赖历史 KV cache，频繁访问显存，并且步骤之间有严格的顺序依赖。

这也是为什么工程上会有很多针对推理性能的优化，比如：

●FlashAttention：通过 IO-aware 的 attention 计算方式，减少显存读写

●continuous batching：动态调整批次，减少 GPU 空转

●chunked prefill / Paged Attention：改进长上下文和缓存管理效率

要注意，这些技术优化的是执行效率，不是模型的“语义本质”。模型本质上做的事情仍然是：基于已有上下文，反复预测下一个 token

我现在觉得，这道题最稳妥的回答方式，就是最后收束成一句话：

一个 LLM 请求的推理过程，本质上是：先把 prompt 模板化并 token 化，经由推理服务调度进入 GPU；模型通过 embedding 和多层 Transformer block 并行完成 prefill，建立上下文表示和 KV cache；随后进入 decode 循环，基于历史缓存逐 token 执行注意力、前馈网络和采样，直到生成结束，再把 token 序列反解码成文本返回。这条链路同时体现了 Transformer 的计算机制、自回归生成范式，以及现代推理系统在 batching、缓存和 attention kernel 上的工程优化

看起来都是推理引擎的活儿啊？

从整个流程上看，几乎都是推理引擎在负责，所以可以这么理解，但要再往前走半步：

●从“流程编排”角度看，LLM 本体确实很被动；

●从“核心计算与语义生成”角度看，LLM 才是全链路里最不可替代的部分。

如果把整个链路拆开，职责大致是这样的：

1.推理引擎 / serving 系统负责：接 HTTP 请求、做 tokenization / 输入处理、调度 batching、管理 KV cache、协调 GPU worker、流式返回结果、做一部分采样与系统优化。vLLM 的官方文档甚至把这几层写得很直白：最少会有 1 个 API server 负责 HTTP、tokenization 和输入处理，1 个 engine core 负责 scheduler 和 KV cache 管理，再加上 N 个 GPU worker 负责执行模型前向计算。

2.LLM 模型本体负责：对 input_ids 做 embedding，经过多层 Transformer block 的 self-attention 和 feed-forward network，输出 logits，也就是“下一个 token 的分数分布”。Transformer 论文给出的核心结构就是 attention + FFN；Transformers 文档也明确说 causal language modeling 本质上是在左侧上下文条件下做 next-token prediction，而模型输出里的 logits 是对词表中每个 token 的预测分数。

所以，**推理引擎决定“怎么高效地跑”，模型决定“到底生成什么”。**前者偏“编排与优化”，后者偏“语义计算与内容生成”

面试必问：ACID 你真的懂了吗？

Wed, 19 Feb 2025 07:45:55 +0000

ACID 是什么？

事务处理中的 ACID 是确保数据库操作可靠性和完整性的四个核心特性

属性	说明	示例
原子性（Atomicity）	事务是不可分割的最小操作单元，事务中的所有操作要么全部成功完成，要么全部失败回滚。	`用户在线购买书籍时的支付流程：`
①支付扣款 ②库存扣减 ③快递下单三个步骤必须全部成功——任一步骤失败时（如库存不足），系统自动取消已付金额，退回到购物未进行状态。
一致性（Consistency）	事务必须保证数据库从一个一致性状态转变到另一个一致性状态。一致性是指数据必须符合预定义的规则和约束，例如完整性约束、业务规则等。	`银行转账场景：`
账户A向账户B转200元后，两人账户总额保持不变（若A+B原为1000元，操作完成后仍为1000）。即便系统中途崩溃，恢复后也不会出现A扣200元但B未入账的金额"凭空消失"。
隔离性（Isolation）	多个事务并发执行时，每个事务都应该感觉不到其他事务的存在，就像在隔离的环境中执行一样。事务之间互相隔离，不会互相影响。	`航班订座系统：`
当乘客A和B同时选择最后一个座位，先完成支付者的订单立即锁定座位，另一用户将实时看到"无余票"提示——避免出现系统误判导致超售。
持久性（Durability）	一旦事务提交成功，对数据库的修改就应该是永久性的，即使系统发生崩溃或重启等意外情况，数据也不会丢失。	`线上预约挂号确认：`
用户成功提交预约后，即便医院服务器遭遇断电，重启后系统依然保留该条预约记录并发送确认短信，不会因突发意外丢失数据。

MySQL 是如何保证 ACID 的？

MySQL 实现 ACID 特性主要依赖日志系统（undo log 和 redo log）、锁机制和 MVCC 多版本并发控制。下面是具体实现原理的详细分析：

一、Atomicity（原子性）

事务是不可分割的最小执行单位。原子性确保事务中的所有操作要么全部成功完成，要么全部失败回滚。不允许中间状态。MySQL 通过 Undo Log + 事务回滚 实现原子性：

当事务开始时，InnoDB 会记录事务修改前的数据（旧版本）到 Undo Log 中，用于事务回滚时恢复原始状态。

Undo Log 记录结构包含：原始数据值、事务ID（trx_id）、回滚指针（roll_pointer）。

Undo Log 记录的是逻辑操作，例如 “删除第 10 行”，“将字段 ’name’ 从 ‘old’ 更新为 ’new’” 等。

举个简单例子：

1-- 事务未提交时，其他事务通过Undo Log读取原始数据（MVCC）
2BEGIN;
3UPDATE accounts SET balance = balance - 100 WHERE id = 1;
4-- 此时Undo Log会记录balance的旧值（如200）
5ROLLBACK; -- 使用Undo Log恢复数据

如果事务执行过程中发生错误或者用户显式执行 ROLLBACK，InnoDB 可以根据 Undo Log 中的记录将数据恢复到事务开始之前的状态，从而实现事务的回滚

二、Isolation（隔离性）

隔离性 (Isolation) 是 ACID 特性中的关键一环，它确保在多个事务并发执行时，每个事务都仿佛独立运行，互不干扰。换句话说，一个事务的中间状态和操作不应该被其他并发事务感知到，从而避免数据混乱和不一致。为了实现这种隔离效果，MySQL 的 InnoDB 存储引擎主要依赖于两大核心机制：锁机制 (Locking) 和 多版本并发控制 (MVCC)

1. 锁机制

首先，锁机制是最基础的隔离手段。InnoDB 实现了多种锁类型，以适应不同的并发场景和隔离需求。其中，行级锁 是 InnoDB 并发控制的核心，它允许事务仅锁定需要修改的数据行，最大程度地提高了并发度。行级锁又细分为 共享锁 (S 锁) 和 排他锁 (X 锁)，前者允许多个事务同时读取同一行数据，而后者则保证在更新或删除数据时，只有一个事务可以独占该行。

除了行级锁，MySQL 还提供 表级锁，它会锁定整个表，虽然并发度较低，但在某些特定场景（如执行 LOCK TABLES 语句）下仍然适用。

为了更高效地管理锁，InnoDB 引入了 意向锁 (Intention Locks)，它在表级别上预先声明事务对行级锁的意图，从而优化锁的检查和兼容性。

此外，在 REPEATABLE READ 和 SERIALIZABLE 这两个较高的隔离级别下，为了解决幻读问题，InnoDB 还使用了 间隙锁 (Gap Locking)，它不仅锁定已存在的记录，还锁定索引记录之间的间隙，防止其他事务在该间隙中插入新记录，从而彻底避免幻读。

我们通过一个具体的例子来说明 InnoDB 的间隙锁（Gap Locking）如何解决幻读问题：

假设有一张表 students，存储学生信息，主键为 id，当前数据如下：

id	name
1	Alice
3	Bob
5	Charlie

现在有两个事务 事务A 和 事务A，操作顺序如下：

事务A 执行范围查询并加锁：
```
1BEGIN;
2SELECT * FROM students WHERE id BETWEEN 1 AND 5 FOR UPDATE;
3-- 查询结果：id=1, 3, 5
```
InnoDB 会为 id 索引加上 Next-Key Lock（行锁 + 间隙锁），锁定的范围包括：

(-∞, 1]
(1, 3]
(3, 5]
(5, +∞) （注：假设表中无其他数据）

事务B 尝试插入新数据：

1BEGIN;
2INSERT INTO students (id, name) VALUES (2, 'David'); -- 尝试插入到间隙 (1,3)
3-- 或者
4INSERT INTO students (id, name) VALUES (4, 'Eve'); -- 尝试插入到间隙 (3,5)

由于 事务A 的间隙锁锁定了 (1,3) 和 (3,5) 的间隙，事务B 的插入操作会被阻塞，直到 事务A 提交或回滚。

事务A 提交：
```
1COMMIT;
```
事务B 的插入操作才会继续执行。

结果对比

没有间隙锁：若事务A未加间隙锁（例如使用 READ COMMITTED 隔离级别），事务B可以插入 id=2 或 id=4。当事务A再次执行 SELECT 时，会看到新插入的行（id=2 或 4），导致幻读。
有间隙锁：事务B的插入操作被阻塞，直到事务A释放锁。事务A在事务执行期间始终看到相同的数据（id=1,3,5），避免幻读。

关键点

间隙锁的锁定范围： InnoDB 的间隙锁不仅锁定已存在的行，还会锁定索引记录之间的“间隙”（例如 (1,3) 和 (3,5)），阻止其他事务在间隙中插入新数据。
Next-Key Lock 的作用： Next-Key Lock = 行锁（锁定已存在记录） + 间隙锁（锁定间隙）。例如，对 id=3 的行锁会锁定范围 (1,3]。
隔离级别的影响：间隙锁仅在 REPEATABLE READ 隔离级别下生效。在 READ COMMITTED 级别下，InnoDB 会禁用间隙锁，幻读仍可能发生。

在实际场景中，比如在电商系统中，若一个事务正在统计某商品（例如库存范围在 100~200）的订单数量，间隙锁可以防止其他事务插入新的订单记录（例如库存为 150 的商品），确保统计结果的一致性。

2. MVCC

为了进一步提升并发性能，尤其是在读多写少的场景下，InnoDB 引入了 多版本并发控制 (MVCC)。 MVCC 的核心思想是允许事务在读取数据时，访问数据在某个时间点的快照版本，而不是直接读取最新的数据。 这样，读操作就不需要等待写操作完成，从而实现读写并发执行，显著提高了系统吞吐量。 MVCC 的实现依赖于 Undo Log 和 Read View (快照读)。 Undo Log 用于记录数据的历史版本，而 Read View 则定义了事务在读取数据时应该看到哪个版本的数据。MVCC 主要应用于 READ COMMITTED 和 REPEATABLE READ 这两个隔离级别，在这两个级别下，MVCC 可以有效减少锁的竞争，提升并发性能。

总结来说：MVCC 就是基于隐藏字段、undo_log 链和 ReadView 来实现的

3. 隔离级别与策略对比

最后，为了满足不同应用场景对隔离程度和性能的不同需求，MySQL 提供了四种事务隔离级别。从最低的 READ UNCOMMITTED (读未提交) 到最高的 SERIALIZABLE (串行化)，隔离级别依次增强，但并发性能也随之降低。

READ UNCOMMITTED 允许脏读，隔离性最弱，但性能最高；
READ COMMITTED 避免了脏读，但可能出现不可重复读；
REPEATABLE READ (InnoDB 默认级别) 在 READ COMMITTED 的基础上解决了不可重复读，但仍可能存在幻读（在某些情况下，InnoDB 通过 Next-Key Locking 尝试解决幻读）；
SERIALIZABLE 通过强制事务串行执行，彻底避免了所有并发问题，但并发性能也最低。

隔离级别	脏读	不可重复读	幻读	实现方式
READ UNCOMMITTED	✔️	✔️	✔️	无锁
READ COMMITTED	✖️	✔️	✔️	每个SELECT生成新Read View
REPEATABLE READ*	✖️	✖️	✖️△	首SELECT生成Read View + 间隙锁
SERIALIZABLE	✖️	✖️	✖️	所有SELECT隐式转成`SELECT ... FOR UPDATE`

△：MySQL通过Next-Key Lock（行锁+间隙锁组合）在REPEATABLE READ级别实际消除幻读。

三、Durability（持久性）

持久性 (Durability) 是 ACID 特性中保障数据安全性的最后一道防线。它确保一旦事务成功提交，对数据库所做的所有更改都必须被永久地保存下来，即使系统随后发生崩溃、断电或任何其他类型的故障，已提交的数据也绝不会丢失。为了实现这种强大的数据保障，MySQL 的 InnoDB 存储引擎采用了一系列精密的机制，其中最核心的是 Redo Log (重做日志)，并辅以 Write-Ahead Logging (WAL) 策略、 Doublewrite Buffer (双写缓冲区) 和灵活的刷盘 (Flush to Disk) 机制，同时，Binlog (二进制日志) 也从更广泛的层面为数据持久性提供了支持。

首先，Redo Log 是 InnoDB 实现持久性的基石。当一个事务执行过程中，InnoDB 并不会立即将数据页的修改直接写入磁盘上的数据文件，而是先将这些修改操作，例如插入、更新或删除的具体内容，以一种紧凑、高效的形式，顺序地记录到 Redo Log Buffer 中。这里的 Redo Log 记录的是物理层面的修改，例如“将数据页 X 的偏移量 Y 处的 Z 个字节修改为新的值”。为了保证效率，Redo Log Buffer 存在于内存中，但为了确保持久性，InnoDB 会定期或者在事务提交时，将 Redo Log Buffer 中的内容刷新到 Redo Log 文件这一磁盘上的持久化存储。

为了进一步确保数据在极端情况下的安全性，InnoDB 遵循 Write-Ahead Logging (WAL) 预写式日志策略。这意味着，在任何数据页的实际修改被写入磁盘数据文件之前，必须先将相应的 Redo Log 记录落盘到 Redo Log 文件中。这种 “先写日志，后写数据” 的机制至关重要，它保证了即使在数据页尚未完全刷入磁盘时系统发生崩溃，已经提交的事务的所有修改操作也已经安全地记录在 Redo Log 中，从而为后续的数据恢复提供了保障。

Doublewrite Buffer (双写缓冲区) 是 InnoDB 为了应对数据页“部分写失效 (Partial Write)” 问题而引入的增强机制。在数据页从内存刷新到磁盘数据文件的过程中，可能会因为断电等意外情况，导致数据页只写入了一部分，造成数据损坏。为了避免这种情况，InnoDB 在数据页最终写入数据文件之前，会先将其完整地写入 Doublewrite Buffer 区域。 Doublewrite Buffer 是磁盘上一个连续的存储区域，InnoDB 会先顺序写入，保证写入的原子性。之后，再将数据页从 Doublewrite Buffer 拷贝到真正的数据文件位置。这样，即使在数据页写入过程中发生崩溃，InnoDB 在重启恢复时，可以通过 Doublewrite Buffer 检查数据页的完整性。如果发现数据页写入不完整或已损坏，可以从 Doublewrite Buffer 中找到该数据页的完整副本进行恢复，从而有效地避免了数据页部分写入导致的数据丢失。

Flush to Disk 机制则提供了对 Redo Log 和数据页刷盘行为的精细控制。 MySQL 提供了多个参数，例如 innodb_flush_log_at_trx_commit 参数控制 Redo Log 何时刷盘，可以设置为每次事务提交都刷盘 (最安全，但性能较低)，或者定期刷盘 (性能较高，但可能在崩溃时丢失少量已提交事务)。 innodb_flush_method 参数则控制数据页刷盘的具体方式，例如是否绕过操作系统缓存直接写入磁盘，以满足不同的性能和可靠性需求。通过调整这些刷盘策略，用户可以在数据安全性和性能之间进行权衡，根据实际业务场景选择合适的配置。

最后，虽然 Binlog (二进制日志) 的主要用途是用于数据库的主从复制和时间点恢复，但它也间接地为数据持久性做出了贡献。 Binlog 记录了数据库中所有的数据变更操作 (逻辑操作，例如 SQL 语句)，这些日志可以用于数据库的备份和恢复，特别是当需要进行全量或增量备份，或者需要恢复到某个特定的时间点时，Binlog 就显得至关重要。虽然 Binlog 的关注点和 Redo Log 略有不同 (Redo Log 侧重于崩溃恢复，Binlog 侧重于时间点恢复和复制)，但它们都为确保数据的长期安全性和可恢复性提供了重要的支持。

总结来说：MySQL InnoDB 通过 Redo Log + WAL 策略保障事务提交的修改能够被可靠地记录下来， Doublewrite Buffer 增强了数据页写入的可靠性，Flush to Disk 机制提供了灵活的刷盘控制，而 Binlog 则从更广泛的层面支持数据备份和时间点恢复。这些机制相互配合，共同构建了持久性保障体系。

四、Consistency（一致性）

事务必须保证数据库从一个一致性状态转变到另一个一致性状态。一致性是指数据库的完整性约束没有被破坏。例如，主键唯一性、外键约束、CHECK 约束等。

约束 (Constraints): MySQL 支持各种约束，如主键 (PRIMARY KEY)、外键 (FOREIGN KEY)、唯一键 (UNIQUE)、非空 (NOT NULL)、检查约束 (CHECK) 等。这些约束在数据写入时被强制执行，确保数据满足预定义的规则。
触发器 (Triggers): 触发器是与表关联的存储程序，在特定事件 (如 INSERT、UPDATE、DELETE) 发生时自动执行。触发器可以用于实现更复杂的业务规则和一致性检查。
应用程序逻辑: 虽然 MySQL 提供了约束和触发器，但最终的数据一致性也需要应用程序逻辑来保证。例如，业务逻辑需要确保事务操作符合业务规则，才能维持数据库的一致性状态。

其实对于一致性来说，它是其他三者（原子性、隔离性、持久性）的综合结果，辅以数据库约束和应用校验来共同保障最终一致性。

总结

MySQL通过以下核心机制实现ACID：

ACID特性	核心机制	关键组件
原子性	Undo Log + 事务状态管理	Undo Log、事务控制块
一致性	约束 + ACID协同	主键、外键、触发器
隔离性	MVCC + 锁 + Next-Key Locks	Read View、行锁、间隙锁
持久性	Redo Log + Doublewrite Buffer	Redo Log、双写缓冲区

我们经常说的最终一致性是其他三个特性协同作用的结果，而非独立机制。当你理解了这些底层原理将会有助于优化事务设计（如合理选择隔离级别）和故障排查（如分析锁冲突）。

面试时的那些潜台词

Thu, 21 Nov 2024 08:27:34 +0000

其实从你与 HR 的第一次沟通开始就已经处在面试周期了，而不是约了正式面试才开始。这期间对方问的每一个问题，说的每一句话都有他的目的，这个我想大家都知道。

本文我特想说说面试中那些我知道的和我不太确定的面试 “潜台词”

HR 篇

第一种是双方都明白的，只是说法不一样，含蓄的表达或意会的，目的是给双方留面子，都是社会人没必要说的太直白。
第二种是直接问的，目的是高效过滤简历

这两种常见于跟 HR 的初次沟通中。

直接问的

比如：

学历（“是全日制本科吗？” 、“是 985 211 院校吗？”）
在职状态（“目前离职了吗？”）
离职原因（“离职的原因是什么？”）
婚育状态（“您成家了吗？”）
期望薪资 (“您的期望薪资是多少？”)
目前薪资 (“您目前的薪资是多少？”)
公司位置（“我们公司在 xxx ，这个位置您对接受吗？”）
工作性质（“我们公司是外派到 xxx 的项目，您接受外派吗？”）
…

你看得出来，这些直接问的都是一些基本情况，能问你就证明你的简历基本上入人家眼了，不然都不会浪费时间问。这里我要强调的是 HR 问你问题，你也要问他们，什么社保、公积金基数、总包多少，有没有年终奖，该问问，别不好意思，出来打工不是图钱，难道为爱发电吗？

尤其对于刚入职场的小白来说，别不好意思，不然坑的就是你，因为有的公司会故意隐瞒一些坑，到时候坑的是自己。另外，初步沟通以后，立即去 “脉脉”、 “天眼查” 、“企查查” 这些平台查询公司相关信息，这很重要，从真实的员工那儿知道公司的情况（有没有裁员、有没有欠薪、有没有加班、有没有别的坑），从工商信息那儿查看公司的规模、投融资情况、有没有劳动争议官司、什么时候成立的、给多少人交着社保、业务范围什么的。

这几个平台你看一圈儿以后心里就对将要面试的公司有个基本的判断了，如果你判断出一些问题，或者你比较犹豫，作为过来人我告诉你，不必浪费时间，直接 Pass 是最优解。

不直接问的

到这里我们就要扣题了，因为潜台词要出现了。

**您住在哪里呀？**潜台词：根据你住的远近，判断你对公司的意向是否强烈。如果你住的比较远很可能会有第二个问题：“您是在那里买房了吗？”，潜台词是：首先判断你是租房还是买房，如果买房通勤太远你的意向就可能会有问题，如果租房还好。其次判断你的经济实力。
当你约好了面试，去现场时，HR 接你的时候可能会问：“您是怎么过来的呀？过来远吗？” 潜台词是：首先跟第一点类似，根据你到公司的距离判断你的意向，其次判断你的经济实力，因为你可能是开车来的，也可能是坐公交地铁来的。可能你会问面个试为什么要判断经济实力？当然是为了拿捏你了，总之软肋越少越不好被拿捏。出来混，面子是自己给的，该怎么说，不用我教你吧。哈哈
如果你做过技术管理工作可能会被问：“您在最近 2 年的工作中，技术和管理的时间占比是多少？” 潜台词：他们想找个带过人，但一直在一线写代码的。不过这个占比如何回答好，我还真拿不准，因为管理的团队越大越会多花精力和时间，不可能我只用一成的时间管理个 50 人的团队，然后再用 9 成的时间写代码，这太极端了，要么会管理的太差，要么就是管理的太好。说白了，他们是想要个纯写代码的牛马，你判断是否愿意干就知道怎么回答了。
…

不回答或晚回答

这种一般出现在你面试结束后长时间没有消息，面的好的话，一般情况下会比较快的通知你下面的流程。这种情况无论 HR 怎么说，大概率是以下两种情况：

面的不好，但那边懒得理你了
面的还行，但那边在犹豫，至于犹豫的点是什么你不用关心（那可多了），是不是有备胎什么的你也不用多想，总之是犹豫。

所以，不回答或晚回答的话，因为有可能还有机会，如果确实挺在乎结果，强迫症想有个闭环的，是可以直接问 HR 的，多问没关系的，成了将来是同事，多打打交道不好吗？不成了以后谁认识谁呀，别有心理压力。

还有，在不回答或晚回答的情况下，HR 有可能会用话术拖着你，别太当真，别太上心，别给他脸，该干啥干啥，心态渣一点儿，没坏处。

女性问题

我是男的，但我知道这个职场对于女性不那么友好，女性可能会面临更多的 “问题”，而有些问题我都没法用潜台词来形容，那是赤果果的歧视。这里我就不展开了，我想说的是职场女性很不容易，而很多 HR 也是女性，希望更多的 “人事” 干点儿人事儿！ ，不然多荒诞啊。

古典派

在面试前就问你很多过去经历、每段工作的离职原因、职业规划等的 HR 都比较古典，问的太多啦，他们无非还是想判断你的 稳定性 看看是不是一只合格的牛马而已。但这种现在也很少了，效率越高的公司越没有这种古典派的，都是激进派的，甚至直接让用人部门自己约人面试，他们最后只负责谈钱。

谈钱

到了谈钱这步，说明前面的面试你都顺利通过了，这是最后一关，但谈崩的可能性也是很大的。

这里要注意的是：无论拿你的过去说你什么，都是一个目的：压价。很多人明白，但我想提醒大家一点的是：不要认真对待别人带有目的性的否定。 你是怎么样的你要客观地评价自己，不能只通过一个 HR、一次面试、一个公司就决定了。再说了，人是会在发展中变化的，也许 2 年以后的你他们根本就高攀不起。

遇到那种谈钱压价不痛快的是挺糟心的，但遇到那种痛快的，也要留心。痛快也是有原因的，可能的情况有：

上一个人刚走，得赶紧找人填坑或背锅
你要少了，怕你反悔，赶紧定
说的数是假的，骗你的，比如压根没有年终奖，然后承诺你有三个月
你太合适了，赶紧定你，怕你不选他家（这种看对眼的情况也是有的，但不多）

技术篇

有关技术面试的问题就很多了，虽然比较专业但仍然有许多潜台词，挑着说几个。

算法

一般不会上来直接考查算法，现在有许多公司把这个当做面试流程的一个必要环节了。一般情况下不会故意难为候选人，但如果出现比较罕见的题目或者 hard ，那么潜台词是：“劝退” 他可能已经不想要你了，但他需要一个非常合理的理由，出一个很难的题，你答不上来，看起来就很合理。

经历

以往工作经历中解决的最困难的问题是什么？

这个问题其实是一个信号，你只要记住，听到这个问题开始吹牛逼就行了。

为什么？就不能实话实说吗？

因为，他们期待听到的，就是吹牛逼的内容。

一般来说，只要问题解决了，你就不觉得它有多困难了，谦虚的程序员们也不觉得是解决了多难的问题，所谓 “难者不会，会者不难”。而且，这个行业有那么多的从业者，有多少人真正接触过非常困难和有技术含量的问题呢？就算是参与过也不是一两个人的功劳，那是团队的功劳，再说了，如果问题只有你能解决，别人解决不了，或接触不到，那么公司一定不愿意看到这种情况出现，他们想的是每个岗位的人都不能有不可替代性，这样才好拿捏你。

当然了，吹牛逼也要有技巧，结合你的工作经历把故事说圆基本就及格了。

八股

就我观察，好的面试官问八股的趋势是越来越少了。一般是为了暖场或者为一些其他问题做准备而铺垫，所以如果你听到那种没有后续的比较纯的八股，那么很有可能这个面试官比较水，进而可以判断出这个公司可能也比较水。

然而还有更水的，在八股上跟你特别较真的，这种你就要小心了，因为回答对或者错都很正常，每个人都有知识盲区，正常的面试官听到答案心里有数就行了，一般不会跟你较真。这种在八股上特别较真的，很有可能不会面试，也问不出什么好问题，公司派这么个人当面试官，你猜这个公司怎么样？

补充一下，我说的较真不是说，你回答错了，他纠正你，那叫点拨，你应该感谢人家。我说的较真是他可能只知道问题的一种解决方案，但却一直否定你给的其他方案。或者他根本就是说错了，但一直坚持自己是对的。再或者，他是对的，但却以别人不知道的八股为荣，进而表示出瞧不起你的态度。注意，我们这里讨论的是八股，面试官和候选人之间的交流，达自己的目的就可以了，这破玩意儿有什么可较真的呢？同样，你如果碰到这样的面试官，心里要清楚你的目的是什么，没必要跟这种人起什么争执。面的不好，也不要放在心上，换个公司再来一次就好了。

聊聊项目

一般会根据你简历中写的项目经验让你描述一下做的具体工作。这里面其实有个潜台词，就是：你不能说的太宏观，也不能讲的太微观

什么意思呢？

如果你做过架构师或技术总监这种全局类的工作，很有可能会从全局角度把项目描述得比较抽象和简单，这不是说你说的不对，而是说你要照顾一下人家想听什么，他们想听什么呢？说白了就是：你到底是不是真的做过，跟他们的工作内容是否贴合，当然能力越强越好，最好解决了他们遇到且没解决过的问题。那怎么体现呢？两个字：“细节” 。在你宏观伟大的项目描述中适当加入一些细节和一些一下子就能把对方拉进具体场景的关键词，这样显得既高大上又细节满满。这样的回答就比较稳了。不会让人觉得只是夸夸其谈。

如果你平常做的比较多的是具体的执行工作，比如按照需求研发功能什么的，那么你要讲项目时要注意适当的拔高一些，在细节工作基础之上稍微上上价值，上升到架构、设计、解决方案的角度，具体怎么说要结合你的具体情况。这样就会觉得你做的比较有价值，而且还显得比较有深度、有思考、有潜力。

其他

其实有关面试还有很多好玩儿的事情，和背后可能蕴含的潜台词，等我找个机会再跟大家唠唠，今天先这样，哈哈。如果关于这个话题你也有想分享的可以在评论区跟大家分享分享，可能你的一句话会帮助到很多朋友。

程序员必备：最直观的数据结构图文手册

Tue, 19 Nov 2024 03:47:23 +0000

这篇文章为了方便以可视化的方式回顾那些最常用的数据结构，你可以用它做面试准备时的复习。希望这些可视化例子能够帮助大家了解这些数据结构。

大 O –时间复杂度

为什么大 O 复杂度很重要？：对于小数据集，算法复杂度可能不会扮演非常重要的角色，但随着我们的数据量增大——算法的性能影响对响应时间有极大的影响。因此，关注复杂度在具有合理规模的任何应用领域中对于程序质量都起着至关重要的作用。

举个例子：

假设我们的数据集有 100 万（1,000,000）个元素

O(1)算法将进行 1 次操作。
O(log(n))算法将进行 20 次操作
O(n)算法将进行 1000000 次操作。
O(n * log(n))算法将进行 2000 万次操作。
O(n 2 )算法将进行 1 万亿次（1,000,000,000,000）操作。

所以，你应该能看出算法复杂度的重要性。

RUM 权衡

另一个在选择数据结构时需要注意的重要方面是 RUM 权衡

读取效率（R）：从数据结构中检索或访问数据有多快。
更新效率（U）：在数据结构中插入、删除或修改数据有多快。
内存效率（M）：数据结构使用的内存或空间大小。

那些最常用且重要的数据结构

数组 & 链表

数组在内存中连续存储，以快速查找而闻名，但更新/写入时间较慢；而链表非连续存储，以快速更新/写入而闻名，但查找较慢

队列

线性数据结构，遵循先进先出（FIFO）原则：

堆栈

遵循后进先出（LIFO）原则，元素从顶部添加和移除：

哈希表

提供几乎即时的元素访问，通过使用哈希函数创建键值对来实现。插入、删除和查找的时间复杂度为 O(1)，代价是内存利用率

树形数据结构

树形数据结构常用于数据密集型应用。

在列出所有数据结构之前，我们首先需要回顾一个在树结构中起着关键作用的算法——二分查找算法。

二分查找

这是一个对排序元素的搜索，通过不断将搜索空间分成一半来完成。就像在字典中找到中间页面，检查我们的搜索词是在字典的左半部分还是右半部分，然后不断重复这个过程，直到找到元素。使用高效的 O(log(n)) 查找

二叉搜索树

一棵二叉树，其中每个节点最多有两个子节点，且左子节点的值小于父节点，右子节点的值大于父节点。如果二叉搜索树平衡（位于左边的节点数量不超过右边的节点数量很多），则可以进行高效的 O(log(n)) 查找。这是因为我们在遍历树时（从父节点到子节点）将搜索空间减半

红黑树

二叉搜索树通过将节点分配颜色（红色或黑色）并遵循一组确保其保持平衡的规则来维护其平衡：

AVL 树

“

AVL 树的全称是 Adelson-Velsky and Landis Tree，以其发明者 G. M. Adelson-Velsky 和 E. M. Landis 的名字命名。

自平衡二叉搜索树，通过确保其平衡因子（所有左子树和右子树之间的高度差）至多为 1 来实现平衡。在插入和删除操作期间通过旋转自动重新平衡

堆

树中每个父节点要么大于等于（最大堆）其子节点，要么小于等于（最小堆）其子节点。允许高效检索最小或最大值，常用于实现优先队列。

跳表

跳表（Skip List）是链表的一种扩展结构，通过引入多级链表来加速查找、插入和删除操作。它的工作原理是允许通过“跳跃”多个链表元素来快速定位到目标节点，这通常是通过从父级链表向下遍历到合适的子级链表来实现的。这种结构类似于二叉搜索树，但具有一定的随机性，通常在效率和简单性上都有不错的表现。

B+ 树

常用于数据库存储。B+树是一种平衡树，其中所有数据都存储在叶节点中，这些叶节点按顺序链接在一起，以便快速顺序访问：

LSM（Log-Structured Merge）树

数据应用中常用的写优化树，为了理解 LSM 树，我们需要熟悉另外两种数据结构：Memtables（内存表）和 SSTables（排序字符串表）。

Memtable

最初，数据被写入一个称为 Memtable 的内存结构中。这个 Memtable 在内存中保存数据，直到达到一定大小，通常通过使用平衡搜索树（如红黑树）、跳表或哈希表来实现，以提供高效的读取访问。当 Memtable 满时，其内容会被写入磁盘作为新的 SSTable。这个过程称为刷新。

SSTable

SSTables 根据键的顺序存储数据。每个 SSTable 由一系列键值对组成，其中键是有序的。一旦创建 SSTable，它就不会被修改。相反，新的数据更新会写入新的 SSTable。

SSTables 通常使用 Bloom 过滤器、稀疏索引等辅助数据结构来快速确定键是否存在于 SSTable 中或定位值。

随着时间的推移，由于频繁更新，可能会创建多个 SSTables。为了优化性能和回收空间，SSTables 会定期合并和压缩。这涉及到将多个 SSTables 中的数据合并成更少的新的 SSTables，同时丢弃过时的条目。

下图是 LSM treee 的一个完整结构：

注意：LSM-tree 不是一种数据结构，是数据组织的一种方式

二叉索引树/斐波那契树

一种紧凑且高效的数据结构，用于处理动态累积频率表或前缀和。换句话说，它非常适合用于区间查询。

树结构存储在一个数组中，其中数组中每个 2 的幂次方索引位置保存其之前所有元素的累积和。举个例子，第 4 个元素（值为 22）存储的是前 4 个元素的和。为了获取树中每个区间的子数组和，我们使用位移操作，使得每次更新和读取的时间复杂度减少到对数级别 O(log(n))，从而提高区间查询的效率。

图数据结构

邻接表与邻接矩阵图表示

一个邻接表将图表示为一系列列表的集合——每个节点都有一个与之相连的节点集合。

邻接矩阵将图表示为一个二维矩阵。如果我们的图有 N 个节点，我们将有一个 N×N 的矩阵，其中每个单元格(i, j)表示顶点 i 和顶点 j 之间是否存在边。

示例图:

字符串搜索数据结构

Trie（字典树）

trie 是一种树形数据结构，用于高效地搜索字符串，其中每个节点代表一个字符，具有包括快速基于前缀的查询和插入等优势。

Radix Tree

它也可以被视为一个紧凑的 Trie。尽管 Trie 很棒，但它们可能会占用大量内存。Redix 树通过合并具有公共前缀的节点来解决这个问题

Splay Tree

伸展树是一种在数据访问频率不均时具有优秀性能的二叉搜索树。树在查找、插入和删除操作后自动调整。在树中访问一个项目后，树会重新排列，使访问的项目移动到顶部（根）。这使得对该项目的未来访问更快。伸展树在缓存中特别有用。

Quadtree

四叉树是一种空间数据结构，它递归地将二维空间划分为四个象限，使其在管理和查询如点或区域等空间数据时非常高效。如果一个节点包含太多点，它将被细分为四个子节点。四叉树通常用于处理碰撞检测。

KD Tree

一棵二叉树，其中每个节点代表 k 维空间中的一个点。该树通过递归地在其中一个维度上分割空间来构建。在树的每一层，数据根据一个维度进行分割，后续的每一层交替使用维度。这使得它在范围查询和最近邻搜索中非常高效。

R-Tree

R 树是一种用于高效索引多维空间数据的树形数据结构。它们将数据组织成最小边界矩形（MBR），这些矩形按层次分组，每个节点的 MBR 包含其子节点的 MBR。

其他数据结构及图

布隆过滤器

布隆过滤器是一种空间高效的概率数据结构，用于测试一个元素是否是集合的成员，通常用于减少对不存在的键的昂贵磁盘（或网络）查找。它可以产生假阳性（报告元素在集合中而实际上不在），但永远不会产生假阴性（如果元素实际上在集合中，它永远不会错误地报告元素不在集合中）。

它使用位数组来存储数据。为了将一个键映射到适当的位，它使用多个独立的哈希函数，每个函数将键映射到位数组中的不同位位置。

二叉堆

二叉堆是一种高效管理元素集合的数据结构，支持快速插入、最小元素提取和堆合并。当需要处理频繁执行这些操作的动态元素集合时，它特别有用

二叉堆由一系列二叉树组成，这些树是相互链接的特殊树

二项式树（0 至 3 阶）：

每个堆中的二叉树都遵循最小堆属性：节点的键值大于或等于其父节点的键值。此外，每个顺序只能有一个或零个二叉树，包括零阶。

以下示例二叉堆包含 13 个节点：

二叉堆在实现优先队列等场景中很有用，在这些场景中，需要频繁地合并堆或对一组元素执行其他操作。

Hash Array Mapped Trie (HAMT)

HAMT 是一种结合了哈希表和 Trie 的优点，用于高效存储和检索键值对的数据结构。它在计算机科学中常用于实现关联数组或字典。在 HAMT 中，键被哈希以确定其在数组中的存储位置，该数组称为哈希数组。哈希数组中的每个条目可以存储多个键值对，从而实现高效的内存利用。如果多个键哈希到相同的数组索引，则使用类似 Trie 的结构来解决冲突。

Merkle Tree

帮助高效、安全地验证大量数据。它通过将数据组织成树状结构，其中每个叶子节点包含数据块的哈希值，每个非叶子节点是其两个子节点的哈希值，一直向上到顶部的 Merkle 根。这种结构在区块链和其他系统中被广泛使用，以确保数据完整性。

最后：8 个数据库中常用的数据结构

自己工资 14K，找到月薪 28K工作后，开心地提交辞呈，租了新房子！入职前一天HR说：原来岗位的人不走了，你offer被取消了

Thu, 19 Sep 2024 13:14:56 +0000

昨天，我刷到一条让人心酸又无奈的职场动态。

小李是一名刚入职场两年的新人，目前在一家小公司做程序员，月薪14000元。虽然工资不高，但胜在工作轻松，离家也近。前段时间，小李在某招聘网站上看到一家知名企业招聘高级开发工程师，工资开到了28000元。他兴奋地投了简历，很快就接到了面试通知。经过两轮面试，小李顺利拿到了offer。他激动地跟现在的公司提交了辞呈，还跟朋友们庆祝了一番。为了配得上新工作的身份，他还租了一套离新公司更近的房子。然而，就在准备入职的前一天晚上，小李突然接到了HR的电话。HR告诉他：“很抱歉，原来那个岗位的人临时决定不走了，所以你的offer取消了。小李瞬间懵了，新房已租，旧工作已辞，这下可怎么办？

昨天，我刷到一条让人心酸又无奈的职场动态。一位刚入职场两年的小李，原本在一家小公司做程序员，月薪14000元。虽然工资不算高，但工作环境还不错，离家也近。

前段时间，他在某招聘网站上看到一家知名互联网企业招聘高级开发工程师，工资直接翻倍到28000元。

小李兴冲冲地投了简历，顺利通过了两轮技术面试和一轮HR面试，拿到了心仪的offer。他激动地向现公司提交了辞呈，还跟朋友们庆祝了一番。为了配得上新工作的身份，他甚至租了一套离新公司更近的高档公寓。

然而，就在准备入职的前一天晚上，噩耗传来—— HR打电话告诉他，由于公司最新一轮融资出现问题，暂时冻结所有新入职岗位，他的offer取消了。

看到这里，你是不是也替小李捏了一把汗？新房已租，旧工作已辞，眼看就要成为无业程序员，这下该怎么办？

这则职场惨案不禁让人深思：为什么看似美好的机会会突然变成噩梦？我们又该如何避免自己成为下一个"小李”？

说实话，我看完这个故事后，心里五味杂陈。作为一个在IT圈摸爬滚打多年的老码农，我深知这种情况并不罕见。让我们一起来剖析一下，为什么会发生这种令人沮丧的情况：

互联网公司风险高，经营状况瞬息万变。有些看似光鲜的大厂，实际上可能正处于动荡期。融资问题、业务调整等都可能导致招聘计划的突然变更。可悲的是，最终受伤的往往是像小李这样的求职者。
技术人员往往过于关注技术而忽视了职场规则。小李在拿到offer后就立即辞职、租房，这种行为虽然可以理解，但确实有些冒失。在职场中，任何事情都有变数，过早地把鸡蛋放在一个篮子里，风险系数自然就高了。
法律意识淡薄，没有书面保障。很多程序员拿到offer后就觉得万事大吉，殊不知口头offer其实没有任何法律效力。如果公司反悔，求职者往往就只能自认倒霉。
行业诚信缺失，某些企业不负责任。有些公司为了抢夺人才，会开出很诱人的条件。但当情况有变时，他们却毫不犹豫地把求职者抛在一边，根本不考虑对方的感受和损失。
求职者自身定位不清，盲目追求大厂高薪。小李原本工作虽然工资不是顶尖，但也有其他优势。为了追求大厂光环和高薪而放弃稳定工作，某种程度上也反映了他对自身价值和职业规划的判断可能存在偏差。

看到这里，你可能会问：那遇到这种情况该怎么办？作为一个职场老兵，我有以下几点建议：

冷静应对，及时止损。天无绝人之路，当务之急是调整心态，不要被一时的挫折打倒。立即开始寻找新的工作机会，同时考虑是否可以挽回原来的工作。技术人才的市场需求通常较大，保持信心很重要。
学会维权，寻求补偿。虽然口头offer没有法律效力，但如果有邮件等书面证据，可以尝试与公司协商，要求一定的经济补偿。即便最后拿不到补偿，也能给不负责任的公司一些压力。
建立职业缓冲带。以后在跳槽时，可以考虑采用"双轨制"：先在新公司试用一段时间，确认稳定后再辞去原工作。这样既能保证收入的连续性，又能降低风险。对于程序员来说，可以考虑先以外包或者兼职的形式进入新公司。
提高法律意识，要求书面offer。在接受offer时，一定要索要正式的录用函。这不仅是对自己负责，也是对公司诚意的一种考验。特别是对于互联网公司，由于其变数较大，更应该要求有书面保障。
理性评估，不要被大厂光环和高薪蒙蔽双眼。在考虑新工作时，不要只看工资和公司名气，还要综合考虑技术栈匹配度、团队氛围、公司发展前景等因素。有时候，看似吸引人的大厂高薪工作可能暗藏陷阱。

职场如代码，每一步都要谨慎。希望小李的经历能给大家敲响警钟。记住，真正的技术高手，不仅要有扎实的编程功底，更要有职场智慧。下次当你收到一份看似诱人的offer时，先别急着庆祝，多问问自己：这份工作靠谱吗？我准备好了吗？

愿每个程序员都能在这个充满挑战的IT世界里，代码写得好，职场走得稳，找到属于自己的一片天地。

面试不会问的Hystrix实现资源隔离

Mon, 25 Apr 2022 03:37:31 +0000

资源是什么？又为什么要隔离？

我们设想一个这样的场景：

在某分布式微服务系统中的某个服务 A ，它依赖外部的 B 、C、D 三个服务，通过 RPC 远程调用它们。
假设服务 A 是一个 springboot 启动的 java 进程，内部 wrap 的 web server 是 tomcat。
假设 tomcat 采用的线程模型是 NIO 模式，它默认的最大连接数是 10000 ，也就是最多同时接收处理10000个用户请求。

在正常情况下，只要同时请求数不超过10000 且服务 A 及内外部服务都正常运行就没有问题。（理论上虽然是这样，但实际情况可能不太严谨）

考虑这样一种情况：

假设依赖的 B 服务由于各种原因不正常了，比如出现了超时，而且 B 服务是一个业务核心依赖（基本所有请求都要过它）。那么这时候用户从 A 服务入口进来的正常请求线程将不能正常 终止（terminated），而会 阻塞（Blocked） 或者 等待 (waiting) 在 B 服务这里。

这时 tomcat 的可用线程数将下降，也就会导致用户对 A 服务的正常请求受到影响，如果 B 服务的情况不能得到改善，那么 A 服务将有可能面临

线程资源不足，A 服务的非核心请求也受到影响（不走 B 服务的）
雪崩 的风险，有可能会因为线程资源不足而 hang 死，产生连锁反应，导致 A 也不可用。

可见，我们并不想产生这样的影响，我们希望无论 B 服务是不是核心依赖，它出了问题，都尽量不要或最小范围影响我本服务。

所以，总结来看，资源具体来说就是线程 ，而隔离的目的，是为了在依赖服务出问题的情况下，影响范围最小化。

Hystrix

Hystrix 模型

Hystrix 将远程服务的请求托管在一个线程池中。即默认情况下，所有 Hystrix 命令 (@HystrixCommand) 共享同一个线程池来处理这些请求。该线程池中持有 10 个线程来处理各种远程服务请求，可以是 REST 服务调用、数据库访问等。如下图所示：

如何隔离

有两种策略分别是

线程池隔离
信号量隔离

两种隔离方式都是限制对共享资源的并发访问量，线程在就绪状态、运行状态、阻塞状态、终止状态间转变时需要由操作系统调度，占用很大的性能消耗；而信号量是在访问共享资源时，进行 tryAcquire，tryAcquire 成功才允许访问共享资源。

1HystrixCommandProperties.Setter().withExecutionisolationStrategy(ExecutionlsolationStrategy.THREAD)
2HystrixCommandProperties.Setter().withExecutionisolationStrategy(ExecutionisolationStrategy.SEMAPHORE)

线程池隔离

@HystrixCommand 的默认配置适用于只有少量远程调用的应用。幸运的是，Hystrix 提供了简单易用的方法实现舱壁来隔离不同的远程资源调用。下图说明了 Hystrix 将不同的远程调用隔离在不同的“舱室”（线程池）中：

Hystrix 可以为每一个依赖建立一个线程池，使之和其他依赖的使用资源隔离，同时限制他们的并发访问和阻塞扩张。每个依赖可以根据权重分配资源（这里主要是线程），每一部分的依赖出现了问题，也不会影响其他依赖的使用资源。

如果简单的使用异步线程来实现依赖调用会有如下问题：

线程的创建和销毁
线程上下文空间的切换，用户态和内核态的切换带来的性能损耗。

使用线程池的方式可以解决第一种问题，但是第二个问题计算开销是不能避免的。

Netflix 在使用过程中详细评估了使用异步线程和同步线程带来的性能差异，结果表明在 99%的情况下，异步线程带来的几毫秒延迟的完全可以接受的。

优点：

一个依赖可以给予一个线程池，这个依赖的异常不会影响其他的依赖。
使用线程可以完全隔离第三方代码，请求线程可以快速放回。
当一个失败的依赖再次变成可用时，线程池将清理，并立即恢复可用，而不是一个长时间的恢复。
可以完全模拟异步调用，方便异步编程。
使用线程池，可以有效的进行实时监控、统计和封装。

缺点：

使用线程池的缺点主要是增加了计算的开销。每一个依赖调用都会涉及到队列，调度，上下文切换，而这些操作都有可能在不同的线程中执行。

线程池的创建和管理

虽然 Hystrix 可以为每个依赖建立一个线程池，但是如果依赖成千上万，建立那么多线程池肯定是不可能的。所以默认情况下，Hystrix 会为每一个 Command Group 建立一个线程池。Hystrix 的线程池在 HystrixConcurrencyStrategy 初始化，线程池是由 ThreadPoolExecutor 实现的。每个线程池默认初始化 10 个线程。Hystrix 有个静态类 Factory，创建的线程池会被存储在 Factory 中的 ConcurrentHashMap 中。ConcurrentHashMap 的 Key 则是上文说到的 CommandGroupKey 或者指定的 ThreadPoolKey。每次命令执行的时候，都会根据 ThreadPoolKey 去找到对应的线程池。线程池拥有一个继承于 rxjava 中 Scheduler 的 HystrixContextScheduler，用于在执行命令的时候，把命令在这个线程池上调度执行。

信号量隔离

“

每次调用线程，当前请求通过计数信号量进行限制，当信号大于了最大请求数（maxConcurrentRequests）时，进行限制，调用 fallback 接口快速返回。

”

信号量的资源隔离只是起到一个开关的作用，例如，服务 X 的信号量大小为 10，那么同时只允许 10 个 tomcat 的线程（此处是 tomcat 的线程，而不是服务 X 的独立线程池里面的线程）来访问服务 X，其他的请求就会被拒绝，从而达到限流保护的作用。

信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。这样就导致了无法对访问做超时（只能依靠调用协议超时，无法主动释放）

什么时候适合用信号量隔离而不是用线程池？

隔离的细粒度太高，数百个实例需要隔离，此时用线程池做隔离开销过大
通常这种都是非网络调用的情况下

选用

两种策略对比

线程池隔离	信号量隔离
线程	与调用线程非相同线程	与调用线程相同
开销	排队、调度、上下文开销等	无线程切换，开销低
异步	支持	不支持
并发支持	支持（最大线程池大小）	支持（最大信号量上限）

对于那些本来延迟就比较小的请求（例如访问本地缓存成功率很高的请求）来说，线程池带来的开销是非常高的，这时，你可以考虑采用其他方法，例如非阻塞信号量（不支持超时），来实现依赖服务的隔离，使用信号量的开销很小。但绝大多数情况下，Netflix 更偏向于使用线程池来隔离依赖服务，因为其带来的额外开销可以接受，并且能支持包括超时在内的所有功能。
当请求的服务网络开销比较大的时候，或者是请求比较耗时的时候，我们最好是使用线程隔离策略，这样的话，可以保证大量的容器 (tomcat) 线程可用，不会由于服务原因，一直处于阻塞或等待状态，快速失败返回。而当我们请求缓存这些服务的时候，我们可以使用信号量隔离策略，因为这类服务的返回通常会非常的快，不会占用容器线程太长时间，而且也减少了线程切换的一些开销，提高了缓存服务的效率。

 1@HystrixCommand(
 2 commandProperties = { //利用 commandProperties 更改线程池的一些默认配置
 3 //选择“线程池”模式、"信号量"模式
 4 @HystrixProperty(name="execution.isolation.strategy",value = "THREAD"/"SEMAPHORE"), 
 5 //超时
 6 @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value = "3000"),
 7 //信号量大小为 10，那么同时只允许 10 个 tomcat 的线程（此处是 tomcat 的线程，而不是服务的独立线程池里面的线程）来访问服务，其他的请求就会被拒绝，从而达到限流保护的作用
 8 @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests",value = "10"),
 9 }，
10)
11public List<License> getLicensesByOrg(String organizationId){
12 //....
13}

注意，如果选用线程池，要合理的设置线程池的大小，和超时时间。

spring cloud 的 yaml 配置可以参考：

 1feign:
 2 hystrix:
 3 # 启用熔断降级策略
 4 enabled: true
 5
 6ribbon:
 7 # 请求建立连接超时时间，单位：毫秒，默认：2000
 8 ConnectTimeout: 3000
 9 # 读取数据超时时间长，单位：毫秒，默认：5000
10 # 这里设置为 10 秒，表示请求发出后，超过 10 秒没有读取到数据时请求超时
11 ReadTimeout: 10000
12 # 对所有操作都进⾏重试，默认：false
13 OkToRetryOnAllOperations: false
14 # 对同一个实例的最大重试次数，默认：0
15 MaxAutoRetries: 1
16 # 切换实例重试的最大次数，默认：1
17 MaxAutoRetriesNextServer: 1
18
19hystrix:
20 command:
21 default:
22 execution:
23 timeout:
24 # 配置 HystrixCommand 命令执行是否开启超时，默认：true。
25 enabled: true
26 isolation:
27 # 隔离策略，分为 THREAD 和 SEMAPHORE，默认为 THREAD。
28 strategy: THREAD
29 semaphore:
30 # 信号量大小，当隔离策略为信号量时，最大并发请求达到该设置值，后续的请求将被拒绝，默认：10
31 maxConcurrentRequests: 100
32 thread:
33 # 表示设置是否在执行超时时，中断 HystrixCommand.run() 的执行，默认：true
34 interruptOnTimeout: true
35 # hystrixCommand 命令执行超时时间，单位：毫秒，默认：1000
36 # 首先要考虑接口的响应时间，其次要考虑 ribbon 的超时时间和重试次数
37 timeoutInMilliseconds: 30000

更多配置请参考：https://github.com/Netflix/Hystrix/wiki/Configuration

参考

阿里云面试题分享

Tue, 12 May 2020 14:23:10 +0000

突如其来的电话面试

事情是这样的，今天吃完晚饭在外面公园遛达了一圈，回到家没一会儿接到了一个电话，说是阿里云的，心中疑惑，不对呀，我刚收到回阿里的拒信（之前投过，被拒了）。

聊了一下，虽然不太清楚阿里的流程，但老哥态度特别好，电话面试一下总是没问题的。

下面分享下问题

一给你一个 ipv4 的地址，把它转到 Int , 用一个Int变量装。

这个题很明显直接装是有可能越界装不下的。int是32位。long倒是可以。

我想了一会儿说了一个答案，没对，后来老哥给我解释了一下，然后恍然大明白了，其实是个小技巧。直接上代码吧。

 1/**
 2 * 将 ip 字符串转换为 int 类型的数字
 3 * <p>
 4 * 思路就是将 ip 的每一段数字转为 8 位二进制数，并将它们放在结果的适当位置上
 5 *
 6 * @param ipString ip字符串，如 127.0.0.1
 7 * @return ip字符串对应的 int 值
 8 */
 9public static int ip2Int(String ipString) {
10 // 取 ip 的各段
11 String[] ipSlices = ipString.split("\\.");
12 int rs = 0;
13 for (int i = 0; i < ipSlices.length; i++) {
14 // 将 ip 的每一段解析为 int，并根据位置左移 8 位
15 int intSlice = Integer.parseInt(ipSlices[i]) << 8 * i;
16 // 求与
17 rs = rs | intSlice;
18 }
19 return rs;
20}
21
22```java
23
24**那怎么再从int 转成ipv4 字符串呢？**
25
26其实也很简单，思路是一样的，将 int 值的 32 位分为 4 个 8 位数字，然后这 4 个 8 位的数字用 0~255 的数字进行表示，用点号分隔即可。我们也基于位运算，7 行代码即可实现。
27
28```cpp
29/**
30 * 将 int 转换为 ip 字符串
31 *
32 * @param ipInt 用 int 表示的 ip 值
33 * @return ip字符串，如 127.0.0.1
34 */
35public static String int2Ip(int ipInt) {
36 String[] ipString = new String[4];
37 for (int i = 0; i < 4; i++) {
38 // 每 8 位为一段，这里取当前要处理的最高位的位置
39 int pos = i * 8;
40 // 取当前处理的 ip 段的值
41 int and = ipInt & (255 << pos);
42 // 将当前 ip 段转换为 0 ~ 255 的数字，注意这里必须使用无符号右移
43 ipString[i] = String.valueOf(and >>> pos);
44 }
45 return String.join(".", ipString);
46}

二设计一个分布式的图片存储系统 QPS：5K以上可以使用通用的中件间。

 针对这个问题我扯了半天，感觉有些在点儿上，有些不在，想来如果你设计过，有过设计经验应该多数能说到点儿上。别的不说，光可高用就能扯半天，比如集群故障情况下的失效转移（Failover）。不同故障下的解决方案（瞬间故障、临时故障、永久故障）。网上相关资料也挺多的，可以参考开源系统的设计比如：FastDFS。是一个由 C 语言实现的开源轻量级分布式文件系统(https://github.com/happyfish100/fastdfs)

关注公众号获取更多精彩内容

滴滴一面（高级java）面试题分享

Mon, 11 May 2020 07:25:08 +0000

1 说下对 volatile关键字的理解

volatile可以禁止指令重排序优化
保证可见性、不保证原子性(也就是说多个线程并发修改某个变量时，依旧会产生多线程问题，但适合使用一个线程写，多个线程读的场合。)

以下场景可以使用volatile
运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
变量不需要与其他的状态变量共同参与不变约束

原理：volatile语义中的内存屏障volatile的内存屏障策略非常严格保守，非常悲观且毫无安全感的心态：在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障；在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障；由于内存屏障的作用，避免了volatile变量和其它指令重排序、线程之间实现了通信，使得volatile表现出了锁的特性。

2 jvm调过优没有，是怎么做的？排查问题时一般会用哪些命令？

 jps(JVM Process Status):虚拟机进程状况工具 显示虚拟机进程 jps -l

 jstat(JVM Statistics Monitoring Tool):监控虚拟机各种运行状态

 jinfo(Configuration Info for Java):java配置信息工具

 jmap(Memory Map for Java) 堆转储快照

 jstack(Stack Trace for Java) java堆栈跟踪工具

3 AQS 原理大概说一下

可参考 ： [彻底搞懂AQS](http://mp.weixin.qq.com/s?__biz=MzI3Njk5ODg4OQ==&mid=2247484343&idx=1&sn=0c0ac16161f09cadd00483addbf6e598&chksm=eb6dbc31dc1a35278931f76fce310d6ead4aba125fc2370aeb52a03b2dc4a78c0d4d95fae420&scene=21#wechat_redirect)

4 Redis 高可用实现方式

redis cluster 或哨兵机制

5 Kafka 或 RocketMq 实现原理

问的太广了，自己知道什么有逻辑的表达一下吧

6 spring cloud 和 dubbo区别

 主要是RPC和生态上的区别

7 spring cloud 用过哪些组件？

可参考：spring及spring cloud框架主要组件介绍

8 Hystrix 熔断器有哪些模式

closed：请求正常时，不使用熔断器；
open：统计请求的失败比例，达到阀值时，打开熔断器，请求被降级处理；延时一段时候后（默认休眠时间是5S）会进入halfopen状态；默认失败比例阀值是50%，请求次数最少不低于20次；
halfopen：在进入该状态后会放入部分请求；判断请求是否成功，不成功，进入open状态，重新计时，进入halfopen状态；成功，进入closed状态，

9 介绍下项目

10 有什么问题问我的？

快手一面（高级java）面试真题分享

Wed, 06 May 2020 10:37:03 +0000

1 ArrayList LinkedList 区别

ArrayList

采用数组的方式来存储对象
非线程安全
每次按照1.5倍（位运算）的比率通过copeOf的方式扩容
初始数组容量为10

LinkedList

基于双向链表机制实现
非线程安全的

2 ArrayList、LinkedList 的boolean add(E e) 、E remove(int index)、void add(int index, E element) 三个方法，分别的时间复杂度

ArrayList:

add(E e) 在不考虑扩容的情况下时间复杂度为：O(1)
add(int index,E element) 时间复杂度为：O(n) 在第几个元素后面插入，后面的元素需要向后移动
remove(int index) 时间复杂度为：O(n) 在第几个元素后面插入，后面的元素需要向后移动

LinkedList:

add(E e) 时间复杂度为：O(1)
add(int index,E element) 时间复杂度为：O(n) 需要先查找到第几个元素，直接指针指向操作
remove(int index) 时间复杂度为：O(n)

总结：

ArrayList 对于随机位置的add/remove，时间复杂度为 O(n),但是对于列表末尾的添加/删除操作,时间复杂度是 O(1).
LinkedList对于随机位置的add/remove，时间复杂度为 O(n),但是对于列表末尾/开头的添加/删除操作,时间复杂度是 O(1).

3 HashMap 数据结构，1.8为什么用红黑树?

参考系列文章：经典面试题之HashMap(一)

4 HashMap 求hash值的算法？

参考系列文章 : 经典面试题之HashMap(二)

5 写代码：实现一下HashMap的put方法

 这个题我说实话，我自己是无法完整的写出来，但大致思路是能说得上来。所以，如果我是面试官的话，要求至少是把思路说出来。能完全写出来的佩服，因为put方法还牵扯很多上下文的信息，这些都记住不易。

参考系列文章：一次性搞定HashMap面试

6 说明一下java的异常体系

7 Redis 怎样实现分布式锁? setnx 和 set区别

 用setnx 可以实现分布式锁

 set:

将字符串值 value 关联到 key 。
如果 key 已经持有其他值， SET 就覆写旧值，无视类型。

setnx:
将 key 的值设为 value ，当且仅当 key 不存在。
若给定的 key 已经存在，则 SETNX 不做任何动作。
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。

8 一个接口调用次数，如果用 static long counter；counter++; 统计有什么问题没有？如果用volatile修饰呢？

 有问题，如果在多线程环境下，会出现数据不对的情况。

 如果用volatile也不能解决这个问题，因为volatile 虽然能够保证有序性和可见性，但就这个例子来讲，运算的结果已经依赖当前变量的值了（counter++） 这样是不能使用volatile的，如果用了，结果也是不对。原因是在counter++中,这条语句编译后的字节码指令不是一句，在多线程环境下其他线程可能已经把值改了，操作数栈顶的值可能就成了过期的数据。 

 **那应该怎么办呢？**

 可以用原子类操作，比如 AtomicInteger

 **AtomicInteger的原理？**

 主要是利用了CAS

 **描述下CAS过程和原理？**

所谓CAS，即“比较与交换”（Compare-and-swap），是最常见的乐观锁实现方式，看官应该对这个概念很熟悉。一次CAS过程是原子的，包含3个操作数：

需要访问的内存地址V；
该内存地址中存储的预期值A；
希望向该地址写入的新值B。

当且仅当V中的值与A相同时，其值才会更新成B，否则就不执行任何动作。

 CAS通过调用JNI的代码实现的。JNI:Java Native Interface为JAVA本地调用，允许java调用其他语言。而compareAndSwapInt就是借助C来调用CPU底层指令(Atomic::cmpxchg(x,addr,e))实现的。

 **CAS存在的问题？**

 如果CAS失败，会一直进行尝试。如果CAS长时间一直不成功，可能会给CPU带来很大的开销。

9 讲一讲熟悉的项目

阿里面试分享

Sat, 25 Apr 2020 07:49:29 +0000

通过与透露题目的朋友得知以下两题出自蚂蚁金服的远程一面。

题目本身并不很难，难的是在阿里评测的平台上，脱离IDE，徒手coding。那个平台其实就是给你一个网址打开就像记事本一样，面试官可以实时看到你写的什么，你以可以说话跟他语音交流。