最近在系统性学习 AI Agent 的构建和落地，喂给了 GPT 一批资料，让它给我整理了一份详细的 roadmap，第一步便是应该先弄清楚这几个概念，GPT 建议我输出一份文档，于是便有了这个文章（但其实这篇文章也是我列好大纲让 AI 写的）。

一、为什么要区分这四个概念

学 AI Agent 的第一步不是写代码，而是搞清楚边界。很多项目失败不是因为技术不行，而是用错了模式——该用 Workflow 的地方强上 Agent，该用 Agent 的地方只做了 RAG。理解这四个概念的区别和关系，是后续所有工程决策的基础。

二、一句话定义

• Chatbot：基于 LLM 的对话系统，用户问一句答一句，不主动行动，不调用外部工具。
• Workflow：预定义的固定流程，每一步做什么、调什么工具、输出什么格式都是开发者写死的。
• RAG（Retrieval-Augmented Generation）：在生成回答前，先从外部知识库检索相关内容注入上下文，让模型基于检索结果回答。
• Agent：具备自主决策循环的系统，能根据当前状态动态选择下一步行动，包括调用工具、检索信息、追问用户，直到任务完成。

三、用一个场景看区别

任务：”帮我了解 LangGraph 适不适合我们的项目”

四、六个维度深度对比

4.1 决策权归属

这是最根本的区别。

• Chatbot / RAG：决策权在用户手里，用户不问它就不动。
• Workflow：决策权在开发者手里，流程提前设计好。
• Agent：决策权在系统自身，根据当前状态自主判断下一步。

4.2 处理意外的能力

• Workflow：遇到意外就出问题，只认识预设路径。
• Chatbot：遇到意外只能说”我不确定”。
• RAG：知识库里没有相关内容时，检索结果变成噪声，回答质量断崖式下跌。
• Agent：可以换策略——搜不到就换关键词，工具报错就试另一个，信息不够就主动追问。

4.3 工具使用方式

• Chatbot：通常不调用工具。
• Workflow：按预设顺序调用固定工具。
• RAG：只调用”检索”这一种工具。
• Agent：动态选择调用什么工具、什么时候调、调几次，可以组合多个工具。

4.4 上下文来源

• Chatbot：训练数据 + 当前对话。
• RAG：训练数据 + 检索到的外部文档片段。
• Workflow：管道中上一步传递的数据。
• Agent：综合所有来源（训练知识、检索结果、工具返回值、对话历史、长期记忆），并自己决定什么时候需要获取更多上下文。

4.5 可控性与风险

4.6 适用场景

用 Chatbot 就够： FAQ、简单信息查询、闲聊。任务单一，不需要外部数据和多步推理。

用 Workflow 更好： 流程确定、步骤固定。例如定时报表生成、工单自动分类、数据管道处理。路径清晰就别用 Agent，Workflow 更稳更快。

用 RAG 更好： 基于特定知识库的问答，且问答模式相对固定。例如企业内部文档问答、产品手册查询、客服知识库。

必须用 Agent： 任务路径不确定，需要多步推理和动态决策。例如线上问题诊断、技术方案调研、需要跨多个数据源才能完成的复杂任务。

五、它们不是互斥的，而是可嵌套的

一个常见误区是把这四个概念当成互斥的选项。实际上它们是不同层次的能力，可以互相嵌套：

1
2
3
4
5

Agent（最上层编排者）
├── 调用 RAG 模块获取知识
├── 调用固定 Workflow 处理子任务
├── 底层对话能力 = Chatbot
└── 通过工具与外部世界交互

一个成熟的 Agent 系统的运行过程可能是：用户提问 → Agent 判断需要查资料 → 调用 RAG 检索 → 发现不够 → 调用搜索工具补充 → 按 Workflow 格式整理结果 → 用对话能力生成自然语言回复。

六、关键判断：什么时候该用 Agent

在决定是否使用 Agent 之前，先问三个问题：

1. 任务路径是否确定？ 如果每次执行的步骤都一样，用 Workflow。
2. 是否需要动态使用多个工具？ 如果只需要检索，RAG 就够。
3. 是否需要系统自主做出决策？ 如果人类可以轻松预定义所有分支，不需要 Agent。

一个简单的原则：能用简单方案解决的，就不要用复杂方案。 Agent 的灵活性是有代价的——更难调试、更难预测、更难保证质量。只有当任务的复杂度确实需要自主决策时，Agent 才是正确的选择。

七、三个核心认知

1. Agent 的”行动能力”来自工具。 LLM 只能生成文本，是工具让它能搜索、能调 API、能读写文件。工具设计的质量直接决定 Agent 的能力上限。

2. 光有 LLM 不等于有 Agent。 LLM 是被动的输入-输出系统。Agent 需要一个持续运行的控制循环：感知 → 决策 → 行动 → 观察结果 → 再决策。LLM 是 Agent 的一个组件，不是 Agent 本身。

3. 复杂度是有成本的。 不是所有问题都需要 Agent。选择 Chatbot / Workflow / RAG / Agent 的依据不是”哪个更高级”，而是”任务的不确定性有多高”。

附：引用

• Microsoft AI Agents for Beginners: Agent 基础概念与组成结构
• OpenAI Building Agents 概览：产品与工程视角的 Agent 设计
• Anthropic Building Effective Agents：Agent 工程实践与复杂度控制建议

数据源加载与分块

1
2
3
4
5
6
7
8
9
10
11

from typing import List

def split_into_chunks(doc_file: str) -> List[str]:
    with open(doc_file, 'r') as file:
        content = file.read()
    return [chunk for chunk in content.split("\n\n")]

chunks = split_into_chunks("doc.md")

for i, chunk in enumerate(chunks):
    print(f"[{i}] {chunk}\n")

我们上篇说到，分块的方式有很多种，这里随便选取一种，按照换行符来给数据源分块。

文本的向量化

1
2
3
4
5
6
7
8
9
10
11

from sentence_transformers import SentenceTransformer

embedding_model = SentenceTransformer("shibing624/text2vec-base-chinese")

def embed_chunk(chunk: str) -> List[float]:
    embedding = embedding_model.encode(chunk, normalize_embeddings=True)
    return embedding.tolist()

embedding = embed_chunk("测试内容")
print(len(embedding))
print(embedding)

1. 代码首先从 sentence-transformers 库导入 SentenceTransformer 类，并加载一个预训练好的中文文本向量化模型 shibing624/text2vec-base-chinese。这个模型擅长将中文文本转换成能表达其语义的数字向量。

2. embed_chunk 函数接收一个文本块，使用加载的模型将其编码（encode）成一个向量。normalize_embeddings=True 参数会将向量进行归一化，这有助于后续的相似度计算。

3. 最后测试打印一下向量化，运行可以看到将测试内容转化成高维（本例是 768）向量。

下面便是调用向量化方法，将第一步加载分块的数据源全部向量化。

1
2
3
4

embeddings = [embed_chunk(chunk) for chunk in chunks]

print(len(embeddings))
print(embeddings[0])

索引与存储

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import chromadb

chromadb_client = chromadb.EphemeralClient()
chromadb_collection = chromadb_client.get_or_create_collection(name="default")

def save_embeddings(chunks: List[str], embeddings: List[List[float]]) -> None:
    for i, (chunk, embedding) in enumerate(zip(chunks, embeddings)):
        chromadb_collection.add(
            documents=[chunk],
            embeddings=[embedding],
            ids=[str(i)]
        )

save_embeddings(chunks, embeddings)

1. 示例中使用的向量数据库是 chromadb
2. 为了演示方便，chromadb.EphemeralClient() 创建了一个临时的、在内存中运行的向量数据库实例。
3. get_or_create_collection 创建了一个名为 “default” 的集合（类似于数据库中的表），用于存放我们的数据。
4. save_embeddings 函数遍历文本块和它们对应的向量，并将它们成对地添加到 chromadb_collection 中。每个条目都包含三部分：
   • documents: 原始的文本内容
   • embeddings: 文本对应的向量
   • ids: 每个条目的唯一标识符，这里使用其在列表中的索引

检索与召回

1
2
3
4
5
6
7
8
9
10
11
12
13

def retrieve(query: str, top_k: int) -> List[str]:
    query_embedding = embed_chunk(query)
    results = chromadb_collection.query(
        query_embeddings=[query_embedding],
        n_results=top_k
    )
    return results['documents'][0]

query = "哆啦A梦使用的3个秘密道具分别是什么？"
retrieved_chunks = retrieve(query, 5)

for i, chunk in enumerate(retrieved_chunks):
    print(f"[{i}] {chunk}\n")

1. retrieve 函数接收一个用户问题 query 和一个整数 top_k（代表需要检索的数量，这里是 5）。

2. 它首先将用户问题也转换成一个向量（使用与之前完全相同的模型）。

3. 然后，它使用 chromadb_collection.query 方法，用问题的向量去数据库中搜索最相似的 top_k 个向量。

4. 数据库返回最相似的条目，函数从中提取出原始的文本文档并返回。

5. 代码最后用一个具体问题 “哆啦A梦使用的 3 个秘密道具分别是什么？” 来测试检索功能，并打印出找到的前 5 个最相关的文本块。

重排

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

from sentence_transformers import CrossEncoder

def rerank(query: str, retrieved_chunks: List[str], top_k: int) -> List[str]:
    cross_encoder = CrossEncoder('cross-encoder/mmarco-mMiniLMv2-L12-H384-v1')
    pairs = [(query, chunk) for chunk in retrieved_chunks]
    scores = cross_encoder.predict(pairs)

    scored_chunks = list(zip(retrieved_chunks, scores))
    scored_chunks.sort(key=lambda x: x[1], reverse=True)

    return [chunk for chunk, _ in scored_chunks][:top_k]

reranked_chunks = rerank(query, retrieved_chunks, 3)

for i, chunk in enumerate(reranked_chunks):
    print(f"[{i}] {chunk}\n")

1. 此处引入了一个 CrossEncoder 模型。与 SentenceTransformer（将单个句子转为向量）不同，CrossEncoder 直接比较一对文本（在这里是 (query, chunk)），并输出一个它们之间的相关性得分。

2. rerank 函数将用户问题与上一步检索到的每个文本块配对。

3. cross_encoder.predict 为每一对计算一个精确的相关性分数。

4. 代码根据这个分数从高到低对检索到的文本块进行重新排序，并返回排序后最靠前的 top_k 个。

上篇文章我们讲了一下重排的作用和目的，这里再次重述一下：重排可以显著提高 RAG 系统的质量，在召回阶段召回的结果可能会包含一些不那么相关的片段，重排序则使用一个更复杂、更精确的模型（CrossEncoder）对初步结果进行精细打磨，确保最终提供给语言模型的上下文质量最高、相关性最强。

生成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

from dotenv import load_dotenv
from google import genai

load_dotenv()
google_client = genai.Client()

def generate(query: str, chunks: List[str]) -> str:
    prompt = f"""你是一位知识助手，请根据用户的问题和下列片段生成准确的回答。

用户问题: {query}

相关片段:
{"\n\n".join(chunks)}

请基于上述内容作答，不要编造信息。"""

    print(f"{prompt}\n\n---\n")

    response = google_client.models.generate_content(
        model="gemini-2.5-flash",
        contents=prompt
    )

    return response.text

answer = generate(query, reranked_chunks)
print(answer)

最后一步就比较好理解了，将问题和重排后的相关片段作为上下文丢给大模型，然后调用 LLM 大模型接口生成答案，代码也比较简洁易懂，这里就不做描述。

以上就利用 python + langchain 实现了一个非常简易的 RAG 系统，主要是针对上一篇文章中三个阶段的代码实现，详细的代码运行结果和数据源文本见本项目地址，运行前项目跟目录下创建一个 .env 文件，将 gemini 的 api key 填进去即可，像下面这样。

1

GEMINI_API_KEY=xxxxxxxxxxxxx<替换成你的API_KEY>

RAG（Retrieval-Augmented Generation）中文叫做检索增强生成，它是一种将外部知识库与大语言模型（LLM）相结合的技术。其核心思想是在大模型生成回答之前，先检索文档将检索到内容作为上下文输入给模型，从而提高回答的准确性和时效性。

在一个典型的 RAG 系统中，首先会对外部文档进行预处理并向量化存储形成知识库，当用户提出问题，系统会将问题转化成向量，并且计算出向量相似度，在知识库中找出与用户问题相近的片段，然后将用户问题和相似片段一起丢给大模型（prompt），大模型在此基础上生成答案。

总结上述过程，大致可以分为三个阶段：

1. 准备阶段：分片、索引
2. 检索阶段：召回、重排
3. 生成阶段：生成

使用场景

通过上述的介绍不难发现，RAG 适合用做智能客服或者企业内部知识库等私有化数据的场景。一般来说，传统的 LLM 通常都有上下文的限制（即使 Gemini 有百万的上下文），这就导致大模型在工作时始终有上下文局限，我们不可能把大量的私有数据一下子全部喂给大模型，而 RAG 通过分片、向量化存储和向量相似性等手段解决了 LLM 根本局限性。

总结一下，可以归纳为三大核心优势：

1. 获取最新信息：RAG通过连接到实时更新的数据源（如新闻网站、社交媒体流或企业内部的动态数据库），克服了LLM的知识时效性问题。这使得RAG系统能够提供反映最新情况的答案，这在金融、新闻和客户服务等快速变化的领域至关重要。
2. 增加事实性并减少幻觉：RAG通过“事实接地”（Factual Grounding）来提高输出的准确性。它要求LLM的回答必须以检索到的外部文档为依据，而不是仅凭其内部的参数化知识。这种机制显著降低了模型产生“幻觉”的风险，并允许系统在生成答案时提供引文或来源链接，从而让用户可以验证信息的准确性。
3. 实现专业领域知识：RAG使得通用的LLM能够在不经过昂贵和耗时的重新训练或微调的情况下，应用于高度专业的领域。无论是医疗、法律还是制造业，企业都可以通过构建包含其专有文档、手册和数据的知识库，来创建一个能够理解并回答特定领域问题的“专家系统”。

下面来说一下 RAG 的工作流程。

工作流程

第一阶段：分片与索引

1. 数据分片（Text Splitting）

   上面说到，LLM 存在上下文的局限，往往无法一次性处理长数据源，因此需要将数据源（文档、链接内容等）切分成多个片段。需要说明的是，分片方式的选择应当是灵活的，它应该是具备“上下文感知”（Context-aware）能力，尽可能沿着段落、章节、标题等自然边界进行分割，以保持每个块内部的语义连贯性，这对于确保检索的精准度和生成答案的质量至关重要。

2. 嵌入（Embedding）

   然后，每个文本块都被送入一个嵌入模型（Embedding Model）中，转换成一个高维的数值向量，即“嵌入向量”。这个向量是文本块语义的数学表示，在向量空间中，意思相近的文本块，其对应的向量在空间中的距离也更近。嵌入模型的选择是一个关键的架构决策，因为它直接决定了后续语义搜索的质量和效果。

3. 索引与存储（Indexing & Storage)

   上一步通过 Embedding 将片段文本转换为向量后，将片段文本连同片段向量存入向量数据库中的过程叫做索引。

第二阶段：召回与重排

第二阶段主要包含查询转换、向量化搜索和重新排名等过程，我们一个个概念说。

1. 召回

   召回就是搜索与用户问题相关的片段过程，大致可以描述如下：
   用户输入问题 -> Embedding（Embedding 下文有专门说到） -> 转换为向量 -> 向量数据库 -> 查询与用户问题相近的片段 -> 召回结果

   需要注意的是，向量数据库查询与用户问题相近的片段这一过程，我们叫做向量相似度计算。向量相似度计算方式有很多种，目前比较常见的有余弦相似度、欧式距离、点积等。

2. 重排

   重排做的事情就是重新排序，它做的事情跟召回类似，对召回结果中的相似片段进行二次评估，从而找到跟用户问题更为相似和接近的片段作为重排结果，提升回答的准确性。跟召回不同的是，重排阶段使用了一个更小、更专业的重排模型，它在提升准确性的同时也带来了更大的开销和成本，因此重排阶段不能跟召回混在一起。

第三阶段：生成

最后这个阶段比较好理解，生成最终答案。

在第二阶段得到重排结果后，系统将经过重新排名后的、最相关的文档块内容，与用户的原始查询组合在一起，形成一个全新的、内容丰富的“增强提示”（Augmented Prompt）。这是一个关键的提示工程（Prompt Engineering）步骤。提示语会明确地指示LLM，将提供的文档块作为其回答的唯一事实依据。

这个增强提示被发送给LLM。模型被要求在严格遵循所提供上下文的基础上，综合信息，并以流畅、连贯的自然语言生成对用户原始问题的回答。这种“有约束的生成”是RAG的核心机制，它将LLM的创造力引导到基于事实的轨道上，从而确保了答案的准确性和可靠性。

最后，生成的答案会呈现给用户。一个设计良好的RAG系统通常会附上答案所依据的来源信息，例如源文档的名称、链接或具体段落的引用 。这种透明度不仅增强了用户的信任感，也为需要审计和验证的专业场景提供了必要支持。

RAG 系统的核心组件说明

上面说完了 RAG 大致的工作流程，下面来说一下 RAG 系统中常见的核心组件。

文本拆分器

上面说到了 RAG 系统的流程第一阶段就需要对数据源进行分片，分片的方式有多种，例如可以对数据源按字数分片、按段落分片、按章节分片和按页码分片等。这其中需要我们的 RAG 能够具备分片的能力，例如常见的 LangChain 就提供了多种文本拆分器，可以满足对数据源进行不同分片方式的场景。

Embedding

Embedding 说简单点就是将文本转换为向量的过程。

我以一个二维向量为例，假设 “某产品的工作电压是 210V～250V 之间” 这个文本片段对应的向量是 [1,2]，“某产品的最佳工作电压是 220V” 这个文本片段对应的向量是 [1,1]，“某产品保修 3 年” 这个文本片段对应的向量是 [-3,-1]，容易看到，前两个文本片段包含的内容比较接近，转化为向量后，向量也是十分接近的，而第三个文本片段和前两个内容差距比较大，转化为向量后差别也比较大，这正是 Embedding 的意义，含义相近的文本在做 Embedding 之后，向量也是相近的。

现在假设用户的问题是 ”某产品应该在多大的电压下工作“，在对用户问题做 Embedding 之后得到一个向量，我们就可以根据向量相似度找到与之相近的向量文本片段，从而将用户问题和相近的文本片段一起丢给大模型，大模型就可以根据这些信息生成最终的答案。

向量数据库

向量数据库是 RAG 系统的基石头，它负责存储和检索嵌入向量，常见的主流的向量数据库有 Pinecone 和 ChromaDB 等。

MCP 架构

MCP 的核心架构遵循客户端-服务器模型，主要包含三个组件：

1. MCP 主机（MCP Host）：指的是希望通过 MCP 利用外部数据或工具的应用程序。例如 AI 助手（如 Claude Desktop）、集成开发环境（IDE）、或其他 AI 工具。MCP Host 负责管理 MCP 客户端实例，并控制权限和安全策略。
2. MCP 客户端（MCP Client）：嵌入在主机应用程序中，是实现 MCP 协议客户端逻辑的部分。它负责与一个或多个 MCP 建立并维护安全、一对一的连接，管理通信、状态和能力协商。
3. MCP 服务器（MCP Server）：是实现协议服务器端逻辑的程序。它连接到具体的数据源（本地文件、数据库等）或远程服务（API），并通过 MCP 协议暴露其能力。MCP Server 可以是本地进程，也可以是远程服务。

MCP Server 暴露的核心能力

MCP Server 主要向客户端暴露三种类型的能力，是 AI 模型能够更深入地理解上下文并执行任务：

1. Resources：提供 AI 模型可以读取的类文件数据或上下文信息。这可以包括文件内容、数据库记录、API 响应、系统信息或应用程序状态等 。例如，文件系统服务器可以暴露本地文档作为资源，数据库服务器可以暴露查询结果作为资源。AI 模型可以将这些资源加载到其上下文中，以获取执行任务所需的信息。
2. Tools：定义 AI 模型可以（在用户批准后）调用的函数或操作 。这些工具使 AI 能够执行计算、访问外部 API、查询数据库、操作文件或与外部系统交互 。例如，GitHub 服务器可能提供 create_issue 或 list_repositories 等工具 。工具是实现“代理行为”（Agentic Behavior）的关键，让 AI 从信息处理者转变为任务执行者。
3. Prompts：提供预定义的、可重用的提示模板或工作流，通常可以通过斜杠命令或菜单选项触发，以帮助用户或 AI 模型完成特定任务 。这有助于引导交互、结构化请求，并确保一致性。

通过以上三种能力的组合，MCP Server 极大地扩展了 AI 模型的功能边界，使其能够更有效地与现实世界的数据和系统进行交互。

MCP 解决了哪些问题

MCP 通过标准化协议解决了 AI 工具在实际应用中面临的两大核心问题：数据接入的局限性和任务执行的缺失。

在 MCP 出现之前，通用大语言模型（LLM）的训练数据是有限的，它只能来自公开的数据源。在实际使用场景下，我们往往需要使用多个不同的数据源作为 LLM 的上下文语料输入，例如：在 AI 工具里，我需要同时使用本地文件的一些资料和高德地图以及 github 的资源，在这种场景下，一般都需要单独定制开发；再比如，我需要 AI 工具帮我在本地 terminal 执行一些命令时，往往需要借助系统提供的 api 来完成。

那么，再有了 MCP 以后，上述场景变成了什么样子的呢？现在可以使用不同的 MCP Server，用一个标准的、通用的协议来完成上述事情。比如，我可以配置本地 file 和 terminal 的 MCP，github 和 高德也都有官方提供的 MCP Server，我们只需要进行一些简单的配置，就可以通过自然语言来描述我们的需求，AI 工具（也叫 MCP Host）会自动选择合适的 MCP Client 和 对应的 MCP Server 通信，来完成各种复杂的任务。

总得来说，MCP 通过以下方式解决了上述问题：

• 提供标准化的交互方式：MCP 为 AI 工具提供了一种标准化的方法来发现和调用外部系统中的操作。它充当了AI“理解”与“执行”之间的桥梁，使AI不仅能回答问题，更能主动完成任务。
• 简化集成开发：通过标准化的协议，MCP大大降低了开发者为AI构建与关键工具安全集成的难度和时间成本。
• 提高 AI 工具间的可替换性：由于采用了统一标准，相似类型的应用（如不同的云存储服务）在MCP服务器实现上会很相似，使得在它们之间切换变得非常简单，可能只需要修改几行代码，而无需重写整个集成。

工作原理

通信协议：JSON-RPC 2.0

MCP 的核心通信机制建立在 JSON-RPC 2.0 协议之上。这是一种轻量级的远程过程调用（RPC）协议，使用 JSON 作为数据格式。选择 JSON-RPC 2.0 提供了几个优势：

• 标准化：它是一个成熟且广泛理解的标准，简化了不同语言和平台之间的互操作性。
• 轻量级：JSON 格式简洁，易于解析，开销较低。
• 支持多种消息类型：JSON-RPC 2.0 定义了请求（Request）、响应（Response，包括成功结果 Result 和错误 Error）以及通知（Notification）等消息类型，满足了 MCP 所需的双向、有状态通信需求。
• 状态管理：MCP 利用 JSON-RPC 建立有状态的连接，支持能力协商、进度跟踪、取消操作和错误报告等高级功能。

所有通过 MCP 传输层发送的消息（无论是请求、响应还是通知）都遵循 JSON-RPC 2.0 的规范进行编码和解码。

传输层：STDIO 与 SSE

MCP 协议本身是与传输层无关的，但它定义了两种标准的传输机制，用于在客户端和服务器之间实际传输 JSON-RPC 消息：

1. STDIO (Standard Input/Output):
   • 机制：在这种模式下，MCP 客户端（通常在主机应用内）将 MCP 服务器作为一个子进程启动。服务器通过其标准输入（stdin）读取来自客户端的 JSON-RPC 消息，并将响应或通知写入其标准输出（stdout）。
   • 适用场景：这是本地集成的理想选择，即客户端和服务器在同一台机器上运行时。它设置简单，通信效率高，适用于进程间通信。官方建议客户端尽可能支持 stdio。许多 SDK 提供内置的 STDIO 传输实现。
   • 由于通信限制在本地进程间，通常被认为相对安全，但仍需注意服务器进程的权限管理。
2. Streamable HTTP (with SSE - Server-Sent Events):
   • 机制：这种模式下，服务器作为一个独立的进程运行（可能在远程机器上），能够处理多个客户端连接。客户端通过标准的 HTTP POST 请求向服务器发送 JSON-RPC 消息。服务器可以使用 Server-Sent Events (SSE) 技术通过一个持久的 HTTP 连接向客户端流式发送响应、通知或服务器发起的请求。客户端也可以通过 HTTP GET 请求启动 SSE 流，以便服务器可以主动向客户端发送消息。
   • 适用场景：适用于需要网络通信的场景，例如连接到远程服务器或基于 Web 的应用。它利用了广泛使用的 HTTP 协议，易于穿透防火墙。微软 Copilot Studio 目前仅支持 SSE 传输。
   • 安全：由于涉及网络通信，安全性变得尤为重要。必须使用 TLS 加密传输。服务器需要实施严格的认证和授权机制，并验证请求来源（例如，检查 Origin 头）以防止 DNS 重绑定等攻击。实现者需要仔细处理连接管理、错误恢复（SSE 支持通过 Last-Event-ID 头进行断线重连）和潜在的拒绝服务攻击。

工作流程

当用户与支持 MCP 功能的 AI 工具交互时，会进行一系列的通信过程。

协议握手

1. 连接初始化（Initial connection）：交互开始，MCP Host 通过 MCP Client 连接到已经配置好的每个 MCP Server；
2. 能力发现（Capability discovery）：MCP Host 会询问每个 MCP Server：“你可以提供什么能力？”，每个 MCP Server 会响应自身可以提供的功能、可以调用的工具等；
3. 登记注册（Registration）：MCP Host 登记注册每个 MCP Server 的能力，以便在后续交互过程中决定请求哪个 MCP Server。

下面以询问 “杭州今天天气怎么样？”为例来介绍整个流程。

1. 需求识别：MCP Host 分析识别问题，识别到此任务需要获取外部数据源的实时信息；
2. 工具或资源选择：MCP Host 确定需要使用 MCP 来完成此任务；
3. 权限请求：MCP Client 确认是否有访问外部数据源的权限；
4. 请求过程：权限一旦得到确认，MCP Host 便调用相应的 MCP Client 使用标准的协议格式向对应的 MCP Server 发送请求；
5. 外部处理：MCP Server 收到来自 MCP Client 的请求，开始调用外部资源进行处理，如：查询天气服务、房访问文件系统或访问数据库；
6. 返回结果：MCP Server 将处理后的结果以标准化格式返回给 MCP Client；
7. 上下文整合：MCP Host 将返回的结果结合上下文环境进行结果整合；
8. 生成响应：MCP Host 根据整合后的上下文生成最终的结果返回给用户。

配置与开发

配置

MCP 的使用配置也相对简单。

首先需要选用支持 MCP 功能的 MCP Host，如 Claude Desktop、cursor、cline、trae 等，将 MCP Server 集成到 MCP Host 中，配置的核心就是告诉 MCP Host 如何启动和与 MCP Server 通信。

• 通用配置元素：配置通常涉及以下信息：

  • 命令（Command）：启动服务器进程的可执行文件或命令（例如 npx, python, docker）
  • 参数（Args）：传递给启动命令的参数列表（例如脚本路径、服务器选项、要暴露的目录等）
  • 环境变量（Env）：为服务器进程设置的环境变量（例如 API 密钥、访问令牌、数据库连接字符串等）

• Claude Desktop 配置示例（clause_desktop_config.json）：

  Clause Desktop 使用一个 JSON 文件（通常位于 ~/Clause/clause_desktop_config.json）来配置 MCP Server，其基本结构如下：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  { "mcpServers": { "server-identifier-1": { "command": "command_to_run_server_1", "args": ["arg1", "arg2"], "env": { "API_KEY": "your_api_key_here" } }, "server-identifier-2": { "command": "docker", "args": [], "env": { "GITHUB_TOKEN": "<YOUR_GITHUB_TOKEN>" } } } }

  • mcpServers 是包含所有 MCP Server 配置的顶层对象
  • server-identifier-1，server-identifier-2 是为每个 MCP Server 指定的唯一标识符（例如：filesystem，github，minecraft）

备注：上述只是介绍了使用 Claude Desktop 配置 MCP Server 的示例，其他的工具比如 cursor、trae 等现在都提供了比较简单的配置方式和交互路径，没有什么难度。

开发

我们可以根据实际场景开发自己的 MCP Client 和 MCP Server，为了简化整个开发流程，官方和社区提供了多种语言的 SDK 和框架，这些 SDK 封装了协议的复杂性，提供了更高级别的抽象。

• 官方主要 SDK：
  • TypeScript/JavaScript
  • Python
  • Java/Kotlin（包括对 Spring 的支持）
  • Go
  • Swift
• SDK 特性：
  • 核心 MCP Client 和 MCP Server 实现
  • 内置的传输层实现（如 STDIO 和 SSE），通常无需外部 Web 框架即可使用
  • 对同步和异步编程范式的支持
  • 用于定义和处理能力的辅助类和函数
  • 协议版本协商、列表变更通知等协议功能的实现

比较与总结

MCP 提供了一种独特的 AI 集成方法，与其他现有技术既有重叠也有区别，最后再来简单总结一下 MCP 与其他集成工具的区别：

• MCP vs 传统 API 调用：

  • 范围：传统 API 是通用的软件接口；MCP 专为 AI 与外部世界交互而设计，侧重于以标准化方式提供上下文（资源）、动作（工具）和引导（提示）
  • 抽象层级：直接调用 API 需要 AI 或其宿主应用处理认证、请求格式化、错误处理等细节。MCP Server 则封装了这些细节，为 AI 提供了一个更高层次、更一致的接口
  • 集成复杂度：MCP 旨在解决 N×M 的集成难题，通过标准化接口减少所需的连接数量

• MCP vs RAG（Retrieval-Augmented Generation）：

  • 交互模式：RAG 主要是一种被动的信息检索机制，通过从知识库（通常是向量数据库）中查找相关文本片段并注入提示词来增强 LLM 的上下文 。MCP 则支持主动交互，AI 可以通过“工具”执行实时查询、调用 API 或执行操作，而不仅仅是检索静态文本
  • 数据时效性：RAG 依赖于预先索引的数据，可能存在时效性问题。MCP 可以直接访问实时数据源
  • 计算开销：RAG 通常需要计算密集型的嵌入生成和向量搜索。MCP 的直接访问模式可以避免这部分开销
  • 关系：MCP 和 RAG 并非完全互斥，可以互补。例如，一个 MCP Server 可以实现一个“工具”，该工具的功能是执行向量数据库查询，从而将 RAG 的能力整合到 MCP 框架下

  备注：我本人对 RAG 也十分感兴趣，后面肯定会单独研究一下 RAG。

• MCP vs 框架工具（如 LangChain Tools）：

  • 标准化层面：LangChain 等框架提供了一个开发者面向的标准（例如，其 Tool 类接口），用于在代码层面集成工具。MCP 则提供了一个模型（或运行时 Agent）面向的标准，允许 AI Agent 在运行时发现和使用任何符合 MCP 规范的服务器暴露的工具，即使这些工具在编写 Agent 代码时是未知的
  • 互补性： 这两者是高度互补的。LangChain 已经提供了适配器，可以将 MCP Server 暴露的工具视为 LangChain 工具来使用 。开发者可以使用 LangChain 来构建 Agent 的逻辑流程，同时利用 MCP 作为与外部工具交互的标准化接口

结来说，MCP 的核心优势在于其开放性、标准化和对主动交互（工具执行）的强调，旨在创建一个更统一、更灵活的 AI 集成生态系统。然而，它的成功依赖于是否被广泛的采纳，并且它将集成的复杂性从直接 API 调用转移到了实现和维护符合协议标准的服务器上。

（全文完）

Refrence

1. https://modelcontextprotocol.io/introduction – MCP 官方文档

进入正文之前先来简单说一下几个概念和 Paxos 的由来。

分布式一致性问题

在分布式计算领域，一个核心且基础的挑战是如何让一组独立的计算机（或称为节点、进程）在可能发生故障（如节点崩溃、网络消息丢失或延迟）的环境下，就某个值或状态达成一致 。这个问题被称为共识（Consensus）。达成共识的能力对于构建可靠的分布式系统至关重要，这些系统需要在多个副本之间维护数据一致性，例如分布式数据库、分布式锁服务、以及实现状态机复制（State Machine Replication）等场景 。状态机复制是一种强大的技术，它允许将任何单机上的确定性算法转化为一个容错的、分布式的实现，确保即使部分副本发生故障，整个系统对外也能表现得像一个永不宕机的单体服务 。

一个健壮的共识算法通常需要满足几个关键属性：

1. 有效性（Validity）：最终被选定的值必须是某个进程实际提议过的值。
2. 一致性（Agreement/Consistency）：所有做出决定的正常进程必须对同一个值达成一致 。这是共识最核心的保证。
3. 完整性（Integrity）：每个进程最多只能决定一个值。
4. 可终止性（Termination/Liveness）：所有正常的进程最终都能做出决定。
5. 容错性（Fault Tolerance）：算法必须能够在一定数量的进程失败或网络异常的情况下继续运行并达成共识。

分布式一致性问题可以简单描述为：如何确保分布式系统中的多个节点对某个值达成一致，即使在部分节点故障或网络不可靠的情况下。

Paxos 的诞生

Paxos 算法由 Leslie Lamport 于 1989 年首次提出，并在 1998 年发表论文《The Part-Time Parliament》。由于这篇论文使用了一个古希腊 Paxos 岛上的议会作为比喻，晦涩难懂，直到 2001 年 Lamport 又发表了《Paxos Made Simple》，才使这个算法被更广泛地理解和应用。

Paxos 算法解决的核心问题是：在一个可能发生节点宕机或网络异常的分布式系统中，如何就某个值达成一致，使得系统满足一致性（所有节点最终达成相同的决定）和安全性（一旦某个值被选定，就不会被改变）。

Paxos 算法之所以如此重要，是因为它为分布式系统中的一个核心问题提供了第一个经过严格证明的、可在异步网络模型下容忍非拜占庭故障（non-Byzantine failures，即节点只会崩溃或丢失消息，不会恶意发送错误信息）的解决方案。

• 保证一致性（Safety）：Paxos 最核心的贡献在于它提供了一种机制，确保即使在节点崩溃、消息丢失、延迟或乱序的情况下，系统中的所有节点最终也能就某个值达成唯一的、一致的决定 。它保证了“只选出最多一个值”（Agreement）和“被选出的值必须是提议过的值”（Validity）这两个关键的安全属性。
• 容错性（Fault Tolerance）：Paxos 算法通过其核心的“法定人数”（Quorum）机制，能够容忍少数节点（通常是少于半数）的失效。只要大多数节点（一个 Quorum）能够正常工作并相互通信，系统就能继续就新的值达成共识 。
• 分布式系统的基石：Paxos 不仅仅是一个理论算法，它为构建实际的、高可用的分布式系统奠定了基础。许多关键的工业级系统，如 Google 的 Chubby 锁服务、微软的 Autopilot 集群管理系统，以及亚马逊、IBM 等公司的许多内部系统，都使用了 Paxos 或其变种来实现核心的协调和一致性保证 。同时，Paxos 的思想也深刻影响了后续共识算法（如 Raft ）的设计。

Paxos 的出现，标志着分布式系统理论的一个重大突破，它成功地将严谨的理论证明与解决实际工程挑战（如构建容错数据库、文件系统等）的需求结合起来。它证明了在充满不确定性的分布式环境中，实现可靠的一致性是可能的，为现代大规模分布式计算系统的发展铺平了道路。

应用场景

Paxos 算法在现代分布式系统中有广泛应用：

1. 分布式数据库 ：如 Google 的 Spanner、Cockroach DB 等
2. 分布式锁服务 ：如 Google 的 Chubby
3. 配置管理 ：如 ZooKeeper（虽然 ZooKeeper 使用的是 Paxos 的变种 ZAB 协议）
4. 共识系统 ：如区块链中的共识机制

Paxos 算法原理和详细实现过程

Paxos 中的角色

Paxos 算法中定义了三种角色：

1. Proposer（提议者） ：提出提案，提案包括提案编号和提案的值。
2. Acceptor（接受者） ：接收提案并决定是否接受。
3. Learner（学习者） ：不参与决议，只学习被批准的提案。

在实际实现中，一个节点可以同时扮演多个角色。这种角色的分离，特别是 Acceptor 作为核心状态维护者的设计，为 Paxos 提供了灵活性。例如，Proposer 的选举（通常为了提高效率而选出一个 Leader）可以独立于核心共识逻辑进行，而 Learner 的实现方式也可以多样化。然而，Acceptor 的正确性和状态持久性是保证整个协议安全性的基石。任何对 Acceptor 状态的访问和修改都需要严格的并发控制和持久化保证。

算法流程

在深入之前，有必要再强调一下提案编号（Proposal Number）的关键作用：

• 唯一性与全序性：每个 Proposer 发起的每一次提议尝试都必须使用一个比它之前使用过的任何编号都大的、全局唯一的编号 。这通常通过组合一个单调递增的计数器（或高精度时间戳）和 Proposer 自身的唯一标识符来实现。
• 建立优先级：提议编号的大小决定了提议的优先级。Acceptor 只会响应（Promise）或接受（Accept）编号大于等于其已承诺的最高编号的提议。这确保了协议的进展总是朝着更新（编号更大）的提议方向进行。
• 保证一致性：提议编号是 Paxos 安全性的核心。通过要求 Proposer 在第二阶段选择的值必须基于第一阶段从多数 Acceptor 处了解到的、具有最高编号的已接受值，Paxos 巧妙地利用提议编号的顺序来确保一旦某个值被选定，后续更高编号的提议也只能选定相同的值。

Paxos 算法分为两个阶段：

阶段一：准备（Prepare）与承诺（Promise）

这个阶段的目标是让一个 Proposer 获得“领导权”（即一个被多数 Acceptor 承诺接受的提议编号），并发现是否存在任何可能已经被选定的值。

• （1a）Prepare 消息：
  • Proposer 想要提议一个值（比如 v），它首选选择一个新的、唯一的、比它之前用过的都大的提议编号 n
  • Proposer 向一个 法定人数（Quorum） 的 Acceptor 发送 Prepare(n) 消息。
• （1b）Promise 响应：
  • 当一个 Acceptor 收到 Prepare(n) 消息时，它会比较 n 和它已经记录的已响应过的最高 Prepare 请求编号 max_prepare。
  • 情况 1：n 大于该 Acceptor 已经响应过的所有 Prepare 请求的编号，则该 Acceptor 必须：
    1. 将 max_prepare 更新为 n，并持久化这个状态。
    2. 向 Proposer 返回一个 Promise(n, prev_accepted_n, prev_accepted_v) 消息。
       • prev_accepted_n 是这个 Acceptor 之前接受过的提议中编号最高的那个提议编号（如果没有接受过任何提议，则为空或者置为特殊值，如 0 或 -1）。
       • prev_accepted_v 是对应 prec_accepted_n 的值（如果 prev_accepted_n 为空，则此值也为空）。
    3. 这个 Promise 响应意味着 Acceptor 承诺：它未来不会再接受任何编号小于 n 的提议，也不会再响应任何编号小于 n 的 Prepare 请求。
  • 情况 2：n 小于 max_prepare，这表示收到了一个过时的 Prepare 请求（可能来自网络延迟，或者有其他的 Proposer）已经发起了更高编号的提议，Acceptor 可以选择：
    1. 直接忽略这个 Prepare(n) 消息。
    2. 或者可以优化一下，回复一个 Nack(n, max_prepare) 拒绝的消息，告知 Proposer 它的提议编号太旧了，让 Proposer 可以更快放弃或重试。

阶段二：接受（Accept）与已接受（Accepted）

如果 Proposer 成功从多数 Acceptor 那里获得了对提议编号 n 的 Promise，它就可以进入第二阶段，尝试让一个具体的值被接受。

• （2a）Accept 消息
  • Proposer 收集来自 Quorum 的 Promise(n, prev_n, prev_v) 响应。
  • 关键决策：选择要提议的值 v_proposal 。
    1. Proposer 检查所有收到的 Promise 响应中携带的 (prev_n, prev_v)。
    2. 如果存在任何 prev_v 不为空的响应（即至少有一个 Acceptor 之前接受过某个值），Proposer 必须选择所有报告的 (prev_n, prev_v) 中具有最高 prev_n 的那个 prev_v 作为它本次要提议的值 v_proposal。
    3. 如果所有收到的 Promise 响应中的 prev_v 都为空（即这个 Quorum 中的 Acceptor 之前都没有接受过任何值），那么 Proposer 可以自由选择它最初想要提议的值 v_original 作为 v_proposal。
  • 一旦确定了 v_{proposal}，Proposer 就向之前回复了 Promise 的那个 Quorum（或者另一个 Quorum，通常是同一个）发送 Accept(n, v_proposal) 消息。
• （2b）Accepted 响应：
  • 当一个 Acceptor 收到 Accept(n, v) 消息时，它会检查 n 是否大于或等于它记录的 max_prepare。注意：这里允许等于 n，因为 Acceptor 在阶段 1b 已经承诺了不接受小于 n 的提议，但接受等于 n 的提议是允许的，并且是协议正确运行所必需的。
  • 情况 1：n > max_prepare。Acceptor 接受这个提议：
    1. 记录下接受的提议编号 accepted_proposal_number = n 和接受的值 accepted_value = v（并持久化这些状态）。
    2. 向 Proposer 和所有 Learner 发送 Accepted(n, v) 消息。
  • 情况 2：n < max_prepare。这表示 Acceptor 在回复 Promise(n) 之后，又收到了一个更高编号的 Prepare(n') 并回复了 Promise(n')。根据承诺，它不能再接受编号为 n 的提议了。因此，它会忽略这个 Accept(n, v) 消息。

共识达成：当一个值 v 被一个 Quorum（多数）的 Acceptor 接受（即它们都发送了 Accepted(n, v) 消息，对于某个特定的 n），那么这个值 v 就被 Paxos 协议**选定（chosen）**了。Learner 通过收集这些 Accepted 消息来得知结果。

这个两阶段过程的核心机制在于：阶段一的 Prepare/Promise 交互强制任何想要成为“领导者”（获得批准的 Proposer）的进程，必须先去了解并尊重可能已经发生的“历史”（即被 Quorum 接受的值），然后才能在阶段二提出自己的（可能被修正过的）主张。 如果 Quorum 中的 Acceptor 报告了之前接受的值，新的 Proposer 就失去了自由选择值的权利，必须延续那个已被接受（或趋向于被接受）的值。正是这种机制，保证了即使有多个 Proposer 并发尝试，或者 Proposer 在过程中失败，最终也只会有一个值被稳定地选定。

算法特性

法定人数（Quorum）的概念：保证多数一致

Quorum 在 Paxos 中扮演着至关重要的角色，它是保证算法安全性和容错性的数学基础。

• 定义：一个 Quorum 是 Acceptor 集合的一个子集，其大小通常定义为严格超过半数。在一个包含 N 个 Acceptor 的系统中，Quorum 的大小通常是 ⌊N/2⌋+1。例如，在有 5 个 Acceptor 的系统中，Quorum 大小是 3；在有 3 个 Acceptor 的系统中，Quorum 大小是 2 。
• Quorum 交集属性：Quorum 的核心特性是任意两个 Quorum 必须至少有一个共同的成员 。这是集合论的一个简单结果（如果两个子集都包含超过半数的元素，它们的交集不可能是空的）。
• 保证安全性（Safety）：Paxos 利用 Quorum 交集属性来确保一致性。
  • 在阶段一，Proposer 必须从一个 Quorum 的 Acceptor 处获得 Promise。
  • 在阶段二，Proposer 必须将 Accept 请求发送给一个 Quorum 的 Acceptor，并且一个值只有被一个 Quorum 的 Acceptor 接受才算被选定。
  • 假设一个值 v 在提议 m 中被一个 Quorum Q_1 接受了。现在，如果另一个 Proposer 发起了更高编号的提议 n > m，它必须在阶段一从某个 Quorum Q_2 获得 Promise。由于 Q_1 和 Q_2 必然有交集，Proposer n 在阶段一必定会联系到至少一个接受了 (m, v) 的 Acceptor。这个 Acceptor 会在 Promise 响应中报告 (m, v)。根据阶段二的规则，Proposer n 必须选择具有最高编号的已接受值，因此它也只能提议值 v（或者是在 m 和 n 之间被选定的某个值，通过归纳法可知也必须是 v）。这样就保证了不会有与 v 不同的值在更高的提议编号中被选定。
• 提供容错性（Fault Tolerance）：Quorum 机制使得 Paxos 能够容忍少数 Acceptor 的失败。在一个有 N = 2F + 1 个 Acceptor 的系统中，只要至少有 F + 1 个 Acceptor（即一个 Quorum）能够正常工作并相互通信，系统就能继续运行 Prepare 和 Accept 阶段，从而达成共识 。系统可以容忍最多 F 个 Acceptor 同时发生故障。
• 动态 Quorum：虽然 Basic Paxos 通常使用静态的、基于多数的 Quorum，但在更高级的系统中，有时会考虑动态调整 Quorum 配置（例如，增减节点）。但这本身就是一个需要通过共识来安全完成的操作，以避免在配置变更期间引入不一致性。

算法难点与挑战

1. 活锁问题 ：多个 Proposer 可能会不断地相互抢占，导致没有提案能被选定。解决方法是引入随机延迟或选举一个主 Proposer。
2. 恢复问题 ：节点故障恢复后如何获取最新状态。
3. 多轮决议 ：实际系统中需要连续对多个值达成一致，需要引入实例编号。

代码实现

下面是一个基于 Golang 版本的 Paxos 算法的简易实现。

基础数据结构定义

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// ProposalID 表示提案编号
type ProposalID struct {
    Number int
    NodeID string
}

// Value 表示提案的值
type Value interface{}

// PrepareRequest 表示准备请求
type PrepareRequest struct {
    ProposalID ProposalID
}

// PrepareResponse 表示准备响应
type PrepareResponse struct {
    ProposalID    ProposalID
    AcceptedID    *ProposalID
    AcceptedValue Value
    Ok            bool
}

// AcceptRequest 表示接受请求
type AcceptRequest struct {
    ProposalID ProposalID
    Value      Value
}

// AcceptResponse 表示接受响应
type AcceptResponse struct {
    ProposalID ProposalID
    Ok         bool
}

Acceptor 实现

Acceptor 是 Paxos 算法中的关键角色，负责接收和响应 Proposer 的请求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

package paxos

// Acceptor represents a node that can accept proposals in the Paxos protocol
type acceptor struct {
    promisedID    *ProposalID
    acceptedID    *ProposalID
    acceptedValue Value
}

// NewAcceptor creates a new Acceptor instance
func NewAcceptor() Acceptor {
    return &acceptor{}
}

// HandlePrepare processes a prepare request from a proposer
func (a *acceptor) HandlePrepare(request PrepareRequest) PrepareResponse {
    // If we haven't promised anyone yet, or this proposal is higher than our promise
    if a.promisedID == nil || (request.ProposalID.Number > a.promisedID.Number) {
        a.promisedID = &request.ProposalID
        return PrepareResponse{
            ProposalID:    request.ProposalID,
            AcceptedID:    a.acceptedID,
            AcceptedValue: a.acceptedValue,
            Ok:           true,
        }
    }

    // Reject if the proposal number is less than what we've promised
    return PrepareResponse{
        ProposalID: request.ProposalID,
        Ok:         false,
    }
}

// HandleAccept processes an accept request from a proposer
func (a *acceptor) HandleAccept(request AcceptRequest) AcceptResponse {
    // Accept only if the proposal ID is greater than or equal to what we've promised
    if a.promisedID == nil || request.ProposalID.Number >= a.promisedID.Number {
        a.promisedID = &request.ProposalID
        a.acceptedID = &request.ProposalID
        a.acceptedValue = request.Value
        return AcceptResponse{
            ProposalID: request.ProposalID,
            Ok:         true,
        }
    }

    // Reject if the proposal number is less than what we've promised
    return AcceptResponse{
        ProposalID: request.ProposalID,
        Ok:         false,
    }
}

在上面的代码中，promisedId 是 Acceptor 承诺过的最高提案编号，acceptedId 和 acceptedValue 分别是已接受的提案编号和值。

Proposer 实现

Proposer 负责发起提案并协商整个一致性过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

package paxos

import (
    "fmt"
    "math/rand"
    "time"
)

// Proposer represents a node that proposes values in the Paxos protocol
type proposer struct {
    nodeID        string
    proposalNum   int
    acceptors     []Acceptor
    quorumSize    int
}

// NewProposer creates a new Proposer instance
func NewProposer(nodeID string, acceptors []Acceptor) Proposer {
    return &proposer{
        nodeID:      nodeID,
        proposalNum: 0,
        acceptors:   acceptors,
        quorumSize:  len(acceptors)/2 + 1,
    }
}

// Propose attempts to get a value accepted by a majority of acceptors
func (p *proposer) Propose(value Value) (bool, Value) {
    for {
        // Generate a new proposal ID
        p.proposalNum++
        proposalID := ProposalID{
            Number: p.proposalNum,
            NodeID: p.nodeID,
        }
        
        // Phase 1: Prepare
        prepareResponses := p.sendPrepareRequests(proposalID)
        
        // Check if we got a majority of OKs
        if len(prepareResponses) < p.quorumSize {
            // Wait a bit before retrying to avoid live-lock
            time.Sleep(time.Duration(rand.Intn(100)) * time.Millisecond)
            continue
        }
        
        // If any acceptor already accepted a value, we must use the value
        // with the highest proposal number
        highestAcceptedID := p.findHighestAcceptedProposal(prepareResponses)
        valueToPropose := value
        
        if highestAcceptedID != nil {
            for _, resp := range prepareResponses {
                if resp.AcceptedID != nil && 
                   resp.AcceptedID.Number == highestAcceptedID.Number &&
                   resp.AcceptedID.NodeID == highestAcceptedID.NodeID {
                    valueToPropose = resp.AcceptedValue
                    break
                }
            }
        }
        
        // Phase 2: Accept
        acceptResponses := p.sendAcceptRequests(proposalID, valueToPropose)
        
        // Check if we got a majority of OKs
        if len(acceptResponses) >= p.quorumSize {
            return true, valueToPropose
        }
        
        // Wait a bit before retrying to avoid live-lock
        time.Sleep(time.Duration(rand.Intn(100)) * time.Millisecond)
    }
}

// sendPrepareRequests sends prepare requests to all acceptors
func (p *proposer) sendPrepareRequests(proposalID ProposalID) []PrepareResponse {
    var okResponses []PrepareResponse
    
    for _, acceptor := range p.acceptors {
        resp := acceptor.HandlePrepare(PrepareRequest{ProposalID: proposalID})
        if resp.Ok {
            okResponses = append(okResponses, resp)
        }
    }
    
    return okResponses
}

// sendAcceptRequests sends accept requests to all acceptors
func (p *proposer) sendAcceptRequests(proposalID ProposalID, value Value) []AcceptResponse {
    var okResponses []AcceptResponse
    
    for _, acceptor := range p.acceptors {
        resp := acceptor.HandleAccept(AcceptRequest{
            ProposalID: proposalID,
            Value:      value,
        })
        if resp.Ok {
            okResponses = append(okResponses, resp)
        }
    }
    
    return okResponses
}

// findHighestAcceptedProposal finds the highest proposal ID among accepted proposals
func (p *proposer) findHighestAcceptedProposal(responses []PrepareResponse) *ProposalID {
    var highest *ProposalID
    
    for _, resp := range responses {
        if resp.AcceptedID != nil {
            if highest == nil || 
               resp.AcceptedID.Number > highest.Number ||
               (resp.AcceptedID.Number == highest.Number && 
                resp.AcceptedID.NodeID > highest.NodeID) {
                highest = resp.AcceptedID
            }
        }
    }
    
    return highest
}

Learner 实现

Learner 不参与提案，它只学习被批准的提案。Learner 接收来自 Acceptor 的消息，当收到来自多数（一个 Quorum）Acceptor 的关于同一个提议（相同编号和值）的 Accepted 消息时，Learner 就知道这个值已经被选定，随之可以将选定的值应用于本地状态或通知客户端。

注意：Learner 的失败通常不影响 Paxos 协议达成共识的过程，但可能会影响最终结果被知晓的范围。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// Learner represents a node that learns the agreed-upon value in the Paxos protocol
type learner struct {
    mu            sync.RWMutex
    learnedValue  Value
    learnedID     *ProposalID
}

// NewLearner creates a new Learner instance
func NewLearner() Learner {
    return &learner{}
}

// Learn records a value that has been accepted by a quorum of acceptors
func (l *learner) Learn(proposalID ProposalID, value Value) {
    l.mu.Lock()
    defer l.mu.Unlock()

    // Only learn if this is a newer proposal than what we've already learned
    if l.learnedID == nil || proposalID.Number > l.learnedID.Number {
        l.learnedValue = value
        l.learnedID = &proposalID
    }
}

// GetLearnedValue returns the most recently learned value
func (l *learner) GetLearnedValue() Value {
    l.mu.RLock()
    defer l.mu.RUnlock()
    return l.learnedValue

总结一下

Paxos 算法是分布式计算领域的一项里程碑式的成就，它为在不可靠网络和节点故障环境中实现数据一致性这一核心挑战提供了第一个经过严格证明的解决方案。通过其精巧的两阶段协议和 Quorum 机制，Paxos 保证了即使在部分失败的情况下，系统也能就某个值达成唯一的共识，这对于构建可靠的分布式数据库、配置管理系统和状态机复制至关重要。

然而，Paxos 的强大功能也伴随着其众所周知的复杂性。其原始论文《The Part-Time Parliament》独特的叙事风格，以及算法本身在并发和故障场景下的微妙交互，使得 Paxos 的理解和正确实现都相当困难。正如本文在实现部分所强调的，状态管理（尤其是 Acceptor 状态的持久化）和并发控制是实现 Paxos 时需要特别注意的关键点，任何疏忽都可能破坏其安全性保证。

Basic Paxos 在理论上优先保证安全性，但牺牲了活性的保证，这导致在实践中几乎必须引入 Leader 选举机制来避免活锁并提高性能。这种对 Leader 的依赖，以及 Basic Paxos 处理一系列决策时的效率问题（每轮决策都需要完整的两阶段），催生了 Paxos 的多种变种：

• Multi-Paxos：通过选举稳定 Leader 并允许 Leader 跳过 Prepare 阶段来优化连续决策的效率，是实践中最常用的形式。
• Fast Paxos：旨在减少达成共识所需的网络延迟，允许在某些条件下（无冲突时）跳过 Prepare 阶段，用一轮消息完成共识，但可能增加冲突处理的复杂性。
• Cheap Paxos：着眼于减少维持系统容错性所需的活跃 Acceptor 数量，通过使用备份 Acceptor 来降低常规操作的资源消耗。

这些变种的存在本身就说明了原始 Paxos 设计中固有的权衡（例如，简单性 vs 效率，理论保证 vs 实践性能）。此外，对 Paxos 理解难度的普遍认同，也直接推动了旨在提供类似一致性保证但更易于理解和实现的替代算法的开发，其中最著名的就是 Raft。Raft 通过更明确地定义 Leader 角色、状态转换和日志复制机制，降低了工程师理解和实施共识算法的门槛。（后面我可能会做一下 6.824 中 Raft 的 lab，到时候可能会专门写一篇 Raft 的文章，先挖个坑吧）

总而言之，Paxos 算法以其开创性的理论贡献和在构建健壮分布式系统中的实际应用价值，奠定了其在计算机科学中的重要地位。尽管其复杂性促使了变种和替代方案的发展，但理解 Paxos 的核心原理——角色、阶段、Quorum 和安全保证——对于任何深入研究或构建分布式系统的工程师和研究人员来说，仍然是不可或缺的基础。

(全文完)

Refrence

1. Lamport, L. (1998). The Part-Time Parliament. ACM Transactions on Computer Systems (TOCS), 16(2), 133-169.
2. Lamport, L. (2001). Paxos Made Simple. ACM SIGACT News (Distributed Computing Column), 32(4), 51-58.
3. Fischer, M. J., Lynch, N. A., & Paterson, M. S. (1985). Impossibility of distributed consensus with one faulty process. Journal of the ACM (JACM), 32(2), 374-382.
4. Ongaro, D., & Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm. 2014 USENIX Annual Technical Conference (USENIX ATC 14), 305-319. (Raft 论文，作为 Paxos 的重要对比和后续发展)
5. Schneider, F. B. (1990). Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Computing Surveys (CSUR), 22(4), 299-319. (关于状态机复制的重要背景文献)
6. https://time.geekbang.org/column/article/201700, https://time.geekbang.org/column/article/202772 (极客时间 - 分布式协议与算法实战)

实验概述

本实验要求实现一个单机版的 kv server，支持 Put、Append 和 Get 三种操作。该服务保证所有的操作都必须是线性化（linearizable）的，确保操作顺序符合实时顺序，并且能够处理网络故障（例如消息丢失），保证操作只执行一次。实验目标是能够满足不同客户端以及不可靠网络等场景，确保服务器在并发和故障情况下都能够正常工作。

设计

• 线性化：通过使用 Go 的互斥锁（mutex）保护共享数据，确保并发访问时操作顺序一致。
• 网络故障处理：客户端为每个请求分配唯一序列号（sequence number），服务器通过客户端唯一标识（Client ID）和请求序列号检测重复请求，确保幂等性。
• 操作定义：
  • Put(key, value): 将键 key 的值设置为 value，覆盖原有值。需确保线程安全，并记录序列号以防重复。
  • Append(key, arg): 向键对应的值增加内容，并返回旧值，若键不存在则视为对空字符串的追加。
  • Get(key): 获取键的值，若键不存在返回空字符串。由于 Get 是只读操作，重复执行不会影响状态，无需特别处理序列号。

实现

核心数据结构设计

键值对存储

键值对存储核心的数据结构选择 map，并配合互斥锁（sync.Mutex）保证并发安全

1
2
3
4
5
6

type KVServer struct {
mu         sync.Mutex
store      map[string]string
clientSeqs map[int64]int // to track the latest sequence number for each client
}

• store: 存储键值对
• clientSeqs：记录每个客户端已经处理过的序列号，用于检测重复请求。

操作原子性

通过互斥锁保护共享资源的访问：

1
2
3
4
5
6
7
8

// Get fetches the current value for the key.
// A Get for a non-existing key should return an empty string.
func (kv *KVServer) Get(args *GetArgs, reply *GetReply) {
kv.mu.Lock()
defer kv.mu.Unlock()
  // 处理 Get 逻辑
}

每个操作在处理前先获取锁，确保同一时刻只有一个协程修改数据。

处理重复请求

为每个客户端分配唯一 ClientId，每次请求携带递增的 Seq。服务器通过 clientSeqs 记录已处理的请求：

1
2
3
4
5
6
7
8
9
10
11

if args.SeqNumber <= kv.clientSeqs[args.ClientId] {
// Repeat the request and return the historical value
reply.PreviousValue = kv.store[args.Key]
return
}

......

// update the request sequence number for the client
kv.clientSeqs[args.ClientId] = args.SeqNumber

关键步骤代码

Get

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// client.go

func (ck *Clerk) Get(key string) string {
args := GetArgs{
Key:       key,
ClientId:  ck.clientId,
SeqNumber: ck.seqNumber,
}
reply := GetReply{}
ck.seqNumber++

// send the Get RPC request
ok := ck.server.Call("KVServer.Get", &args, &reply)
if ok {
return reply.Value
}
return ""
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// server.go

// Get fetches the current value for the key.
// A Get for a non-existing key should return an empty string.
func (kv *KVServer) Get(args *GetArgs, reply *GetReply) {
kv.mu.Lock()
defer kv.mu.Unlock()

value, exists := kv.store[args.Key]
if !exists {
reply.Value = ""
} else {
reply.Value = value
}
}

Put && Append

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// client.go

func (ck *Clerk) PutAppend(key string, value string, op string) string {
args := PutAppendArgs{
Key:       key,
Value:     value,
Op:        op,
ClientId:  ck.clientId,
SeqNumber: ck.seqNumber,
}
reply := PutAppendReply{}
ck.seqNumber++

// send the RPC request
ok := ck.server.Call("KVServer."+op, &args, &reply)
if ok {
return reply.PreviousValue
}
return ""
}

func (ck *Clerk) Put(key string, value string) {
ck.PutAppend(key, value, "Put")
}

// Append value to key's value and return that value
func (ck *Clerk) Append(key string, value string) string {
return ck.PutAppend(key, value, "Append")
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// server.go

// Put installs or replaces the value for a particular key in the map.
func (kv *KVServer) Put(args *PutAppendArgs, reply *PutAppendReply) {
kv.mu.Lock()
defer kv.mu.Unlock()

if args.SeqNumber <= kv.clientSeqs[args.ClientId] {
// Repeat the request and return the historical value
reply.PreviousValue = kv.store[args.Key]
return
}

kv.store[args.Key] = args.Value
reply.PreviousValue = kv.store[args.Key]

// update the request sequence number for the client
kv.clientSeqs[args.ClientId] = args.SeqNumber
}

// Append appends arg to key's value and returns the old value.
// An Append to a non-existing key should act as if the existing value were a zero-length string.
func (kv *KVServer) Append(args *PutAppendArgs, reply *PutAppendReply) {
kv.mu.Lock()
defer kv.mu.Unlock()

if args.SeqNumber <= kv.clientSeqs[args.ClientId] {
reply.PreviousValue = kv.store[args.Key]
return
}

// find the key if exist
value, exists := kv.store[args.Key]
if !exists {
// a zero-length string
value = ""
}
// append the value
kv.store[args.Key] = value + args.Value
reply.PreviousValue = value

// update the request sequence number for the client
kv.clientSeqs[args.ClientId] = args.SeqNumber
}

总结

本实验是一个比较简单的分布式系统的入门实验。它初步提出了分布式系统中的数据一致性问题以及容错处理，在实现过程中需要考虑线性化、客户端的重复请求和网络故障处理等场景，实现较为简单，因此本文篇幅也相对较短。完整代码见本项目 Github 仓库。

Refrence

1. http://nil.csail.mit.edu/6.5840/2024/labs/lab-kvsrv.html

仔细分析发现，现实世界中有很多满足上述处理模型的例子，关于 MapReduce 的产生背景和详细的介绍本文不再详细叙述，强烈建议阅读 Google 的论文，一定会对 MapReduce 模型有更进一步的理解。

说起分布式系统，大家应该都知道 MIT 有一个明星课程 6.824，它是专门讲解分布式系统的，这个课程还设置了一系列非常有难度的实验来检验你对课程的掌握。为了进一步加深我对分布式系统的理解，前段时间我便开始完成 2024 年春季 6.824 的 5 个实验 lab（备注：6.824 以前是 4 个实验 lab，从 2024 年春季课程开始，拆分成了 5 个，但是 lab 的大体内容都是一样的，并且现在课程改名为 6.5840，其实都是一样的），本篇文章就是 MapReduce 实验的实现详解文章，以此记录实现步骤和思考过程。

6.824 历年所有的课程安排、实验 lab 和示例代码都可以在 课程官网 找到。

实验前准备

关于实验前的准备，这里我以 2024 春季课程为例。

1. 本实验是基于 Go 语言来完成的，首先需要安装 Go 的开发环境；
2. clone 实验代码，本实验运行的 main 函数已经编写好，我们只需要自己实现 Coordinator 和 Worker 以及 RPC 模块，代码仓库地址和实验标准也可以在 官网 找到。

实验详解

本实验中我们需要实现一个分布式的 MapReduce 来完成统计多个文件中每个单词出现的次数多任务。这个分布式的 MapReduce 是由一个 Coordinator 进程 和多个 Worker 进程共同完成任务。我们要完成这个任务分为两步，第一步是执行 Map 任务，第二步是执行 Reduce 任务。

执行概括

通过将 Map 调用的输入数据自动分割为 M 个数据片段的集合，Map 调用被分布到多台机器上执行。输入的数据片段能够在不同的机器上并行处理。使用分区函数将 Map 调用产生的中间 key 值分成 R 个不同分区（例如本实验中的 hash(key) mod R），Reduce 调用也被分布到多台机器上执行。分区数量（R）和分区函数由用户指定。在本实验中，R 从主函数中当作参数传入，为 10。下面是 MapReduce 执行概览图。

在 MapReduce 模型中，有一个特殊的程序叫 Coordinator（也叫做 Master），其他的程序都是 Worker 程序，由 Coordinator 分配任务给 Worker。待分配的任务被分成了两类，一类是 Map 任务，一类是 Reduce 任务，Coordinator 先将 Map 任务分配给空闲的 Worker，并记录 Worker 进程和 Map 任务的相关信息和执行结果，等所有的 Map 任务都执行结束后开始分配 Reduce 任务给空闲的 Worker，直至所有的任务结束，程序退出。

程序数据结构设计

Coordinator

Coordinator 进程只有一个，它负责任务的调度，并且记录每一个任务的状态（等待调度、执行中或已完成），同时 Cootdinator 还应该记录每个 Worker 机器（进程）的标识。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

type Phase int

const (
MapPhase Phase = iota + 1
ReducePhase
Done
)

type TaskType int

const (
MapTask    TaskType = iota + 1
ReduceTask          // reduce task
)

type TaskStatus int

const (
Waiting TaskStatus = iota + 1
Running
Finished
)

type Task struct {
Id       int        // the map task or reduce task id
WorkName string     // the worker name
TaskType TaskType   // the task type, map or reduce
Status   TaskStatus // the task state
Input    []string   // task input files, map task is only one input file
Output   []string   // task output files, reduce task is only one output file
}

type BaseInfo struct {
nReduce   int // the total number of reduce tasks
taskMap   map[TaskType][]*Task
workerMap map[string]*WorkInfo
}

type WorkInfo struct {
name           string
lastOnlineTime time.Time
}

type Coordinator struct {
phase    Phase
baseInfo *BaseInfo
timer    chan struct{}
mutex    sync.Mutex
}

Worker

Worker 进程有一个或者多个，在真实的 MapReduce 场景中，Worker 进程往往分布在不同的机器上执行以提高任务执行的效率，在本实验中所有的 Worker 进程都在一个机器上完成，可以通过起多个 Worker 进程来模拟，不过我的程序依然是按照多机器来设计的。

Worker 进程负责具体执行任务，它通过 RPC 和 Coordinator 通信。在本实验中，空闲的Worker 进程不断地向 Coordinator 发送请求获取任务，直至 MapReduce 程序退出。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

type WorkerS struct {
name    string
mapF    func(string, string) []KeyValue
reduceF func(string, []string) string
workDir string
}

// KeyValue is the key/value pire of the map functions
type KeyValue struct {
Key   string
Value string
}

// ByKey is for sorting by key
type ByKey []KeyValue

func (a ByKey) Len() int           { return len(a) }
func (a ByKey) Swap(i, j int)      { a[i], a[j] = a[j], a[i] }
func (a ByKey) Less(i, j int) bool { return a[i].Key < a[j].Key }

RPC 设计

前面说到，Coordinator 和 Worker 通过 RPC 通信，官方给出的 RPC 代码中使用了 Unix domain socket 建立连接，这里需要了解一下 Unix domain socket。

Unix domain socket 或者 IPC socket 是一种终端，可以使同一台操作系统上的两个或多个进程数据通信。与管道相比，Unix domain sockets 既可以使用字节流也可以使用数据队列，而管道只能使用字节流。Unix domain socket 的接口和Internet socket 很像，区别在于它不使用网络底层协议来通信，而是使用系统文件的地址来作为自己的身份。它可以被系统进程引用，因此两个进程可以同时打开一个 Unix domain sockets 来进行通信，不过这种通信方式是发生在系统内核里而不会在网络里传播。关于这种通信方式，下面是一个用 golang 实现的简易的服务端和客户端通信的 demo。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

// server.go

package main

import (
    "fmt"
    "io"
    "log"
    "net"
    "os"
)

func main() {
    var file string = "test.sock" //用于 unix domain socket 的文件
start:
    lis, err := net.Listen("unix", file) //开始监听
    if err != nil {                      //如果监听失败，一般是文件已存在，需要删除它
            log.Println("UNIX Domain Socket 创 建失败，正在尝试重新创建 -> ", err)
            err = os.Remove(file)
            if err != nil { //如果删除文件失败 ，要么是权限问题，要么是之前监听不成功，不管是什么 都应该退出程序，不然后面 goto 就死循环了
                    log.Fatalln("删除 sock 文件失败！程序退出 -> ", err)
            }
            goto start //删除文件后重新执行一次创建
    } else { //监听成功会直接执行本分支
            fmt.Println("创建 UNIX Domain Socket 成功")
    }

    defer lis.Close() //虽然本次操作不会执行， 不过还是加上比较好

    for {
            conn, err := lis.Accept() //开始接 受数据
            if err != nil {
                    log.Println("请求接收错误 -> ", err)
                    continue //一个连接错误，不会影响整体的稳定性，忽略就好
            }
            go handle(conn) //开始处理数据
    }
}

func handle(conn net.Conn) {
    defer conn.Close()

    for {
            io.Copy(conn, conn) //把发送的数据 转发回去
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// client.go

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "os"
)

func main() {
    file := "test.sock"
    conn, err := net.Dial("unix", file) //发起 请求
    if err != nil {
            log.Fatal(err) //如果发生错误，直接退出程序，因为请求失败所以不需要 close
    }
    defer conn.Close() //习惯性的写上

    input := bufio.NewScanner(os.Stdin) //创建 一个读取输入的处理器
    reader := bufio.NewReader(conn)     //创建 一个读取网络的处理器
    for {
            fmt.Print("请输入需要发送的数据: ")       //打印提示
            input.Scan()                    // 读取终端输入
            data := input.Text()            // 提取输入内容
            conn.Write([]byte(data + "\n")) // 将输入的内容发送出去，需要将 string 转 byte 加 \n  作为读取的分割符

            msg, err := reader.ReadString('\n') //读取对端的数据
            if err != nil {
                    log.Println(err)
            }
            fmt.Println(msg) //打印接收的消息
    }
}

我们再来看官方给的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

// server start a thread that listens for RPCs from worker.go
func (c *Coordinator) server() {
rpc.Register(c)
rpc.HandleHTTP()
//l, e := net.Listen("tcp", ":1234")
sockname := coordinatorSock()
os.Remove(sockname)
l, e := net.Listen("unix", sockname)
if e != nil {
log.Fatal("listen error:", e)
}
go http.Serve(l, nil)
}

// call send an RPC request to the coordinator, wait for the response.
// usually returns true, returns false if something goes wrong.
func call(rpcname string, args interface{}, reply interface{}) bool {
// c, err := rpc.DialHTTP("tcp", "127.0.0.1"+":1234")
sockname := coordinatorSock()
c, err := rpc.DialHTTP("unix", sockname)
if err != nil {
log.Fatal("dialing:", err)
}
defer c.Close()

err = c.Call(rpcname, args, reply)
if err == nil {
return true
}

log.Println(err)
return false
}

// Cook up a unique-ish UNIX-domain socket name
// in /var/tmp, for the coordinator.
// Can't use the current directory since
// Athena AFS doesn't support UNIX-domain sockets.
func coordinatorSock() string {
s := "/var/tmp/5840-mr-"
s += strconv.Itoa(os.Getuid())
return s
}

可以看到正是基于上述的通信方式。

任务执行

接着我们再来谈任务的执行。Worker 进程向 Coordinator 发送请求获取任务，Coordinator 找到空闲的任务，将其返回给 Worker，Worker 根据任务的类型和任务的参数执行任务，待任务结束后，Worker 告知 Coordinator，Coordinator 修改任务状态，继续分配下一个任务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

// worker.go

// Worker is called by main/mrworker.go
func Worker(mapf func(string, string) []KeyValue, reducef func(string, []string) string) {
// get the current workspace path
workDir, _ := os.Getwd()
w := WorkerS{
name:    "worker_" + strconv.Itoa(rand.Intn(100000)),
mapF:    mapf,
reduceF: reducef,
workDir: workDir,
}

// send the RPC to the coordinator for asking the task in a loop
for {
reply := callGetTask(w.name)
if reply.Task == nil {
// can not get the task, maybe all map tasks or all reduce task are running but not be finished
// waiting to the next phase
time.Sleep(time.Second)
}

log.Printf("[Info]: Worker: Receive the task: %v \n", reply)
var err error
switch reply.Task.TaskType {
case MapTask:
err = w.doMap(reply)
case ReduceTask:
err = w.doReduce(reply)
default:
// worker exit
log.Printf("[Info]: Worker name: %s exit.\n", w.name)
return
}
if err == nil {
callTaskDone(reply.Task)
}
}
}

// callGetTask send RPC request to coordinator for asking task
func callGetTask(workName string) *GetTaskReply {
args := GetTaskArgs{
WorkerName: workName,
}
reply := GetTaskReply{}
ok := call("Coordinator.GetTask", &args, &reply)
if !ok {
log.Printf("[Error]: Coordinator.GetTask failed!\n")
return nil
}
return &reply
}

func callTaskDone(task *Task) {
args := TaskDoneArgs{
Task: task,
}
reply := TaskDoneReply{}
ok := call("Coordinator.TaskDone", &args, &reply)
if !ok {
log.Printf("[Error]: Coordinator.TaskDone failed!\n")
}
}

首先是 Map 任务。它负责读取初始文件，根据文件内容生成一系列的临时中间文件，这些临时的中间文件内容是一系列的 key/value pair，其中 key 是单词，value 是次数，也就是 1。Map 任务的数量应当根据输入文件的多少适当拆分，本实验中为简单起见，约定一个文件一个 Map 任务，因此一共是 8 个 Map 任务。所有的 Map 任务执行成功后开始 Reduce 阶段，因此 MapReduce 程序需要标记当前处于 Map 阶段还是 Reduce 阶段，只有 Map 阶段结束，才会进入 Reduce 阶段。

Map 任务

以本实验为例，Map 任务负责读取一个原始的文件的内容，调用 map 函数（注意 map 函数以插件的方式加载，本实验中不需要我们实现）生成 [word-1] 这种格式的临时文件。前面说到，为了方便起见，一个文件代表一个 Map 任务，每个 Map 任务生成的临时文件数量和分区数量 R 保持一致。关于 Map 产生的临时文件分配及命名规则，后面会单独描述，下面是 Worker 节点处理 Map 任务的逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

// doMap execute the map task
func (w *WorkerS) doMap(reply *GetTaskReply) error {
task := reply.Task
if len(task.Input) == 0 {
log.Printf("[Error]: task number %d: No input!\n", task.Id)
return errors.New("map task no input")
}
log.Printf("[Info]: Worker name: %s start execute number: %d map task \n", w.name, task.Id)

fileName := task.Input[0]
inputBytes, err := os.ReadFile(fileName)
if err != nil {
log.Printf("[Error]: read map task input file error: %v \n", err)
return err
}

// kv2ReduceMap: key: reduce index, value: key/value list. split the same key into reduce
kv2ReduceMap := make(map[int][]KeyValue, reply.NReduce)
var output []string
outputFileNameFunc := func(idxReduce int) string {
return fmt.Sprintf("mr-%d-%d-temp-", task.Id, idxReduce)
}

// call the map function
kva := w.mapF(fileName, string(inputBytes))
for _, kv := range kva {
idxReduce := ihash(kv.Key) % reply.NReduce
kv2ReduceMap[idxReduce] = append(kv2ReduceMap[idxReduce], kv)
}

for idxReduce, item := range kv2ReduceMap {
// write to the temp file
oFile, _ := os.CreateTemp(w.workDir, outputFileNameFunc(idxReduce))
encoder := json.NewEncoder(oFile)
for _, kv := range item {
err := encoder.Encode(kv)
if err != nil {
log.Printf("[Error]: write map task output file error: %v \n", err)
_ = oFile.Close()
break
}
}
// rename
index := strings.Index(oFile.Name(), "-temp")
_ = os.Rename(oFile.Name(), oFile.Name()[:index])
output = append(output, oFile.Name())
_ = oFile.Close()
}

task.Output = output
log.Printf("[Info]: Worker name: %s finished the map task number: %d \n", w.name, task.Id)
return nil
}

Reduce 任务

Reduce 任务发生在 Map 任务全部执行结束以后，负责执行 Reduce 操作。它处理 Map 任务产生的中间文件，调用 Reduce 函数输出结果到最终的文件中。以本实验为例，Reduce 任务找到其对应编号（具体规则下面会说）的临时文件，统计单词出现的次数，并将最终的结果输出到文件中，下面是 Worker 节点处理 Reduce 任务的逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

// doReduce execute the reduce task
func (w *WorkerS) doReduce(reply *GetTaskReply) error {
task := reply.Task
var kva ByKey
for _, fileName := range task.Input {
open, _ := os.Open(fileName)
decoder := json.NewDecoder(open)
for {
var kv KeyValue
if err := decoder.Decode(&kv); err != nil {
log.Printf("[Error]: read reduce task input file error: %v \n", err)
_ = open.Close()
break
}
kva = append(kva, kv)
}
}

// sort
sort.Sort(kva)

// write to a temp file
tempFile := fmt.Sprintf("mr-out-%d-temp-", task.Id)
oFile, _ := os.CreateTemp(w.workDir, tempFile)

i := 0
for i < len(kva) {
j := i + 1
for j < len(kva) && kva[j].Key == kva[i].Key {
j++
}
var values []string
for k := i; k < j; k++ {
values = append(values, kva[k].Value)
}
result := w.reduceF(kva[i].Key, values)
_, _ = fmt.Fprintf(oFile, "%v %v\n", kva[j].Key, result)

i = j
}

// rename the reduce task output
index := strings.Index(oFile.Name(), "-temp")
_ = os.Rename(oFile.Name(), oFile.Name()[:index])
_ = oFile.Close()

task.Output = []string{oFile.Name()}
log.Printf("[Info]: Worker name: %s finished the reduce task number: %d \n", w.name, task.Id)
return nil
}

产生的文件

Map 任务和 Reduce 任务产生的文件这里单独来说。在 MIT 实验里对产生的文件名作了具体的要求：

1. A reasonable naming convention for intermediate files is mr-X-Y, where X is the Map task number, and Y is the reduce task number.
2. The worker implementation should put the output of the X’th reduce task in the file mr-out-X.

前面我们知道，每个 Map 都有对应的任务 ID，每一个原始文件对应一个 Map 任务，根据实验要求，每个 Map 分别输出 R 个临时文件，这里的 R 就是分区数量，即 Reduce 任务的数量。在 Map 任务中，对每个 key 作 hash，并与分区数量 R 取余，从而将不同的 key 散列到不同的 Reduce 任务上；Reduce 任务根据自身任务 ID 和散列的文件 ID 找到它需要处理的临时文件，这样就实现了相同的 key 必定由同一个 Reduce 处理的效果，从而确保了统计的准确性。最后每个 Reduce 根据其自身编号输出对应的文件。

假设一共有 4 个文本需要处理，对应 4 个 Map 任务，分区数量 R 是 9。那么按照规则编号为 1 的 Map 任务生成的中间临时文件便是 mr-1-1、mr-1-2、mr-1-3 …… mr-1-9，同样地，2 号 Map 任务生成的中间临时文件是 mr-2-1、mr-2-2、mr-2-3 …… mr-2-9。

可以看到，Reduce 阶段，编号为 1 的 Reduce 任务需要处理 Y = 1 的临时文件，其他 Reduce 也是如此。

以上我们就把 Map 任务和 Reduce 产生的文件处理规则说清楚了。

容错

最后来说一下错误处理。

Master 故障

论文中提到，处理 Master 失败一个简单的解决办法就是让 Master 节点周期性的将其数据结构写入磁盘，即形成一个检查点，如果 Master 节点异常，则可以从最后一个检查点重新启动 Master 进程，从而完成故障恢复。实验原因，本次并未实现 Master 节点的故障恢复。

Worker 故障

处理 Worker 节点故障可以单独起一个线程，让 Master 节点周期性地 ping 每个 Worker 节点，如果在一个约定的时间范围内 Master 没有收到 Worker 节点的心跳信息，则将其标记为失效。所有由这个失效的 worker 完成的 Map 任务被重设为初始状态，重新分配给其他的 Worker 节点。同样的，Worker 失效时正在运行的 Map 或 Reduce 任务也将被重置为空闲状态，重新等待分配执行。

当 Worker 故障时，由于已经完成的 Map 任务的输出存储在这台机器上，Map 任务的输出已经不可访问了，因此必须重新执行。而已经完成的 Reduce 任务的输出存储在全局文件系统上（例如 GFS），因此不需要再次执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

// workerTimer create a timer that checks the worker online status every 1 second
func (c *Coordinator) workerTimer() {
go func() {
ticker := time.NewTicker(time.Second)
defer ticker.Stop()

for range ticker.C {
select {
case <-c.timer:
log.Printf("[Info]: Worker timer exit. \n]")
return
default:
c.mutex.Lock()

for _, workInfo := range c.baseInfo.workerMap {
if time.Now().Sub(workInfo.lastOnlineTime) <= 10 {
continue
}
// According to the MapReduce paper, in a real distributed system,
// since the intermediate files output by the Map task are stored on their respective worker nodes,
// when the worker is offline and cannot communicate, all map tasks executed by this worker,
// whether completed or not, should be reset to the initial state and reallocated to other workers,
// while the files output by the reduce task are stored on the global file system (GFS),
// and only unfinished tasks need to be reset and reallocated.
if c.phase == MapPhase {
mapTasks := c.baseInfo.taskMap[MapTask]
for _, task := range mapTasks {
if task.WorkName == workInfo.name {
task.Status = Waiting
task.WorkName = ""
task.Output = []string{}
}
}
} else if c.phase == ReducePhase {
reduceTasks := c.baseInfo.taskMap[ReduceTask]
for _, task := range reduceTasks {
if task.WorkName == workInfo.name && task.Status == Running {
task.Status = Waiting
task.WorkName = ""
task.Output = []string{}
}
}
}
delete(c.baseInfo.workerMap, workInfo.name)
}
c.mutex.Unlock()
}
}
}()
}

注：本实验完整代码见我的 Github 仓库。

(全文完)

Refrence

http://nil.csail.mit.edu/6.5840/2024/labs/lab-mr.html

https://pdos.csail.mit.edu/6.824/papers/mapreduce.pdf

本文是此系列文章的第二篇，介绍 WebRTC 中信令服务器的设计。

信令介绍

在 WebRTC 的技术栈里，详细定义了一整套的规范，例如它的接口设计，使用 SDP 进行媒体协商、使用 ICE 收集网络地址并进行联通性检测等，这些规范使得客户端与客户端之间的数据交换变得非常容易和方便，但是我们发现 WebRTC 并没有对客户端建立点对点连接之前的过程定义规范，“空缺”的这部分，其实就是信令服务器在发挥作用的地方。

概括来说，WebRTC 信令是设备通信和交换点对点连接所需的信息的方式，包括交换应用程序之间的网络信息、协商媒体格式并处理通信会话的各个方面，因此在 WebRTC 的世界中，信令格外重要。

信令服务器作用

上面介绍了 WebRTC 中的信令，我们知道，WebRTC 的核心是点对点通信，在客户端连接建立之前，我们需要一个公共的服务器来实现上述信息的交换剂，这便是信令服务器，具体说来，一个信令服务器应该具备以下作用：

• 交换通信双方的网络信息：
  • 最常见的是交换通信双方的 IP 和端口；
  • 两个 WebRTC 客户端之间会尽可能选择 P2P 进行通信。同一个局域网内，P2P 传输很容易实现；不同的局域网，需要借助网络穿透等技术手段实现 P2P 传输，若遇到网络穿透失败或者无法穿透的情况，则需要借助中转服务器实现数据传输。
• 交换通信双方的媒体信息
  • 媒体信息用 SDP 表示，SDP 包含浏览器中的 RTP 媒体栈配置媒体会话所需要的全部信息，包括媒体类型(音频、视频、数据)，所用的编解码器(Oplus、G.711 等)、用于编解码器的各个参数或设置、以及有关宽带的信息；
  • 信令通道也需要交换用于 SRTP 的密钥材料；
  • 总结一下，SDP 可以简单理解为：媒体类型的编码是什么、是否支持对应的媒体类型和编码器、编码方式是什么等。
• 业务层的功能管理
  • 创建会话、加入已存在的会话、退出会话等；
  • 会话生命周期的管理和用户的管理等；
  • 客户端的身份认证。

因为我打算使用 WebRTC 技术实现一个文件传输的工具，因此本文更多讨论的是在文件传输工具的 WebRTC 实现下信令服务器的设计与实现。

WebRTC 信令工作流程

一个 WebRTC 系统信令的工作流程图大概如下：

• 客户端 A 和客户端 B 通过 WebSocket 等协议请求信令服务器；
• 客户端 A 与信令服务器之间的通信称为 offer-answer 机制，是 WebRTC 等一部分；
• 客户端 A 和客户端 B 可以视为两个对等点，对等点之间的连接是为了在设备之间建立通信，在这之前对等点之间必须通过 WebRTC 信令服务器进行连接前的通信。

架构设计

介绍了信令服务器的作用后，我设计的文件传输工具信令服务器大体架构是这样：

架构整体结构不难，主要在于信令服务器对会话、用户等的管理，下面将详细说一下信令服务器这部分的管理功能。

管理模块

用户和房间管理

信令服务器能够对用户进行管理。两个需要建立点对点连接的用户，要能够找到彼此，需要借助房间的概念，即两个用户加入同一个房间，在同一个房间的用户可以交换彼此的连接信息，从而建立彼此的点对点连接。

在传输过程中，用户和房间的连接信息由信令服务器维护。再进一步扩展，信令服务器应当支撑多个 WebRTC 传输环境，即多个房间，且房间之间互不影响；每个房间参与的人数也应该不受限制，信令服务器应当支持多个用户可以进入同一个房间，可以选择对房间内特定的用户传输文件或者对房间内所有的用户传输文件。

会话管理

• 信令服务器支持创建一个新的会话，允许客户端通过信令服务器交换剂网络信息和媒体信息；
• 信令服务器还应当管理现有会话，允许新的用户加入现有的会话；
• 不同的会话之前应该互不影响、相互隔离。

信令传输方式与协议

信令传输协议比较灵活，理论上可以选择多种通信协议。但是实际使用时，我们一般选择 TCP 或者基于 TCP 的 HTTP/HTTPS、WS/WSS 等应用层协议作为信令服务器的通信协议。

HTTP 传输

• 浏览器可以发起新的 HTTP 请求，以便向服务器发送信令信息并从中接受信令消息；
• 可以通过轮询或者 get 请求来从服务器获取信令信息

不难看出，通过 HTTP 协议的方式有非常明显的弊端，当房间新加入用户时，信令服务器没办法主动通知房间中已经存在的用户，即传统的 HTTP 协议没办法从服务端主动向客户端推送数据。

当然，这种弊端也是可以通过技术手段解决的，例如升级 HTTP2 或者客户端不断轮询请求信令服务器。

WebSocket 传输

• WebSocket 允许浏览器开通一个与服务器的双向连接，客户端不仅能从信令服务器请求数据，信令服务器还能主动向客户端推送数据；
• 现在主流的浏览器都支持 WebSocket，但某些 Web 代理和防火墙并不完全支持 WebSocket，可能会导致问题，尤其在身份验证方面。

NAT 穿透

本篇的最后来说一下客户端建立对等连接时的网络问题。

在一个 WebRTC 系统中，一个比较理想的情况是在客户端之间直接通过获取操作系统和网卡的 IP 地址建立点对点通信，我们一般称之为客户端之间处在同一个的内网中，但是实际中的场景往往复杂的多。目前我们日常使用的大部分设备都处在 NAT 设备后面，这就导致客户端没办法通过读取各自网卡的 IP 信息建立连接，在这种情况下，就需要借助 NAT 穿透技术。

关于 NAT 穿透技术，在本系列第一篇文章中已经提到可以借助 STUN/TURN 等方案实现 NAT 穿透，这里不再阐述，并且本篇文章主要关注 WebRTC 信令服务器的设计和实现，NAT 穿透技术的工作原理和工作流程将在本系列第三篇文章中详细展开说明。

这里先看一下 NAT 设备下信令服务器的通信过程：

1. 前面已经说过，客户端通信前需要先建立对信令服务器的连接；
2. NAT 设备的场景，交换剂信息前，客户端还需要与 STUN/TURN 建立连接，这样做的目的是通过 STUN/TURN 服务器获得各自的外网 IP 地址（子网和公网）、端口和 NAT 结构（IP 地址和端口对我们称之为 ICE Candidate）。连接后通信双方就可以通过信令服务器彼此交换信息了；
3. 当获得彼此信息后，就可以尝试 NAT 穿透，客户端之间建立对等的 P2P 连接。

Reference

https://sheerbittech.medium.com/webrtc-signaling-server-everything-you-need-to-know-569f6b5c7317

https://juejin.cn/post/7171089420911640613

本篇文章是此系列文章的第一篇，详细介绍 WebRTC 技术。

WebRTC 概述

WebRTC（Web Real-Time Communication）是一个开源项目，旨在通过简单的应用程序接口（API）实现浏览器和移动应用之间的实时通信（RTC）。它允许网页浏览器进行语音通话、视频聊天和点对点文件分享，而无需用户安装特殊的插件或第三方软件。

简单来说，WebRTC 项目主要思想是定义 WebRTC API，该 API 允许浏览器安全地访问设备上的输入外设，如麦克风和网络摄像头，以点对点的方式与远程设备共享或交换媒体数据以及实时数据。借助 WebRTC，多个不同设备可以在一个平台上流畅地、安全地共享语音、视频和实时数据。

WebRTC 是 Google 在 2011 开源的项目，并将其纳入 Chrome 浏览器的开发计划，经过多年持续的发展和壮大，它已经成为浏览器间实时通信的主流技术之一，现在，几乎所有主流的浏览器都支持 WebRTC 标准，并且在各个领域得到了广泛的应用和推广。有关 WebRTC 的历史可以参考这篇文章。

WebRTC 是实时通信的未来，它受欢迎的原因有很多，我总结了 WebRTC 以下几个特点：

• WebRTC 是一种无需插件的现代实时通信技术。它不需要任何额外的插件或应用程序来进行音频、视频流和数据共享，它使用 JavaScript、应用程序编程接口（API）和 HTML5 将通信技术嵌入到浏览器中。像 Google Hangouts、Whatsapp、Facebook Messenger、ZOOM 团队通信、Zendesk 客户支持、Skype for Web 等产品都集成了 WebRTC。
• 不同设备的浏览器能够以对等的方式直接与其他浏览器交换实时媒体。
• WebRTC 提供了比其他流媒体更高的安全性，并且无需借助第三方软件。
• 它是免费开源的，并且在全球范围内应用，这正是推动此项技术发展的动力。
• WebRTC 支持多种编程语言的客户端 API。WebRTC 标准受到多种编程语言和框架的支持，例如：JavaScript、Java(Android)、NodeJs Rest、NodeJs WebSocket、Go、PHP、Python、React Native、REST、Ruby、Swift(IOS)。

核心组件和架构设计

三个核心组件

WebRTC 是通过浏览器进行的实时通信，通过标准化的 WebRTC API 与 Web 浏览器进行工作和通信，因此 WebRTC API 必须提供一系列的实用工具，其中包括一些类似于连接管理（以点对点方式）、编解码功能协商、选择和控制、媒体控制、安全和防火墙等。WebRTC 的功能大体可以分为以下三个组件。

MediaStream

媒体捕获和流处理组件，MediaStream 允许浏览器访问设备的摄像头和麦克风，并捕获音视频流。

这是实现实时通信的第一步：获取用户想要分享的数据。在这个阶段下，可能会发生以下情况：

1. 用户期望的流数据（音频/视频/其他数据）和即将要建立的通信模式被捕获；
2. 即将分享的本地媒体流允许浏览器访问流设备，如摄像头、麦克风等；
3. 允许浏览器捕获媒体。

以上操作均是通过 getUserMedia() 方法获取访问权限，具体 API 操作参考这篇文章。

RTCPeerConnection

网络通信组件，它是 WebRTC 中最核心的组件，负责在浏览器之间建立、维护和管理直接的音视频或数据通信连接。

实时通信的第二步：确定了通信流之后，下一步就是将不同的设备连接起来，这涉及到网络通信组件，通信双方通过 STUN 和 TURN 服务允许发送者和接受者之间建立点对点连接。具体连接过程将在后面详细说明。

此阶段具体 API 操作参考这篇文章。

RTCDataChannel

数据通信组件，允许网页应用直接在用户浏览器之间建立安全的双向数据通道，用于传输任何类型的数据。

实时通信的最后一步：数据通信和交换，发挥作用的是数据通信组件，具体来说就是不同设备通过浏览器直接点对点交换数据。具体发生在当第一次在一个实例化的 PeerConnection 对象上调用 CreateDataChannel() 方法时。

此阶段具体 API 操作参考这篇文章。

WebRTC 架构设计

以下是源自官网的 WebRTC 结构设计图

可以看出，WebRTC 的设计相当复杂，如果你是浏览器开发者，你应该关注 WebRTC C++ API 和可以使用的捕获/渲染钩子；如果你是 Web 程序开发者，你应该更多关注 Web API 部分。

关键技术

信令

前面说到 WebRTC 是一种点对点的实时通信技术，不同设备的客户端浏览器可以直接通过 WebRTC 提供的 Web API 建立对等点对点连接，信息的交换与分享不需要借助中间服务器。但是在建立连接之前，客户端之间是如何知晓彼此的连接信息呢？多个客户端之间的实时通信会话又是如何维护的呢？这就需要借助信令服务器了。

简单说来，信令服务器就是在连接建立之前负责在通信双方传递信令数据来建立和维护实时通信会话，信令数据包括但不限于传递会话初始化信息、客户端信息、媒体元信息以及网络配置信息等。客户端通过信令服务器交换和协商上述信息，从而建立点对点的连接，需要说明的是，连接建立以后，客户端之间的实时通信和数据交换是不通过信令服务器的，它仅仅是在会话建立前发挥作用，以及维护多个会话状态等。

WebRTC 客户端实现实时通信的第一步就是连接信令服务器，需要特别说明的是，WebRTC 标准自身不规定任何特定的信令协议，开发者可以选择 WebSocket、SIP 或者 HTTPS 等其他协议实现会话控制、媒体元数据交换、网络配置信息交换等功能，所以信令服务器在 WebRTC 技术框架中是极其重要且实现方式多种多样的，保证了技术的灵活性和开放性。

NAT 穿透

上面说到，WebRTC 客户端之间建立连接是通过信令服务器来交换网络连接信息的，这一般涉及客户端的 ip 地址和端口信息，这里涉及到两种情况：

WebRTC 客户端处在同一个局域网内

这种情况比较好处理，只需要通过信令服务器交换客户端彼此的局域网地址，通过 WebRTC 提供的 Web API 即可建立连接，实现点对点通信。

WebRTC 客户端不在同一个局域网内

这种情况更符合大多数的情况，因为现如今互联网上大多数设备都在分配私有 IP 地址的 NAT 后面，并且一般限制了来自外部的访问，这种情况下因为不在同一个局域网内，直接交换客户端的私有 IP 地址就行不通了，这就需要 NAT 穿透技术。

因此，NAT 穿透技术在 WebRTC 技术体系内是必要且至关重要的。

WebRTC 使用多种技术来实现 NAT 穿透

STUN（Session Traversal Utilities for NAT）

• STUN 是一种协议，是基于 UDP 的完整的穿透 NAT 的解决方案，属于打洞技术，它允许 NAT 后面的客户端发现其公共 IP 地址以及它们所在的 NAT 类型
• 客户端向 STUN 服务器发送请求，STUN 服务器以客户端的公网 IP 地址和端口号响应
• 如果两个对等连接的客户端都位于允许直接连接的 NAT 类型后面，则该信息将用于建立直接连接

TURN（Traversal Using Relays around NAT）

• TURN 是一种数据传输协议，通过 Relay 方式穿越 NAT，TURN 主要用在 STUN 无法穿透的场景下，例如一方或者双方位于对称 NAT 后的情况
• TURN 服务器在对等点之间中继流量，有效绕过 NAT
• 此方法会引入额外的延迟和带宽成本，因为所有流量必须经过 TURN 服务器

ICE（Interactive Connectivity Establishment）

• ICE 是一个结合 STUN 和 TURN 建立连接的框架
• ICE 尝试多种方法来找到连接的最佳路径，它使用 STUN 进行打洞，若失败，则使用 TURN 进行中转

通信过程

局域网通信

WebRTC 客户端都位于同一个局域网内，这种情况属于比较简单的一种通信模式，借助信令服务器，客户端连接信令服务器时，会携带客户端在局域网内的 IP 地址和端口信息，此信息可用于直接建立点对点连接。

通信模型如下：

广域网通信

这种模式涉及的场景就复杂了，在这种通信模式下，不同的客户端处于不同的网络环境，客户端前面的 NAT 也有不同的部署方式，所以存在不同类型的 NAT，而穿透不同类型的 NAT 所使用的方式和技术成本是不一样的，在本系列的第三篇文章里，我会专门详细介绍 NAT 穿透技术，这里不作展开。

通信模型如下：

安全性

WebRTC 的安全性这里拿出来单独说。

一直以来，人们都希望自己的通信和交流处在安全且私密的环境中，安全性方面，WebRTC 也做了大量的考虑和设计。

• 加密：所有 WebRTC 组件（包括信令）都必须加密
• 安全协议：WebRTC 强制使用安全的实时传输协议（SRTP）来传输音视频数据，在数据通道上使用数据加密传输协议（DTLS）确保通信安全
• 浏览器保证：当使用 API 获取设备的摄像头、麦克风权限时，浏览器会有明确的提示，且必须经过用户同意后才能开启

附图：WebRTC 的协议栈和加密通信协议示意图

应用场景

现如今，WebRTC 的应用场景极为丰富，包括但不限于：

• 视频会议和语音通话：提供低延迟、高质量的实时视频和音频通信体验
• 实时数据共享：支持文本、文件、屏幕共享等多种形式的实时数据共享
• 直播和点播：支持实时直播与点播服务，为用户提供丰富的媒体体验
• 远程协作和教育：在线教育、远程会议和协作工具等应用中提供实时互动能力

Reference

https://www.geeksforgeeks.org/introduction-to-webrtc/

https://web.dev/articles/webrtc-basics?hl=zh-cn

https://webrtc.github.io/samples/

https://bloggeek.me/how-webrtc-works/

https://medium.com/callstatsio/what-are-stun-and-turn-in-computer-networking-95d5130597c7

https://medium.com/dvt-engineering/introduction-to-webrtc-cad0c6900b8e

https://blog.jianchihu.net/webrtc-av-transport-basis-nat-traversal.html

https://webrtc-security.github.io/

（全文完）

一开始我在总结过去的一年的时候，发现并没有太多值得总结的事情，出于博客网站的需要，我决定还是开个好头，写下了这篇文章。需要特别说明的是，这是一篇流水账式的文章，并没有特别的干货，写的真的很烂。

既然说到这里，先来说一下我的个人网站，2023 年是我正式开始写博客的第一年，正如我在这篇文章中所说，以前我总是记录的很杂、很随意，我希望通过写博客的方式让自己养成记录的好习惯，并且借此得以规范我的记录，希望这是一个好的开始。截止到现在，整个 2023 年我一共正式写了 12 篇文章，算很少的了，其中有不少时间还花在个人网站的建设上，一开始我使用的是 hugo 来构建我的网站，苦于我使用的主题文档缺少，加上 hugo 可自定义性不高，在 12 月份的时候我把个人网站改为了 hexo 构建，并且使用了全新的主题，这套主题文档很详细，可配置性很高，比较适合作为我构建个人网站的选择，最后也就是你现在看到的这个样子。

去年 12 月，我跟妹子摇中了一个不错的盘，也算正式上车，成为房奴大队的一员，今年 1 月，随着房子封顶，我们正式开始了还贷的日子，一开始多少会有些不适应，索性我跟妹子的收入加起来还算可观，目前在房贷的压力下，我们的生活质量并没有受到太大的影响。我们的运气算不错，房子预计会提前交付，大概是在 24 年的 6 月份，再过半年我们就正式结束 3 年多的杭漂，对此心里还是有不小的期待。交房后的半年预计会很忙，所以明年下半年大部分的时间都在操心房子装修的事情，到时候关于装修的过程，我预计也会水几篇文章来记录新房折腾的过程，这里先挖个坑。

生活上，这一年似乎过的比较平淡，没有什么特别值得纪念的事情，印象中这一年倒是去了不少地方。上半年去了两趟上海，熟悉的外滩、热闹的步行街、拥堵的街道、熙熙攘攘的人群，还有不少杭州吃不到的美食，总体来说，上海这座城市给我留下的印象还是不错的，我喜欢这座城市带给我的高级感，但是我并不喜欢它拥堵的交通。

10 月国庆节，去了一趟妹子家，双方父母见了面，婚期也被提上了日程。

年底，跟大学室友在庐山聚了一次，这是 1220 宿舍从毕业旅行之后再一次相聚旅游，3 天时间，很快也很快乐。我是一个重感情的人，我喜欢跟朋友一起玩的感觉，几个要好的朋友从不同的城市相聚，大家述说着自己的生活，倾听着彼此的经历，有吐槽、有吹牛，也有对未来生活的向往…… 这种美好的感觉是能够治愈心灵的，所以在旅行结束，我发了这样一条朋友圈：

旅游确实可以放松心情，在大自然面前，它可以接纳你的一切情绪，不论是你带着喜悦的心情，或者是忧愁的情感，都会得到心灵的净化，从而收获内心的平静，这也是我一直想要追求的。

工作上，6 月，我换了一份工作，离开了工作了 3 年的地方，刚开始及其的不适应，陌生的环境、陌生的同事，这种感觉持续了将近 1 个月，我并没有刻意调整自己的这种情绪，后来应该是麻木了，这种感觉渐渐消失了。实话说，面对工作，我是及其焦虑的，新工作是 CURD 的工作，这并不是我想要的工作，更不是我喜欢的方向，需要说明的是，我并不是一个眼高手低的人，但是我很清楚自己想要什么，我很清楚我理想中的工作应该是做什么样的内容和方向。这种理想和现实的差距让我不知所措，我陷入了长久了焦虑中，越焦虑，这种失落的情绪就越是明显和深刻。幸运的是，我对自己还算有一个清醒的认识，焦虑的情绪并没有太久的占据上风，我知道现阶段的我还不够好，不管怎么样，还是要做好当下的工作，也算是暂时地与自己“和解”了。

技术上，感觉也没有什么好总结的，过去的 2023 年，我在技术上确实是一事无成，想参与的开源迟迟没有进展，我感兴趣的中间件和云原生领域也没有按计划开始，对于计算机内功的修炼也只是进行了皮毛，想做的项目也只是建了一个仓库…… 我去翻了一下年中换工作时文章里面给自己制定的计划，当时制定的计划都还历历在目，大致总结了一下：

1. 操作系统 CSAPP 这本书只看了第一章的内容，书上的实验也没有做，做的很烂。
2. 计算机网络方面看的较多，算是做的比较好的地方。
3. 分布式系统方面，《mit 6.824》已经开始看了，目前也开始接触了 MapReduce 的论文。
4. 打算和两个好友做一个 RSS 订阅的应用，目前项目前期的工作已经准备的差不多了，年末的时候有小伙伴去闭关开发了，计划明年启动开发。

总结下来发现，年中给自己制定的目标完成的情况太差，但让我高兴的是，我终于在今年迈出了这一步，我觉得这是一个好的开始，期待在 2024 年我可以做的更好。

下半年还看了几本书，有两本技术人写的，也有技术无关的，关于阅读这一部分，本站 阅读专栏会有详细的总结。阅读能让我收获极大的内心平静，这也是我逐渐养成阅读的原因，每当我焦虑时、或者迷茫时，我会去读书，可能在某个时刻，突然就在书中找到答案了，希望你可以和我一样，在书中找到属于自己的天地。

可能是因为年底看完了耗子叔（陈皓）的遗作《左耳听风》，这是一本新书，和耗子书极客时间专栏同名，书里面也有很多耗子书博客中的内容。写到这里，我不禁怀念起耗子叔，他应该是我最喜欢的技术人了，率真的性格、及其鲜明的技术观点、对年轻人的鼓励、终身学习的态度、谦逊的性格，这些都深深打动了我，今年有一段时间，我几乎每天下班都泡在耗子叔的网站中，也几乎看完了他在极客时间上的专栏，还没来得及跟他交流一番，他就离开了我们，这里放上耗子叔生前的座右铭–芝兰生于深谷，不以无人而不芳；君子修身养德，不以穷困而改志。永远缅怀耗子叔！

我以前并不是一个爱给自己制定计划的人，因为我觉得对我来说，制定计划只是装装样子，大概率也不会完成。今年这一年我的观念变化真的很大，我发现经过这半年的探索，自己好像很享受完成既定计划的感觉，这种成就感也会反推我去完成更多的事情，总结的最后，我也大致列出了 2024 年要完成事情：

1. 继续看 CSAPP 这本书，完成前 6 章的内容和课后实验，同时完成 《mit 6.828》的内容；
2. 完成 《mit 6.824》分布式系统剩下的课程和课后的 lab；
3. 和伙伴完成 go-my-rss 第一版订阅功能；
4. 有时间看一下《mit 6.829》；
5. 完成新房装修，折腾一下软路由和新家网络；
6. 出去旅游，暂定新疆、重庆、东北、香港、韩国；
7. 至少看 5 本书技术之外的书；
8. 练习口语。

就先列举这些吧，给自己一个大致的计划方向，每天提升一点点。

上面就是我 2023 年终总结的全部内容，草草梳理完了自己的 2023 年，希望这是一个全新的开始，也期待在 2024 年终总结中自己可以交出更好的答卷。

（全文完）

先前，Oracle 官方宣布，在 2023 年 10 月 21 日之后，MySQL 5.7 将达到其生命周期的终点，这意味着 Oracle 将不再为 MySQL 5.7 提供官方更新、错误修复或安全补丁，正是在这一背景下，才有了 GitHub 此次的升级。

根据 GitHub 官方介绍，GitHub 使用 MySQL 来存储大量关系数据，因此对于数据库这种底层的基础设施的升级绝非易事，为了升级到 MySQL 8.0，他们规划、测试和升级本身总共花费了一年多的时间，并且需要 GitHub 内部多个团队的协作。因此对于 GitHub 此次这种大规模的底层数据库的升级，我本身是抱有极大的兴趣，也想了解一下如此大规模的 MySQL 的集群采用了什么样的升级方案，所以我去阅读了 GitHub 官方博客，并且将原文翻译如下，以下是原文翻译全部内容。

15 年前，GitHub 开始于一个使用 Ruby on Rails（cczywyc 注：一个基于 Ruby 语言的 web 开发框架）框架构建的应用，使用单体的 MySQL 数据库，从那时起，Github 逐渐改进 MySQL 结构，以满足平台的扩展和弹性需求，这其中包括构建高可用、实现自动化测试和数据分区的要求。如今，MySQL 仍热是 GitHub 基础设施的核心部分，并且也是我们选择关系型数据库的核心部分。

下面就是我们将我们的 1200 多个 MySQL 主机升级到 8.0 版本的过程。在不影响我们的服务水平目标（SLO）的前提下升级 MySQL 版本可谓是一项不小的成就，在这个过程中，升级规划、测试和升级本身就花费了我们一年多的时间，并且还依赖于 GitHub 内部多个团队的协作。

升级的动机

为什么我们要升级到 MySQL8.0 版本呢？随着 MySQL 5.7 临近生命周期的尾声，我们将我们 MySQL 集群升级到了下一个主要的版本 – MySQL8.0。我们不仅希望使用这个能够获得最新的安全补丁、错误修复和性能增强功能的 MySQL 版本，我们还希望能够使用到 8.0 版本中的一些新功能，这包括 Instant DDLs、不可见索引和压缩二进制日志等。

GitHub 的 MySQL 的基础设施

在我们深入了解升级过程之前，让我们先来全面了解一下我们的 MySQL 基础设施：

• 我们的 MySQL 集群包括 1200 多台主机，它们包括在数据中心的 Azure 虚拟机和裸金属主机。
• 我们数据库存储了超过 300 TB 的数据，并且在 50 多个数据库集群中每秒处理 550 万次的查询。
• 每个集群都带有主集群加副本集群的配置，用来实现高可用性。
• 我们做到了数据分区。我们利用水平和垂直分片来扩展 MySQL 集群，针对特定的领域，我们有特定的 MySQL 集群来存储这些特定领域的数据，同时我们还为大区域提供了水平分片的 Vitess 集群，这些区域的增长超出了单-主 MySQL 集群的规模。
• 我们拥有一个庞大的工具生态系统，包括 Percona Toolkit、gh-ost、orchestrator、freno 以及内部自动化，用于运营我们的平台。

上面所有的这些组合成一个多样化且复杂的部署，需要在保持我们的 SLOs 的同时进行升级。

准备阶段

作为 GitHub 主要的数据存储，我们对可用性设定了很高的标准。由于我们的数据库集群的规模和 MySQL 基础设施的关键性，我们对升级过程确定了一下的要求：

• 我们必须在遵守我们的服务水平目标（SLO）和服务水平协议（SLA）的同时升级每个 MySQL 数据库。
• 我们无法在测试和验证阶段考虑所有的故障模式，因此，为了保持在服务水平目标（SLO）范围内，（在发生升级故障时）我们需要能够在不中断服务的情况下可以回滚到先前的 MySQL 5.7 版本。
• 我们的 MySQL 集群负载非常多样化，为了降低风险，我们需要对每个数据库集群进行原子升级，并在其他重大变更周围安排计划，这意味着升级过程会很长，因此我们从一开始就预见我们需要能够维持运行混合版本的环境。

升级准备工作开始于 2022 年 7 月，甚至在升级任何一个生产数据库之前，我们就设定了几个关键里程碑。

准备升级的基础设施

我们需要确定 MySQL 8.0 的适当默认值，并进行一些基准性能测试。因为我们需要操作两个版本的 MySQL，我们的工具和自动化需要能够处理混合版本，并且能够识别在 5.7 和 8.0 之间的新的、不同的或已弃用的语法。

确保应用兼容性

我们将 MySQL 8.0 添加到所有使用 MySQL 的应用程序的持续集成（CI）中。我们在 CI 中并行运行 MySQL 5.7 和 8.0，以确保在长时间的升级过程中不会出现回归。我们检测到 CI 中的各种错误和不兼容性，帮助我们删除任何不受支持的配置或功能，并转义任何新的保留关键字。

为帮助应用程序开发人员过渡到 MySQL 8.0，我们还在 GitHub Codespacees 中启动了选择 MySQL 8.0 预构建容器的选项，以便进行调试，并为额外的预生产测试提供了 MySQL 8.0 开发集群。

沟通和透明度

我们使用 GitHub Projects 创建了一个 滚动日历，以便在内部进行升级计划的沟通和跟踪。我们创建了 issue 模版，用于跟踪应用团队和数据库团队的 checklist，以协调升级工作。

升级计划

为了满足我们的可用性标准，我们采用了一种渐进式升级策略，允许在整个过程中设置检查点和回滚。

步骤一：滚动副本升级

我们首先升级了单个副本，并在其离线状态下进行监控，以确保基本功能稳定。然后我们启用了生产流量，并继续监控查询延迟、系统指标和应用程序指标。接着，我们逐步将 8.0 副本上线，直到升级了整个数据中心，然后遍历其他数据中心。同时，我们还保留了足够的 5.7 版本的副本以便进行回滚，但我们禁用了它们的生产流量，开始通过 8.0 服务器提供所有的读取流量。

步骤二：更新复制拓扑

在所有的只读流量通过 8.0 副本提供服务后，我们调整了复制拓扑如下：

• 配置一个 8.0 的主备候选节点，直接在当前的 5.7 主节点下进行复制。
• 在那个 8.0 副本的下游创建了两个复制链：
  • 一组仅包含 5.7 版本的副本（不提供流量，但已准备好以防回滚）
  • 一组仅包含 8.0 版本的副本（服务流量）
• 拓扑结构在这个状态下只持续了很短的时间（最多几个小时），然后我们就进入了下一步

步骤三：将 MySQL 主机升级为主节点

我们选择不直接在主数据库主机上进行升级。相反，我们将通过 Orchestrator 执行的优雅故障切换将一个 MySQL 8.0 副本升级为主数据库。在那时，复制拓扑结构包括一个8.0 主数据库，连接到它的有两个复制链：一个用于回滚的离线的 5.7 副本集和一个用于服务的 8.0 副本集。

Orchestrator 还能将 5.7 版本的数据库主机作为潜在的故障切换候选者列入黑名单，以防止在计划外的故障切换时发生意外回滚。

步骤四: 升级内部实例类型

我们在内部还拥有用于备份或非生产工作负载的辅助服务器，我们对这些服务器也进行了升级以确保一致性。

步骤五：清理

一旦我们确认这些集群无需再回滚，并已成功升级至 8.0 版本，我们就移除 5.7 版本的服务器。然后验证包括至少完成一轮完整的 24 小时流量循环，以确保在流量高峰期间没有问题。

回滚的能力

保持我们升级策略的一个核心部分就是能够回滚到之前的 MySQL 5.7 版本的能力。对于只读副本，我们确保保持足够的 5.7 副本在线以提供生产流量负载，并且如果 8.0 副本运行不良时，通过禁用这些 8.0 副本来启动回滚操作；对于主节点来说，为了在不丢失数据或中断服务的情况下进行回滚，我们就需要能够在 8.0 和 5.7 之间保持双向的数据复制。

MySQL 数据复制支持从一个版本复制到下一个更高的版本，但并不明确支持相反过程（MySQL 复制的兼容性）。当我们在演示集群上测试将 8.0 主机升级为主节点时，我们发现所有的 5.7 副本的复制都中断了。下面是我们需要解决几个问题：

1. 在 MySQL 中，utf8mb4 是默认的字符集，并使用更现代的 utf8mb4_0900_ai_ci 排序规则作为默认值，之前的 MySQL 5.7 版本支持 utf8mb4_unicode_520_ci 排序规则，但不支持最新版本的 Unicode utf8mb4_0900_ai_ci。
2. MySQL 8.0 引入了角色管理的特性，但这个特效在 MySQL 5.7 中并不存在。当将 8.0 实例提升为集群中的主节点时，我们遇到了问题，我们的配置管理会将某些权限集扩展为包含角色语句并执行它们，这会导致 5.7 副本的下游复制中断，我们是通过在升级窗口期间临时调整受影响用户的定义权限从而解决了这个问题。

为了解决字符排序规则的不兼容性，我们必须将默认字符编码设置为 utf8，排序规则设置为 utf8_unicode_ci。

对于 GitHub.com 的整体架构，我们的 Rails 配置确保字符排序规则一致，并且使得标准化客户端配置到数据库变得更容易。因此，我们对于我们最关键的应用程序能够保持双向复制具有很强的信心。

挑战

在我们的测试、准备和升级过程中，我们遇到了一些技术挑战。

关于 Vitess

我们使用 Vitess 对关系型数据进行水平分片。总体而言，升级我们的 Vitess 集群与升级 MySQL 集群并无太大不同。我们已经在 CI 中运行 Vitess，因此我们能够验证查询的兼容性。在我们分片集群的升级策略中，我们一次升级一个分片。VTgate，即 Vitess 代理层，会广播 MySQL 的版本信息，而一些客户端行为取决于这个版本信息。例如，一个应用程序使用了一个禁用了 5.7 服务器查询缓存的 Java 客户端，因为在 8.0 中移除了查询缓存，对于它们来说，这会生成阻塞错误。因此，一旦给定 keyspace 的单个 MySQL 主机完成升级，我们必须确保我们也更新了 VTgate 的设置以广播 8.0 的信息。

复制延迟

我们使用读取副本来扩展我们的读取可用性，GitHub.com 需要低的复制延迟，以提供最新的数据。

在我们的测试早期，我们遇到了一个 MySQL 的复制错误，它在 8.0.28 版本中被修复：

Replication: If a replica server with the system variable replica_preserve_commit_order = 1 set was used under intensive load for a long period, the instance could run out of commit order sequence tickets. Incorrect behavior after the maximum value was exceeded caused the applier to hang and the applier worker threads to wait indefinitely on the commit order queue. The commit order sequence ticket generator now wraps around correctly. Thanks to Zhai Weixiang for the contribution. (Bug #32891221, Bug #103636)

我们恰好符合触发此错误的所有条件：

• 我们使用 replica_preserve_commit_order，因为我们使用基于 GTID 的复制。
• 我们的许多集群在很长一段时间内承受着高强度的负载，尤其是我们最关键的集群。大部分集群都有很高的写入压力。

由于此错误已在上游修复，我们只需要确保我们部署的 MySQL 版本高于 8.0.28 版本即可。

我们还观察到，在 MySQL 8.0 中，导致复制延迟的大量写入问题变得更加严重。这使得我们更加重视避免大量的写入突发情况。在 GitHub，我们使用 freno 来根据复制延迟来控制写入工作负载。

查询在 CI 中通过但是在生产环境失败

我们知道在生产环境中不可避免地会出现问题，因此我们采用了逐步升级副本的策略。我们遇到了一些在 CI 中通过的查询，在生产环境中遇到真实工作负载时却失败的情况。其中一个显著的问题是，在具有大型 WHERE IN 子句的查询中，MySQL 会崩溃。我们有一些包含数万个值的大型 WHERE IN 查询。在这些情况下，我们需要在继续升级过程之前重写这些查询。查询抽样有助于跟踪和检测这些问题。在 GitHub，我们使用 Solarwinds DPM（VividCortex），即一个 SaaS 数据库性能监控工具，用于查询可观察性。

经验教训和收获

经过测试、性能调优和解决已识别的问题，我们的整个升级过程持续了一年多，其中涉及到 GitHub 的多个团队的工程师。最终我们将我们的整个集群升级到了 MySQL 8.0，包括用户 GitHub.com 的演练集群、生产集群以及支持我们内部工具的实例。此次升级凸显了我们可观察性平台、测试计划和回滚能力的重要性。测试和逐步推出策略使我们能够及早发现问题，并减少主要升级中遇到新故障模式的可能性。

尽管有逐步推出的策略，我们仍然需要在每一步都具备回滚的能力，并且我们需要能够观察以识别何时需要回滚的信号。使回滚变得最具挑战的方面是保持从新的 8.0 主服务器到 5.7 副本的反向复制。我们发现 Trilogy 客户端库的一致性为我们提供了更可预测的连接行为，并让我们有信心，主 Rails 单体的连接不会破坏反向复制。

然而，对于我们的一些 MySQL 集群，连接来自不同框架/语言的多个不同客户端，我们发现反向复制在几个小时内就会中断，缩短了回滚机会的时间窗口。幸运的是，这些情况很少见，我们没有出现在我们需要回滚之前复制中断的情况。但对我们来说，这是一个教训，即具有已知且被充分理解的客户端连接配置是有益的。它强调了制定准则和框架以确保在这些配置中保持一致性的价值。

我们之前对数据进行分区的努力得到了回报——它使我们能够针对不同的数据领域进行更有针对性的升级。这一点非常重要，因为一个失败的查询会阻塞整个集群的升级，而不同的工作负载分区使我们能够逐步进行升级，并减少在过程中遇到的未知风险的影响范围。这种权衡的结果是我们的 MySQL 集群规模也随之增长。

GitHub 上次升级 MySQL 版本时，我们有五个数据库集群，现在我们有 50 个以上的集群。为了成功升级，我们不得不投资于监测、工具和管理整个群集的流程。

小结

此次 MySQL 升级只是我们必须执行的例行维护中的一种类型——对于我们在集群上运行的任何软件，都必须具备升级路径。作为升级项目的一部分，我们开发了新的流程和操作能力，成功完成了 MySQL 版本的升级。然而，在升级过程中仍然有太多需要手动干预的步骤，我们希望减少完成未来 MySQL 升级所需的工作量和时间。

我们预计随着 GitHub.com 的增长，我们的集群将继续扩大，并且我们有将数据进一步分区的目标，这将随着时间增加我们的 MySQL 集群数量。在操作任务和自愈能力方面进行自动化建设可以帮助我们未来扩展 MySQL 运营能力。我们相信，投资可靠的集群管理和自动化将使我们能够扩展 GitHub，并跟上所需的维护工作，提供更可预测和弹性的系统。

此次升级的经验为我们的 MySQL 自动化奠定了基础，并为将来的升级铺平了道路，使其更加高效完成，但仍然保持同样的关注和安全水平。

（全文完）

交换机概述

什么是交换机

交换机是一种网络硬件设备，用于连接多台设备（如计算机、服务器、打印机等），使它们能够在一个局域网（LAN）内通过数据包进行通信，现如今，交换机是包括互联网在内的现代 IT 网络的基本组成部分之一，它解决了设备间通信的问题。

交换机接受一个设备的数据包，并且将数据包发送到指定的设备上去，从而实现设备间高效通信。交换机是如何知道它收到的数据包应该发往哪个设备呢？其实是通过 MAC 地址来实现的，交换机收到的网络报文头里包含了源 MAC 地址和目的 MAC 地址，然后交换机在它的地址表中找到对应的网络设备，从而将数据包发往指定的设备。关于交换机具体的工作原理，将在下面具体介绍。

交换机类型

从网络模型上来看，我们说的交换机一般都是指的工作在二层网络模型上面的交换机，我们称为二层交换机，它通过检查数据帧的目标 MAC 地址，将数据帧发送到正确的目标设备，从而实现局域网内的数据通信，并通过构建 MAC 地址表来实现数据的快速转发和广播域的隔离。当然，也存在三层交换机，它具备路由功能，可以根据目标 IP 地址来进行数据包的转发，它能够根据网络层的信息进行智能的数据包转发，提高网络的性能和效率；同时，三层交换机具备执行路由的功能，它可以执行静态路由和动态路由，具有更快的切换速度，甚至比传统的路由器更快，三层交换机可以执行 IP 地址和子网划分来路由数据包，同时处理 VLAN 内通信以及不同 VLAN 之间的数据包路由。

下面是二层交换机和三层交换机的特点：

通常二层交换机有如下使用场景：

1. 办公室局域网：在办公室环境中，二层交换机用于连接各个工作站、打印机和其他网络设备，实现内部局域网的通信和数据交换。
2. 数据中心网络：在大型数据中心中，二层交换机用于连接服务器、存储设备和其他网络设备，提供高带宽、低延迟的数据交换和通信。
3. 无线接入网络：在无线网络中，二层交换机通常用于连接无线接入点（Access Point），将无线设备连接到有线网络，并提供无线设备之间的数据转发和通信。

三层交换机有如下使用场景：

1. 跨子网通信：在大型企业网络中，三层交换机用于实现不同子网之间的通信，通过路由功能将数据包从一个子网转发到另一个子网，实现跨网络的数据交换。
2. 虚拟化环境：在虚拟化环境中，三层交换机用于连接虚拟机和物理服务器，提供虚拟机之间和虚拟机与物理服务器之间的高性能数据交换和通信。
3. 多租户网络：在云计算环境或多租户网络中，三层交换机用于隔离不同租户的网络流量，提供安全的数据隔离和路由功能，确保不同租户之间的数据互不干扰。

交换机的连接方式

根据网络的需求和拓扑结构的不同，交换机有多种不同的连接方式。

1. 直连连接（Point-to-Point）：两个交换机通过一根直接的物理电缆连接，适用于小型网络或相邻设备之间的连接。
2. 级联连接（Daisy-Chaining）：多个交换机按顺序连接在一起，形成链状结构，用于扩展网络规模，但链的长度可能影响性能。
3. 聚合连接（Link Aggregation）：将多个物理链路组合成一个逻辑上的连接，增加带宽、提高冗余。例如，MALG 就是一种聚合连接的方式。
4. 星型连接（Star Topology）：交换机直连到一个中心设备，通常是网络中心交换机或者路由器，提供简单的管理和良好的冗余性。
5. 环形连接（Ring Topology）：交换机按环形连接，提供冗余路径，但当其中一个连接中断时可能影响到整个环。
6. 堆叠连接（Stacking）：多个交换机通过特殊的堆叠接口或电缆连接，形成逻辑上的单一设备，用于增加端口数量和提高性能。
7. 交叉连接（Cross-Connect）：直接连接两个交换机，通常在大型数据中心或企业网络中使用，提高网络性能和减少延迟。

堆叠和 MLAG 比较

由于我们业务中，这两种形态比较多，这里着重介绍一下交换机堆叠和 MLAG 两种工作方式。

堆叠

交换机堆叠是通过将多个交换机连接在一起，形成一个逻辑上的单一设备，主要是用于扩展交换机端口数量和提高带宽，提高系统整体性能。这一组连接在物理上通过专用的堆叠接口或堆叠电缆连接。在逻辑上，这些堆叠的交换机被视为一个整体，共享一个管理 IP 地址、配置和操作状态。通过堆叠，可以统一管理整个堆叠，简化网络管理。

堆叠是提升系统的健壮性、提升性能的手段。

MLAG

MLAG（MUlti-chassis Link Aggregation）是一种通过多个设备形成链路聚合组（LAG）以实现冗余的方法，MLAG 是通过对等链路连接两个交换机，并形成一个链路聚合组，以作为逻辑上的单一设备，可以使用该机制将更多的交换机添加到链路聚合组中。目前 MLAG 已经成为一种广泛应用的链路聚合方法，MLAG 拓扑结构可以在很大程度上扩展网络能力，它在 LAG 提供的传统链路级冗余基础上增加了节点级冗余，提高系统可靠性，并简化管理，在这个系统中，当其中一个交换机失效时，系统仍然可以工作。

MALG 是提升系统高可用性的手段。

MLAG 的高可用实现

总的说来，交换机 MLAG 技术通过多种手段确保了整个系统的可靠性和故障恢复能力，主要表现为以下几个关键方面：

1. 对等链路（Peer-Link）：MLAG 中的两个交换机通过对等链路进行连接。对等链路是一条专用链路，用于传输 MALG 协议消息和同步数据。通过对等链路，两个交换机之间可以实现实时的状态同步和故障检测。
2. 逻辑单元：MLAG 中的多个交换机被视为一个逻辑单元，它们共享相同的 MAC 地址和配置信息。这意味着对外部设备而言，MALG 表现为一个单一的逻辑交换机，提供冗余和负载均衡。
3. 心跳检测：MLAG 中的交换机通过对等链路进行心跳检测，以确保彼此的可用性。如果一台交换机无法检测到对等链路上的心跳信号，它将认为对方交换机发生故障，并接管系统对外提供服务。
4. 数据同步：MLAG 中的交换机通过对等链路同步数据，以确保数据的一致性。当一台交换机接管另一台交换机的功能时，它会继续处理之前交换机处理的数据流，以实现无缝的故障转移。
5. 网络拓扑：MLAG 的高可用性还取决于网络拓扑的设计。为了实现冗余和故障恢复，MLAG 中的交换机应该通过不同的物理路径连接到其他设备，以避免单点故障。

这里再单独说一下 MLAG 中数据同步的问题。我们知道，在一个分布式系统中，数据的一致性是及其重要的，同时在一个分布式系统中实现数据的一致性也是及其复杂的。同样的，在交换机 MLAG 机制中，数据一致性也是必要的，它主要是通过对等链路实现数据一致性的。

这种数据一致性主要包括 MAC 地址同步和数据转发。每个交换机维护了一个共享的 MAC 地址表，用于转发数据包到指定的目标设备，当一个交换机学习到新的 MAC 地址时，它会通过对等链路将该信息发送给另外一个交换机，以确保两个交换机的 MAC 地址表保持一致。MLAG 交换机对外表现为一个逻辑单元，当这个逻辑单元收到数据包时，MLAG 交换机可以共同处理数据流量，并确保数据包按相同的规则进行转发。

交换机的工作原理

交换机的工作原理基于数据链路层的功能，我们知道数据包在网络上进行传输时，都是一个完整的数据包，这里说的完整的数据包指的是它应当包含网络模型中每一层的结构，一个不完整的数据包是无法在网络上传输的。

上面说到网络上传输的都是一个完整的数据包，每一层的数据包都有其特定的报文格式，一般来说一个即将发送的数据，最开始由上层协议组装，然后下层的数据包都是在上一层的数据包的基础上加上自己特有的数据头，这样数据经过层层组装，最终成为一个完整的包，最终发出去，并且每一层的数据包是在不同的地方进行组装和处理的，这里以 MAC 头和 IP 头为例简单描述一下：

比如说上图中的 MAC 头部分，就是由交换机组装的，交换机将数据组装成数据帧，其中包含了目标设备的 MAC 地址和源设备的 MAC 地址。搞明白了数据包在各层的组装方式以后，这里我用一个非常常用的 ping 的例子说一下交换机在数据包传输过程中的工作原理：

假设在一个简单的局域网内，192.168.1.1 的机器去 ping 192.168.1.2 的机器（ping 使用的 ICMP 协议不是本文讨论的范围，不作说明，只重点说明交换机的作用），首先这两台机器的 ip 地址在同一个网段内，它们是可以 ping 通的。

这里上来就会遇到第一个问题，上面我们说到数据要在网络上传输，数据包必须是完整的，但是很明显 192.168.1.1 这个机器只知道要 ping 的机器的 ip 地址，也就是192.168.1.2，它并不是对方的 MAC 地址是多少，应该怎么办呢？答案就是 ARP 协议（ARP 不在本文讨论的范围，不作说明）。

我们知道了机器 192.168.1.1 是通过发送 ARP 报文知道了机器 192.168.1.2 的 MAC 地址，然后组装好一个完整的数据包，数据包在交换机处理时，这时交换机会做一个事情，那就是 MAC 地址学习。数据包中包含了源设备（机器 192.168.1.1）的 MAC 地址，交换机会在地址表中查找是否有这个端口和源设备 MAC 地址的对应关系，如果没有，它会进行 MAC 地址学习，在地址表中新增该端口和源设备 MAC 地址的对应关系，或者更新该地址表。

接着，交换机会在地址表中查找目标设备 MAC 地址的记录，如果在地址表中找到了目标设备 MAC 地址对应的端口，就直接把数据包发往对应的端口。那么这里又来了新的问题，如果没有在地址表中找到呢？很容易想到，那就是广播，交换机会广播数据包到除了源设备端口以外的其他所有端口，数据包广播出去以后，目标设备在收到数据包后，会根据 MAC 地址判断这个数据包是否是发给自己的，如果是，它会发送一个响应。一旦目标设备响应，交换机会学习并记录新的 MAC 地址和端口的对应关系，新增地址表。

经过几轮的广播洪泛，就可以确保在交换机地址表中建立正确的 MAC 地址与端口的映射关系，从而提高网络转发的效率和准确性。需要注意的是，频繁的广播洪泛可能导致网络中的一些性能问题，因此交换机通常会采用一些优化策略，如 Aging Time（老化时间）来控制地址表中映射的生命周期，防止不必要的广播洪泛。

VLAN

上面说了交换机的工作原理，现在我们来思考两个问题：

广播问题：根据交换机的工作原理，很容易想到，随着网络内设备的不断增多，整个系统内广播包一大堆，性能势必就会下降。

安全问题：广播包每个设备都可以收到，试想如果局域网内每个设备都可以收到广播包，简单抓包就可以知道很多信息，会带来数据安全的问题。

尤其是现在云的时代，云计算设施和大型数据中心内，上述问题会尤为突出，为了解决这些问题，就需要做好隔离。网络隔离包括了传统意义上的物理隔离和虚拟隔离。

物理隔离

先说物理隔离，每个需要隔离的逻辑单元都使用单独的交换机，配置单独的子网，可以解决上述问题，但是想象一下在大型企业或者大型数据中心里面，这种全面的物理隔离势必会增加大量的成本，所以目前这种手段并不是首选。

虚拟隔离

还有一种方式就是虚拟隔离，这就是我们常用的 VLAN，全称叫做虚拟局域网。使用 VLAN，一个交换机上会连属于多个局域网的机器，交换机是根据 VLAN ID 来区分不同的机器所属的局域网的。具体的实现方式也很好理解，只需要在原来的数据包的二层头上加一个 TAG，里面有一个 VLAN ID，一共 12 位，最多可以划分 4096 个 VLAN。

如果我们买的交换机是支持 VLAN 的，当交换机把二层的头取下来的时候，就能够识别这个 VLAN ID，这样只有相同 VLAN 的包，才会相互转发，不同 VLAN的包，是看不到的，这样广播和安全的问题就都能解决了。

交换机的 VLAN ID 是 12 位的，这是因为 IEEE 802.1Q 标准规定了 VLAN 标签的格式和长度。在 VLAN 标签中，有 16 位用于 VLAN 标识符（VLAN Identifier，简称 VID）。这 16 位中，有 12 位用于表示 VLAN 的编号，可以用来标识不同的 VLAN。

为什么 VLAN ID 只有 12 位呢？这是因为在 VLAN 标签中，还有其他的字段需要占用一部分位数。其中，2 位用于标识标签协议识别符（Tag Protocol Identifier，简称 TPID），用于识别帧是否为 IEEE 802.1Q 标签帧。另外，还有 1 位用于标识丢弃优先级（Drop Eligible Indicator，简称 DEI），用于指示在拥塞情况下是否可以丢弃该帧。最后，还有 1 位用于标识优先级代码点（Priority Code Point，简称 PCP），用于指定帧的优先级。

因此，剩下的 12 位就用于表示 VLAN 的编号，这样可以支持最多 4096 个不同的 VLAN。其中，编号为 0 和 4095 的 VLAN 是保留的，不能用于实际的 VLAN。所以实际可用的 VLAN 编号范围是从 1 到 4094。

GRE & VXLAN

上面说了 VLAN 这种虚拟局域网的实现，我们知道由于 VLAN ID 只有 12 位，因此它只能支持最多 4096 个不同的 VLAN，最初设计的时候看起来是够了，但是现如今在大型的数据中心或者云计算平台等地方显然是不够用的，该如何解决这个问题呢？

• 一种方式是修改协议：显然是不现实、不可能的，已经形成标准的协议并且在千千万万的设备上都按照这个协议来跑的程序，不可能去做协议层面的修改。
• 另外一种方式就是扩展：在原来包格式的基础上扩展出一个头，里面包含足够用于区分租户的 ID，外层包的格式和原来的保持一样。

那么机遇上面扩展的思路，就有了 Overlay 网络，这是一种基于物理网络的虚拟化网络实现。而 Overlay 网络的两个著名的实现有 GRE 和 VXLAN。

GRE

先说 GRE，GRE 全称 Generic Routing Encapsulation，它是一种 IP-over-IP 的隧道技术。它将 IP 包封装在 GRE 包里，外面加上 IP 头，在隧道的一端封装数据包，并在通路上进行传输，到另外一端的时候解包。你可以认为 Tunnel 是一个虚拟的、点对点的连接。

上图可以看到，在 GRE 包头中，前 32 位是一定会有的，后面的都是可选的。包头里面的 key 字段，是一个 32 位的字段，里面存放的就是用于区分用户的 Tunnel ID，32 位足够了。

下面的格式类型是专门用于网络虚拟化的 GRE 包头格式，称为 NVGRE，它的网络号是 24 位，也完全够用了。

使用 GRE 隧道，我以下图的场景为例，说明一下数据包是如何传输的：

这里面有两个网段，两个路由器，中间要通过 GRE 隧道进行通信，当隧道建立以后，会多出两个 Tunnel 端口，用于封包、解包。

1. 主机 A 在左边的网络，IP 地址为 192.168.1.102，它想要访问主机 B，主机 B 在右边的网络，IP 地址为 192.168.2.115。于是发送一个包，源地址为 192.168.1.102，目标地址为 192.168.2.115。因为要跨网段访问，于是根据默认的 default 路由表规则，要发给默认的网关 192.168.1.1，也即左边的路由器。
2. 根据路由表，从左边的路由器，去 192.168.2.0/24 这个网段，应该走一条 GRE 的隧道，从隧道一端的网卡 Tunnel0 进入隧道。
3. 在 Tunnel 隧道的端点进行包的封装，在内部的 IP 头之外加上 GRE 头。对于 NVGRE 来讲，是在 MAC 头之外加上 GRE 头，然后加上外部的 IP 地址，也即路由器的外网 IP 地址。源 IP 地址为 172.17.10.10，目标 IP 地址为 172.16.11.10，然后从 E1 的物理网卡发送到公共网络里。
4. 在公共网络里面，沿着路由器一跳一跳地走，全部都按照外部的公网 IP 地址进行。
5. 当网络包到达对端路由器的时候，也要到达对端的 Tunnel0，然后开始解封装，将外层的 IP 头取下来，然后根据里面的网络包，根据路由表，从 E3 口转发出去到达服务器 B。

GRE 的问题

从上面我们知道，GRE 通过隧道的方式，很好地解决了 VLAN ID 不足的问题，但是 GRE 本身还是存在不少问题。

• Tunnel 数量问题。GRE 是一种点对点隧道，如果有三个网络，就需要在每两个网络之间建立一个隧道。如果网络数目增多，这样隧道的数目会呈指数性增长。
• GRE 不支持组播，因此一个网络中的一个虚机发出一个广播帧后，GRE 会将其广播到所有与该节点有隧道连接的节点。
• 当前有很多防火墙和三层网络设备无法解析 GRE，因此它们无法对 GRE 封装包做合适的过滤和负载均衡。

VXLAN

VXLAN 全称叫做虚拟可扩展局域网，也是一种网络虚拟化技术标准，它允许单个物理网络被多个不同的组织或租户共享，而任何一个租户都无法看到其他任何租户的网络流量。

从技术实现上来看，VXLAN 通过在 4 层 UDP 数据包中封装 2 层 以太网帧，使其能够创建跨越 3 层 物理网络的虚拟化 2 层子网。每个分段的子网都由 VXLAN 网络标识符（VNI）唯一标识。在 VXLAN 网络实现中，执行数据包的封装和解包的实体叫做 VTEP（VXLAN Tunnel Endpoint），VTEP 可以是独立的网络设备，例如物理路由器或者交换机，也可以是部署在服务器上的虚拟交换机。VTEP 将以太网帧封装为 VXLAN 数据包，然后通过 IP 或其他 3 层网络发送到目标 VTEP，在那里进行解封并转发到目标服务器。为了支持无法独立作为 VTEP 运行的设备，例如裸金属服务器，一些硬件 VTEP 可以封装和解封数据包。VTEP 可以驻留在 Hypervisor 主机中，例如基于内核的虚拟机（KVM），以直接支持虚拟化工作负载。这种类型的 VTEP 被称为软件 VTEP。

从报文格式上来看，VXLAN 和 GRE 不同，VXLAN 是从二层外面就套了一个 VXLAN 的头，这里面包含的 VXLAN ID 为 24 位，非常够用了。在 VXLAN 头外面还封装了 UDP、IP，以及外层的 MAC 头。

和 GRE 端到端的隧道不同，VXLAN 不是点对点的，而是支持通过组播来定位目标机器的，不一定是这一端发出，另外一个端接收。当一个 VTEP 启动的时候，它们都需要通过 IGMP 协议加入到一个组播组，就像加入到一个微信群一样，所有发送到这个“微信群”里面的消息，大家都能收到，而当每个物理机上的虚拟机启动之后，VTEP 就知道，有一个新的 VM 上线了，它归我管。

下面我以一个云平台中的例子，说明这个通信过程。

如图，假设虚机 1、2、3 属于云中同一业务的机器，因此给他们划分了相同的 VXLAN ID，在机器上，我们分别可以知道它们的 IP 地址，于是可以在虚拟机 1 上 ping 虚拟机 2。这个时候虚拟机 1 并不知道虚拟机 2 的 MAC 地址，因此这个包是发不出去的，所以要先发送 ARP 广播。

ARP 请求到达 VTEP1 的时候，VTEP1 知道要访问一台“不归自己管”的机器，上面提到它不是加了一个组播组吗，于是就类似于在微信群里发送 @all 消息一样，问一下虚拟机 2 归睡管，于是 VTEP1 将 ARP 请求封装在 VXLAN 里面，组播出去。由于同一个组播组，VTEP2 和 VTEP3 当然都收到了消息，因此都会解开 VXLAN 包看，里面是一个 ARP。

VTEP3 在本地广播半天，没人回；同样地，VTEP2 也在本地广播，虚拟机 2 回了，于是 VTEP2 便知道了虚拟机 2 归它管，也知道了虚拟机 2 的 MAC 地址，同时，VTEP2 也学会了虚拟机 1 归 VTEP1 管，以后要找虚拟机 1，去找 VTEP1 就可以了。

VTEP2 将 ARP 的回复封装在 VXLAN 里面，这次不用组播了，直接发回给 VTEP1。VTEP1 解开 VXLAN 的包，发现是 ARP 的回复，于是发给虚拟机 1。通过这次通信，VTEP1 也学到了，虚拟机 2 归 VTEP2 管，以后找虚拟机 2，去找 VTEP2 就可以了。虚拟机 1 的 ARP 得到了回复，知道了虚拟机 2 的 MAC 地址，于是就可以发送包了。

虚拟机 1 发给虚拟机 2 的包到达 VTEP1，它当然记得刚才学的东西，要找虚拟机 2，就去 VTEP2，于是将包封装在 VXLAN 里面，外层加上 VTEP1 和 VTEP2 的 IP 地址，发送出去。网络包到达 VTEP2 之后，VTEP2 解开 VXLAN 封装，将包转发给虚拟机 2。虚拟机 2 回复的包，到达 VTEP2 的时候，它当然也记得刚才学的东西，要找虚拟机 1，就去 VTEP1，于是将包封装在 VXLAN 里面，外层加上 VTEP1 和 VTEP2 的 IP 地址，也发送出去。网络包到达 VTEP1 之后，VTEP1 解开 VXLAN 封装，将包转发给虚拟机 1。

完成整个通信流程。

VXLAN 和 EVPN

EVPN（Ethernet VPN）是一种以太网虚拟专用网络技术，它提供了一种灵活、可扩展的解决方案，用于在广域网（WAN）中扩展以太网服务。EVPN 通过使用 BGP（边界网关协议）作为控制平面，将以太网的 2 层和 3 层连接扩展到跨越多个站点的网络中。当 VXLAN 与 EVPN 结合使用时，操作员可以在支持该标准并且属于同一 3 层网络的任何物理网络交换机上创建虚拟网络。例如，可以从交换机 A 获取一个端口，从交换机 B 获取两个端口，再从交换机 C 获取另外一个端口，然后构建一个虚拟网络，对所有连接的设备来说，它看起来就像是一个单一的物理网络，参与此虚拟网络的设备将无法看到其他 VXLAN 或底层网络的流量。下面是 VXLAN 和 EVPN 结合使用的一些主要优势：

1. 灵活的网络扩展：VXLAN 与 EVPN 结合使用可以在 3 层 IP 或 MPLS 网络上扩展 2 层网络，这意味着，我们可以在支持 EVPN 的任何物理网络交换机上创建虚拟网络，而不受物理布局和地理距离的限制，这使得网络扩展变得更加灵活和容易。
2. 简化的网络管理：VXLAN 与 EVPN 结合使用可以将虚拟网络与物理基础设施分离，从而简化了网络管理。操作员可以在支持 EVPN 的交换机上创建虚拟网络，而无需关心底层物理网络的细节。这使得网络配置和管理变得更加简单和高效。
3. 安全的网络分段：VXLAN 与 EVPN 结合使用可以实现安全的网络分段。每个虚拟网络都可以作为一个独立的分段，不同的虚拟网络之间的流量是隔离的。这样可以确保不同租户之间的流量互不干扰，提高了网络的安全性。
4. 高性能和高扩展性：VXLAN 与 EVPN 结合使用可以提供高性能和可扩展性的网络解决方案。EVPN 使用 BGP（Border Gateway Protocol）作为控制平面，可以实现灵活的路由和转发。VXLAN 提供了灵活的数据平面封装和解封装，可以在大规模网络中实现高性能的数据传输。
5. 多站点互联：VXLAN 与 EVPN 结合使用可以实现多站点互联。通过在不同数据中心的交换机上创建虚拟网络，并使用 EVPN 进行路由和转发，可以实现跨数据中心的网络互联。这使得数据中心之间的数据传输更加灵活和高效。

Reference

https://www.geeksforgeeks.org/difference-between-layer-2-and-layer-3-switches/

https://documentation.meraki.com/MS/Layer_3_Switching/Comparing_Layer_3_and_Layer_2_Switches

https://www.qsfptek.com/qt-news/switch-stacking-vs-mlag.html

https://www.practicalnetworking.net/stand-alone/vlans/

https://www.practicalnetworking.net/stand-alone/routing-between-vlans/

https://time.geekbang.org/column/intro/100007101?tab=catalog

https://www.techtarget.com/searchnetworking/definition/virtual-LAN

https://www.n-able.com/blog/what-are-vlans

https://www.solarwinds.com/resources/it-glossary/vlan

https://en.wikipedia.org/wiki/Virtual_Extensible_LAN

https://www.juniper.net/us/en/research-topics/what-is-vxlan.html

https://www.juniper.net/us/en/research-topics/what-is-evpn-vxlan.html

https://support.huawei.com/enterprise/en/doc/EDOC1100168670

（全文完）

• 丰富的主题
• 完善的插件系统
• 支持独立部署
• 功能齐全

同时我也认为它有不好的地方（个人主观观点）：

• PHP 驱动实现，稍有笨重，不够”现代化“
• 虽然有较为丰富的主题，但整体 UI 风格不是特别喜欢
• 用户系统不够完善，可玩性不高
• 不支持除 RSS 订阅以外的形态，例如：网页、文章阅读清单功能

基于上述，我决定自己开始探索这种类 RSS 阅读器的产品形态，自己做一个类 RSS 阅读器。

目前，大部分的博客网站都是支持 RSS 的，不支持 RSS 的网站，也有 RSS Hub 这样的产品帮助我们解决问题。RSS 文件订阅类型一般有 rss、atom、json类型，文件格式为 XML 和 JSON。网站将网站的内容信息整合到一个 RSS 文件中，这个文件我们一般称为 feed，也叫信源。在 RSS 文件里面具体包含了网站的标题、描述、作者信息、文章列表等信息，并且随着网站内容更新，RSS 文件也会随之更新，因此 RSS 阅读器通过定时解析 RSS 文件，就可以知道我们关注的网站有更新，实现了信息聚合。因此，最重要的过程就变成了两部分：

1. 生成 RSS 文件，搞定信息来源
2. 解析 RSS 文件，搞定信息展示

对于第 1 点来说，除了网站自身会提供 RSS 文件之外，也有诸如 RSS Hub 这样的项目，来帮助我们实现生成网站的 RSS 文件。第二部分，就是实现一个 RSS 阅读器的关键。这个过程本质不难，就是解析 RSS 文件，它们往往基于 XML 格式或者 JSON 格式，所以理论上我们只要解析到 XML 的 item 或者解析到 JSON 的节点，就能获取 RSS 文件的内容，从而获取网站的内容。

RSS 内容解析

在这之前，我们要搞清楚 RSS 文件都包含哪些内容，哪些内容是我们需要的，可以使用标准库来解析 XML 或者 JSON，当然 go 生态里面也有不少库已经帮我们做了这部分功能，这里我选择使用 gofeed 来解析 RSS 文件。

前面说到 RSS 文件有几种不同的类型，其中 rss 和 atom 类型都是基于 XML 格式的。例如 阮一峰的网络日志 就是 rss 类型的，云风 的博客就是 atom 类型的，通过例子也比较容易看出两种类型的区别。

gofeed 解析 RSS 文件，用法也比较简单，下面是几种常见的用法：

1
2
3
4

// parse feed from a rss URL
fp := gofeed.NewParser()
feed, _ := fp.ParseURL("http://feeds.twit.tv/twit.xml")
fmt.Println(feed)

1
2
3
4
5
6
7
8
9

// parse feed from String(XML or JSON)
feedData := `<rss version="2.0">
<channel>
<title>Sample Feed</title>
</channel>
</rss>`
fp := gofeed.NewParser()
feed, _ := fp.ParseString(feedData)
fmt.Println(feed)

1
2
3
4
5
6

// parse feed from file(io.Reader)
file, _ := os.Open("/path/to/a/file.xml")
defer file.Close()
fp := gofeed.NewParser()
feed, _ := fp.Parse(file)
fmt.Println(feed)

上面代码示例可以看到，我们最终解析到的都是一个 feed 对象，那么这个 feed 结构体具体包含哪些内容呢，不同的 RSS 文件类型有什么区别呢，下面结合 gofeed 结构体中的定义具体说明。

rss 类型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// Feed is an RSS Feed
type Feed struct {
Title               string                   `json:"title,omitempty"`
Link                string                   `json:"link,omitempty"`
Links               []string                 `json:"links,omitempty"`
Description         string                   `json:"description,omitempty"`
Language            string                   `json:"language,omitempty"`
Copyright           string                   `json:"copyright,omitempty"`
ManagingEditor      string                   `json:"managingEditor,omitempty"`
WebMaster           string                   `json:"webMaster,omitempty"`
PubDate             string                   `json:"pubDate,omitempty"`
PubDateParsed       *time.Time               `json:"pubDateParsed,omitempty"`
LastBuildDate       string                   `json:"lastBuildDate,omitempty"`
LastBuildDateParsed *time.Time               `json:"lastBuildDateParsed,omitempty"`
Categories          []*Category              `json:"categories,omitempty"`
Generator           string                   `json:"generator,omitempty"`
Docs                string                   `json:"docs,omitempty"`
TTL                 string                   `json:"ttl,omitempty"`
Image               *Image                   `json:"image,omitempty"`
Rating              string                   `json:"rating,omitempty"`
SkipHours           []string                 `json:"skipHours,omitempty"`
SkipDays            []string                 `json:"skipDays,omitempty"`
Cloud               *Cloud                   `json:"cloud,omitempty"`
TextInput           *TextInput               `json:"textInput,omitempty"`
DublinCoreExt       *ext.DublinCoreExtension `json:"dcExt,omitempty"`
ITunesExt           *ext.ITunesFeedExtension `json:"itunesExt,omitempty"`
Extensions          ext.Extensions           `json:"extensions,omitempty"`
Items               []*Item                  `json:"items"`
Version             string                   `json:"version"`
}

上面的结构体属性较多，我们只需要关注几个即可

• Title：通常是网站的标题

• Link：网站的 url 地址

• Links：网站的链接集合，通常包含网站的 url，网站订阅链接的 URL 等

• Description：网站的描述

• Items：注意看，这也是一个结构体，它就是我们解析的网站的内容集合，我们 RSS 阅读器就是要解析这部分内容，并把它每一个节点内容展示出来。

  点开 Items，它的结构属性如下：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

  // Item is an RSS Item type Item struct { Title string `json:"title,omitempty"` Link string `json:"link,omitempty"` Links []string `json:"links,omitempty"` Description string `json:"description,omitempty"` Content string `json:"content,omitempty"` Author string `json:"author,omitempty"` Categories []*Category `json:"categories,omitempty"` Comments string `json:"comments,omitempty"` Enclosure *Enclosure `json:"enclosure,omitempty"` Enclosures []*Enclosure `json:"enclosures,omitempty"` GUID *GUID `json:"guid,omitempty"` PubDate string `json:"pubDate,omitempty"` PubDateParsed *time.Time `json:"pubDateParsed,omitempty"` Source *Source `json:"source,omitempty"` DublinCoreExt *ext.DublinCoreExtension `json:"dcExt,omitempty"` ITunesExt *ext.ITunesItemExtension `json:"itunesExt,omitempty"` Extensions ext.Extensions `json:"extensions,omitempty"` Custom map[string]string `json:"custom,omitempty"` }

  这一部分，还是挑几个重要的属性说：

  • Title：这里的 Title 代表的是文章标题
  • Link：文章的 url 地址
  • Description：文章的概要描述
  • Content：文章的完整内容

  值得一提的是，不同的 RSS 服务提供方，这里面的字段会有稍微差别，比如说，有些网站提供的 RSS 订阅就只有 Description，没有 Content 属性（或者 Content 属性跟 Description 内容一样，并没有显示文章完整内容），所以你会看到在 RSS 阅读器上，有的订阅是可以完整显示内容的，有的只是显示了摘要，需要你点击到原网站才能看到完整的内容。比如 美团技术团队 的 RSS 文件，它的 Content 就不完整，你在 tt-rss 里面看到的就是这个样子

  关于这一部分不能解析到完整内容的 RSS 文件，我将在后面单独说。

  atom 类型

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

  // Feed is an Atom Feed type Feed struct { Title string `json:"title,omitempty"` ID string `json:"id,omitempty"` Updated string `json:"updated,omitempty"` UpdatedParsed *time.Time `json:"updatedParsed,omitempty"` Subtitle string `json:"subtitle,omitempty"` Links []*Link `json:"links,omitempty"` Language string `json:"language,omitempty"` Generator *Generator `json:"generator,omitempty"` Icon string `json:"icon,omitempty"` Logo string `json:"logo,omitempty"` Rights string `json:"rights,omitempty"` Contributors []*Person `json:"contributors,omitempty"` Authors []*Person `json:"authors,omitempty"` Categories []*Category `json:"categories,omitempty"` Entries []*Entry `json:"entries"` Extensions ext.Extensions `json:"extensions,omitempty"` Version string `json:"version"` }

  这是 atom 类型的结构体属性，大部分字段跟上面的 rss 类型差不多，不同的就是网站内容部分这里是 Entry，点开 Entry 属性，结构体属性如下：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  // Entry is an Atom Entry type Entry struct { Title string `json:"title,omitempty"` ID string `json:"id,omitempty"` Updated string `json:"updated,omitempty"` UpdatedParsed *time.Time `json:"updatedParsed,omitempty"` Summary string `json:"summary,omitempty"` Authors []*Person `json:"authors,omitempty"` Contributors []*Person `json:"contributors,omitempty"` Categories []*Category `json:"categories,omitempty"` Links []*Link `json:"links,omitempty"` Rights string `json:"rights,omitempty"` Published string `json:"published,omitempty"` PublishedParsed *time.Time `json:"publishedParsed,omitempty"` Source *Source `json:"source,omitempty"` Content *Content `json:"content,omitempty"` Extensions ext.Extensions `json:"extensions,omitempty"` }

  这种 atom 类型下，Summary 表示的就是网站概要总结，Content 表示的就是网站的完整内容。

  json 类型

  Json 类型跟字段属性跟上面两种类型差别不大，由于平时本人见的也不多，这里就不贴代码了，具体的代码见 gofeed 仓库。

  gofeed 支持

  说完上述三种类型的 RSS 订阅文件，再来看一下 gofeed 的支持。gofeed 对这三种类型的 RSS 订阅文件也都有直接的支持。

  1 2 3 4 5 6 7 8 9 10

  // RSS Feed feedData := `<rss version="2.0"> <channel> <webMaster>example@site.com (Example Name)</webMaster> </channel> </rss>` fp := rss.Parser{} rssFeed, _ := fp.Parse(strings.NewReader(feedData)) fmt.Println(rssFeed.WebMaster)

  1 2 3 4 5 6 7 8

  // Atom Feed feedData := `<feed xmlns="http://www.w3.org/2005/Atom"> <subtitle>Example Atom</subtitle> </feed>` fp := atom.Parser{} atomFeed, _ := fp.Parse(strings.NewReader(feedData)) fmt.Println(atomFeed.Subtitle)

  1 2 3 4 5 6

  // JSON Feed feedData := `{"version":"1.0", "home_page_url": "https://daringfireball.net"}` fp := json.Parser{} jsonFeed, _ := fp.Parse(strings.NewReader(feedData)) fmt.Println(jsonFeed.HomePageURL)

  这些用法在 gofeed 官方仓库都有对应说明

  no Content 的场景

  上面说到，有些订阅的 RSS 文件，并没有网站的完整内容，对于这种场景，应该如何解析呢？

  普遍的做法是类似 tt-rss 这样，在没有 Content 的情况下，解析 Description 显示，只显示内容摘要，可以通过点击标题进原地址看完整内容。在这种情况下，如果我想解析到网站完整的内容并且直接在 RSS 阅读器中展示应该怎么办呢？

  1. 容易想到，一种方式可以通过文章的原文链接，爬取原文网页上的内容。这种通过爬虫的方式，及其不稳定，主要涉及到不同网站样式布局会有不同的表现，需要针对不同的网站的 RSS 文件做单独适配。
  2. 另外一种，我有考虑过在 RSS 阅读器的内容显示区域，直接调用浏览器的能力根据原文地址链接直接渲染原网页。

  上面两种方式是我一开始就想到的方式，但是在我看来，这两种方式实现起来并不优雅，似乎不是一个好的解决方案，所以这两种方式我现阶段并没有去做验证和调研。在写这篇文章的时候，我突然想到现在 AI 大模型这么火，这个场景是不是能接入大模型实现的更优雅一点呢？比如说，对这种无法解析完整文章内容的场景，我可以借助原文的地址链接让 AI 大模型总结提取文章内容（互联网接入功能），我知道的目前 Microsoft Bing Chat 是提供互联网接入功能的，尝试了一下是可以读取原文完整内容的。

  最后，对于这种利用 AI 大模型的做法，我接下来应该会详细做一个验证，到时候可能会单独写一篇文章讲述整个验证过程，证明其是否具有可行性。

  （本文完）

说来奇怪，RSS 本应是上个时代的产物，近些年缺被越来越多的人追捧，在目前这个信息爆炸的时代，各种信息流充满着我们的屏幕，不同的信息平台也有着不同的推送方式，导致信息获取破碎，无法筛选自己真正感兴趣的信息。如果你跟我有差不多同样的想法，那么，搭建一个自己的 RSS 服务就显的很有必要了。

我的信息获取来源，一方面是一些微信公众号，还有一些技术博客和刊栏，导致我的信息获取非常的分散不集中，于是便萌生了搭建一个自己的 RSS 服务的想法，在进行了一番调研之后，我的其中一个很重要的要求就是要能独立部署，所以在抛弃了众多优秀的 RSS 阅读器之后，tt-rss 似乎成为了我最佳的选择，那么说干就干。

环境准备

要搭建一个自己的 RSS 服务，首先需要一个主机，可以是物理机，当然也可以是云主机，这里我选择一个 Ubuntu 服务器来搭建，使用云服务器也是现在更容易选择的便捷方式。具体需要准备的如下：

• 云服务器：Ubuntu 22.04 LTS
• 域名：xxx.xxx
• SSL 证书

需要说明的是，域名和 SSL 证书是必要的，一方面我们尽量不要使用 ip 访问我们的网站，另外为了安全起见，应当使用 HTTPS 访问我们的 RSS 服务。基本上每一个云服务厂商都提供了域名和 SSL 证书的申请，域名首单购买超级便宜，SSL 证书则基本都有免费的测试证书，对于搭建个人的 RSS 服务来说应该是够用了。域名和 SSL 的配置各大云服务厂商都有很详细的配置说明，这里就不作展开。

服务搭建

这里我选择的是 tt-rss，由于它依赖于 postgres 数据库和其他的服务，可以按照官网的方式搭建，社区也有人提供了 docker-compose 的方式，可以全部把需要的服务都以 docker 容器的方式启动。这里我强烈推荐 Awesome TTRSS 来快速搭建 RSS 服务。

安装 docker 和 docker-compose

docker 的安装有很多种方式，首选的当然是官网的教程，docker 官网针对于不同的操作系统都提供了很详细的安装方式。比如以 Ubuntu 为例，官网就写出了很详细的教程：

设置 docker 源

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# set up docker's apt repository

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repository to Apt sources:
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

安装 docker

1
2

# install docker packages
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

安装 docker-compose

1
2

# install docker-compose
sudo apt-get install docker-compose

检查是否安装成功

1
2
3
4
5
6
7

# check docker
docker -v
Docker version 24.0.7, build afdd53b

# check docker-compose
docker-compose -v
docker-compose version 1.29.2, build unknown

当出现上面的回显，说明 docker 和 docker-compose 安装成功

安装 tt-rss 相关服务

去 AweSome-TTRSS github 仓库 下载 docker-compose.yml，示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

version: "3"
services:
  service.rss:
    image: wangqiru/ttrss:latest
    container_name: ttrss
    ports:
      - 181:80
    environment:
      - SELF_URL_PATH=https://your_domain/ # please change to your own domain
      - DB_PASS=ttrss # use the same password defined in `database.postgres`
      - PUID=1000
      - PGID=1000
    volumes:
      - feed-icons:/var/www/feed-icons/
    networks:
      - public_access
      - service_only
      - database_only
    stdin_open: true
    tty: true
    restart: always

  service.mercury: # set Mercury Parser API endpoint to `service.mercury:3000` on TTRSS plugin setting page
    image: wangqiru/mercury-parser-api:latest
    container_name: mercury
    networks:
      - public_access
      - service_only
    restart: always

  service.opencc: # set OpenCC API endpoint to `service.opencc:3000` on TTRSS plugin setting page
    image: wangqiru/opencc-api-server:latest
    container_name: opencc
    environment:
      - NODE_ENV=production
    networks:
      - service_only
    restart: always

  database.postgres:
    image: postgres:13-alpine
    container_name: postgres
    environment:
      - POSTGRES_PASSWORD=ttrss # feel free to change the password
    volumes:
      - ~/postgres/data/:/var/lib/postgresql/data # persist postgres data to ~/postgres/data/ on the host
    networks:
      - database_only
    restart: always

  # utility.watchtower:
  #   container_name: watchtower
  #   image: containrrr/watchtower:latest
  #   volumes:
  #     - /var/run/docker.sock:/var/run/docker.sock
  #   environment:
  #     - WATCHTOWER_CLEANUP=true
  #     - WATCHTOWER_POLL_INTERVAL=86400
  #   restart: always

volumes:
  feed-icons:

networks:
  public_access: # Provide the access for ttrss UI
  service_only: # Provide the communication network between services only
    internal: true
  database_only: # Provide the communication between ttrss and database only
    internal: true

其中第 7 行，是 ttrss 服务端口，这里默认是 181 端口映射到容器里面的 80 端口，映射出来的端口可以自行修改；第 9 行就是 ttrss 的访问地址，这里设置成你的域名；最后是第 10 行和第 44 行，设置 pg 的密码，两个地方成一样的就行。

利用 docker-compose 启动容器：

1
2

# at your docker-compose.yml dir
docker-compose up -d

执行完成后，检查容器是否启动成功：

1
2
3
4
5
6
7
8

# chekc docker containers
docker ps

CONTAINER ID   IMAGE                                COMMAND                  CREATED        STATUS        PORTS                                   NAMES
9d7a30db8f54   postgres:13-alpine                   "docker-entrypoint.s…"   44 hours ago   Up 44 hours                                           postgres
30f0ca736138   wangqiru/mercury-parser-api:latest   "dumb-init -- npm ru…"   44 hours ago   Up 44 hours   3000/tcp                                mercury
918e35b76206   wangqiru/opencc-api-server:latest    "docker-entrypoint.s…"   44 hours ago   Up 44 hours                                           opencc
aff0d1127aac   wangqiru/ttrss:latest                "sh /docker-entrypoi…"   44 hours ago   Up 44 hours   0.0.0.0:181->80/tcp, :::181->80/tcp   ttrss

当看到有 4 个容器时，则启动成功

设置 HTTPS 访问

在服务器上安装 nginx，以 Ubuntu 为例：

1
2

# install nginx
sudo apt install nginx

编辑 nginx.conf：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

# /etc/nginx/nginx.conf

user root;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
worker_connections 768;
# multi_accept on;
}

http {

##
# Basic Settings
##

sendfile on;
tcp_nopush on;
types_hash_max_size 2048;
# server_tokens off;

# server_names_hash_bucket_size 64;
# server_name_in_redirect off;

include /etc/nginx/mime.types;
default_type application/octet-stream;

##
# SSL Settings
##

ssl_session_timeout 5m;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;

##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

##
# Gzip Settings
##

gzip on;

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

upstream rss {
server 127.0.0.1:181;
}

server {
listen 443 ssl;
server_name your_domain.com;

ssl_certificate crt_file_path;
ssl_certificate_key key_file_path;

location / {
      proxy_redirect off;
proxy_pass http://rss;

      proxy_set_header  Host                $http_host;
      proxy_set_header  X-Real-IP           $remote_addr;
      proxy_set_header  X-Forwarded-Ssl     on;
      proxy_set_header  X-Forwarded-For     $proxy_add_x_forwarded_for;
      proxy_set_header  X-Forwarded-Proto   $scheme;
      proxy_set_header  X-Frame-Options     SAMEORIGIN;

      client_max_body_size        100m;
      client_body_buffer_size     128k;

      proxy_buffer_size           4k;
      proxy_buffers               4 32k;
      proxy_busy_buffers_size     64k;
      proxy_temp_file_write_size  64k;
    }
}

server {
listen 80;
    server_name  your_domain.com;
    return 301 https://your_domain.com$request_uri;
}

}