From 7ff45781c88c1074a97b1351c8da8afc98b3bcfb Mon Sep 17 00:00:00 2001
From: JavaEdge <sss2855845850@gmail.com>
Date: Fri, 4 Jul 2025 16:00:22 +0800
Subject: [PATCH] =?UTF-8?q?docs:=E6=96=B0=E5=A2=9E=E6=96=87=E7=AB=A0?=
 =?UTF-8?q?=E4=B8=93=E6=A0=8F?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 docs/.vuepress/config.js                      | 103 ++-
 ...a2a-a-new-era-of-agent-interoperability.md | 288 +++++++
 .../AI/{llm => agent}/Build-App-with-Dify.md  |   0
 ...workflow-resilience-with-error-handling.md |   0
 .../configuring-models-in-dify.md             |   0
 ...ent-and-zapier-mcp-unlock-ai-automation.md |   0
 ...mented-search-unlock-ai-driven-insights.md |   0
 ...1-0-building-a-vibrant-plugin-ecosystem.md |   0
 ...edge-retrieval-with-customized-metadata.md |   0
 docs/md/AI/agent/perplexity-labs.md           |  37 +
 docs/md/AI/{llm => agent}/what-is-llmops.md   |   0
 docs/md/AI/agent/windsurf-update.md           | 745 ++++++++++++++++++
 ...rsing-and-chunking-in-open-source-tools.md | 102 +++
 docs/md/AI/llm/cuda.md                        | 230 ++++++
 docs/md/AI/llm/gpullama3-java-gpu-llm.md      |  70 ++
 docs/md/AI/llm/inference-engine.md            | 184 +++++
 docs/md/AI/llm/memory-faq.md                  | 133 ++++
 docs/md/AI/llm/qwen3-embedding.md             |  61 ++
 ...are-parsefrom-mqtt-protobuf-consumption.md | 322 ++++++++
 ...kafka-iot-message-streaming-integration.md |   0
 .../md/MQTT/mqtt-publish-subscribe-intro.md   |   0
 ...00\346\234\257\345\216\237\347\220\206.md" | 259 ++++++
 docs/md/design/open-close-principle.md        | 349 ++++++++
 .../md/java/Java16-new-features.md            |   0
 .../md/java/Java21-new-features.md            |   0
 .../md/java/Java22-new-features.md            |   0
 .../md/java/Java23-new-features.md            |   0
 .../md/java/Java9-new-features.md             |   0
 docs/md/java/java-news-roundup-jun02-2025.md  | 126 +++
 ...g-adminclient-principles-and-practices.md} | 100 +--
 .../mysql-transaction-isolation-mechanism.md  | 497 ++++++++++++
 ...mize-slow-queries-massive-row-deletions.md | 105 +++
 ...-solve-high-cpu-usage-in-tomcat-process.md |  21 +-
 33 files changed, 3657 insertions(+), 75 deletions(-)
 create mode 100644 docs/md/AI/a2a/a2a-a-new-era-of-agent-interoperability.md
 rename docs/md/AI/{llm => agent}/Build-App-with-Dify.md (100%)
 rename docs/md/AI/{llm => agent}/boost-ai-workflow-resilience-with-error-handling.md (100%)
 rename docs/md/AI/{llm => agent}/configuring-models-in-dify.md (100%)
 rename docs/md/AI/{llm => agent}/dify-agent-and-zapier-mcp-unlock-ai-automation.md (100%)
 rename docs/md/AI/{llm => agent}/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md (100%)
 rename docs/md/AI/{llm => agent}/dify-v1-0-building-a-vibrant-plugin-ecosystem.md (100%)
 create mode 100644 docs/md/AI/agent/dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata.md
 create mode 100644 docs/md/AI/agent/perplexity-labs.md
 rename docs/md/AI/{llm => agent}/what-is-llmops.md (100%)
 create mode 100644 docs/md/AI/agent/windsurf-update.md
 create mode 100644 docs/md/AI/document-parsing-and-chunking-in-open-source-tools.md
 create mode 100644 docs/md/AI/llm/cuda.md
 create mode 100644 docs/md/AI/llm/gpullama3-java-gpu-llm.md
 create mode 100644 docs/md/AI/llm/inference-engine.md
 create mode 100644 docs/md/AI/llm/memory-faq.md
 create mode 100644 docs/md/AI/llm/qwen3-embedding.md
 create mode 100644 docs/md/MQTT/avoid-bare-parsefrom-mqtt-protobuf-consumption.md
 rename "docs/md/mqtt/MQTT\344\270\216Kafka\345\234\250\347\211\251\350\201\224\347\275\221\346\266\210\346\201\257\344\270\216\346\265\201\346\225\260\346\215\256\351\233\206\346\210\220\345\256\236\350\267\265.md" => docs/md/MQTT/mqtt-kafka-iot-message-streaming-integration.md (100%)
 rename "docs/md/MQTT/07-MQTT\345\217\221\345\270\203\350\256\242\351\230\205\346\250\241\345\274\217\344\273\213\347\273\215.md" => docs/md/MQTT/mqtt-publish-subscribe-intro.md (100%)
 create mode 100644 "docs/md/chain/\351\232\220\347\247\201\350\256\241\347\256\227\346\212\200\346\234\257\345\216\237\347\220\206.md"
 create mode 100644 docs/md/design/open-close-principle.md
 rename "docs/md/java/JDK16\346\226\260\347\211\271\346\200\247.md" => docs/md/java/Java16-new-features.md (100%)
 rename "docs/md/java/JDK21\346\226\260\347\211\271\346\200\247.md" => docs/md/java/Java21-new-features.md (100%)
 rename "docs/md/java/JDK22\346\226\260\347\211\271\346\200\247.md" => docs/md/java/Java22-new-features.md (100%)
 rename "docs/md/java/JDK23\346\226\260\347\211\271\346\200\247.md" => docs/md/java/Java23-new-features.md (100%)
 rename "docs/md/java/Java9\346\226\260\347\211\271\346\200\247\346\246\202\350\277\260.md" => docs/md/java/Java9-new-features.md (100%)
 create mode 100644 docs/md/java/java-news-roundup-jun02-2025.md
 rename docs/md/kafka/{13-KafkaAdminClient.md => kafka-operations-tool-exploring-adminclient-principles-and-practices.md} (50%)
 create mode 100644 docs/md/mysql/mysql-transaction-isolation-mechanism.md
 create mode 100644 docs/md/mysql/optimize-slow-queries-massive-row-deletions.md
 rename "docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md" => docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md (86%)

diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
index f97454f809..7894468068 100644
--- a/docs/.vuepress/config.js
+++ b/docs/.vuepress/config.js
@@ -751,10 +751,6 @@ module.exports = {
                         text: 'LangChain4j',
                         link: '/md/AI/langchain4j/01-intro'
                     },
-                    {
-                        text: 'MCP',
-                        link: '/md/AI/mcp/mcp-fad-or-fixture'
-                    },
                     {
                         text: '大模型发展',
                         link: '/md/AI/llm/GPTs'
@@ -767,6 +763,14 @@ module.exports = {
                         text: 'AI Agent',
                         link: '/md/AI/agent/changelog-cursor'
                     },
+                    {
+                        text: 'MCP',
+                        link: '/md/AI/mcp/mcp-fad-or-fixture'
+                    },
+                    {
+                        text: 'A2A',
+                        link: '/md/AI/a2a/a2a-a-new-era-of-agent-interoperability'
+                    },
                     ]
                 },
 
@@ -796,6 +800,11 @@ module.exports = {
                         text: '以太坊区块链',
                         link: '/md/chain/01-以太坊智能合约与高级语言.md'
                     },
+                    
+                    {
+                        text: '隐私计算',
+                        link: '/md/chain/隐私计算技术原理.md'
+                    },
 
                     ]
                 },
@@ -1179,8 +1188,9 @@ module.exports = {
                         collapsable: false,
                         sidebarDepth: 0,
                         children: [
-                            "MQTT与Kafka在物联网消息与流数据集成实践",
-                            "07-MQTT发布订阅模式介绍"
+                            "mqtt-kafka-iot-message-streaming-integration",
+                            "mqtt-publish-subscribe-intro",
+                            "avoid-bare-parsefrom-mqtt-protobuf-consumption",
                         ]
                     }],
 
@@ -1246,15 +1256,16 @@ module.exports = {
                         sidebarDepth: 0,
                         children: [
                             "java-se-support-roadmap",
-                            "Java9新特性概述",
+                            "Java9-new-features",
                             "jdk14-new-features-complete-guide",
-                            "JDK16新特性",
+                            "Java16-new-features",
                             "understanding-java17-new-features-sealed-classes",
-                            "JDK21新特性",
-                            "JDK22新特性",
-                            "JDK23新特性",
+                            "Java21-new-features",
+                            "Java22-new-features",
+                            "Java23-new-features",
                             "java24-new-features",
                             "java2024",
+                            "java-news-roundup-jun02-2025",
                         ]
                     },
 
@@ -1397,7 +1408,7 @@ module.exports = {
                             "03-Tomcat的生命周期管理",
                             "04-Tomcat实现热部署、热加载原理解析",
                             "05-Tomcat如何打破双亲委派机制实现隔离Web应用的？",
-                            "Tomcat进程占用CPU过高怎么办？",
+                            "how-to-solve-high-cpu-usage-in-tomcat-process",
                         ]
                     }],
 
@@ -1501,6 +1512,7 @@ module.exports = {
                             "为什么临时表可以重名？",
                             "为什么阿里不推荐使用MySQL分区表？",
                             "一文看懂这篇MySQL的锁机制",
+                            "mysql-transaction-isolation-mechanism",
                         ]
                     },
 
@@ -1515,6 +1527,7 @@ module.exports = {
                             "MySQL查询优化",
                             "MySQL深分页调优实战",
                             "online-sql-deadlock-incident-how-to-prevent-deadlocks",
+                            "optimize-slow-queries-massive-row-deletions",
                         ]
                     },
 
@@ -1542,7 +1555,7 @@ module.exports = {
                             "05-流式操作：如何使用 Flux 和 Mono 高效构建响应式数据流？",
                         ]
                     }],
-                    
+
                     "/md/sentinel/": [{
                         title: "Sentinel基础",
                         collapsable: false,
@@ -1682,7 +1695,7 @@ module.exports = {
                             "Kafka门派知多少",
                             "08-全网最全图解Kafka适用场景",
                             "09-消息队列的消息大量积压怎么办？",
-                            "13-KafkaAdminClient",
+                            "kafka-operations-tool-exploring-adminclient-principles-and-practices",
                             "15-基于kafka实现延迟队列",
                             "kafka-transaction-implementation",
                             "kafka-versions",
@@ -2153,10 +2166,21 @@ module.exports = {
                             "lm-studio-transform-mac-into-ai-tool",
                             "navigating-llm-deployment-tips-tricks-and-techniques",
                             "only-ai-flow-can-do",
-                            "chatgpt-canva",
                             "llm-reasoning-limitations",
                             "making-an-llm-that-sees-and-reasons",
                             "lmstudio-local-llm-call",
+                            "inference-engine",
+                            "cuda",
+                            "gpullama3-java-gpu-llm",
+                        ]
+                    },
+                    {
+                        title: "ChatGPT",
+                        collapsable: false,
+                        sidebarDepth: 0,
+                        children: [
+                            "chatgpt-canva",
+                            "memory-faq",
                         ]
                     },
                     {
@@ -2214,6 +2238,7 @@ module.exports = {
                             "boost-ai-workflow-resilience-with-error-handling",
                             "introducing-parent-child-retrieval-for-enhanced-knowledge",
                             "dify-v1-0-building-a-vibrant-plugin-ecosystem",
+                            "dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata",
                             "dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights",
                             "dify-agent-and-zapier-mcp-unlock-ai-automation",
                         ]
@@ -2327,29 +2352,37 @@ module.exports = {
                         ]
                     },
                     {
-                        title: "辅助编程",
+                        title: "cursor",
                         collapsable: false,
                         sidebarDepth: 0,
                         children: [
                             "changelog-cursor",
+                        ]
+                    },
+
+                    {
+                        title: "windsurf",
+                        collapsable: false,
+                        sidebarDepth: 0,
+                        children: [
                             "goodbye-cursor-hello-windsurf",
-                            "Junie",
-                            "introducing-codex",
+                            "windsurf-update",
                         ]
                     },
-                    ],
-                    
-                    "/md/AI/agent/dify/": [{
-                        title: "快速上手",
+                    {
+                        title: "Dify基础",
                         collapsable: false,
                         sidebarDepth: 0,
                         children: [
-                            "ai-agents-dont-security-nightmare",
-                            "improve-quality-gen-ai",
+                            "what-is-llmops",
+                            "configuring-models-in-dify",
+                            "Build-App-with-Dify",
+                            "integrate-dify-and-aws-services-to-enable-more-flexible-translation-workflows",
+                            "llm-knowledge-base-segmentation-data-cleaning",
                         ]
                     },
                     {
-                        title: "案例",
+                        title: "Dify案例",
                         collapsable: false,
                         sidebarDepth: 0,
                         children: [
@@ -2359,6 +2392,15 @@ module.exports = {
                             "introducing-codex",
                         ]
                     },
+
+                    {
+                        title: "Perplexity",
+                        collapsable: false,
+                        sidebarDepth: 0,
+                        children: [
+                            "perplexity-labs",
+                        ]
+                    },
                     ],
 
                     "/md/AI/mcp/": [{
@@ -2381,6 +2423,16 @@ module.exports = {
                     },
                     ],
 
+                    "/md/AI/a2a/": [{
+                        title: "A2A",
+                        collapsable: false,
+                        sidebarDepth: 0,
+                        children: [
+                            "a2a-a-new-era-of-agent-interoperability",
+                        ]
+                    },
+                    ],
+
                     "/md/AI/spring-ai-alibaba/": [{
                         title: "Spring AI Alibaba",
                         collapsable: false,
@@ -2529,6 +2581,7 @@ module.exports = {
                         sidebarDepth: 0,
                         children: [
                             "01-单一职责原则",
+                            "open-close-principle",
                             "rest-api-design-resource-modeling",
                         ]
                     },
diff --git a/docs/md/AI/a2a/a2a-a-new-era-of-agent-interoperability.md b/docs/md/AI/a2a/a2a-a-new-era-of-agent-interoperability.md
new file mode 100644
index 0000000000..47271d5f00
--- /dev/null
+++ b/docs/md/AI/a2a/a2a-a-new-era-of-agent-interoperability.md
@@ -0,0 +1,288 @@
+# Agent2Agent (A2A) 协议发布
+
+![](https://p.ipic.vip/95frfl.jpg)
+
+## 1 智能体互操作性的新时代
+
+通过自主处理大量日常重复性或复杂性任务，AI智能体为提高人们工作效率带来独特机遇。如今，企业正在构建和部署越来越多的自主智能体，以便扩展、自动化和改进工作场所的各种流程，如订购新笔记本电脑、协助客户服务代表和协助供应链规划。
+
+为最大限度发挥智能体 AI 优势，这些智能体须能在横跨孤立数据系统和应用程序的动态、多智能体生态系统中协作。即使智能体由不同供应商构建或在不同的框架中构建，也能实现智能体之间的互操作性，这将提高自主性并成倍提高生产力，同时降低长期成本。
+
+今天，Google发布Agent2Agent (A2A) 全新开放协议，Atlassian、Box、Cohere、Intuit、Langchain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、UKG 和 Workday 等 50 多家技术合作伙伴及埃森哲、BCG、Capgemini、Cognizant、德勤、HCLTech、Infosys、毕马威、麦肯锡、普华永道、TCS 和 Wipro 等领先服务提供商均支持。
+
+凭借 A2A 协议，AI 智能体能在各种企业平台或应用程序之上相互通信、安全交换信息和协调操作。A2A 框架将为客户创造巨大的价值，他们的 AI 智能体将服务于整个企业的各类应用程序资产。
+
+这种协作努力体现人们对未来的共同愿景，即无论底层技术如何，AI 智能体都能无缝协作，以自动化复杂企业工作流程，推动效率与创新达到前所未有的高度。
+
+A2A 是一个开放协议，是对MCP的补充，MCP为智能体提供了有用的工具和上下文。借鉴 Google 在扩展智能体系统方面的内部专业知识，我们设计了 A2A 协议，以应对我们在为客户部署大规模、多智能体系统时遇到的挑战。借助 A2A 协议，开发者可以构建能够与使用该协议构建的任何其他智能体建立连接的智能体，让用户能够灵活地组合来自各种提供商的智能体。至关重要的是，企业可以受益于这种标准化方法，跨不同平台和云环境管理其智能体。我们相信，这种通用的互操作性对于充分发挥协作 AI 智能体的潜力至关重要。
+
+![](https://p.ipic.vip/dipy89.png)
+
+## 2 A2A设计原则
+
+A2A 是一种开放协议，提供了一种让智能体相互协作的标准方式，无论其底层框架或供应商是什么。与合作伙伴一起设计该协议时，坚持五大关键原则：
+
+- 拥抱智能体能力：A2A聚焦于让智能体以其自然、非结构化的方式进行协作，即使彼此没有共享内存、工具和上下文，也能高效协作。我们将实现真正的多智能体场景，不再将智能体仅仅看作是“工具”
+
+- 依托现有标准构建：该协议是基于 HTTP、SSE、JSON-RPC等当下主流标准构建而成，即其能更轻松与企业当前日常使用的 IT 堆栈进行集成
+
+- 默认安全：A2A旨在支持企业级身份验证和授权，并在发布时与 OpenAPI 的身份验证方案保持对等
+
+- 支持长时间运行的任务：A2A非常灵活，支持各种场景，可出色完成从快速任务到深入研究（在有人类参与时，可能需数小时甚至数天时间才能完成）的所有任务。在整个过程中，A2A 可以向用户提供实时反馈、通知和状态更新
+
+- 模式不受限：智能体世界不仅限于文本，这就是为什么我们将 A2A 设计为支持各种模式，包括音频和视频流
+
+## 3 A2A工作原理
+
+一个说明远程Agent和客户端Agent之间数据流的插图流程图，以产生安全协作、任务和状态管理、用户体验协商及能力发现 
+
+![](https://p.ipic.vip/ngue0z.png)
+
+A2A方便了“客户端”智能体与“远程”智能体之间的通信。客户端智能体负责制定和传达任务，而远程智能体负责执行这些任务，力图提供正确的信息或采取正确的行动。这种交互涉及几个关键功能：
+
+- 能力发现：智能体可用 JSON 格式“智能体卡”来宣传其能力，使客户端智能体能识别出能执行任务的最佳智能体，并利用 A2A 与远程智能体进行通信
+
+- 任务管理：客户端智能体与远程智能体之间的通信以完成任务为导向，智能体在其中努力完成最终用户的请求。该“任务”对象由协议定义，且具有生命周期。任务可立即完成，而长时间运行的任务，每个智能体都可进行通信，以便彼此之间保持同步，了解任务完成情况的最新状态。任务的输出被称为“工件”
+
+- 协作：智能体可相互发送信息，交流上下文、回复、工件或用户指令
+
+- 用户体验协商：每条消息都包含“部件”，“部件”是一个完整的内容片段，如生成的图像。每个部件都有指定的内容类型，允许客户端和远程智能体协商所需的正确格式，并明确包括用户界面功能的协商，如 iframe、视频、网页表单等
+
+参阅[规范草案](https://github.com/google/A2A)，了解协议工作原理的完整细节。
+
+## 3 真实案例：搜寻候选人
+
+通过 A2A 协作，可大大简化软件工程师招聘过程。在 Agentspace 这样的统一界面中，用户（如招聘经理）可以要求其智能体寻找符合职位列表、地点和技能组合的候选人。然后，智能体与其他专业智能体互动，寻找潜在的候选人。用户收到这些建议后，可指示其智能体安排进一步面试，简化候选人搜寻流程。面试流程结束后，还可让另一个智能体协助背调。这这只是 AI 智能体需要跨系统协作以寻找合格求职者的一个示例。
+
+##  4 智能体互操作性的未来
+
+A2A有望开启智能体互操作性的新时代，推动创新浪潮，构建功能更强大、用途更广泛的智能体系统。我们坚信，该协议将为未来智能体发展奠定基础，促使智能体无缝协作以攻克复杂难题，提升我们生活品质。
+
+致力于与合作伙伴和社区公开合作构建该协议。开源方式发布该协议，并建立明确贡献途径。可在 [A2A 网站](https://google.github.io/A2A)查看[完整版规范草案](https://github.com/google/A2A)、试用代码示例和查看示例场景，并了解贡献方式。
+
+正与合作伙伴合作，计划今年晚些推出可用于生产的协议版本。
+
+## 5 A2A技术合作伙伴反馈
+
+### ask-ai.com
+
+> Ask-AI 很高兴与 Google 合作开发 A2A 协议，共同塑造 AI 互操作性和无缝智能体协作的未来，从而提升其在企业 AI 客户体验领域的领导地位。
+> ——Alon Talmor 博士，首席执行官
+
+### Atlassian
+
+> 凭借 Atlassian 对 Rovo 智能体的投资，像 A2A 这样的标准化协议的开发将帮助智能体成功地发现、协调和推理彼此，从而实现更丰富的授权和大规模协作形式。
+> ——Brendan Haire，Atlassian 的 AI 平台工程副总裁
+
+### Articul8
+
+> 在 Articul8，我们认为 AI 必须协作和互操作，才能真正跨企业扩展。我们很高兴支持 A2A 互操作性协议的开发，该计划与我们提供跨复杂系统和工作流程无缝运行的特定领域 GenAI 功能的使命完美契合。我们正在使 Articul8 的 ModelMesh（“智能体中的智能体”）将 A2A 视为一等公民，从而实现智能智能体之间的安全、无缝通信。
+> —— Arun Subramaniyan，Articul8 创始人兼首席执行官
+
+### Arize AI
+
+> Arize AI很荣幸与 Google 合作，成为 A2A 互操作性协议的产品发布合作伙伴，从而推进跨 AI 智能体的无缝、安全交互，这是 Arize 对开源评估和可观测性框架立场承诺的一部分。
+> ——Jason Lopatecki，Arize AI 联合创始人兼首席执行官
+
+### BCG
+
+> BCG 帮助重新设计以智能为核心的组织。像 A2A 这样开放和可互操作的功能可以加速这一进程，从而实现可持续的、自主的竞争优势。
+> —— *Djon Kleine，BCG 合伙人兼总经理*
+
+### Box
+
+> 我们期待扩大与 Google 的合作，使 Box 智能体能够使用 A2A 与 Google Cloud 的智能体生态系统协同工作，共同创新以塑造 AI 智能体的未来，同时使组织能够更好地自动化工作流程、降低成本并生成值得信赖的 AI 输出。*
+> ——Ketan Kittur，Box 的产品管理、平台和集成副总裁*
+
+### **C3 AI**
+
+> 在 C3 AI，我们认为开放、可互操作的系统是使企业 AI 在现实世界发挥作用和创造价值的关键，A2A 有潜力帮助客户打破孤岛，并安全地使 AI 智能体在系统、团队和应用程序之间协同工作。
+> —— *Nikhil Krishnan，C3 AI 高级副总裁兼负责数据科学的首席技术官*
+
+### **Chronosphere**
+
+> A2A 将支持可靠且安全的智能体专业化和协调，为计算编排的新时代打开大门，使公司能够更快、更可靠地交付产品和服务，并使他们能够将工程工作重点放在推动创新和创造价值上。*
+> ——Rob Skillington，创始人兼首席技术官*
+
+### **Cognizant**
+
+> “作为企业多智能体系统的先驱，Cognizant 致力于实现智能体互操作性，并主动将其视作我们客户的关键要求。”
+> —— *Babak Hodjat，AI 首席技术官*
+
+### **Cohere**
+
+> 在 Cohere，我们正在构建企业放心地采用自主智能体所需的安全 AI 基础设施，而开放的 A2A 协议可确保即使在气隙环境中也能实现无缝、可信的协作，使企业能够在不影响控制或合规性的情况下进行大规模创新。*
+> ——Autumn Moulder，Cohere 工程副总裁*
+
+### **Confluent**
+
+> A2A 使智能智能体能够建立直接、实时的数据交换，简化复杂的数据管道，从根本上改变智能体的通信方式并促进决策。*
+> ——Pascal Vantrepote，Confluent 创新高级总监*
+
+### **Cotality（原 CoreLogic）**
+
+> A2A 为智能、实时通信和协作的新时代打开了大门，Cotality 将其带给房屋贷款、保险、房地产和政府领域的客户，帮助他们提高生产力，加快决策速度。*
+> ——Sachin Rajpal，Cotality 数据解决方案总经理*
+
+### **DataStax**
+
+> DataStax 很高兴能成为 A2A 的一部分，并探索如何利用它为 Langflow 提供支持，这是迈向真正可互操作的 AI 系统的重要一步，这些系统可以协作完成跨多个环境的复杂任务。*
+> ——Ed Anuff，DataStax 首席产品官*
+
+### **Datadog**
+
+> 我们很高兴看到 Google Cloud 推出 A2A 协议，以简化复杂智能体系统的开发，这将帮助 Datadog 使其用户能够构建更具创新性、更优的和更安全的智能体 AI 应用程序。*
+> ——Yrieix Garnier，Datadog 产品副总裁*
+
+### **Elastic**
+
+> Elastic 支持开放、可互操作的智能体生态系统这一愿景，期待与 Google Cloud 和其他行业领导者合作开发 A2A，并提供其数据管理和工作流程编排经验来改进该协议。*
+> ——Steve Kearns，Elastic 副总裁兼搜索业务总经理*
+
+### **GrowthLoop**
+
+> A2A 有潜力加速 GrowthLoop 为我们的客户实现复合营销的愿景——使我们的 AI 智能体能够与其他专业智能体无缝协作，更快地从企业数据中学习，并快速优化整个营销生态系统中的活动，同时尊重客户云基础设施上的数据隐私。*
+> ——Anthony Rotio，GrowthLoop 首席数据战略官*
+
+### **Harness**
+
+> Harness 很高兴支持 A2A，并致力于通过将 AI 驱动的智能集成到软件生命周期的每个阶段来简化开发者体验，从而使团队能够从运行时数据中获得更深入的见解，自动化复杂的工作流程，提高系统性能。*
+> ——Gurashish Brar，Harness 工程主管*
+
+### **Incorta**
+
+> Incorta 很高兴支持 A2A 并推进客户的智能体通信，使未来的企业自动化更智能、更快速，并真正实现数据驱动。*
+> ——Osama Elkady，Incorta 首席执行官*
+
+### **Intuit**
+
+> Intuit 坚信，像 A2A 这样的开源协议将支持复杂的智能体工作流程，加速我们的合作伙伴集成，并通过有效协作的跨平台智能体推动行业向前发展。*
+> ——Tapasvi Moturu，Intuit 的智能体框架软件工程副总裁*
+
+### **JetBrains**
+
+> 我们很高兴成为 A2A 的产品发布合作伙伴，该计划增强了智能体协作，使我们更接近真正的多智能体世界，为 JetBrains IDE、团队工具和 Google Cloud 的开发者赋能。*
+> ——Vladislav Tankov，JetBrains 的 AI 总监*
+
+### **JFrog**
+
+> JFrog 很高兴加入 A2A 协议，我们认为该计划将有助于克服当今的许多集成挑战，并将成为新一代智能体应用程序的关键驱动力。*
+> ——Yoav Landman，JFrog 首席技术官兼联合创始人*
+
+### **LabelBox**
+
+> A2A 是充分发挥 AI 智能体潜力的关键一步，它支持 AI 真正增强人类能力、实现复杂工作流程自动化和推动创新的未来。*
+> ——创始人兼首席执行官 Manu Sharma*
+
+### **LangChain**
+
+> LangChain 认为，智能体与其他智能体交互是指日可待的未来，我们很高兴与 Google Cloud 合作，提出一个满足智能体构建者和用户需求的共享协议。*
+> ——Harrison Chase，LangChain 联合创始人兼首席执行官*
+
+### **MongoDB**
+
+> 通过将 MongoDB 强大的数据库基础设施和混合搜索功能与 A2A 和 Google Cloud 的前沿 AI 模型相结合，企业可以释放零售、制造等行业的新可能性，从而重新定义 AI 应用程序的未来。*
+> ——Andrew Davidson，MongoDB 产品高级副总裁*
+
+### **Neo4j**
+
+> Neo4j 很荣幸与 Google Cloud 合作，将我们的图技术知识图谱和 GraphRAG 功能与 A2A 相结合，帮助组织释放新的自动化和智能水平，同时确保智能体交互在上下文中保持相关、可解释和值得信赖。*
+> ——Sudhir Hasbe，Neo4j 首席产品官*
+
+### **New Relic**
+
+> 我们相信，Google Cloud 的 A2A 协议与 New Relic 的智能可观测性平台之间的协作，将通过简化集成、促进跨不同系统的数据交换，并最终创建一个更统一的 AI 智能体生态系统，为我们的客户提供显著价值。*
+> ——Thomas Lloyd，New Relic 首席业务和运营官*
+
+### **Pendo**
+
+> 我们很荣幸与 Google Cloud 的 A2A 协议合作，这将是使 AI 智能体能够有效协同工作，同时保持大规模信任和可用性的关键一步。
+> —— *Rahul Jain，Pendo 联合创始人兼首席产品官*
+
+### **PayPal**
+
+> PayPal 支持 Google Cloud 的 A2A 协议，这代表着开发者和商家创建由智能体 AI 驱动的新一代商业体验的新方式。*
+> ——Prakhar Mehrotra，PayPal 高级副总裁兼人工智能主管*
+
+### **普华永道**
+
+> 在普华永道，我们相信企业 AI 的未来在于无缝协作，它不仅仅是人员和系统之间的协作，还有智能体之间的协作；因此，我们很荣幸能与普华永道的智能体操作系统协作支持 A2A，帮助制定企业级的安全、可扩展的智能体互操作性标准。
+> —— *Dallas Dolen，全球 Google Cloud 联盟负责人*
+
+### **SAP**
+
+> SAP 致力于与 Google Cloud 和更广泛的生态系统合作，通过 A2A 协议塑造智能体互操作性的未来，这是使 SAP Joule 和其他 AI 智能体能够跨企业平台无缝协作，并释放端到端业务流程的全部潜力的关键一步。*
+> ——Walter Sun，高级副总裁兼 AI 工程全球主管*
+
+### **Salesforce**
+
+> Salesforce 正在率先支持 A2A 标准，以扩展我们的开放平台，使 AI 智能体能够在 Agentforce 和其他生态系统中无缝协作，将脱节的功能转化为精心设计的解决方案，并为客户和员工提供增强的数字化劳动力。*
+> ——产品架构副总裁 Gary Lerhaupt*
+
+### **ServiceNow**
+
+> ServiceNow 和 Google Cloud 正在合作，为智能体间互操作性设定新的行业标准，我们相信 A2A 将为更高效、更互联的支持体验奠定基础。*
+> ——Pat Casey，ServiceNow 的首席技术官兼 DevOps 执行副总裁*
+
+### **Supertab**
+
+> 借助 Google Cloud 的 A2A 协议和 Supertab Connect，智能体将能够像人类企业一样支付服务费用、收取服务费用和交换服务。*
+> ——Cosmin Ene，Supertab 创始人*
+
+### **UKG**
+
+> UKG 很高兴与 Google Cloud 合作开发新的 A2A 协议，该框架将使我们能够构建更智能、更具支持性的人力资本和劳动力体验，以前所未有的方式预测和响应员工需求。*
+> ——Eli Tsinovoi，UKG 的 AI 主管*
+
+### **Weights & Biases**
+
+> Weights & Biases 很荣幸与 Google Cloud 合作开发 A2A 协议，该协议设定了一个关键的开放标准，使组织能够放心地部署、编排和扩展各种 AI 智能体，而无需考虑底层技术。*
+> ——Shawn Lewis，Weights & Biases 首席技术官兼联合创始人*
+
+## 6 服务合作伙伴
+
+### **埃森哲**
+
+> Google Cloud 的多智能体 A2A 协议是将跨不同平台的特定领域智能体连接起来以应对复杂挑战的桥梁，从而实现无缝通信和集体智能，以实现更智能和更高效的智能体解决方案。*
+> ——Scott Alfieri，埃森哲 AGBG 全球负责人*
+
+### **德勤**
+
+> 智能体间互操作性是实现智能体 AI 架构演进的基础要素，Google Cloud 发起的 A2A 计划将技术行业参与者的生态系统凝聚到一起，共同开发和支持该协议，将极大地加速智能体 AI 的采用。*
+> ——德勤的 Gopal Srinivasan*
+
+### **EPAM**
+
+> 我们已经在 A2A 领域处于领先地位，专注于能产生实际商业价值的行业解决方案，此等价值包括节省时间、减少管理费用以及帮助客户增加收入和改进流程（如药物发现过程中 FDA 文件的编制）。*
+> ——Marc Cerro，EPAM 全球 Google Cloud 合作伙伴副总裁*
+
+### **HCLTech**
+
+> HCLTech 处于智能体企业的前沿，我们很荣幸与 Google Cloud 合作，通过开放的 A2A 标准定义智能体间互操作性并推进智能体 AI 的可能性。*
+> ——Vijay Guntur，HCLTech 首席技术官兼生态系统主管*
+
+### **毕马威**
+
+> 毕马威很高兴能参与这项新兴计划，因为 A2A 提供了不同 AI 智能体真正有效和负责任地协作所需的基本标准，借助该标准，客户和企业可以无缝地利用 AI 来实现创新和效率提升。*
+> ——Sherif AbdElGawad，毕马威的合伙人兼 Google Cloud 和 AI 负责人*
+
+**Quantiphi**
+
+> 智能体动态发现功能并打造跨平台用户体验的能力对于释放企业的真正潜力至关重要。我们认为 A2A 协议是支持企业构建此类可互操作智能体的关键一步。*
+> ——Asif Hasan，Quantiphi 联合创始人*
+
+### **塔塔咨询服务公司 (TCS)**
+
+> A2A 协议为智能体自动化新时代奠定了基础，语义互操作性在新时代占据突出地位，我们很荣幸能够引领这一变革之旅。*
+> ——Anupam Singhal，TCS 主管制造业务的总裁*
+
+### **Wipro**
+
+> 因为 AI 的未来在于无缝协作，所以像 A2A 这样的开放协议将成为 AI 智能体大规模推动创新的生态系统的基础。*
+> ——Nagendra P Bandaru，Wipro 管理合伙人兼技术服务全球主管*
+
+##  7 详细了解A2A
+
+要了解有关 A2A框架更多信息，仔细研读[**完整规范草案**](https://github.com/google/A2A)，并探索[**可用的代码示例**](https://google.github.io/A2A)，以根据其代码检查该协议的结构实验。
+
+[提交想法](https://docs.google.com/forms/d/e/1FAIpQLScS23OMSKnVFmYeqS2dP7dxY3eTyT7lmtGLUa8OJZfP4RTijQ/viewform)、[贡献文档](https://github.com/google/A2A/blob/main/CONTRIBUTING.md)以及与社区互动，为协议的演进做出贡献，一起定义智能体互操作性的未来。
\ No newline at end of file
diff --git a/docs/md/AI/llm/Build-App-with-Dify.md b/docs/md/AI/agent/Build-App-with-Dify.md
similarity index 100%
rename from docs/md/AI/llm/Build-App-with-Dify.md
rename to docs/md/AI/agent/Build-App-with-Dify.md
diff --git a/docs/md/AI/llm/boost-ai-workflow-resilience-with-error-handling.md b/docs/md/AI/agent/boost-ai-workflow-resilience-with-error-handling.md
similarity index 100%
rename from docs/md/AI/llm/boost-ai-workflow-resilience-with-error-handling.md
rename to docs/md/AI/agent/boost-ai-workflow-resilience-with-error-handling.md
diff --git a/docs/md/AI/llm/configuring-models-in-dify.md b/docs/md/AI/agent/configuring-models-in-dify.md
similarity index 100%
rename from docs/md/AI/llm/configuring-models-in-dify.md
rename to docs/md/AI/agent/configuring-models-in-dify.md
diff --git a/docs/md/AI/llm/dify-agent-and-zapier-mcp-unlock-ai-automation.md b/docs/md/AI/agent/dify-agent-and-zapier-mcp-unlock-ai-automation.md
similarity index 100%
rename from docs/md/AI/llm/dify-agent-and-zapier-mcp-unlock-ai-automation.md
rename to docs/md/AI/agent/dify-agent-and-zapier-mcp-unlock-ai-automation.md
diff --git a/docs/md/AI/llm/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md b/docs/md/AI/agent/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md
similarity index 100%
rename from docs/md/AI/llm/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md
rename to docs/md/AI/agent/dify-deep-research-workflow-farewell-to-fragmented-search-unlock-ai-driven-insights.md
diff --git a/docs/md/AI/llm/dify-v1-0-building-a-vibrant-plugin-ecosystem.md b/docs/md/AI/agent/dify-v1-0-building-a-vibrant-plugin-ecosystem.md
similarity index 100%
rename from docs/md/AI/llm/dify-v1-0-building-a-vibrant-plugin-ecosystem.md
rename to docs/md/AI/agent/dify-v1-0-building-a-vibrant-plugin-ecosystem.md
diff --git a/docs/md/AI/agent/dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata.md b/docs/md/AI/agent/dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/docs/md/AI/agent/perplexity-labs.md b/docs/md/AI/agent/perplexity-labs.md
new file mode 100644
index 0000000000..efa5243373
--- /dev/null
+++ b/docs/md/AI/agent/perplexity-labs.md
@@ -0,0 +1,37 @@
+# 不止于搜索！Perplexity Labs深度解析：以项目为核心的 AI 工作流！
+
+## 0 前言
+
+Perplexity推出全新功能 [Labs](https://www.perplexity.ai/pl/hub/blog/introducing-perplexity-labs)，专为 Pro 订阅用户设计，旨在支持更复杂的任务，功能超越了传统的问答服务。这一重大更新标志着 Perplexity 从以搜索为核心的交互模式，转向由生成式 AI 驱动的结构化、多步骤工作流。
+
+## 1 交互模式
+
+Perplexity Labs 让用户可在一个统一界面完成多种任务，包括生成报告、分析数据、编写和执行代码、构建轻量级网页应用等。用户可以通网页和移动端的新模式切换器进入 Labs，桌面端支持也即将上线。
+
+## 2 适用场景
+
+与专注于简洁回答的 Perplexity Search 和提供深入信息整合的 Research（原名 Deep Research）不同，Labs 更适合需要完整成果输出的用户。这些成果可能包括格式化的电子表格、可视化图表、交互式仪表盘和基础网页工具等。
+
+每个 Lab 项目都包含一个“Assets”标签页，用户可在此查看或下载所有生成的素材，如图表、图片、CSV 文件和代码文件。有些 Labs 还支持“App”标签页，可以直接在项目环境中渲染基本网页应用。
+
+## 3 使用反馈
+
+Perplexity 的 CEO 和联合创始人 Aravind Srinivas 表示：
+
+> 推出 Perplexity Labs，是我们在 Perplexity 上进行搜索的一种全新方式，支持更复杂的任务，如构建交易策略、仪表盘、用于房地产研究的无头浏览任务、迷你网页应用、故事板，以及生成素材的目录等。
+
+实际使用看，Labs 实现了多个软件工具功能的整合与自动化，大大减少了手动操作，尤其适用于结构化研究、数据处理或原型开发等场景。
+
+用户反馈也显示出平台在速度和语境理解方面的优势。Sundararajan Anandan 就曾[分享](https://www.linkedin.com/feed/update/urn:li:ugcPost:7333908730314399752?commentUrn=urn%3Ali%3Acomment%3A(ugcPost%3A7333908730314399752%2C7334912579871326209)&dashCommentUrn=urn%3Ali%3Afsd_comment%3A(7334912579871326209%2Curn%3Ali%3AugcPost%3A7333908730314399752))：
+
+> 我最近尝试了 Perplexity Labs，它真的改变了游戏规则。以前需要花几个小时才能完成的手动研究和格式整理，现在在 10 分钟内就能输出清晰、可执行的见解。虽然目前还处于早期阶段，平台也有待进一步完善，但初次体验已经相当令人惊艳。
+
+不过，一些早期用户也指出了可改进的地方，特别是在初次生成后进行跟进操作或修改代码方面功能有限。正如一位 Reddit 用户[评论](https://www.reddit.com/r/perplexity_ai/comments/1kza7vo/comment/mv6koy5/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)所说：
+
+> Labs 最大的问题在于它对后续操作的支持不够，基本要求用户一击命中，非常考验技巧。
+
+## 4 总结
+
+Perplexity 还宣布将统一产品术语，将“Deep Research”简化为“Research”，以便更清晰地区分三种模式：Search、Research 和 Labs。
+
+目前，Perplexity Labs 已正式上线，向所有 Pro 用户开放。平台还提供了 [Projects Gallery](https://www.perplexity.ai/labs)，展示了各种示例和使用案例，帮助用户快速上手完成实际任务。
\ No newline at end of file
diff --git a/docs/md/AI/llm/what-is-llmops.md b/docs/md/AI/agent/what-is-llmops.md
similarity index 100%
rename from docs/md/AI/llm/what-is-llmops.md
rename to docs/md/AI/agent/what-is-llmops.md
diff --git a/docs/md/AI/agent/windsurf-update.md b/docs/md/AI/agent/windsurf-update.md
new file mode 100644
index 0000000000..2ff335fbe9
--- /dev/null
+++ b/docs/md/AI/agent/windsurf-update.md
@@ -0,0 +1,745 @@
+# Windsurf功能更新
+
+## v 1.10.3 Windsurf Browser
+
+June 12, 2025
+
+- 可将浏览器上下文共享给 Windsurf
+- 支持共享代码块、选中文本、网页元素、截图和控制台日志
+- 可将这些内容直接发送到 Cascade
+
+## v 1.10.1 计划模式
+
+2025年6月10日
+
+![](https://p.ipic.vip/um84ce.png)
+
+### 计划模式
+
+- 可以在“计划模式”下向 Cascade 发消息，该模式允许 Cascade 在执行编辑操作前先进行规划
+- Cascade 会创建一个名为 `plan.md` 的文件，列出其准备执行的操作
+- 用户可编辑这个计划文件，Cascade 会识别用户的修改内容
+
+### 终端优化
+
+- Cascade 面板中新增原生终端
+- 现可直接在 Cascade 面板的终端中输入指令
+
+### 移除旧版模式
+
+- 移除旧版模式，现仅保留“Write模式”和“Chat模式”
+
+### 其他改进
+
+- 在 @提及 中加入图标
+- 代码块根据主题自动适配样式，界面焕新
+- 改进 `.codeiumignore` 文件支持
+- 新增菜单，可快速打开和切换之前的对话
+
+## v 1.9.4 修复
+
+2025年6月3日
+
+- 合并了来自 VS Code 1.99.3 的最新更新
+
+## v 1.9.2 支持自带 Anthropic 密钥
+
+2025年5月22日
+
+#### 自带密钥（BYOK）
+
+- 现在你可以在 Cascade 中使用自己的 Anthropic API 密钥，支持 Claude 4 Sonnet、Claude 4 Sonnet（思考版）、Claude 4 Opus 和 Claude 4 Opus（思考版）模型
+- 使用方法：前往 [提供 API 密钥](https://windsurf.com/subscription/provider-api-keys) 页面并输入你的密钥
+- 输入后返回 Windsurf 并重新加载页面，即可使用这些新模型
+
+## v 1.9.1 SWE-1 改进
+
+2025年5月21日
+
+### 多模态支持
+
+- 为 SWE-1 增加了多模态支持，现已支持图像输入
+
+## v 1.9.0 新一代 SWE-1 模型系列
+
+2025年5月15日
+
+### SWE-1
+
+- Windsurf 推出了全新的 SWE-1 模型
+- SWE-1 具备前沿级别的模型能力
+- 专业用户限时免费使用
+
+### SWE-1-lite
+
+- 替代原有 Cascade Base 的新版本，性能大幅提升
+- 所有用户免费用
+
+### SWE-1-mini
+
+- SWE-1-mini 是为 Windsurf 中的标签补全功能特别优化的轻量模型
+
+## v 1.8.2 Cascade Customization
+
+May 6, 2025
+
+### 界面改进
+
+- 重设计型选择器
+- 增加了继续按钮以处理单个工具调用限制
+- 优化会话关联的工作区打开方式
+- 代码块接受/拒绝组件新增紧凑模式，减少占用空间。
+
+### Cascade UX Improvements
+
+- Improvements to commit message generation quality
+- Commit message generation reads from global rules as context
+- Ability to edit proposed terminal command
+
+### 自定义工作流
+
+- 用户可创建并保存“工作流”
+- 通过斜杠命令调用
+- Cascade支持创建和编辑这些工作流
+- 文件保存于工作区的.windsurf/workflows目录下
+
+### 基于文件的规则
+
+- 允许创建细粒度的规则文件，可全局生效、被@提及、由Cascade请求，或附加到文件 glob 模式中
+- 规则文件保存于.windsurf/rules目录
+
+### 多任务处理
+
+- Cascade支持在切换对话时持续运行
+- 并新增了通过下拉菜单或键盘快捷键切换对话的功能
+
+### Cascade插件
+
+- Cascade新增MCP服务器管理面板
+- 简化了一键安装和卸载流程
+- 优化搜索体验
+- MCP现支持资源管理和多模型响应
+- 未来将推出更多MCP服务选项
+
+## v 1.8.0 团队功能
+
+May 6, 2025
+
+### 代码审查
+
+- 团队管理员可安装GitHub应用进行代码审查及PR标题/描述编辑
+- 每月提供500次审查，适用于团队和企业SAAS用户
+
+### 对话分享
+
+- 团队成员可生成共享链接，仅团队内其他成员可访问
+- 适用于团队和企业SaaS方案
+
+### 知识管理
+
+- 团队管理员可连接Google账户并整理相关文档
+- 团队成员可以@提及这些文档以便Cascade检索
+- 适用于团队和企业SAAS用户
+
+### 部署功能
+
+- 团队用户可通过Windsurf设置连接Netlify账户
+- 直接将应用部署至Netlify团队
+- 支持SSO、自定义域等通过Netlify控制台的团队专用设置
+
+### 分析仪表盘
+
+- 更新了团队分析仪表盘
+- 增加Cascade相关数据，如消息数量、工具调用次数、模型使用情况等
+
+### 系统升级
+
+升级至VS Code 1.99.1版本。
+
+## v 1.7.2 全新应用图标与免费套餐升级
+
+2025年4月28日
+
+### 全新应用图标
+
+- Windsurf 现已启用全新设计的应用图标
+- Windsurf.com 网站也同步更新了新版文字标志
+- （Mac 系统）可自定义应用图标也采用新标识
+
+### 免费套餐升级
+
+- 免费用户的使用额度提升
+- 现可在写作模式用 Cascade
+- Cascade 提示额度从每月 5 条提升至 25 条
+- Fast Tab 功能无限制使用
+- Cascade Base 功能无限制使用
+- 可访问预览功能
+- 支持 1 个部署操作
+
+### 性能优化
+
+- 部署应用时的性能和稳定性提升
+- 即使已有部署配置文件（yaml），仍可创建新的部署
+- 部署 Web 应用工具中新增“检查部署状态”的调用功能
+- 对远程扩展（WSL、SSH、Dev Containers）进行了稳定性改进
+- 在大型差异区域中打字时的性能表现更好
+
+### 其他更新
+
+- Command 中新增对 GPT-4.1 的支持
+- 升级至 VSCode 基础版本 1.98
+
+## v 1.7.1
+
+2025年4月24日
+
+- 更新了 IDE 应用商店链接，现同步至 Open VSX 镜像平台
+
+## v 1.7.0
+
+April 21, 2025
+
+### 更新后的简化定价方案
+
+#### 我们将取消 Flow 操作点数（Flow Action Credits）
+
+- 为了让定价模式更简单，我们将取消 Flow 操作点数
+- 此变更将于 2025 年 4 月 21 日起生效
+- 各订阅方案现在将包含「提示点数」，也可以额外购买点数包
+
+#### 用户提示点数（User Prompt Credits）
+
+- 所有订阅方案将提供提示点数，发送每条消息时会消耗点数，而不是每次工具调用时消耗
+- 可额外购买点数包
+- 用户可在个人资料中开启自动充值功能（可设置上限）
+
+#### 现有订阅方案
+
+- 所有现有订阅方案将自动迁移至新的定价模式
+- 更多详情请访问 [定价页面](https://windsurf.com/pricing)
+
+## v 1.6.5
+
+2025年4月16日
+
+### 全新 o4-mini 模型上线，限时免费使用
+
+- Windsurf 现已支持 o4-mini medium 和 o4-mini high 两个模型，所有用户均可免费使用
+- 使用时间限于 4 月 16 日至 4 月 21 日
+
+## v 1.6.4
+
+2025年4月14日
+
+### 全新 GPT 4.1 模型上线，限时免费使用
+
+- Windsurf 现已支持全新的 GPT 4.1 模型，所有用户均可免费使用
+- 使用时间限于 4 月 14 日至 4 月 21 日
+
+2025年4月9日
+
+### Cascade 现已支持JetBrains
+
+- 查看完整的 [JetBrains 更新日志](https://windsurf.com/changelog/jetbrains)
+- 阅读 [官方公告](https://windsurf.com/blog/windsurf-wave-7)
+
+### **Codeium 正式更名为 Windsurf**
+
+- 公司名称更改为Windsurf，插件产品也将更名为 **Windsurf Plugin**。
+
+- 自从推出 [Windsurf 编辑器](https://windsurf.com/editor) 以来，我们明确了真正的
+
+- 目标：融合人类创造力与机器智能，打造强大却毫不费力的体验。
+
+## v 1.6.3
+
+2025年4月7日
+
+- 修复了 Windows 系统上提交生成解析的问题
+- 修复了规则页面的部分 UI 问题
+- 允许部署网站时包含空文件
+- 提升部署错误的可见性
+- 网站部署时支持编辑子域名
+- 提高 MCP SSE 连接的稳定性
+
+## v 1.6.2
+
+2025年4月3日
+
+- 修复了 "Remote - WSL" 扩展相关的问题
+- 一些用户体验方面的小修复
+
+## v 1.6.1
+
+### **2025年4月2日**
+
+### **部署功能（测试版）**
+
+- 使用一句提示将应用部署至 Netlify，使用 windsurf.build 域名
+- 认领你的应用 URL 后，可持续部署更新至相同项目
+- 想部署新站点或更换子域名？只需让 Cascade 部署到新子域即可
+- 所有用户都可使用，付费计划有更多权限
+
+### **提交信息生成（测试版）**
+
+- 在源码控制面板中一键生成提交信息
+- 付费用户可用，且不额外消耗积分
+
+### **Cascade 记忆功能增强**
+
+- 新增记忆标签页
+- 支持编辑记忆标题、内容和标签
+- 支持搜索 Cascade 生成的记忆
+- 设置中可启用/关闭自动生成记忆的开关
+- 开启后自动记录重要上下文；关闭后只会根据请求创建记忆
+
+### **长对话改进**
+
+- 引入用户消息目录，滚动时显示，支持快速定位历史内容
+
+### **Windsurf Tab 改进**
+
+- 支持 Jupyter Notebook
+- 新增上下文信号，包括 IDE 内部搜索内容
+
+### **新图标（Mac）**
+
+付费用户可选两款新应用图标：Retro 和 Pixel Surf
+
+### **其他更新**
+
+- 新增 Cascade 工具栏，整合 MCP、预览、部署等工具
+- Cascade 支持 JSON 配置中的 SSE MCP 服务器
+- “打开新窗口时关闭 Cascade” 的设置现已生效
+- 输入框内容在新建会话和活跃会话中保留
+- 终端界面焕新，“打开终端”按钮更加醒目
+- 链接支持点击跳转
+- 可开启“运行结束播放提示音”（测试中）
+- 修复 Remote - SSH 扩展问题，支持自定义 SSH 路径
+- 合并 VS Code 1.97.0 相关更新
+
+## **v 1.5.9**
+
+### **2025年3月25日**
+
+### **新模型：Gemini 2.5 Pro（测试版）**
+
+- Gemini 2.5 Pro 正式进入测试阶段！
+- 每条消息消耗 1 个用户提示积分，每次工具调用消耗 1 个流程操作积分
+- 所有计划（包括免费）均可使用
+- *当前需求量大，团队正在扩容中*
+
+### **修复内容**
+
+- 修复了 Remote - SSH 扩展及自定义 SSH 路径设置问题
+
+## **v 1.5.8**
+
+### **2025年3月24日**
+
+### **修复内容**
+
+- Cascade 更好地遵循用户定义的记忆
+- 浏览器预览改进
+- 修复 Cascade 图标相关布局问题
+
+## **v 1.5.6**
+
+### **2025年3月18日**
+
+### **全新 Windsurf Tab 体验**
+
+- 将 Autocomplete、Supercomplete、Tab to Jump、Tab to Import 整合为一体化体验
+- 使用更大更高质量模型，提升上下文理解、速度与质量
+
+### **上下文优化**
+
+- 补全功能可利用浏览文件、终端命令、Cascade 会话等信号
+- 剪贴板上下文（默认关闭，可在高级设置中启用）
+- 上下文长度扩展，提升补全效果
+
+### **质量提升**
+
+- 自动选择插入补全 vs 编辑补全更加精准
+- Tab to Jump 跳转范围翻倍
+- 提高缩进与排版质量
+
+### **性能提升**
+
+- 预测触发补全，连贯完成多轮建议
+- 增强服务器能力与推理速度
+- 网络优化，延迟更低
+
+### **Tab 使用体验升级**
+
+- 接受的补全高亮为绿色（可关闭）
+
+- Tab to Jump 与 Tab to Import 小部件视觉更清晰、可点击
+
+### **其他改进**
+
+- 自动修复 Lint 模式中信用扣除更准确
+- 终端命令现可作为上下文
+- Debug Console 中 Tab 键支持补全
+- Cascade 差异审查体验优化
+- 修复信用不足提示、补全速度设置等问题
+- 快捷设置下拉菜单改进
+- 提升 CPU 和内存使用效率
+- 新增 Neon 数据库作为 MCP 模板
+
+## **v 1.4.6**
+
+2025年3月10日
+
+### **修复内容**
+
+- 修复 Sonnet 3.7 网页搜索问题
+- 修复代理设置问题
+
+## v 1.4.4 修复
+
+2025年3月6日
+
+- 重新添加设置项至设置面板（代理设置、索引大小）
+
+## v 1.4.3
+
+### **2025年3月5日**
+
+### **Windsurf 预览、自动 Linter、新 MCP 服务**
+
+#### **Windsurf 预览（测试版）**
+
+- Cascade 支持在 IDE 或浏览器中预览本地网站
+- 可选中 React 或 HTML 元素作为上下文提供给 Cascade
+- 错误信息也可传递作为上下文
+- 可通过“启动 Web 应用”或工具栏图标激活预览
+- 支持在 Chrome、Arc、Chromium 浏览器中展示
+- 可在设置中关闭
+
+#### **Cascade 自动 Linter**
+
+- Cascade 现在自动修复自己生成代码中的 lint 错误
+- 每步中 lint 修复不计入积分消耗
+- 示例：若某次修改包含4个 lint 错误，将自动尝试修复，无额外消耗
+- 可在设置中关闭
+
+#### **新 MCP 服务支持**
+
+- 可将 Cascade 配置为调用可信 MCP 工具服务器
+- Windsurf 设置页提供常用 MCP 服务器列表
+- 新用户界面便于添加和配置 MCP
+- 设置页中仍支持用户自定义 JSON
+- 专业与终极专业计划可用，团队与企业计划即将支持
+
+#### **Tab-to-Import**
+
+- 自动补全缺失依赖导入
+- 使用 Tab 接受建议即可完成导入
+
+#### **建议操作**
+
+- Cascade 提供任务相关建议操作，点击即可继续操作流程
+
+#### **拖放文件作为上下文**
+
+- 支持从文件资源管理器拖放文件进 Cascade
+- 支持所有文件类型
+
+#### **模型管理控制**
+
+- 团队管理员可选择开放哪些模型供团队使用
+- 成员默认仅见管理员启用的模型
+
+#### **Claude Sonnet 3.7 支持**
+
+- Cascade 支持 Claude Sonnet 3.7
+- 工具调用与流程操作表现更优
+
+#### **其他更新**
+
+- 新版快速设置界面与高级设置视图
+
+- 支持读取 .gitignore 文件
+
+- 推出用户推荐系统
+
+- Windsurf directory：官方精选规则集，帮助 Cascade 更好理解你与代码库
+
+  - [查看规则目录](https://codeium.com/windsurf/directory)
+
+## **v 1.3.10**
+
+### **修复内容**
+
+- 优化 Claude 3.7 Sonnet 的积分使用
+- 更新后建议在新会话中运行所有后续操作
+- 新增查看/编辑 .gitignore 文件的选项
+
+## **v 1.3.9**
+
+### **新模型：Claude 3.7**
+
+- Cascade 现已支持 Claude 3.7 Sonnet（高级模型）
+
+  
+
+  - 每条消息消耗 1 积分，每次工具调用也消耗 1 积分
+  - “思维模式”下使用该模型积分乘数为 1.5x
+
+  
+
+- [渐进推出] GPT-4.5 模型测试中
+
+  
+
+  - 因成本、速率限制与质量测试，将逐步放出
+
+
+## **v 1.3.3**
+
+2025 年 2 月 13 日
+
+## **模型上下文协议、自定义应用图标，以及 Tab 跳转**
+
+### **模型上下文协议 (Model Context Protocol)**
+
+- Cascade 现在支持模型上下文协议（MCP）
+- 你可以设置 Cascade 对话使用 MCP 服务器进行工具调用
+- 可以通过点击 Cascade 输入栏的锤子图标设置 MCP
+- 对所有个人用户计划开放
+- 每次 MCP 工具调用消耗 1 个流动操作积分，无论执行结果如何
+
+### **新增可自定义应用图标**
+
+- 你现在可以更改 Windsurf 的应用图标（仅限 Beta & Mac）
+- 付费用户可以选择 Classic、Blueprint、Hand-drawn、Valentine 等风格
+- 更改图标后需重启系统以实现系统级别的图标更新
+- 对所有付费用户计划开放
+- Windows 和 Linux 平台即将上线该功能
+
+### **补全功能改进**
+
+- Tab to Jump 功能正式发布，可智能预测下一个编辑位置并通过 Tab 键跳转
+
+### **Cascade Turbo 模式**
+
+- Cascade Turbo 模式全面升级，可自动执行终端命令（除非被加入拒绝列表）
+- 对所有个人用户计划开放
+
+### **Cascade 拖拽图片支持**
+
+- Cascade支持从系统文件或截图中拖拽图片到输入框
+
+### **积分使用可视化**
+
+- Cascade 现在可以显示每个操作消耗了多少积分
+- 鼠标悬停在执行后的操作上可查看积分消耗
+
+### **其他改进**
+
+- 修复了 Cascade 终端命令的一些 Bug
+- 命令步骤现在会显示自动执行的行为信息
+- 修复了重新加载后 Cascade 面板总是自动打开的问题，即使用户已在设置中关闭
+- 你可以使用 Cmd/Ctrl+L 快捷键 @提及 终端文字，新增了选择弹窗
+- @docs 结果现在支持滚动查看，避免选项被截断
+- @docs 支持更多服务，如 Vercel、Bun、Supabase 等
+
+### **新增模型**
+
+- Cascade 新增高级模型：Gemini 2.0 Flash
+
+  
+
+  - 每条消息消耗 0.25 用户提示积分，每次工具调用消耗 0.25 流动操作积分
+
+
+## **v 1.2.4**
+
+2025 年 1 月 31 日
+
+## 新增模型：DeepSeek-R1、DeepSeek-V3 和 o3-mini
+
+### 模型
+
+- 新增高级模型：DeepSeek-R1、DeepSeek-V3 和 o3-mini÷
+- DeepSeek-V3 和 R1 适用于 Pro 和 Pro Ultimate 用户
+- DeepSeek-V3：每条消息消耗 0.25 用户提示积分，每次工具调用消耗 0.25 流动操作积分
+- DeepSeek-R1：每条消息消耗 0.5 用户提示积分，每次工具调用消耗 0.5 流动操作积分
+- o3-mini 适用于所有付费用户
+- o3-mini：每条消息和每次调用均消耗 1 个积分
+
+
+### 修复内容
+
+- 增加拖拽图片至 Cascade 功能支持
+
+## v 1.2.0 弹性积分系统上线，Cascade Base 开源！
+
+2025 年 1 月 25 日
+
+### 弹性积分系统
+
+- Windsurf 现在引入 **弹性积分（Elastic Credits）** 系统
+
+- 拆分为两类积分：
+
+  - 用户提示积分（User Prompt Credits）
+  - 流动操作积分（Fluid Action Credits）
+
+- 模型对话、文件上传、API 工具调用、终端操作都将按实际用途计费，更透明可控
+
+- 设置 > 积分详情中查看各模型和工具的积分消耗
+
+- 套餐每月包含的积分数不变，仅计费方式调整
+
+### Cascade Base 开源
+
+- 作为本地运行的轻量 AI 助理，开源地址：https://github.com/exafunction/cascade
+- 用户可以自定义工具链，连接任意本地服务或模型
+
+### **新增模型**
+
+- **Claude 3 Opus** 模型上线（适用于 Pro Ultimate 用户）
+- 消耗：每条消息需 2 用户提示积分，每次工具调用需 2 流动操作积分
+
+### **改进项**
+
+- 文件上传功能更清晰，拖拽上传 UI 优化
+- 文件上传后自动触发 @files 工具处理内容
+
+## v 1.1.1
+
+2025 年 1 月 19 日
+
+### **修复内容**
+
+- 修复了终端调用 API 返回乱码的问题
+- 修复调用工具时出错未显示详细错误的 bug
+- 修复选择文件时的路径错乱问题
+- 修复长时间运行后模型响应变慢的问题
+
+## v 1.1.0
+
+2025 年 1 月 15 日
+
+## 文件支持、自动调用工具，以及 Claude 3 模型上线！
+
+### **文件功能（Beta）**
+
+- 你现在可以上传文件至对话中，AI 可自动引用内容
+- 支持的文件类型：.txt, .md, .pdf, .docx, .csv, .json 等
+- 文件内容可以通过 @files 工具进行提问和搜索
+- 文件将默认保存在本地，不会上传至云端
+
+### 自动调用工具
+
+- Cascade 现在支持 **自动调用工具**
+- 在你与 AI 对话过程中，会自动触发相关工具（如终端、API、搜索等）
+- 可在设置中手动启用或关闭自动调用
+
+### 新增 Claude 3 模型
+
+- 新增 Anthropic 的 Claude 3 Haiku 和 Claude 3 Sonnet 模型
+
+  - Claude 3 Haiku：快速响应、低消耗
+  - Claude 3 Sonnet：更强大，适用于复杂任务
+
+- 默认对所有付费用户开放，Sonnet 限 Pro 及以上
+
+## v 1.0.6
+
+2024年12月6日
+
+### 使用透明度
+
+![1.0.6 更新日志横幅](https://exafunction.github.io/public/changelog/windsurf/1.0.6/106_hero_img.jpg)
+
+#### 使用透明度与定价
+
+- 推出 Windsurf 的全新使用和定价系统。详情请参见[定价](https://codeium.com/redirect/windsurf/learn-pricing)
+- 快速设置面板现在会显示当前计划的使用情况，包括试用期到期时间、下一个刷新周期的信息以及升级链接
+- Cascade 新增“Legacy Chat”模式，当用户的 Flow Credits 耗尽时激活。此模式功能有限，但无需使用 Flow Credits
+- 在设置面板中查看 Cascade 的使用情况。更多信息请参见[此处](https://docs.codeium.com/windsurf/usage#viewing-your-usage)。
+
+#### Cascade 图片上传
+
+- Cascade 图片上传的大小限制取消为 1MB
+
+#### 增强 Python 语言支持
+
+- 通过 Windsurf Pyright 提供功能丰富的 Python 语言支持。Windsurf Pyright 是 Pylance 的替代方案
+
+### 其他修复
+
+- 从其他基于 VS Code 的 IDE 导入，可连同设置一起导入代码片段
+- 快速设置面板中可查看并配置 AI 相关快捷键
+
+## v 1.0.5 图片上传
+
+2024年11月27日
+
+#### 上传图片到 Cascade
+
+- Cascade 现在支持在高级模型上传图片
+- 上传图片后可以让 Cascade 构建或调整 UI
+
+#### 新增快捷键
+
+- 快捷键在 Cascade 差异视图中导航（默认是 ⌥/Alt + j 和 ⌥/Alt + k）
+- 快捷键在具有 Cascade 差异的文件间导航（默认是 ⌥/Alt + h 和 ⌥/Alt + l）
+
+### 其他修复
+
+- 增加了控制 Cascade 是否自动打开创建/编辑文件的选项（默认启用）
+- 修复了影响部分用户的自动补全设置问题
+- 快速设置面板 UI 更新
+
+## v 1.0.4 解释并修复问题
+
+2024年11月21日
+
+- Cascade 将尝试修复代码库中的问题
+- 鼠标悬停在问题上时会出现选项
+
+#### 从cursor导入
+
+- 导入设置和扩展
+- 可通过命令面板或重置引导流程获取
+
+#### 新增快捷键
+
+- 接受文件中所有活动差异的快捷键（默认是 ⌘/Ctrl + ⏎）
+- 拒绝文件中所有活动差异的快捷键（默认是 ⌘/Ctrl + ⌫）
+- ⌘/Ctrl + Shift + L 打开 Cascade 中的新对话，同时复制选中的终端/编辑器文本到新对话
+
+### 改进与修复
+
+####  改进的命令
+
+- 改进了 Jupyter Notebook 中的命令体验
+
+####  改进的差异视图
+
+- 删除了 Cascade 删除文件中的差异显示
+- 更清晰的光标指示，显示已删除文本的差异内容可被选中
+
+###  其他修复
+
+- Windsurf 快速设置面板在点击面板外部时会自动关闭
+- 提高了某些主题中引导元素的可见性
+- 修复了一些轻微的布局问题
+- 增加了加入 Discord 社区的按钮
+- 提高了通过 SSH 使用时 Cascade 面板的稳定性
+- 由 Cascade 编辑/创建的文件将自动在后台打开。如果没有活动的编辑器，首个编辑/创建的文件将作为当前活动编辑器打开
+- 在标题栏下拉菜单中新增了更新日志链接，同时在用户更新版本后显示更新日志提醒
+
+## v 1.0.2 - Windsurf上线
+
+2024年11月13日
+
+![](https://exafunction.github.io/public/changelog/windsurf/1.0.2/102_hero_img.jpg)
+
+- 正式发布！
+- 使用 Cascade 与 Codeium 的完整代码库上下文聊天，支持多文件编辑
+- 新模式 Supercomplete，可预测下一步意图
\ No newline at end of file
diff --git a/docs/md/AI/document-parsing-and-chunking-in-open-source-tools.md b/docs/md/AI/document-parsing-and-chunking-in-open-source-tools.md
new file mode 100644
index 0000000000..52b8b8e2f6
--- /dev/null
+++ b/docs/md/AI/document-parsing-and-chunking-in-open-source-tools.md
@@ -0,0 +1,102 @@
+# 01-RAG应用框架和解析器
+
+## 1 开源解析和拆分文档
+
+第三方工具去对文件解析拆分，提取文件内容，并将文档内容拆分成一个小chunk。
+
+PDF、word、markdown、JSON、HTML等都有很好的模块执行提取。
+
+### 1.1 优势
+
+- 支持丰富的文档类型
+- 每种文档多样化选择
+- 与开源框架无缝集成
+
+![](https://my-img.javaedge.com.cn/javaedge-blog/2024/06/704e6a30d6793c931c5db2a5afe142d5.png)
+
+但有时效果很差，内容跟原文件差别大。
+
+## 2 PDF格式多样性
+
+![](https://my-img.javaedge.com.cn/javaedge-blog/2024/06/96e776191774b85d9490cd0d2b3d1d4a.png)
+
+复杂多变的文档格式，提高解析效果困难。
+
+## 3 复杂文档格式解析问题
+
+文档内容质量很大程度影响最终效果，文档处理涉及问题：
+
+### 3.1 内容不完整
+
+对文档的内容提取时，可能发现提取出的文档内容会被截断。跨页形式，提取出来它的上下页，两部分内容就会被截断，导致文档内部分内容丢失，去解析图片或双栏复杂的这种格式，它会有一部分内容丢失。
+
+### 3.2 内容错误
+
+同一页PDF文件可能存在文本、表格、图片等混合。
+
+PDF解析过程中，同一页它不同段落其实会也会有不同标准的一些格式。按通用格式去提取解析就遇到同页不同段落格式不标准情况。
+
+### 3.3 文档格式
+
+像常见PDF md文件，需要去支持把这些各类型的文档格式的文件都给提取。
+
+### 3,4 边界场景
+
+代码块还有单元格这些，都是我们去解析一个复杂文档格式中会遇到的一些问题。
+
+## 4 PDF内容提取流程
+
+![](https://p.ipic.vip/bgzr90.png)
+
+## 5 为啥解析文档后，要做知识片段拆分？
+
+### 5.1 Token限制
+
+- 绝大部分开源限制 <= 512 Tokens
+- bge_base、e5_large、m3e_base、text2vector_large_chinese、multilingnal-e5-base..
+
+### 5.2 效果影响
+
+- 召回效果：有限向量维度下表达较多的文档信息易产生失真
+- 回答效果：召回内容中包含与问题无关信息对LLM增加干扰
+
+### 5.3 成本控制
+
+- LLM费用：按Token计费
+- 网络费用：按流量计费
+
+## 6 Chunk拆分对最终效果的影响
+
+### 6.1 Chunk太长
+
+信息压缩失真。
+
+### 6.2 Chunk太短
+
+表达缺失上下文；匹配分数容易变高。
+
+### 6.3 Chunk跨主题
+
+内容关系脱节。
+
+### 原文连续内容（含表格）被截断
+
+单个Chunk信息表达不完整，或含义相反
+
+### 干扰信息
+
+如空白、HTML、XML等格式，同等长度下减少有效信息、增加干扰信息
+
+### 主题和关系丢失
+
+缺失了主题和知识点之间的关系
+
+## 7 改进知识的拆分方案
+
+![](https://p.ipic.vip/n7g8l0.png)
+
+## 8 商用向量数据库AI套件
+
+Vector DB AI套件：
+
+![](https://p.ipic.vip/69bx73.png)
\ No newline at end of file
diff --git a/docs/md/AI/llm/cuda.md b/docs/md/AI/llm/cuda.md
new file mode 100644
index 0000000000..735f4355e0
--- /dev/null
+++ b/docs/md/AI/llm/cuda.md
@@ -0,0 +1,230 @@
+# 空有A100却在“吃灰”？给Javaer的三种CUDA“遥控器”，榨干GPU性能
+
+## 0 前言
+
+有自己的智算中心和这么多A100“大杀器”，了解CUDA不是“要不要”，而是“必须”的问题了。不把GPU潜力榨干，那可真是太浪费了。
+
+作为Java架构师，无需像C++程序员手写底层CUDA C++代码，但须理解核心思想和工作原理。才能在架构层正确决策，判断：
+
+- 哪些业务场景适合交给GPU加速
+- 咋将Java应用与底层CUDA能力连接
+
+这就像不一定手写汇编，但懂些CPU工作原理，能写更高性能Java代码。
+
+## 1 CUDA是啥？从JVM说起
+
+先定调：对Java架构师，可把CUDA看作专属于NVIDIA GPU的“JVM + JIT编译器”。
+
+  * **JVM是什么？** 一个标准的运行时，能让Java字节码（`.class`文件）在不同的操作系统和CPU上运行
+  * **CUDA是什么？** 一个标准的运行时和API集合，能让你写的“GPU代码”（通常是C++写的`.cu`文件）在NVIDIA的GPU硬件运行
+
+再进一步：
+
+  * **JIT（Just-In-Time）编译器**：JVM精髓之一。运行时把热点的Java字节码动态编译成本地机器码，充分压榨CPU性能
+  * **NVCC（NVIDIA C Compiler）**：CUDA的“编译器”。会把`.cu`文件（一种混合C++和CUDA特殊指令的源文件）编译成能在GPU上高效执行的机器码（PTX或SASS）
+
+所以，谈论CUDA时，谈论的是一个完整生态系统：
+
+  * **一个编程模型**：告诉你咋写并行代码
+  * **一套API和库**：给你提供现成工具调用GPU
+  * **一个驱动和运行时**：负责在硬件上实际执行你的代码
+
+一句话总结：CUDA是连接上层应用软件和底层NVIDIA GPU硬件的“驱动+标准接口+运行时”，是释放GPU强大并行计算能力的钥匙。
+
+## 2 CUDA“世界观”：为啥它能那么快？
+
+CPU和GPU设计哲学完全不同：
+
+  * **CPU（中央处理器）**：全能的单兵王者。核心（Core）数不多（如16、32核），但每个核心都极其强大和复杂。巨大缓存、复杂分支预测和指令流水线，擅长处理**复杂的、带有大量逻辑判断和串行依赖的任务**。就像几个经验丰富项目经理，能处理各种疑难杂症
+
+  * **GPU（图形处理器）**：纪律严明的万人军团。核心数量庞大（一张A100有6912个CUDA核心！），但每个核心很简单，功能有限。不擅长复杂逻辑判断，但极其擅长**对海量数据执行同一个简单的计算任务**。就像上万个士兵，每人只会“前进、刺击”简单动作，但上万人一起做，形成冲击力毁灭性。
+
+CUDA编程模型的核心就是**咋组织和指挥这个“万人军团”**。它引入了几个核心概念：
+
+  * **Kernel（内核）**：你希望GPU执行的那个“简单任务”的定义。可以把它想象成你写的一个Java `Runnable` 接口的 `run()` 方法。这个方法里的代码，将会被成千上万个线程去执行
+
+  * **Thread（线程）**：GPU执行`Kernel`的最小单元。相当于一个Java的`Thread`实例
+
+  * **Block（块）**：一组GPU线程，形成一个“班”或“排”。同一个Block里的线程可以非常高效地进行通信和数据同步（通过一块共享内存`Shared Memory`）。这有点像一个`ExecutorService`线程池里的线程，它们可协同工作
+
+  * **Grid（网格）**：一组Block，形成一个“师”或“军”。这是你向GPU提交的一个完整的计算任务
+
+所以，一个典型CUDA任务流程：
+
+1.  **定义任务**：用CUDA C++写一个`Kernel`函数，比如“给这个数组的每个元素都乘以2”
+2.  **组织军团**：确定你要启动多少个线程（Grid和Block的维度），比如“启动1024个Block，每个Block包含256个线程，总共262,144个线程大军”
+3.  **数据传输**：把需要处理的数据从CPU的内存（我们Java应用的堆内存）拷贝到GPU的显存（VRAM）中。**这是关键瓶颈之一！**
+4.  **执行命令**：在GPU上启动`Kernel`，让成千上万个核心同时开始计算
+5.  **回收结果**：等GPU计算完成后，再把结果从GPU显存拷贝回CPU内存
+
+**架构师的启示**：一个任务是否适合用GPU加速，关键看：
+
+1.  **计算密集型**：任务本身需要大量的数学运算，而不是复杂的业务逻辑
+2.  **高度并行性**：任务可以被拆解成成千上万个完全独立的子任务。比如矩阵乘法、图像滤镜、大规模数据转换等。如果任务前后依赖严重，比如`for`循环里下一步的计算依赖上一步的结果，那就不适合GPU
+
+## 3 Javaer咋“遥控”CUDA？
+
+我们的主战场。
+
+知道CUDA原理，但我们是Java架构师，总不能去写C++吧？当然不用！有几种“遥控”方式，从“硬核”到“优雅”：
+
+### 3.1 JNI
+
+Java Native Interface，硬核但灵活。最原始、最底层方式：
+
+#### 原理
+
+Java通过JNI规范，可以调用C/C++写的动态链接库（`.dll`或`.so`文件）。我们可以让C++团队把所有CUDA相关的复杂操作（内存管理、核函数启动等）封装成一个简单的C函数，并编译成`.so`文件。Java应用在需要时，通过JNI加载这个库，并调用那个C函数。
+
+#### 优点
+
+性能最好，灵活性最高。你可以100%控制所有CUDA的细节。
+
+#### 缺点
+
+极其复杂！需要一个精通CUDA C++和JNI的团队。JNI的开发、调试、部署都非常痛苦，内存管理容易出错导致JVM崩溃。这就像你为了开个车，先自己从零件开始造发动机。
+
+#### 适用场景
+
+对性能要求达到极致，且有专门的C++/CUDA团队支持的超大型项目。
+
+### 3.2 JCuda / JCublas等第三方库 - “JDBC”模式
+
+这是目前比较主流和现实的方式。
+
+#### 原理
+
+像JCuda这样的库，已经帮你把CUDA Driver API和Runtime API用JNI封装好了，并提供了易于使用的Java接口。你不需要写一行C++代码，就可以在Java里直接调用CUDA的函数。
+
+#### 类比
+
+这完美对标我们JavaEE里的**JDBC**。我们写Java时，不会直接去跟Oracle或MySQL的底层通信协议打交道，而是使用标准的JDBC接口。JCuda就是CUDA的“JDBC驱动”。
+
+#### 示例（伪代码）
+
+```java
+// 1. 初始化CUDA环境
+JCuda.cudaInit();
+
+// 2. 分配GPU显存
+Pointer deviceInput = new Pointer();
+JCuda.cudaMalloc(deviceInput, dataSize);
+
+// 3. 从Java堆内存拷贝数据到GPU显存
+JCuda.cudaMemcpy(deviceInput, hostInput, dataSize, cudaMemcpyHostToDevice);
+
+// 4. 配置并启动Kernel（Kernel通常是预先编译好的.ptx文件）
+// ... 配置Grid和Block维度
+// ... 加载.ptx文件中的Kernel函数
+// ... 调用cuLaunchKernel
+
+// 5. 从GPU显存拷回结果到Java堆内存
+JCuda.cudaMemcpy(hostOutput, deviceOutput, dataSize, cudaMemcpyDeviceToHost);
+
+// 6. 释放资源
+JCuda.cudaFree(deviceInput);
+```
+
+#### 优点
+
+大大降低了使用门槛，纯Java开发，生态相对成熟。
+
+#### 缺点
+
+仍然需要手动管理GPU显存、数据拷贝，对CUDA的运行时模型要有比较清晰的理解。API比较啰嗦，更像是过程式的C API的Java映射。
+
+#### 适用场景
+
+绝大多数需要在Java应用中集成自定义CUDA加速的场景。你们有智算中心，想在现有的Java微服务或大数据处理任务中，把某个计算瓶颈 offload 到A100上，这通常是首选。
+
+### 3.3 TornadoVM / Aparapi等 - “JIT”终极模式
+
+这是最前沿、最优雅，也最具野心的方式。
+
+#### 原理
+
+TornadoVM是一个特殊的OpenJDK插件。它的目标是让你**像写普通的Java并行流（Parallel Stream）一样写代码，然后它自动帮你把代码JIT编译成CUDA/OpenCL代码，并 offload 到GPU上执行！**
+
+#### 类比
+
+这才是真正的“GPU上的JIT”。你甚至都不用关心GPU的存在，TornadoVM会自动分析你的Java字节码，判断是否可以并行化，然后动态生成GPU代码并执行。
+
+#### 示例（伪代码）
+
+```java
+// 你只需要在你的方法上加一个注解
+public static void matrixMultiplication(float[] a, float[] b, float[] c, final int N) {
+    // TornadoVM会把这个@Parallel注解的循环自动编译成CUDA Kernel
+    @Parallel for (int i = 0; i < N; i++) {
+        for (int j = 0; j < N; j++) {
+            float sum = 0.0f;
+            for (int k = 0; k < N; k++) {
+                sum += a[i * N + k] * b[k * N + j];
+            }
+            c[i * N + j] = sum;
+        }
+    }
+}
+
+// 在主程序中，用TornadoVM的TaskSchedule来运行
+TaskSchedule s0 = new TaskSchedule("s0")
+    .task("t0", YourClass::matrixMultiplication, matrixA, matrixB, matrixC, N)
+    .streamOut(matrixC);
+s0.execute();
+```
+
+#### 优点
+
+对Java程序员的透明度极高！** 几乎没有学习成本，可以用纯粹的Java思维来利用GPU。这可能是未来的终极方向。
+
+#### 缺点
+
+还比较新，生态和社区不如JCuda成熟。自动编译的性能可能不如C++专家手写的Kernel。对代码写法有一定要求（不能太复杂）。
+
+#### 适用场景
+
+希望快速将现有Java计算密集型代码（如科学计算、金融风控模型）迁移到GPU上进行验证和加速。新项目技术选型，可以重点关注。
+
+## 4 实践：A100该咋用？
+
+有自己的智算中心和A100，可从以下几个层面思考：
+
+### 4.1 识别瓶颈，建立“GPU加速候选池”
+
+#### 离线大数据处理
+
+Spark/Flink任务中，有开销巨大的`map`或`filter`操作？如对海量图片预处理、对金融交易数据特征提取，都是绝佳候选。可用JCuda或TornadoVM写一个UDF（User-Defined Function），让这个UDF内部调用GPU来计算。
+
+#### 在线微服务
+
+有没有哪个服务的RT（响应时间）因为某个复杂的计算而居高不下？如风控服务的实时风险评分、推荐系统的实时向量相似度计算、图像服务的AI审查。可以考虑将这个服务改造为“CPU+GPU”的混合服务。轻量级请求走CPU，计算密集型请求异步 offload 到GPU。
+
+#### 模型推理
+
+像TensorRT-LLM底层就是CUDA C++写的，它已将A100的Tensor Core（A100的“特种兵”，专精矩阵运算）用到极致。Java应用只需要通过REST/gRPC调用这些推理服务。
+
+### 4.2 构建GPU资源管理与调度层
+
+  * 既是智算中心，就不能让每个Java应用像“野孩子”一样直连GPU。需一个中间层
+  * 可基于k8s的Device Plugin机制，对GPU资源进行池化和调度
+  * 开发一套“GPU任务提交网关”，Java应用通过这个网关提交计算任务，网关负责排队、调度到空闲的A100卡上，并返回结果。这使得GPU对上层业务透明，成为一种可被计量的“计算资源”
+
+### 4.3 技术选型与团队赋能
+
+#### 短期见效
+
+对已有Java应用，选择**JCuda**方案，对最痛的计算瓶颈进行“手术刀”式的改造。
+
+#### 长期投资
+
+励团队研究**TornadoVM**，探索“无感”使用GPU的可能性，降低未来业务的开发成本。
+
+#### 专业分工
+
+如可能，培养或引入1-2名精通CUDA C++的工程师，作为你们的“核武器”，负责攻克最艰难的性能优化问题，并为上层Java应用提供封装好的高性能计算库。
+
+## 5 总结
+
+CUDA对Javaer，不是一门需精通的编程语言，而是须了解的异构计算平台。理解其工作原理和与Java的集成方式，就能打开新大门，将那些过去在CPU上跑得气喘吁吁的任务，扔给A100这个“万人军团”去瞬间完成。
+
+这不仅能带来几十甚至上百倍的性能提升，更是未来AI时代架构设计中不可或缺的一环。
\ No newline at end of file
diff --git a/docs/md/AI/llm/gpullama3-java-gpu-llm.md b/docs/md/AI/llm/gpullama3-java-gpu-llm.md
new file mode 100644
index 0000000000..313bd3e3ae
--- /dev/null
+++ b/docs/md/AI/llm/gpullama3-java-gpu-llm.md
@@ -0,0 +1,70 @@
+# 告别 CUDA！GPULlama3.java 横空出世，Java 首次实现原生 GPU 跑大模型
+
+## 0 前言
+
+曼彻斯特大学 [Beehive Lab](https://github.com/beehive-lab) 发布 [GPULlama3.java](https://github.com/beehive-lab/GPULlama3.java)，这是首个支持 GPU 自动加速的 Java 原生 [Llama3](https://www.llama.com/models/llama-3/) 实现。该项目基于  [TornadoVM](https://github.com/beehive-lab/TornadoVM)，让开发者无需编写 CUDA 或原生代码，即可在 Java 中实现LLM的 GPU 推理。这有望彻底改变 Javaer 在企业环境中构建 AI 应用的方式。
+
+## 1 GPULlama3.java 的核心
+
+TornadoVM —— 一款创新的异构编程框架，它扩展了 OpenJDK 和 GraalVM，使 Java 程序能自动在 GPU、FPGA 以及多核 CPU 加速运行。与传统 GPU 编程方式不同，TornadoVM 无需手动重写 CUDA 或 OpenCL 代码，开发者可完全用 Java 编写逻辑，TornadoVM 负责底层加速。
+
+根据 [TornadoVM 官方文档](https://tornadovm.readthedocs.io/en/latest/introduction.html) 的介绍，该系统通过扩展 Graal JIT 编译器，添加专用后端，在运行时将 Java 字节码转换为 GPU 可执行代码。只需用 `@Parallel` 注解标记方法，TornadoVM 就能将普通 Java 字节码转换为 Graal 中间表示（IR），应用 GPU 优化策略，并生成目标平台代码，如 OpenCL C（跨平台）、PTX（NVIDIA）或 SPIR-V（二进制格式，支持 Intel 显卡）。
+
+```java
+// 来自 TornadoVM 文档的 TaskGraph 示例
+TaskGraph taskGraph = new TaskGraph("computation")
+    .transferToDevice(DataTransferMode.FIRST_EXECUTION, data)
+    .task("process", MyClass::compute, input, output)
+    .transferToHost(DataTransferMode.EVERY_EXECUTION, output);
+
+TornadoExecutionPlan executor = new TornadoExecutionPlan(taskGraph.snapshot());
+executor.execute();
+```
+
+根据 [TornadoVM 编程指南](https://tornadovm.readthedocs.io/en/latest/programming.html)，开发者可用与硬件无关的 API，在不同硬件平台上运行相同的 Java 代码。TornadoVM 运行时会自动处理所有设备相关的优化、内存管理和数据传输。
+
+## 2 支持后端
+
+GPULlama3.java 支持三种主要后端，可运行在多种硬件：
+
+- **NVIDIA 显卡**：支持 OpenCL 和 PTX 两种后端
+- **Intel 显卡**：包括 Arc 独显和集成的 HD Graphics，支持 OpenCL
+- **Apple Silicon**：M1/M2/M3 可通过 OpenCL 运行（但由于 Apple 已弃用 OpenCL，未来将转向 Metal）
+
+项目运行时可通过命令行参数配置：
+
+```bash
+# 使用 GPU 加速运行（项目 README 示例）
+./llama-tornado --gpu --verbose-init --opencl --model beehive-llama-3.2-1b-instruct-fp16.gguf --prompt "Explain the benefits of GPU acceleration."
+```
+
+该项目依赖 Java 的现代功能，具体包括：
+
+- 要求 **Java 21 及以上版本**，以使用 Vector API 和 Foreign Memory API
+- 支持 **GGUF 模型格式**，方便模型打包与部署
+- 支持 **量化格式**（Q4_0 和 Q8_0），以降低内存占用
+
+GPULlama3.java 基于 [Alfonso Peterssen 的原始 LLama3.java 实现](https://github.com/mukel/llama3.java) 开发，并在此基础引入 TornadoVM GPU 加速功能。正如 [Peterssen 在 Devoxx 2024 大会](https://youtu.be/zgAMxC7lzkc?si=pPqZzeu81ESWjUdx) 展示，他的工作首次实现无需原生依赖即可运行 Llama 模型。TornadoVM 团队进一步将其适配为异构加速架构。
+
+## 3 Java LLM 项目
+
+GPULlama3.java 的发布也使其成为 Java LLM 项目的一员，其他相关项目还包括：
+
+- [JLama](https://github.com/tjake/Jlama)：一个现代 Java LLM 推理引擎，支持分布式部署
+- [Llama3.java](https://github.com/mukel/llama3.java)：专注 CPU 优化的纯 Java 实现
+
+正如 [Quarkus 官方博客关于 Java LLM 的文章](https://quarkus.io/blog/quarkus-jlama/) 所指出的，Java 生态系统正不断拓展其 AI/机器学习能力，使开发者能够无需离开 Java 平台就能构建 LLM 驱动的应用程序。
+
+[TornadoVM](https://www.infoq.com/articles/tornadovm-java-gpu-fpga/) 起源于曼彻斯特大学的研究项目，自 2013 年以来持续发展，目标是让 Java 开发者更容易使用异构计算。该框架目前仍在不断增加后端支持并进行性能优化。
+
+## 4 当前进度
+
+GPULlama3.java 目前处于测试阶段，团队正在持续优化性能并收集基准测试数据。由于 Apple 弃用 OpenCL，当前在 Apple Silicon 上的性能不佳，TornadoVM 团队正在开发 Metal 后端，以提升兼容性并优化 Transformer 操作。
+
+
+
+## 5 总结
+
+总的来说，GPULlama3.java 的发布标志着 Java 生态在 GPU 加速 LLM 推理方面迈出了重要一步。得益于 TornadoVM 的加持，Java 开发者无需跳出熟悉的开发环境，就能享受到 GPU 加速的强大计算能力。尽管目前仍在开发中，但该项目已展示出 Java 在 AI 应用中无限的可能性，特别是在对安全性、可扩展性与可维护性有高要求的企业级场景下。
+
+对想要在 Java 中尝试 GPU 加速 LLM 推理的开发者而言，该项目已经 [开源发布于 GitHub](https://github.com/beehive-lab/GPULlama3.java)，并配有文档和示例，方便快速上手。
\ No newline at end of file
diff --git a/docs/md/AI/llm/inference-engine.md b/docs/md/AI/llm/inference-engine.md
new file mode 100644
index 0000000000..cdcc4b3d10
--- /dev/null
+++ b/docs/md/AI/llm/inference-engine.md
@@ -0,0 +1,184 @@
+# 大模型的“Tomcat”：一文读懂AI推理引擎（Inference Engine)
+
+## 1 推理引擎是啥？
+
+从熟悉的“服务器”说起，想象你用Java写好了一个业务应用，如订单处理服务，打成一个JAR或WAR包。这包能直接运行吗？显然不能。你需要一个“东西”来运行它：
+
+* Java应用，这就是JVM。JVM负责解释执行你的Java字节码，管理内存，处理线程等等
+* Web应用，你可能还需一个**应用服务器**，如Tomcat或WebLogic。它在JVM基础，提供HTTP服务、Servlet容器、连接池等一系列能力，让你的Web代码能对外提供服务
+
+现在我们把主角换成大模型。AI科学家们通过海量“学习资料”（数据）和复杂“学习方法”（训练算法），最终“毕业”得到一个成果——**模型文件**。这个模型文件，好比打包好的`order-service.jar`，包含庞大网络结构和数以百亿计的参数（权重），记录模型学到的所有“知识”。
+
+这个模型文件能直接响应我们的请求，如回答“今天天气怎么样”吗？同样不能。它也需要一个“运行环境”来加载它、管理它、并高效地执行它，最终把结果（答案）输出给我们。
+
+这专门用来运行LLM的“超级应用服务器”，就是——**推理引擎 (Inference Engine)**。
+
+### 小结
+
+把训练好的大模型比作“应用程序包（JAR/WAR）”，推理引擎就是运行这个包的“应用服务器（Tomcat/WebLogic）+ JVM”的组合体。其核心任务，就是让模型**高效、稳定、经济**地对外提供服务。这过程，在AI领域叫“推理（Inference）”。
+
+## 2 没有推理引擎又如何？直接Python跑不行？
+
+Q：我看到很多AI工程师直接用Python+PyTorch/TensorFlow就能加载模型跑，为啥非搞个这么复杂推理引擎？
+
+A：好问题！这就像我们也能用`main`方法，直接`new`一个`HttpServer`启动一个Web服务，但这能直接上生产？你会遇到：
+
+* **性能极差：** 一个请求就把CPU打满了，并发能力几乎为零
+* **资源浪费：** 内存占用巨大，无法精细化管理
+* **功能缺失：** 没有日志、没有监控、没有高可用、没有动态扩缩容
+
+直接用Python框架（如PyTorch）运行模型，就面临类似问题，而且在AI场景下，这些问题会被指数级放大：
+
+### 2.1 “慢”得离谱（高延迟）
+
+**业务场景：** 用户在智能客服里问个问题，等了30秒才看到第一个字蹦出来。
+
+**技术原因：** 大模型的计算量是天文数字。一个请求过来，逐层计算，不经任何优化，就像开着一辆家用小轿车去拉一整火车的货。
+
+### 2.2 “吞”得吓人（低吞吐）
+
+**业务场景：** 数据中心支撑全集团业务，现要上线一个基于大模型的报告自动生成功能。结果发现，系统同时只能服务3、5个人，再多请求就全部卡死排队。
+
+**技术原因：** 模型会独占一块或多块GPU显卡，而GPU显存非常宝贵且昂贵。一个请求就把显存用完了，其他请求只能干等着。这就像一个只有一个窗口的银行，办完一个才能叫下一个。
+
+### 2.3 “贵”得心疼（高成本）
+
+**业务场景：** 为支撑业务，不得不堆砌大量顶级GPU卡（一张A100/H100几十万）。年终汇报时，老板一看电费和硬件采购单，脸都绿了。
+
+**技术原因：** 资源利用率极低。GPU大部分时间可能在空闲等待，或者显存被大量浪费。花了大价钱买来的“法拉利”，却一直在市区里堵着车，油耗还高得惊人。
+
+所以，直接用原生框架跑模型，只适合实验室里做研究、发论文。一旦进入生产，**推理引擎就成了必选项**。
+
+## 3 推理引擎的最佳实践
+
+推理引擎之所以能解决上述问题，是因为它在“运行”模型这件事，做大量优化和工程化工作。
+
+### 3.1 模型“瘦身术” 
+
+就像做Java应用性能优化时，会对代码重构，优化数据结构，减少不必要的对象创建。
+
+#### 3.1.1 量化 (Quantization)
+
+原始的模型参数通常32位浮点数（FP32），精度高但占空间大，计算也慢。量化就是把这些参数“降级”成16位（FP16/BF16）甚至8位整数（INT8）。好比把一个需要用`double`类型存储的数字，发现用`float`甚至`int`就够，精度损失不大，但存储空间和计算速度大大提升。
+
+#### 3.1.2 剪枝 (Pruning)
+
+科学家发现，模型里很多参数（神经元连接）其实“冗余”，对最终结果影响不大。把这些“细枝末节”砍掉，进一步减小模型体积。
+
+#### 3.1.3 最佳实践
+
+场景：你们需要在一个边缘设备或者性能没那么强的服务器上部署一个模型，用于内部的文档识别或人脸识别。
+
+推理引擎咋做：像NVIDIA的**TensorRT-LLM**、开源的**llama.cpp**等推理引擎，都内置了强大的量化工具。你只需要把原始的FP32模型丢给它，配置好量化参数（比如INT8），它就能自动帮你生成一个“瘦身”后的模型。这个新模型体积可能只有原来的1/4，推理速度提升好几倍，而识别准确率可能只下降了不到1%。对于很多业务场景来说，这种性价比极高。
+
+### 3.2 请求“拼车”大法
+
+批处理 (Batching)如数据库操作，我们会把多个单条`INSERT`合并成一个`batch insert`，减少网络和数据库IO开销。
+
+#### 3.2.1 理论概念
+
+GPU是并行计算神器，它最喜欢“干大事”：一次处理一大批相似任务。若一个一个请求喂给它，就像让一个128车道高速公路，每次只跑一辆车，巨大浪费。批处理就是把在短时间内收到的多个用户请求，“攒”成一个大大的批次（Batch），再一次性丢给GPU去计算。
+
+#### 3.2.2 最佳实践
+
+##### ① 挑战
+
+简单的批处理（静态批处理）会引入延迟，须等到凑够一个批次或超时才处理。但用户请求是动态到达的，有的长有的短。
+
+##### ② 推理引擎的进化（Continuous Batching）
+
+假设有3个用户同时请求。
+
+* 用户A：请求生成一篇500字短文
+* 用户B：请求生成一句10个字的诗
+* 用户C：请求生成一份2000字的报告
+
+传统方式： 须等最长的C请求（2000字）全部生成完毕，这个批次才算结束。A和B早就生成完了，但它们的GPU资源必须被占用着，干等着，造成巨大的浪费（显存空泡）。
+
+最佳实践：vLLM引擎的PagedAttention技术。**近两年最火的优化技术了！它的思想借鉴了操作系统的**虚拟内存分页（Paging）。把GPU显存划分成一个个固定大小“块（Block）”，一个请求来了，按需分配块，而非一次性预分配一个巨大的连续空间。当用户B的请求（10个字）生成完毕后，它占用的“块”会立刻被释放，并马上可以分配给新的等待请求。
+
+效果：这种“持续批处理”或“动态批处理”技术，将吞吐量提升**2-4倍**甚至更高！目前业界顶级的开源推理引擎，如**vLLM**、**HuggingFace TGI (Text Generation Inference)**、**TensorRT-LLM**都将此作为核心能力。作为架构师，在选择推理引擎技术栈时，支持Continuous Batching是关键考量点。
+
+### 3.3 计算“流水线”
+
+和Java多线程、微服务拆分异曲同工。一个大任务，一个人干不过来，就拆成小任务，多个人/多个服务一起干。
+
+#### 张量并行
+
+TP，Tensor Parallelism。
+
+一个模型的某层（如一个巨大的矩阵乘法）计算量太大，一张GPU卡都扛不住。就把这大矩阵“切”成几块，分给多张卡，每张卡算自己那一小块，最后再把结果合并。好比用`Fork/Join`框架处理一个大集合。
+
+#### 流水线并行
+
+PP，Pipeline Parallelism。
+
+把模型不同层（Layer）放到不同GPU。如一个模型有80层，1号GPU负责1-20层，2号GPU负责21-40层... 数据像在流水线一样，流过一张张GPU，每张GPU只做自己那部分工作。这完全就是微服务架构的思想，每个GPU就是一个“微服务”。
+
+#### 最佳实践
+
+##### 场景
+
+部署一个像Llama3-70B（700亿参数）巨型模型，单张GPU卡装不下。
+
+##### 推理引擎咋做？
+
+像**DeepSpeed Inference**、**TensorRT-LLM**这类引擎，提供成熟分布式推理能力。无需手动实现复杂的卡间通信（All-Reduce、All-Gather等），只需在配置文件中声明：“我要用4张卡跑这个模型，使用2路张量并行和2路流水线并行”。推理引擎会自动帮你完成模型的切分、部署和协同工作。
+
+这就屏蔽了底层的分布式计算复杂性，让你能像管理一个逻辑上的“大GPU”一样，去管理一个GPU集群。你的关注点，从如何实现并行，变成了如何规划并行策略以达到最佳性价比。
+
+## 4 推理引擎选型
+
+选型通常考虑**稳定性、社区活跃度、技术支持和国产化替代**等。
+
+### 4.1 NVIDIA TensorRT-LLM，重量级选手，性能标杆
+
+NVIDIA官方出品，性能优化到极致。深度绑定NVIDIA硬件生态，能最大化榨干A100/H100等显卡的性能。支持前面提到的所有高级优化。
+
+适用场景：对性能有极致要求，不差钱，且技术栈以NVIDIA为主的场景。追求业界SOTA（State-of-the-Art）性能。
+
+类比：像是Oracle数据库，性能强悍，但有厂商锁定风险。
+
+### 4.2 vLLM，开源新贵，吞吐量之王
+
+凭借其创新的PagedAttention技术，在吞吐量方面表现极其出色，迅速成为开源社区的明星项目。易用性好，Python接口友好。
+
+适用场景：高并发的在线服务场景，如智能客服、AI聊天机器人。希望快速部署，获得极高吞吐量的首选。
+
+类比：像是Nginx，轻量、高效，专注于解决高并发问题。
+
+### 4.3 Hugging Face TGI（Text Generation Inference）社区宠儿，生态完善
+
+来自最大的AI开源社区Hugging Face，对Hugging Face生态中的海量模型支持最好。功能全面，工程化成熟度高，易于部署和监控。
+
+适用场景：需要快速验证和部署多种不同类型的开源大模型。企业内部的AI中台、模型即服务（MaaS）平台的理想底座。
+
+类比：像是Spring Boot，开箱即用，生态整合能力强，能快速构建应用。
+
+### 4.4 国产推理引擎
+
+如TNN, MindSpore Lite等。
+
+**特点：** 国内厂商（如腾讯、华为）主导，更侧重于国产芯片（如昇腾、寒武纪）的适配和优化，在信创和国产化替代方面有天然优势。
+
+**适用场景：** 国企中对软硬件自主可控有强要求的项目。
+
+**类比：** 像是TongWeb、Kingdee，在特定政策和生态环境下是必然选择。
+
+### 4.5 建议
+
+* 初次接触和探索的项目，强烈推荐 **vLLM** 或 **Hugging Face TGI** 入手。都提供Docker镜像，方便在现有数据中心K8s集群拉起一个服务。可以像部署一个普通的Java微服务一样，通过RESTful API或gRPC来调用它，无缝集成到现有的Java技术栈中
+* 核心业务和性能要求极高的场景，可深入研究 **TensorRT-LLM**，它能带来极致的性能回报
+* 务必关注信创和国产化要求，提前了解和测试国产推理框架与硬件结合方案
+
+## 5 总结
+
+跳出繁杂技术细节，站在架构师高度审视：
+
+* **它是一种资源虚拟化和池化技术：** 它将昂贵、稀缺的GPU计算资源，通过批处理、并行计算等技术，池化成一个可以被多个业务方高效共享的服务。这与我们用K8s管理CPU和内存资源，用数据库连接池管理数据库连接，在思想上是完全一致的。
+* **它是一个标准的“中间件”：** 它解决了大模型这个“特殊应用”在生产环境运行时的通用问题（性能、并发、稳定性），将AI研究人员和我们业务开发人员解耦。研究员专注于模型算法，我们专注于业务逻辑和系统集成，大家各司其职。
+* **它是未来AI应用的核心基础设施：** 就像JVM之于Java，K8s之于云原生，推理引擎将成为企业“AI中台”或“MaaS平台”不可或缺的基石。
+
+虽无需直接写CUDA，不直接研究Attention机制，但理解推理引擎的原理、价值和选型策略，将是我们在AI时代保持核心竞争力的关键。它能帮助我们更好地规划企业级的AI基础设施，设计出更健壮、更高效、更具扩展性的AI赋能业务系统。
+
+希望本文帮你把“推理引擎”这个概念，从一个模糊的术语，变成一个你工具箱里清晰的、可以评估和使用的架构组件！
\ No newline at end of file
diff --git a/docs/md/AI/llm/memory-faq.md b/docs/md/AI/llm/memory-faq.md
new file mode 100644
index 0000000000..45168871e7
--- /dev/null
+++ b/docs/md/AI/llm/memory-faq.md
@@ -0,0 +1,133 @@
+# 解锁 ChatGPT 超能力：全新「记忆」功能深度解析
+
+## 0 📌 **注意事项**
+
+由于近期法律变化，某些服务的数据保留政策可能受到影响，详见[官方博客说明](https://openai.com/index/response-to-nyt-data-demands/)。
+
+------
+
+## 1 🆕 免费用户也能享受「记忆」功能升级！
+
+**2025 年 6 月 3 日起**，开始向已登录的 **免费用户**逐步推出「记忆能力」优化升级。现在，**ChatGPT 可参考你最近的对话内容**，从而提供更贴近你的需求、更个性化的回答。
+
+- 免费用户获得的是「轻量版记忆」，能在多轮对话中保留短期上下文信息。
+- Plus 和 Pro 用户的记忆功能则更强大，具备长期记忆能力。
+
+### 1.1 ✅ 启用方式（仅适用于欧洲地区）：
+
+对于在欧盟、英国、瑞士、挪威、冰岛或列支敦士登的免费用户，会看到提示让你启用记忆功能，或可在 **设置 > 个性化 > 记忆 > 引用聊天记录** 中手动开启。
+
+其他地区的免费用户如果已启用记忆功能，将自动获得此次升级。
+
+可随时关闭 ChatGPT 的记忆功能，选择：
+
+- 不引用“保存的记忆”
+- 不引用“聊天记录”
+
+也可用「**临时聊天**」，完全不调用或更新任何记忆内容。
+
+## 2 ☎️ 语音助手体验（仅限美国和加拿大）
+
+拨打 **1-888-GPT-0090**，即可体验 ChatGPT 的语音助手，快速获取关于 ChatGPT 及 OpenAI 产品的帮助。
+
+通话可能会用于改进服务质量。[了解更多](https://help.openai.com/en/articles/11391933-1-888-gpt-0090-ai-voice-help-over-the-phone-experimental)。
+
+## 3 🧠 ChatGPT 的记忆功能说明
+
+ChatGPT 可以在多轮对话中记住有用信息，让回答更贴合你的兴趣和需求。不论是打字、语音、还是图像请求，只要你表达过清晰的偏好，它都有可能被记住。
+
+如你告诉它：“**记住我是素食主义者，推荐食谱时请考虑这一点**”，它将会在未来对话中考虑这个偏好。
+
+你可以随时问它：“你还记得我哪些事情？”来查看当前记忆。[了解更多](https://help.openai.com/en/articles/9237897-chatgpt-search)。
+
+## 4 👤 可随时管理 ChatGPT 的记忆
+
+- 删除单条记忆
+- 清除某些或所有记忆
+- 关闭记忆功能
+- 使用「临时聊天」跳过记忆记录
+
+## 5 🧩 「记忆」功能咋运作？
+
+ChatGPT 有两种记忆设置：
+
+### 5.1 **引用保存的记忆**
+
+- 是你明确告诉 ChatGPT 要记住的内容（如姓名、爱好、饮食偏好）。
+- 类似「自定义说明」，但它是自动更新的，不需你手动管理。
+- 如果你说了某些可能在未来有用的信息，ChatGPT 也可能自动保存为记忆。
+
+> 示例：你说“我住在北京”，下次提问“周末去哪玩？”时，它可能回答“北京的好去处有……”
+>  如果你删除这条记忆，它将不再在新对话中使用，但旧对话不会自动清除相应内容。
+
+### 5.2 **引用聊天记录**
+
+- ChatGPT 会引用近期聊天内容作为上下文，用于改进响应质量。
+- 不同于保存的记忆，这类信息会根据上下文自动更新或遗忘。
+- 如果关闭“引用保存的记忆”，聊天记录引用也会一并关闭。
+
+## 6💡 启/禁用记忆功能
+
+进入 **设置 > 个性化 > 记忆**，可选：
+
+- 仅开启“引用保存的记忆”
+- 仅开启“引用聊天记录”
+- 同时开启或全部关闭
+
+> ⚠️ 关闭“引用保存的记忆”会自动关闭“引用聊天记录”。
+
+## 7 🧽 如何彻底删除某项记忆？
+
+若开启了记忆功能，想**彻底删除某条信息**，请：
+
+1. 删除「保存的记忆」；
+2. 删除包含该信息的聊天记录。
+
+否则，旧聊天中仍可能出现相关内容。
+
+## 8 📁 ChatGPT 记忆容量说明
+
+- **引用聊天记录**没有存储上限。
+- **保存的记忆**有容量限制。你可以在 **设置 > 个性化 > 管理记忆** 中查看用量。
+
+存满时，ChatGPT 不会再保存新记忆，直到你清理空间。
+
+## 9 🧾 ChatGPT 会记住敏感信息吗？
+
+处理记忆时，严肃对待用户隐私和安全：
+
+- 默认不主动记住敏感信息（如健康状况），除非你明确要求。
+- 你始终掌控自己的信息，可以随时查看、删除、关闭记忆功能。
+
+如果你不希望某些内容被记录，请不要在聊天中提及。
+
+## 10 🧠 ChatGPT 会用我的记忆来训练模型吗？
+
+只有在你**启用了“帮助改进模型”**功能时，ChatGPT 才可能使用你分享的内容（包括记忆）来改进模型表现。
+
+- 你可以随时在 **数据控制** 中关闭该功能。
+- **ChatGPT Team、Enterprise 和 Edu 用户的内容默认不会用于训练。**
+
+[了解更多数据使用政策](https://help.openai.com/en/articles/7730893-data-controls-faq)
+
+## 11 🧠 所有模型都支持记忆吗？
+
+不是所有模型都支持记忆功能。截至目前，**o1-pro 模型不支持所有用户的记忆功能**。
+
+## 12 🔍 记忆功能如何影响 ChatGPT 搜索？
+
+当你启用了记忆，并使用 **o3 或 o4-mini 模型**时，ChatGPT 可使用你的记忆或最近聊天内容来优化搜索查询。
+
+如你曾说自己是“**素食主义者，住在旧金山**”，
+
+当你问：
+
+> “我附近有什么餐厅值得推荐？”
+
+ChatGPT 可能会自动转化为：
+
+> “旧金山有哪些适合素食者的餐厅？”
+
+以提供更个性化结果。
+
+[了解更多 ChatGPT 搜索功能](https://help.openai.com/en/articles/9237897-chatgpt-search)
\ No newline at end of file
diff --git a/docs/md/AI/llm/qwen3-embedding.md b/docs/md/AI/llm/qwen3-embedding.md
new file mode 100644
index 0000000000..e4973f4189
--- /dev/null
+++ b/docs/md/AI/llm/qwen3-embedding.md
@@ -0,0 +1,61 @@
+# Qwen3 Embedding：新一代文本表征与排序模型
+
+qwen正式发布 Qwen3 Embedding 系列模型, Qwen 模型家族的新成员。该系列模型专为文本表征、检索与排序任务设计，基于 Qwen3 基础模型进行训练，充分继承了 Qwen3 在多语言文本理解能力方面的优势。在多项基准测试中，Qwen3 Embedding 系列在文本表征和排序任务中展现了卓越的性能。 qwen使用了 Apache 2.0 协议在 Hugging Face 和 ModelScope 上开源了这一系列的文本表征及排序模型，并在 GitHub 公布了技术报告及相关代码。
+
+![img](https://mitalinlp.oss-cn-hangzhou.aliyuncs.com/dingkun/models/qwen-embedding/q3e-mteb-result-0605.png)
+
+**排序模型评测结果**
+
+|               Model                | Param |  MTEB-R   |  CMTEB-R  |  MMTEB-R  |   MLDR    | MTEB-Code | FollowIR  |
+| :--------------------------------: | :---: | :-------: | :-------: | :-------: | :-------: | :-------: | :-------: |
+|      **Qwen3-Embedding-0.6B**      | 0.6B  |   61.82   |   71.02   |   64.64   |   50.26   |   75.41   |   5.09    |
+| Jina-multilingual-reranker-v2-base | 0.3B  |   58.22   |   63.37   |   63.73   |   39.66   |   58.98   |   -0.68   |
+|   gte-multilingual-reranker-base   | 0.3B  |   59.51   |   74.08   |   59.44   |   66.33   |   54.18   |   -1.64   |
+|         BGE-reranker-v2-m3         | 0.6B  |   57.03   |   72.16   |   58.36   |   59.51   |   41.38   |   -0.01   |
+|      **Qwen3-Reranker-0.6B**       | 0.6B  |   65.80   |   71.31   |   66.36   |   67.28   |   73.42   |   5.41    |
+|       **Qwen3-Reranker-4B**        |  4B   | **69.76** |   75.94   |   72.74   |   69.97   |   81.20   | **14.84** |
+|       **Qwen3-Reranker-8B**        |  8B   |   69.02   | **77.45** | **72.94** | **70.19** | **81.22** |   8.05    |
+
+> **Note**:
+>
+> - q'wen使用MTEB(eng, v2), MTEB(cmn, v1), MTEB (Multilingual) 以及MTEB (Code)中的检索数据集进行测试, 分别记作MTEB-R, CMTEB-R, MMTEB-R, MTEB-Code.
+> - 排序结果基于[Qwen3-Embedding-0.6B](https://huggingface.co/Qwen/Qwen3-Embedding-0.6B)的top-100向量召回结果进行排序.
+
+**主要特点**:
+
+**卓越的泛化性**: Qwen3 Embedding 系列在多个下游任务评估中达到行业领先水平。其中，8B 参数规模的Embedding模型在MTEB多语言Leaderboard榜单中位列第一（截至 2025 年 6 月 5 日，得分 **70.58**），性能超越众多商业 API 服务。此外，该系列的排序模型在各类文本检索场景中表现出色，显著提升了搜索结果的相关性。
+
+**灵活的模型架构**: Qwen3 Embedding 系列提供从 0.6B 到 8B 参数规模的 3 种模型配置，以满足不同场景下的性能与效率需求。开发者可以灵活组合表征与排序模块，实现功能扩展。此外，模型支持以下定制化特性：1) 表征维度自定义：允许用户根据实际需求调整表征维度，有效降低应用成本；2) 指令适配优化：支持用户自定义指令模板，以提升特定任务、语言或场景下的性能表现。
+
+**全面的多语言支持**: Qwen3 Embedding 系列支持超过 100 种语言，涵盖主流自然语言及多种编程语言。该系列模型具备强大的多语言、跨语言及代码检索能力，能够有效应对多语言场景下的数据处理需求。
+
+## 模型总览
+
+|     Model Type     |        Models        | Size | Layers | Sequence Length | Embedding Dimension | MRL Support | Instruction Aware |
+| :----------------: | :------------------: | :--: | :----: | :-------------: | :-----------------: | :---------: | :---------------: |
+| **Text Embedding** | Qwen3-Embedding-0.6B | 0.6B |   28   |       32K       |        1024         |     Yes     |        Yes        |
+|                    |  Qwen3-Embedding-4B  |  4B  |   36   |       32K       |        2560         |     Yes     |        Yes        |
+|                    |  Qwen3-Embedding-8B  |  8B  |   36   |       32K       |        4096         |     Yes     |        Yes        |
+| **Text Reranking** | Qwen3-Reranker-0.6B  | 0.6B |   28   |       32K       |          -          |      -      |        Yes        |
+|                    |  Qwen3-Reranker-4B   |  4B  |   36   |       32K       |          -          |      -      |        Yes        |
+|                    |  Qwen3-Reranker-8B   |  8B  |   36   |       32K       |          -          |      -      |        Yes        |
+
+注：`MRL Support` 表示 Embedding 模型是否支持最终向量的自定义维度。`Instruction Aware` 表示 Embedding 或 Reranking 模型是否支持根据不同任务定制输入指令。
+
+## 模型架构
+
+基于 Qwen3 基础模型， qwen的 Embedding 模型和 Reranking 模型分别采用了双塔结构和单塔结构的设计。通过 LoRA 微调， qwen最大限度地保留并继承了基础模型的文本理解能力。具体实现如下：1) Embedding 模型接收单段文本作为输入，取模型最后一层`[EOS]`标记对应的隐藏状态向量，作为输入文本的语义表示；2) Reranking 模型则接收文本对（例如用户查询与候选文档）作为输入，利用单塔结构计算并输出两个文本的相关性得分。
+
+![img](https://mitalinlp.oss-cn-hangzhou.aliyuncs.com/dingkun/models/qwen-embedding/q3e-model-arc.png)
+
+## 模型训练
+
+Qwen3 Embedding 系列模型的训练继承了 GTE-Qwen 系列的多阶段训练范式，但针对具体应用场景进行了深度优化。在 Embedding 模型的训练过程中， qwen采用三阶段训练架构：第一阶段通过超大规模弱监督数据进行对比学习预训练；第二阶段基于高质量标注数据进行监督训练；最终通过模型融合策略融合多个候选模型，以提升整体性能。这种分阶段训练机制有效平衡了模型的泛化能力与任务适配性。
+
+在 Reranking 模型的训练中，基于实验验证结果， qwen直接采用高质量标注数据进行监督训练，以提升训练效率。特别需要说明的是，在 Embedding 模型的第一阶段弱监督训练中， qwen构建了多任务适配的 Prompt 体系，利用 Qwen3 基础模型的文本生成能力， qwen针对不同任务类型和语言特性，动态生成了一系列弱监督文本对，突破了传统方法依赖社区论坛或开源数据筛选获取弱监督文本对的局限性，实现了大规模弱监督数据的高效生成。
+
+![](https://mitalinlp.oss-cn-hangzhou.aliyuncs.com/dingkun/models/qwen-embedding/q3e-train-pipeline.png)
+
+## 未来发展
+
+Qwen3 Embedding 系列模型是一个新的起点，依托于 Qwen 基础模型的持续优化,  qwen将继续提升文本表征与排序模型的训练效率，以增强模型在实际场景中的部署性能。此外， qwen还计划拓展多模态表征体系，构建跨模态语义理解能力。 qwen期待更多开发者基于 Qwen3 Embedding 系列探索更广泛的应用场景，推动模型在不同业务场景中的深入应用。
\ No newline at end of file
diff --git a/docs/md/MQTT/avoid-bare-parsefrom-mqtt-protobuf-consumption.md b/docs/md/MQTT/avoid-bare-parsefrom-mqtt-protobuf-consumption.md
new file mode 100644
index 0000000000..6329eaeae8
--- /dev/null
+++ b/docs/md/MQTT/avoid-bare-parsefrom-mqtt-protobuf-consumption.md
@@ -0,0 +1,322 @@
+# 别再裸写 parseFrom() 了！这才是 MQTT + Protobuf 消费的正确姿势
+
+## 0 前言
+
+很多刚接触这个技术栈的同学，可能会觉得有点绕。MQTT 负责传输，Protobuf 负责定义数据结构，听起来是天作之合，但具体到代码层，咋写最“哇塞”？本文以车联网（V2X）场景为例，把这个事儿聊透，让你不仅知其然，更知其所以然。
+
+咱们的案例原型就是这段非常
+
+## 1 典型的 `.proto` 文件
+
+```protobuf
+syntax = "proto3";
+option java_multiple_files = true;
+option java_package = "cn.javaedge.v2x.protocol";
+package cn.javaedge.v2x.pb;
+
+enum Message_Type {
+    UKNOWN_MSG = 0;
+    OBJECT_MSG = 1;
+    EVENT_MSG = 2;
+    // ... 其他消息类型
+    CAM_MSG = 11;
+    DENM_MSG = 12;
+}
+
+// 消息体定义，如车辆消息
+message VehicleMessage {
+    string vehicle_id = 1;
+    double longitude = 2;
+    double latitude = 3;
+    float speed = 4;
+    // ... 其他车辆信息
+}
+```
+
+实际业务中，通常会有一个统一的“信封”消息，里面包含消息类型和真正的业务数据包。
+
+需求明确：Java服务作MQTT客户端，订阅某Topic，源源不断收到二进制数据。这些数据就是用上面这 `.proto` 文件定义的 `VehicleMessage` 序列化后的结果。我们的任务就是把它**高效、健壮**地解码出来。
+
+## 2 核心思路：从“能跑就行”到“最佳实践”
+
+很多同学第一反应直接在 MQTT 的 `messageArrived` 回调方法写一堆 `try-catch`，再调用 Protobuf 的 `parseFrom()` 方法：
+
+```java
+// 伪代码：一个“能跑就行”的例子
+public void messageArrived(String topic, MqttMessage message) {
+    try {
+        byte[] payload = message.getPayload();
+        VehicleMessage vehicleMsg = VehicleMessage.parseFrom(payload);
+        // ... 处理 vehicleMsg ...
+        System.out.println("收到车辆消息: " + vehicleMsg.getVehicleId());
+    } catch (InvalidProtocolBufferException e) {
+        // ... 打印个日志 ...
+        e.printStackTrace();
+    }
+}
+```
+
+这段代码能工作吗？当然能。但在高并发、要求高可用、业务逻辑复杂的生产环境中，这远远不够。它就像一辆只有发动机和轮子的裸车，能跑，但一阵风雨就可能让它趴窝。
+
+最佳实践是啥？，建立一套**分层、解耦、易于维护和扩展**的处理流程。
+
+## 3 最佳实践：构建稳如泰山的 Protobuf 解析层
+
+让我们把这个过程拆解成几个关键步骤，并逐一优化。
+
+### 3.1 Protobuf代码生成与依赖管理
+
+构建阶段，看似准备工作，却是保证后续一切顺利的基石。
+
+#### 使用 Maven插件自动生成代码
+
+别手动执行 `protoc` 命令，再把生成的 `.java` 文件拷贝到项目里。这是“上古时期”做法。现代化的构建工具能完美解决这个问题。
+
+Maven示例：
+
+```xml
+<dependencies>
+    <dependency>
+        <groupId>com.google.protobuf</groupId>
+        <artifactId>protobuf-java</artifactId>
+        <version>3.25.3</version> </dependency>
+    <dependency>
+        <groupId>org.eclipse.paho</groupId>
+        <artifactId>org.eclipse.paho.client.mqttv3</artifactId>
+        <version>1.2.5</version>
+    </dependency>
+</dependencies>
+
+<build>
+    <plugins>
+        <plugin>
+            <groupId>org.xolstice.maven.plugins</groupId>
+            <artifactId>protobuf-maven-plugin</artifactId>
+            <version>0.6.1</version>
+            <configuration>
+                <protocArtifact>com.google.protobuf:protoc:3.25.3:exe:${os.detected.classifier}</protocArtifact>
+                <protoSourceRoot>${project.basedir}/src/main/proto</protoSourceRoot>
+                <outputDirectory>${project.build.directory}/generated-sources/protobuf/java</outputDirectory>
+                <clearOutputDirectory>false</clearOutputDirectory>
+            </configuration>
+            <executions>
+                <execution>
+                    <goals>
+                        <goal>compile</goal>
+                        <goal>test-compile</goal>
+                    </goals>
+                </execution>
+            </executions>
+        </plugin>
+    </plugins>
+</build>
+```
+
+#### 这样做的好处
+
+1.  **自动化**：每次构建项目时，都会自动检查 `.proto` 文件是否有更新，并重新生成 Java 类
+2.  **版本一致性**：确保 `protoc` 编译器版本和 `protobuf-java` 运行时库版本的一致，避免因版本不匹配导致的各种诡异错误
+3.  **IDE 友好**：IDEA能很好识别这些生成的源代码，提供代码补全和导航
+
+### 3.2 定义清晰的解析器接口
+
+设计模式的应用，直接在 MQTT 回调里写解析逻辑，违反**单一职责原则**。MQTT 客户端的核心职责是网络通信，不应关心消息体的具体格式。
+
+应将解析逻辑抽象出来：
+
+```java
+// 定义一个通用的反序列化器接口
+public interface MessageDeserializer<T> {
+    /**
+     * 将字节数组反序列化为指定类型的对象
+     * @param data 原始字节数据
+     * @return 反序列化后的对象
+     * @throws DeserializationException 如果解析失败
+     */
+    T deserialize(byte[] data) throws DeserializationException;
+}
+
+// 定义一个自定义的解析异常
+public class DeserializationException extends RuntimeException {
+    public DeserializationException(String message, Throwable cause) {
+        super(message, cause);
+    }
+}
+```
+
+然后，为我们的 `VehicleMessage` 实现该接口：
+
+```java
+import com.google.protobuf.InvalidProtocolBufferException;
+import cn.javaedge.v2x.pb.VehicleMessage; // 自动生成的类
+
+public class VehicleMessageDeserializer implements MessageDeserializer<VehicleMessage> {
+
+    @Override
+    public VehicleMessage deserialize(byte[] data) throws DeserializationException {
+        if (data == null || data.length == 0) {
+            // 对于空消息体，根据业务决定是抛异常还是返回 null/默认实例
+            throw new DeserializationException("Payload is empty.", null);
+        }
+        try {
+            // 核心解析逻辑
+            return VehicleMessage.parseFrom(data);
+        } catch (InvalidProtocolBufferException e) {
+            // 关键：将底层具体的异常，包装成我们自己的业务异常
+            // 这样上层调用者就不需要关心是 Protobuf 还是 JSON 或是其他格式的错误
+            throw new DeserializationException("Failed to parse VehicleMessage from protobuf", e);
+        }
+    }
+}
+```
+
+#### 好处
+
+1.  **解耦**：MQTT 消费者代码与 Protobuf 解析逻辑完全分离。未来如果想把数据格式从 Protobuf 换成 JSON，只需要换一个 `MessageDeserializer` 的实现类即可，消费者代码一行都不用改。
+2.  **职责单一**：`VehicleMessageDeserializer` 只干一件事：解析 `VehicleMessage`。代码清晰，易于测试。
+3.  **统一异常处理**：通过自定义的 `DeserializationException`，我们将底层的 `InvalidProtocolBufferException` 进行了封装。上层代码只需要捕获 `DeserializationException`，大大简化了错误处理逻辑。
+
+### 3.3 在 MQTT 消费者中优雅地使用解析器
+
+组合与分发。现在，MQTT消费者变得清爽：
+
+```java
+public class MqttConsumerService {
+
+    private final MessageDeserializer<VehicleMessage> vehicleMessageDeserializer;
+    private final BusinessLogicHandler businessLogicHandler; // 负责处理业务逻辑的服务
+
+    // 使用依赖注入来管理依赖关系
+    public MqttConsumerService(BusinessLogicHandler businessLogicHandler) {
+        this.vehicleMessageDeserializer = new VehicleMessageDeserializer(); // 在真实项目中会通过 IoC 容器注入
+        this.businessLogicHandler = businessLogicHandler;
+    }
+
+    // MQTT 回调方法
+    public void onMessageReceived(String topic, byte[] payload) {
+        try {
+            // 1. 调用解析器进行反序列化
+            VehicleMessage vehicleMsg = vehicleMessageDeserializer.deserialize(payload);
+
+            // 2. 将解析后的强类型对象传递给业务逻辑层
+            businessLogicHandler.processVehicleMessage(vehicleMsg);
+
+        } catch (DeserializationException e) {
+            // 集中处理解析失败的情况
+            // 比如：记录错误日志、发送到死信队列(DLQ)等待人工处理
+            log.error("Failed to deserialize message from topic [{}].", topic, e);
+            // sendToDeadLetterQueue(topic, payload, e.getMessage());
+        } catch (Exception e) {
+            // 捕获其他未知异常，防止消费者线程挂掉
+            log.error("An unexpected error occurred while processing message from topic [{}].", topic, e);
+        }
+    }
+}
+```
+
+#### 架构精髓
+
+##### ① 依赖注入 (DI)
+
+通过构造函数注入依赖（解析器和业务处理器），而不是在方法内部 `new` 对象。这使得整个服务非常容易进行单元测试。我们可以轻易地 mock `MessageDeserializer` 来测试 `MqttConsumerService` 的逻辑，而不需要真实的 Protobuf 数据。
+
+##### ② 关注点分离 (SoC)
+
+* `MqttConsumerService`：负责从 MQTT 接收字节流，协调解析和业务处理的流程，并统一处理异常。
+* `VehicleMessageDeserializer`：负责将字节流转换为 `VehicleMessage` 对象。
+* `BusinessLogicHandler`：负责拿到 `VehicleMessage` 对象后所有的业务计算和处理。
+
+##### ③ 健壮的异常处理
+
+* **区分已知和未知异常**：我们明确捕获 `DeserializationException`，这是“已知”的解析失败，通常意味着消息格式有问题。对于这种消息，最佳实践是**隔离**它，比如发送到“死信队列”，避免它反复阻塞正常消息的处理。
+* **捕获顶级 `Exception`**：这是一个保护性措施，确保任何意想不到的错误（比如空指针、业务逻辑层的运行时异常）都不会导致整个 MQTT 消费者线程崩溃。
+
+## 4 进阶：应对真实世界的复杂性
+
+上面的架构已很优秀，但更复杂场景下，还需考虑更多。
+
+### 4.1 多消息类型处理 (Message Dispatching)
+
+通常一个 MQTT Topic 不会只有一种消息类型。还记得我们 `.proto` 文件里的 `Message_Type` 枚举吗？这正是用于区分不同消息的。
+
+实际的 Protobuf 结构通常是这样的“信封模式” (Envelope Pattern)：
+
+```proto
+message UniversalMessage {
+    Message_Type type = 1;
+    google.protobuf.Any payload = 2; // 使用 Any 来包装任意类型的消息
+}
+```
+
+`google.protobuf.Any` 是 Protobuf 的一个标准类型，可以包含任意一种 Protobuf 消息。
+
+消费者的逻辑就需要升级为一个**分发器 (Dispatcher)**：
+
+```java
+public class UniversalMessageDispatcher {
+
+    // 一个注册表，存储消息类型到具体解析器的映射
+    private final Map<String, MessageDeserializer<?>> deserializerRegistry = new HashMap<>();
+
+    public UniversalMessageDispatcher() {
+        // 在构造时注册所有已知的解析器
+        deserializerRegistry.put(VehicleMessage.getDescriptor().getFullName(), new VehicleMessageDeserializer());
+        // ... 注册其他消息类型的解析器
+        // deserializerRegistry.put(EventMessage.getDescriptor().getFullName(), new EventMessageDeserializer());
+    }
+
+    public void dispatch(byte[] payload) {
+        try {
+            UniversalMessage envelope = UniversalMessage.parseFrom(payload);
+            Any messagePayload = envelope.getPayload();
+            String messageTypeUrl = messagePayload.getTypeUrl(); // e.g., "type.googleapis.com/cn.javaedge.v2x.pb.VehicleMessage"
+            String messageFullName = extractFullNameFromUrl(messageTypeUrl);
+
+            MessageDeserializer<?> deserializer = deserializerRegistry.get(messageFullName);
+            if (deserializer != null) {
+                // 使用 Any 的 unpack 方法来安全地解包
+                if (messageFullName.equals(VehicleMessage.getDescriptor().getFullName())) {
+                    VehicleMessage vehicleMsg = messagePayload.unpack(VehicleMessage.class);
+                    // ... 交给对应的业务处理器 ...
+                } else if (...) {
+                    // ... 处理其他消息类型 ...
+                }
+            } else {
+                log.warn("No deserializer found for message type: {}", messageFullName);
+            }
+        } catch (InvalidProtocolBufferException e) {
+            throw new DeserializationException("Failed to parse UniversalMessage envelope", e);
+        }
+    }
+
+    private String extractFullNameFromUrl(String url) {
+        return url.substring(url.lastIndexOf('/') + 1);
+    }
+}
+```
+
+这种基于“注册表”和 `Any` 类型的分发模式，是处理多消息类型时**扩展性最好**的方案。
+
+### 4.2 性能考量：对象池与零拷贝
+
+高吞吐量场景下（如每秒处理成千上万条消息），频繁创建和销毁 `VehicleMessage` 对象会给 GC 带来巨大压力。
+
+#### 对象池技术
+
+可以使用像 Apache Commons Pool2 这样的库，来复用 `VehicleMessage.Builder` 对象。解析时，从池中获取一个 Builder，用 `mergeFrom()` 方法填充数据，构建出 `VehicleMessage` 对象，使用完毕后再将 Builder 清理并归还到池中。
+
+#### 零拷贝
+
+Protobuf 的 `ByteString` 类型在内部做很多优化，可实现对底层 `byte[]` 的“零拷贝”引用。在传递数据时，尽量传递 `ByteString` 而非 `byte[]`，可减少不必要的内存复制。
+
+## 5 总结
+
+从一个简单的 `parseFrom()` 调用，逐步构建一套企业级 MQTT-Protobuf 消费方案。
+
+1.  **构建自动化**：Maven插件管理 Protobuf 代码生成，告别刀耕火种
+2.  **设计模式先行**：定义 `MessageDeserializer` 接口，实现**策略模式**，解耦【解析】与【消费】逻辑
+3.  **分层与解耦**：将流程清晰划分为**网络接入层** (MQTT Client)、**反序列化层** (Deserializer) 和**业务逻辑层** (Handler)，职责分明，易维护
+4.  **健壮的错误处理**：封装自定义异常，并设计了对解析失败消息的隔离机制（如死信队列），保证系统的韧性
+5.  **面向未来的扩展性**：引入“信封模式”和“分发器”，从容应对未来不断增加的新消息类型
+
+**优秀的代码不仅是让机器读懂，更是让同事（及半年后的自己）轻松读懂**。核心思想即通过**抽象、解耦和分层**，来管理软件的复杂性。
\ No newline at end of file
diff --git "a/docs/md/mqtt/MQTT\344\270\216Kafka\345\234\250\347\211\251\350\201\224\347\275\221\346\266\210\346\201\257\344\270\216\346\265\201\346\225\260\346\215\256\351\233\206\346\210\220\345\256\236\350\267\265.md" b/docs/md/MQTT/mqtt-kafka-iot-message-streaming-integration.md
similarity index 100%
rename from "docs/md/mqtt/MQTT\344\270\216Kafka\345\234\250\347\211\251\350\201\224\347\275\221\346\266\210\346\201\257\344\270\216\346\265\201\346\225\260\346\215\256\351\233\206\346\210\220\345\256\236\350\267\265.md"
rename to docs/md/MQTT/mqtt-kafka-iot-message-streaming-integration.md
diff --git "a/docs/md/MQTT/07-MQTT\345\217\221\345\270\203\350\256\242\351\230\205\346\250\241\345\274\217\344\273\213\347\273\215.md" b/docs/md/MQTT/mqtt-publish-subscribe-intro.md
similarity index 100%
rename from "docs/md/MQTT/07-MQTT\345\217\221\345\270\203\350\256\242\351\230\205\346\250\241\345\274\217\344\273\213\347\273\215.md"
rename to docs/md/MQTT/mqtt-publish-subscribe-intro.md
diff --git "a/docs/md/chain/\351\232\220\347\247\201\350\256\241\347\256\227\346\212\200\346\234\257\345\216\237\347\220\206.md" "b/docs/md/chain/\351\232\220\347\247\201\350\256\241\347\256\227\346\212\200\346\234\257\345\216\237\347\220\206.md"
new file mode 100644
index 0000000000..356507e66f
--- /dev/null
+++ "b/docs/md/chain/\351\232\220\347\247\201\350\256\241\347\256\227\346\212\200\346\234\257\345\216\237\347\220\206.md"
@@ -0,0 +1,259 @@
+# 隐私计算技术原理
+
+## 0 隐私计算核心原理概述
+
+隐私计算目标是让各方在**数据“可用不可见”**的前提下进行联合计算。常见技术包括：
+
+## 1 联合建模
+
+Joint Modeling。
+
+### 1.1 定义
+
+多个参与方共同训练一个机器学习模型，但各自的数据不离开本地。在满足各参与方的合规政策和数据价值保护的需求下，实现模型迭代和更新的服务。
+
+### 1.2 类比理解
+
+就像几个医生一起研究某种疾病的治疗方案，但每位医生只分享“经验总结”（如模型参数），而不透露具体的病人信息。
+
+### 1.3 实际应用
+
+- 多家保险公司想共同训练一个新能源汽车保险风险评估模型，但每家都只能用自己的客户数据
+- 让大家共享模型能力，而不把原始数据给别人
+
+### 1.4 技术实现
+
+联邦学习或多方安全计算。
+
+## 2 可信执行环境
+
+Trusted Execution Environment，TEE。
+
+### 2.1 定义
+
+利用硬件级隔离技术（如Intel SGX、ARM TrustZone），在一个“沙盒”中执行敏感代码，外界无法窥探其中的数据。
+
+### 1.2 类比理解
+
+就像在金库处理现金，只有特定人员能进去操作，外面的人看不见也摸不到。
+
+### 1.3 实际应用
+
+- 在 TEE 中运行保险公司的评分算法，即使平台管理员也无法看到内部逻辑和数据
+- 适合对性能要求高、但又必须保证安全的场景
+
+### 1.4 技术实现
+
+依赖 CPU 的安全扩展指令集，如Intel SGX。
+
+利用硬件隔离确保计算过程安全可证明。在TEE中，数据和算法在硬件隔离区内处理，即使操作系统被攻破，数据仍受保护。
+
+## 3 同态加密（HE）
+
+Homomorphic Encryption。
+
+### 3.1 定义
+
+允许在加密数据上直接进行运算，结果解密后与明文运算一致。
+
+### 3.2 类比理解
+
+你把一封信锁进密码箱里，送到朋友那里，他可以在不解锁的情况下帮你算里面的内容总和，再寄回来你打开看结果。
+
+### 3.3 实际应用
+
+- 对新能源车的电池评分进行加密传输，接收方可以直接在这个加密数据上做评分计算，无需先解密
+- 适合需要完全隐藏数据内容的场景
+
+### 3.4 技术实现方式
+
+使用复杂的数学结构（如 Ring-LWE、CKKS 方案），Java 中可调用 C++ 库封装接口（如 Microsoft SEAL）。
+
+对数据进行加密后，在密文上直接运算，最后解密得到结果。HE 允许对敏感数据进行复杂计算，但性能开销大。
+
+## 4 差分隐私（DP）
+
+Differential Privacy。通过加入噪声保护单个记录隐私，常用于数据发布和统计分析。DP 与上述技术常结合使用，进一步降低泄露风险。
+
+以上技术可单独或混合使用。例如如锘崴所述，隐私计算通过 MPC、HE、FL（软件层）和 TEE（硬件层）等多种路径协同工作。车联网场景中，即可在**汽车本地或边缘节点**进行模型训练和推理，而无需上传车主敏感数据，并在跨机构聚合时使用 MPC/HE 等加密技术，兼顾数据隐私与高效建模。
+
+### 定义
+
+在统计数据时加入随机噪声，使得输出结果对任意个体的存在与否不敏感，从而保护隐私。
+
+### 类比理解
+
+你问一群人平均工资，每个人回答前偷偷给自己工资加上一个随机数，这样最终的平均值还是大致准确，但没人知道谁说了实话。
+
+### 实际应用
+
+- 统计新能源车用户的驾驶习惯（如急刹车频率），但不希望任何人被识别出来。
+- 常用于数据发布、统计分析。
+
+### 技术实现
+
+- 使用拉普拉斯噪声、指数机制等
+- 可以集成到 SQL 查询引擎或机器学习框架中
+
+## 5 隐匿查询（PIR）
+
+Private Information Retrieval。
+
+### 5.1 定义
+
+用户可从DB查询某数据，但DB不知用户查了哪条。
+
+### 5.2 类比理解
+
+你在图书馆借书，但图书管理员不知道你借的哪本。
+
+### 5.3 实际应用
+
+- 用户想查某辆车的历史维修记录，但不想让数据中心知道是哪辆车。
+- 适用于保护用户行为隐私的场景。
+
+### 5.4 技术实现
+
+使用加密查询协议，部分基于同态加密。
+
+## 6 隐私求交（PSI）
+
+Private Set Intersection。
+
+### 定义
+
+两个集合找出交集，但彼此不知对方的非交集元素。
+
+### 类比理解
+
+两个人想知道有没有共同的朋友，但不想告诉对方自己所有的朋友名单。
+
+### 实际应用
+
+- 两家公司想找出共同客户，但不能交换全部客户名单
+- 保险公司和车企想找出哪些用户既是投保人又是车主
+
+### 技术实现
+
+使用Oblivious Transfer（OT）、哈希+加密等方法。
+
+## 7 多方安全分析（MSA）
+
+Secure Multi-Party Analysis。
+
+### 定义
+
+多个参与方在不共享原始数据的前提下，完成数据分析任务（如统计、回归、聚类等）。
+
+### 类比理解
+
+就像几个公司想统计他们员工的平均薪资，但每个公司只想贡献“汇总后的统计量”。
+
+### 💡 实际应用：
+
+- 多个城市想比较新能源汽车的充电频率，但不希望暴露各自城市的详细数据。
+- 医疗机构之间想共享疾病分布情况，但不能泄露患者身份。
+
+### 技术实现方式
+
+结合 MPC、HE、DP 等多种技术。
+
+## 8 多方安全计算（MPC）必备
+
+Secure Multi-Party Computation，MPC，在参与方不共享各自数据且没有可信第三方的情况下安全地计算约定函数的技术和系统。
+
+![](https://p.ipic.vip/h2aerh.png)
+
+各方将数据加密或秘密共享，在加密状态下共同计算函数，最终只输出结果。
+
+参与方不泄露原始数据，通过加密状态协同得到计算结果。
+
+多方将数据加密分片，分别计算，最终合成结果，任何单方看不到完整数据。
+
+### 类比理解
+
+就像几个人在黑暗中同时写下一个数字，通过某种机制知道这些数加起来多少，但不知道别人写了啥。
+
+### 应用
+
+- 几个公司想知道他们的用户有多少是重叠的，但不想暴露各自的用户列表（隐私求交 PSI 就是它的一个子集）。
+- 银行之间想统计总贷款额，但不想告诉对方自己的具体数据。
+
+### 技术实现
+
+设计特殊加密算法（如 Yao’s Garbled Circuits、秘密共享等）和协议，基于密码学原理实现在无可信第三方情况下，多个参与方将明文形式的数据加密后或转化后再提供给其他方，任一参与方都无法接触到其他方的明文形式的数据，从而保证各方数据的安全。
+
+安全多方计算的基本安全算子包括同态加密、秘密分享、混淆电路、不经意传输、零知识证明、同态承诺等。
+
+![img](https://www.primihub.com/img/anquanjisuan.4586f50f.png)
+
+## 9 联邦学习（FL）必备
+
+Federated Learning。
+
+### 定义
+
+一种分布式机器学习方法，允许多个参与方协同训练模型，但不共享原始数据。
+
+各方本地训练模型，将加密参数汇聚更新，实现模型共享。“数据不出门，算法满地跑”。可结合安全聚合、MPC 等增强隐私。像是分布式机器学习的参数交换，避免数据直接暴露。
+
+可让一组组织或同一组织内的群组以协作和迭代的方式，训练和改进共享的全局机器学习模型。参与方通过安全的算法协议进行联合机器学习，可以在各方数据不出本地的情况下联合多方数据源建模和提供模型推理与预测服务。
+
+在FL框架下，各参与方只交换密文形式的中间计算结果或转化结果，不交换数据，达到数据可用不可见。
+
+#### 联邦模型一
+
+![](https://p.ipic.vip/4n86te.png)
+
+#### 联邦模型二
+
+![](https://p.ipic.vip/v3wrf4.png)
+
+### 类比理解
+
+像一群学生一起做题，每个人都在自己的练习本上算，最后只告诉老师答案的“趋势”，老师再统一调整教学内容。
+
+### 实际应用
+
+新能源车企与保险公司合作：车企提供车辆运行数据（如电池状态、行驶轨迹），保险公司提供理赔数据，双方都不交出原始数据，但可以共同训练一个更准确的风险预测模型。
+
+### 技术实现
+
+- 使用加密梯度聚合（如同态加密或差分隐私）
+- 支持横向/纵向联邦学习
+
+##### 横/纵向联邦学习
+
+| 类型                          | 特点                             | 示例                                           |
+| ----------------------------- | -------------------------------- | ---------------------------------------------- |
+| 横向联邦学习（Horizontal FL） | 参与方拥有相同的特征，不同的样本 | 多家银行都有贷款记录，但各自有不同的客户       |
+| 纵向联邦学习（Vertical FL）   | 参与方拥有相同的样本，不同的特征 | 同一家客户，银行有收入数据，保险公司有健康数据 |
+
+## 选型建议
+
+### 开源 V.S 商业
+
+开源项目隐语免费且可深度定制，适合研发团队评估或基础研究。但需要投入部署运维成本。
+
+商业平台（蚂蚁、锘崴、腾讯等）提供了更完善的产品支持和界面，适合快速落地或生产环境，但往往费用较高，且对算法改动有限制。
+
+### 部署环境
+
+若需要在**本地或私有云**部署，应关注系统对 Docker/Kubernetes 的支持、平台稳定性和可扩展性。隐语支持容器化部署。若更倾向**云服务**，可直接使用蚂蚁或腾讯提供的 PaaS，不必自行搭建环境。
+
+### 自定义算法和数据控制
+
+对于需要上传自研算法的需求，应选择支持“算法沙箱”或脚本扩展的平台。
+
+- PrimiHub、FATE、Huakong 清交等支持用户自定义模型和协议扩展
+- 商业云产品通常只提供固定算子，也可通过SDK接口进行二次开发
+
+### 性能与安全要求
+
+- 数据量巨大或安全级别要求极高，可考虑软硬结合方案（锘崴、清交）或专用加速卡
+- 普通业务场景，纯软件方案（开源或云服务）即可满足需求
+
+综上，根据团队技术栈和业务场景平衡可控性与易用性：
+
+- **测试评估阶段**可选择开源平台快速搭建原型；
+- **生产应用阶段**则可视实际情况选用商业平台或混合方案
\ No newline at end of file
diff --git a/docs/md/design/open-close-principle.md b/docs/md/design/open-close-principle.md
new file mode 100644
index 0000000000..2b5c52a02a
--- /dev/null
+++ b/docs/md/design/open-close-principle.md
@@ -0,0 +1,349 @@
+# 开闭原则（Open Close Principle，OCP）
+
+## 1 定义
+
+来个需求就改一次代码，理所当然？反正修改也易，再CV一份，也不费脑。但每人每次改点，日积月累，再来新需求，后人改动量就大了。每人都无辜，都只是简单修改一点。但最终导致接盘侠无法维护，直接推翻老系统，写新系统（也算是创造就业机会了）。
+
+既然“修改”这么多问题，不修改行吗？就得精通OCP。
+
+`Software entities like classes,modules and functions should be open for extension but closed for modifications`
+一个软件实体如类、模块和方法应对扩展开放，对修改关闭。这是Bertrand Meyer在《面向对象软件构造》（Object-Oriented Software Construction）提出，它给软件设计提出极高要求：不修改代码，对扩展开放。可问题：
+
+- 开放啥？
+- 对修改关闭，咋关闭？
+
+### 1.1 不修改代码，还能写需求？
+
+扩展，即新需求用新代码实现。OCP向我们描述的是结果：可不修改代码，仅靠扩展就完成新功能。
+
+#### 前提
+
+在软件内部留好扩展点，这就需要设计（高级工程师的素质了）。每个扩展点都是个需要设计的模型。
+
+### 1.2 用抽象构建框架，用实现扩展细节
+
+一个软件实体应通过扩展实现变化，而不是通过修改已有代码实现变化。它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。
+
+## 2 案例 - 书店
+
+###  2.1 源码
+
+```java
+package com.javaedge.design.principle.openclose;
+
+/**
+ * 书籍接口
+ * 
+ * @author JavaEdge
+ */
+public interface BaseBook {
+
+    /**
+     * 获取书籍 ID
+     *
+     * @return 书籍 ID
+     */
+    Integer getId();
+
+    /**
+     * 获取书籍名
+     *
+     * @return 书籍名
+     */
+    String getName();
+
+    /**
+     * 获取书籍价
+     *
+     * @return 书籍价
+     */
+    Double getPrice();
+}
+```
+
+```java
+/**
+ * Java书籍实现类
+ * 
+ * @author JavaEdge
+ */
+@AllArgsConstructor
+@Getter
+@Setter
+public class JavaBook implements BaseBook {
+
+    private Integer id;
+
+    private String name;
+
+    private Double price;
+}
+```
+
+```java
+/**
+ * 测试类
+ *
+ * @author JavaEdge
+ */
+@Slf4j
+public class Test {
+    public static void main(String[] args) {
+        JavaBook baseCourse = new JavaBook(66, "Java编程思想", 98d);
+
+        JavaDiscountBook discountBook = (JavaDiscountBook) baseCourse;
+        log.info("书籍ID:" + discountBook.getId() +
+                " 书籍名称:" + discountBook.getName() +
+                " 书籍原价:" + discountBook.getPrice() +
+                "书籍优惠价:" + discountBook.getDiscountPrice());
+    }
+}
+```
+
+### 2.2 需求
+
+新增一个折扣优惠方法：若直接修改原接口，则每个实现类都得重新添加方法实现。但接口应稳定，不应频繁修改！
+
+```java
+package com.javaedge.design.principle.openclose;
+
+/**
+ * Java 书籍折扣类
+ *
+ * @author JavaEdge
+ */
+public class JavaDiscountBook extends JavaBook {
+
+    public JavaDiscountBook(Integer id, String name, Double price) {
+        super(id, name, price);
+    }
+
+    public Double getDiscountPrice() {
+        return super.getPrice() * 0.8;
+    }
+}
+```
+
+现UML：
+
+![](https://p.ipic.vip/ix904j.png)
+
+`接口应稳定且可靠，不应经常变化`，否则接口作为契约的作用就失去效能。
+
+### 2.3 修改实现类
+
+在getPrice()实现打折处理，低级程序员都习惯这样通过class文件替换，极速完成部分业务变化（或bugfix）。
+
+该方法在项目有明确章程（团队内约束）或优良架构设计时，很优秀，但若采购书籍人员也要看价格，由于该方法已实现打折处理价格，因此采购人员看到也是折后价，会`因信息不对称而出现决策失误`。因此，这不是最优解。
+
+### 2.4 通过扩展实现变化
+
+`增加子类`OffNovelBook，重写getPrice，高层次模块（static静态模块区）通过OffNovelBook类产生新对象，完成业务变化对系统的最小化开发。
+
+好办法！修改少，风险也小。
+
+OCP对扩展开放，对修改关闭，但并不是说不做任何修改，低层模块的变更，必然要与高层模块耦合，否则就是孤立无意义的代码段。
+
+## 3 变化的类型
+
+### 3.1 逻辑变化
+
+只变化一个逻辑，不涉及其它模块。如原算法`a*b+c`，要修改为`a*b*c`，那就直接修改原有类中的方法，但前提条件：所有依赖或关联类都按相同逻辑处理。
+
+### 3.2 子模块变化
+
+一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的。
+
+### 3.3 可见视图变化
+
+如Swing。若仅是按钮、文字重排还简单，最司空见惯的是业务耦合变化一个展示数据的列表，按原有需求是6列，突然要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现，这样的变化是恐怖的，但还是能通过扩展完成变化。
+
+### 3.4 小结
+
+放弃修改历史的想法吧！一个项目的基本路径：项目开发、重构、测试、投产、运维。
+
+- 重构，可对原有设计和代码进行修改
+- 运维，尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统稳定性
+
+## 4 案例 - 酒店会员
+
+开发酒店CRS系统，针对不同用户，计算不同房价：
+
+- 普通用户全价
+- 金卡8折
+- 银卡9折
+
+代码可能：
+![](https://img-blog.csdnimg.cn/d74b8a7ac93f45a0b259be02bffe8c75.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+### 4.1 新需求
+
+增加白金会员75折，CV大法好：
+![](https://img-blog.csdnimg.cn/e35d591b809f47bdbc8788bd6766e102.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+这就是【修改代码】，每增加一个新类型，就修改一次代码。
+但一个有各种级别用户的酒店系统肯定不只房价不同，提供服务也可能有区别，如是否有早餐？预付现付？优惠券力度、连住优惠规则？。可预见，每增加一个用户级别，要改的代码散布各地。
+
+### 4.2 何解？
+
+应考虑设计成可扩展模型。既然每次要增加的是用户级，且各种服务差异都体现在用户级，就需要一个用户级模型。
+
+#### ① 用户级别重构
+
+
+
+![](https://p.ipic.vip/8gg2cy.png)
+
+原代码即可重构成：
+
+![](https://img-blog.csdnimg.cn/7e59471ba0924cccbd4fac2503eb4f7e.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+此时再增加白金用户，只需新写一个类：
+
+![](https://img-blog.csdnimg.cn/34ec979369794553827bfe978fb70bc2.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_SmF2YUVkZ2U=,size_18,color_FFFFFF,t_70,g_se,x_16)
+可以这么做，是因为代码里留好了扩展点：UserLevel把原来只支持枚举值的UserLevel，升级成【有行为】的UserLevel。
+
+改造后，HotelService的getRoomPrice就稳定了，无需根据用户级别不断调整。
+一旦有稳定的构造块，就能在后续将其当做一个稳定模块复用。
+
+## 5 构建扩展点
+
+其实我们修改代码效果不佳，但真到自己写代码，就晕了。你开发的系统有问题吗？相信大部人都承认有。但又问：你经常主动优化吗？大部人却又沉默。
+它虽然垃圾，但在线上运行好好，万一我优化坏了咋办，绩效可就 3.25！现实就是这样 ，系统宏观层面人人都懂，而代码落地层，却各种原因本能的忽视。
+
+所以，写软件系统，就该提供一个个稳定小模块，然后，将它们组合。一个经常变动的模块不稳定，用它去构造更大模块，必后患无穷。
+
+### 5.1 为什么懂很多道理，却依旧写不好代码？
+
+阻碍我们构造稳定模块的，是构建模型的能力。回想产生变化的UserLevel是如何升级成有行为的UserLevel。
+
+封装的要点是行为，数据只是实现细节，而很多人习惯性面向数据写法，导致设计缺乏扩展性。
+
+### 5.2构建模型的难点
+
+1. 分离关注点
+2. 找到共性
+
+**要构建起抽象就要找到事物的共同点**，业务处理过程发现共性对大部分人就已经开始有难度。
+
+## 6 案例 - 报表服务
+
+![](https://img-blog.csdnimg.cn/f2d1fb410ecb49ed8b2d30cf24a89d7c.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+很多人日常写代码就这风格，代码流程僵化。只要有新需求，基本都要修改这段。
+
+### 6.1 需求
+
+把统计信息发给另外一个内部系统，该内部系统可将统计信息展示出来，供外部合作伙伴查阅。
+
+### 6.2 分析
+
+发给另一个系统的内容是**统计信息**。原代码里：
+
+- 前2步获取源数据，生成**统计信息**
+- 后2步生成报表，将**统计信息**通过邮件发出
+
+后2步和即将添加的步骤有个共同点，都使用统计信息。所以，可用共同模型，如OrderStatisticsConsumer：
+![](https://img-blog.csdnimg.cn/927eade9b0d74d9392b5bb987100577a.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+这样，新需求也只需添加一个新类，而非 if/else：
+![](https://img-blog.csdnimg.cn/07d88e8615564fb2974ea0631b48b087.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+该案例中，第一步要做的还是分解：
+
+- 把一个个步骤分开
+- 然后找出步骤间相似点
+- 并构建一个新模型
+
+实际项目代码更复杂，但并非一定业务逻辑复杂，而是代码写得就垃圾且复杂。
+所以，要先根据SRP，将不同需求来源引起的变动拆到不同方法，形成一个个小单元，再做这里的分析。
+
+实际项目达到OCP并非一朝一夕。这里只是因为有需求变动，才提取出一个OrderStatisticsConsumer。
+
+未来可能还有其它变动，如生成报表的逻辑。那时，也许再提取一个新OrderStatisticsGenerator的接口。但不管怎样，每做一次这种模型构建，最核心的类就会朝稳定发展。
+
+**好的设计都会提供足够扩展点给新功能去扩展（想起 Spring 生命周期）。**
+《Unix 编程艺术》提倡“提供机制，而非策略”，这就体现OCP。
+
+很多系统的插件机制，如IDEA和VS Code都体现OCP。去了解它们的接口，即可看到这个软件给我们提供的各种能力。
+
+### 6.3 抓手
+
+OCP还可帮助我们优化系统，查看Git，找出那些最经常变动的文件，它们通常都没满足OCP，这就能成为你系统优化的起航点。
+
+## 7 为何选择OCP？
+
+### 7.1 OCP对测试的影响
+
+有变化提出时，就要考虑：原有的健壮代码是否能不修改，而仅通过扩展实现变化？否则，就需要把原有测试过程全部回笼一遍，需要进行UT、功能测试、集成测试甚至验收测试。
+
+回看书店案例，*BaseBook*接口写完，实现类JavaBook也写好了，写个测试类：
+
+```java
+public class JavaBookTest extends TestCase {
+     private String name = "Java666";
+     private int price = 6000;
+     private String author = "JavaEdge";      
+     private BaseBook javaBook = new JavaBook(name,price,author);
+     
+     // 测试getPrice方法
+     public void testGetPrice() {
+             //原价销售，根据输入和输出的值是否相等进行断言
+             super.assertEquals(this.price, this.novelBook.getPrice());
+     }
+}
+```
+
+若加个打折销售需求，直接修改getPrice，就要修改UT类。而实际项目，一个类一般只有一个测试类，其中可以有很多测试方法，在一堆本就复杂的断言中进行大量修改，难免测试遗漏。
+
+**所以，要通过扩展实现业务逻辑变化，而非修改**。可通过增加一个子类OffJavaBook完成业务需求变化，这对测试有啥好处？重新生成一个测试文件OffJavaBookTest，然后对getPrice测试，UT是孤立测试，只要保证我提供的方法正确就成，其他不管：
+
+```java
+public class OffNovelBookTest extends TestCase {   
+     private BaseBook below40NovelBook = new OffJavaBook("Java666",3000,"JavaEdge");
+     private BaseBook above40NovelBook = new OffJavaBook("Go999",6000,"JavaEdge");
+      
+     // 测试低于40元的数据是否是打8折
+     public void testGetPriceBelow40() {
+             super.assertEquals(2400, this.below40NovelBook.getPrice());
+     }
+     
+     // 测试大于40的书籍是否是打9折
+     public void testGetPriceAbove40(){
+             super.assertEquals(5400, this.above40NovelBook.getPrice());
+     }
+}
+```
+
+新增加的类，新增加的测试方法，只要保证新增加类是正确的就可以了。
+
+### 7.2 提高复用性
+
+OOP中，所有逻辑都从原子逻辑组合而来，而非在一个类中独立实现一个业务逻辑。只有这样代码才可复用，粒度越小，被复用可能性越大。
+
+#### ①  为何要复用？
+
+减少代码量，避免相同逻辑分散，避免后来的维护人员为修改一个小bug或加个新功能，而在整个项目到处查找相关代码，然后发出对开发人员吼出“极度失望”的感慨。
+
+#### ②  如何提高复用率？
+
+缩小逻辑粒度，直到一个逻辑不可再拆分。
+
+### 7.3 提高可维护性
+
+一款软件投产后，接盘侠不仅要对数据进行维护，还可能要对程序进行扩展，接盘侠最爱干的就是扩展一个类，而非修改一个类，甭管原有代码好坏，让接盘侠先看懂原有代码，再修改，就是炼狱！不要让他在原有代码海洋里瞎游完毕后再修改，那是对接盘侠的摧残，会缺水溺死。
+
+### 7.4 OOP
+
+万物皆对象，我们要把所有事物抽象成对象，再针对对象操作，但运动是一定的，有运动就有变化，有变化就要有策略应对，如何快速应对？就需要在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转为“现实”。
+
+## 8 总结
+
+若说SRP主要看封装，而OCP须有多态。要想提供扩展点，就要面向接口编程。
+
+Java SPI提供扩展机制，Spring Boot和Dubbo继续改进，各自提供扩展点：
+
+- Spring Boot允许用户自定义starter
+- Dubbo可自定义协议
+
+1、识别修改点，构建模型，将原来静态逻辑转为动态逻辑
+2、构建模型的难点在于分离关注点，其次找到共性
\ No newline at end of file
diff --git "a/docs/md/java/JDK16\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java16-new-features.md
similarity index 100%
rename from "docs/md/java/JDK16\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java16-new-features.md
diff --git "a/docs/md/java/JDK21\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java21-new-features.md
similarity index 100%
rename from "docs/md/java/JDK21\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java21-new-features.md
diff --git "a/docs/md/java/JDK22\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java22-new-features.md
similarity index 100%
rename from "docs/md/java/JDK22\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java22-new-features.md
diff --git "a/docs/md/java/JDK23\346\226\260\347\211\271\346\200\247.md" b/docs/md/java/Java23-new-features.md
similarity index 100%
rename from "docs/md/java/JDK23\346\226\260\347\211\271\346\200\247.md"
rename to docs/md/java/Java23-new-features.md
diff --git "a/docs/md/java/Java9\346\226\260\347\211\271\346\200\247\346\246\202\350\277\260.md" b/docs/md/java/Java9-new-features.md
similarity index 100%
rename from "docs/md/java/Java9\346\226\260\347\211\271\346\200\247\346\246\202\350\277\260.md"
rename to docs/md/java/Java9-new-features.md
diff --git a/docs/md/java/java-news-roundup-jun02-2025.md b/docs/md/java/java-news-roundup-jun02-2025.md
new file mode 100644
index 0000000000..4f3022a035
--- /dev/null
+++ b/docs/md/java/java-news-roundup-jun02-2025.md
@@ -0,0 +1,126 @@
+# Java 新闻速递：JDK 25 进入收尾阶段，JDK 26 专家组成立，Hibernate Search 发布，Oracle 推出 Project Crema
+
+## 0 前言
+
+上周Java 新闻回顾重点：JDK 25进入Rampdown第一阶段、JDK 26专家组成立、Hibernate Search 8.0.0.Final发布、Grails 7.0.0第四个里程碑版本发布、Open Liberty 25.0.0.6测试版发布、Eclipse JNoSQL、Helidon 和 JBang 的小版本更新，以及 Oracle Labs 推出的新项目 Project Crema 预览。
+
+## 1 OpenJDK
+
+JEP 509：[JFR CPU时间分析（实验性）](https://openjdk.org/jeps/509) 已从“拟定为目标”升级为“已确定目标”，将会包含在 JDK 25。该JEP提议增强 JDK Flight Recorder（JFR），使其可在 Linux 系统记录 CPU 时间的分析信息。
+
+## 2 JDK 25
+
+JDK 25 的[早期访问版本 Build 26](https://github.com/openjdk/jdk/releases/tag/jdk-25%2B26)上周上线，包含自 Build 25 以来的多项[更新](https://github.com/openjdk/jdk/compare/jdk-25%2B25...jdk-25%2B26)，修复了多个[问题](https://bugs.openjdk.org/browse/JDK-8357287?jql=project %3D JDK AND fixversion %3D 25 and "resolved in build" %3D b26 order by component%2C subcomponent)。完整详情可见[发行说明](https://jdk.java.net/25/release-notes)。
+
+根据 JDK 25 的[发布计划](https://openjdk.org/projects/jdk/25/#Schedule)，Oracle Java平台首席架构师 [Mark Reinhold](https://www.linkedin.com/in/markreinhold) [宣布](https://mail.openjdk.org/pipermail/jdk-dev/2025-June/010191.html)，JDK 25已进入 Rampdown Phase One，即主线源码仓库已分支为[JDK稳定版本仓库](https://github.com/openjdk/jdk/tree/jdk25)，不会再添加新JEP特性。JDK 25 正式发布（GA）将于 2025 年 9 月进行，最终包含18项功能：
+
+- JEP 470：[加密对象的PEM编码（预览）](https://openjdk.org/jeps/470)
+- JEP 502：[稳定值（预览）](https://openjdk.org/jeps/502)
+- JEP 503：[移除32位x86平台支持](https://openjdk.org/jeps/503)
+- JEP 505：[结构化并发（第五次预览）](https://openjdk.org/jeps/505)
+- JEP 506：[作用域值](https://openjdk.org/jeps/506)
+- JEP 507：[在模式匹配、instanceof 和 switch 中使用原始类型（第三次预览）](https://openjdk.org/jeps/507)
+- JEP 508：[向量API（第十次孵化）](https://openjdk.org/jeps/508)
+- JEP 509：[JFR CPU时间分析（实验性）](https://openjdk.org/jeps/509)
+- JEP 510：[密钥派生函数API](https://openjdk.org/jeps/510)
+- JEP 511：[模块导入声明](https://openjdk.org/jeps/511)
+- JEP 512：[简洁的源文件和实例 main 方法](https://openjdk.org/jeps/512)
+- JEP 513：[灵活的构造方法体](https://openjdk.org/jeps/513)
+- JEP 514：[AOT 命令行参数优化](https://openjdk.org/jeps/514)
+- JEP 515：[AOT 方法分析](https://openjdk.org/jeps/515)
+- JEP 518：[JFR 协作采样](https://openjdk.org/jeps/518)
+- JEP 519：[紧凑对象头](https://openjdk.org/jeps/519)
+- JEP 520：[JFR 方法计时与追踪](https://openjdk.org/jeps/520)
+- JEP 521：[新一代 Shenandoah 垃圾回收器](https://openjdk.org/jeps/521)
+
+JDK 25 将是继 JDK 21、17、11 和 8 之后的下一代长期支持（LTS）版本。
+
+## 3 JDK 26
+
+JSR 401：[Java SE 26](https://jcp.org/en/jsr/detail?id=401) 已于上周正式批准，宣布成立四人专家组，成员包括 [Simon Ritter](https://www.linkedin.com/in/siritter/)（Azul Systems）、[Iris Clark](https://www.linkedin.com/in/iris-clark-49159b13b/)（Oracle）、[Stephan Herrmann](https://github.com/stephan-herrmann)（Eclipse Foundation）和 [Christoph Langer](https://www.linkedin.com/in/christoph-langer-764280208/)（SAP SE）。Clark 将担任规范负责人。JDK 26 的[计划时间表](https://openjdk.org/projects/jdk/26/spec/)包括：2025年11月到2026年2月的公开评审期，GA版本预计在2026年3月发布。
+
+此外，JDK 26 的[Build 0](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B0) 和 [Build 1](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B1) 也在本周发布，修复了部分[初期问题](https://bugs.openjdk.org/browse/JDK-8355746?jql=project %3D JDK AND fixVersion %3D "26" AND "Resolved In Build" %3D b01 order by component%2C subcomponent)。
+
+开发者可通过 [Java Bug Database](https://bugreport.java.com/bugreport/) 提交 JDK 25 的问题反馈。
+
+## 4 Jakarta EE
+
+Eclipse 基金会 Jakarta EE 开发者倡导者 [Ivar Grimstad](https://se.linkedin.com/in/ivargrimstad) 在他每周的 [Hashtag Jakarta EE 博客](https://www.agilejava.eu/)中更新了 Jakarta EE 11 和 EE 12 的进展：
+
+> 该庆祝了！Jakarta EE 11 平台的所有发布审查材料都已提交，作为规范委员会的导师，我将于6月9日（周一）启动发布审查投票。这意味着最迟将在6月24日正式发布。希望那天有蛋糕……
+>
+> 随着 EE 11 推出，接下来的重点将转向 [Jakarta EE 12](https://jakarta.ee/specifications/platform/12/)。目前计划评审已完成，平台项目已启动并开始定义里程碑，[详细计划](https://jakartaee.github.io/platform/jakartaee12/JakartaEE12ReleasePlan)包括制定 *Milestone 0*，确保各个子规范项目准备就绪。
+
+Jakarta EE 11 的发布经历了五个里程碑版本，包括2024年12月发布的 [Core Profile](https://jakarta.ee/specifications/coreprofile/)、2025年4月发布的 [Web Profile](https://jakarta.ee/specifications/webprofile/)，以及平台版的候选发布版本，预计正式发布将在2025年6月。
+
+## 5 Eclipse JNoSQL
+
+[Eclipse JNoSQL](https://www.jnosql.org/) 1.1.8 发布，作为 [Jakarta NoSQL](https://jakarta.ee/specifications/nosql/) 规范的兼容实现，此版本带来以下更新：
+
+- 支持图数据库类型，新增 Java 的 Graph API，采用 Neo4j 的 [Cypher 查询语言](https://neo4j.com/product/cypher-graph-query-language/)
+- 新增 Quarkus 扩展：[quarkus-jnosql-core](https://quarkus.io/extensions/io.quarkiverse.jnosql/quarkus-jnosql-core/)，支持 MongoDB、ArangoDB、Cassandra 和 Hazelcast
+
+图形 API 的实现细节可参考这篇 [LinkedIn 博客](https://quarkus.io/extensions/io.quarkiverse.jnosql/quarkus-jnosql-core/)。
+
+## 6 Spring Framework
+
+[Spring Cloud](https://spring.io/projects/spring-cloud) 2022.0.11（代号 Kilburn）作为第11个维护版本，[已发布](https://spring.io/blog/2025/06/02/spring-cloud-2022-0-11-aka-kilburn-has-been-released)，包含多项Bug修复和依赖升级，尤其是：
+
+- [Spring Cloud Config](https://spring.io/projects/spring-cloud-config) 4.0.11 修复了 [CVE-2025-22232](https://spring.io/security/cve-2025-22232)
+- [Spring Cloud Gateway](https://spring.io/projects/spring-cloud-gateway) 4.0.12 修复了 [CVE-2025-41235](https://spring.io/security/cve-2025-41235)
+
+## 7 Hibernate
+
+[Hibernate Search](https://hibernate.org/search/) 8.0.0.Final [正式发布](https://in.relation.to/2025/06/06/hibernate-search-8-0-0-Final/)，包括：
+
+- 兼容 Hibernate ORM 7.0.0.Final
+- 与 [Hibernate Models](https://github.com/hibernate/hibernate-models/blob/main/README.adoc) 集成增强
+- 在 [Hibernate Search DSL](https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#search-dsl) 中支持请求指标聚合
+- 各类Bug修复
+
+更多详情请参阅[发行说明](https://hibernate.atlassian.net/issues/?jql=project%3D10061 AND fixVersion%3D33769)。
+
+## 8 Helidon
+
+Helidon 4.2.3 发布，主要改进包括：
+
+- 在 [Metrics](https://helidon.io/docs/v4/se/metrics/metrics)、[Health Checks](https://helidon.io/docs/v4/se/health)、[OpenAPI](https://helidon.io/docs/v4/se/openapi/openapi) 和 [Config](https://helidon.io/docs/v4/se/config/introduction) API 输出中添加 **`nosniff`** 的 **`X-Content-Type-Options`** 头部，防止浏览器自动推断内容类型
+- 修复了 **`SecurityEnvironment`** 类中 **`queryParams()`** 方法无法获取查询参数的问题
+
+详细变更见 [更新日志](https://github.com/helidon-io/helidon/blob/4.2.3/CHANGELOG.md)。
+
+## 9 Open Liberty
+
+[Open Liberty](https://openliberty.io/) 25.0.0.6-beta [发布](https://openliberty.io/blog/2025/06/03/25.0.0.6-beta.html)，新特性包括：
+
+- 为 Java EE 7 和 8 应用回移支持 [Microprofile Health 4.0](https://github.com/microprofile/microprofile-health/blob/main/README.adoc) 规范（`mpHealth-4.0`）
+- 更新了[基于文件的健康检查机制](https://blogs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/blog/2025/04/08/25.0.0.4-beta.html#backport)，新增了 **`server.xml`** 中的 **`startupCheckInterval`** 属性及其环境变量 **`MP_HEALTH_STARTUP_CHECK_INTERVAL`**，默认值为100毫秒
+
+## 10 Grails
+
+[Grails](https://grails.org/) 7.0.0 的第四个里程碑版本发布，更新内容包括：
+
+- 由于迁移至 Apache 软件基金会，进行了[构件命名重构](https://github.com/apache/grails-core/blob/7.0.x/RENAME.md)
+- 将多个仓库（如 **`grails-views`**、**`gsp`** 等）的源码整合至 **`grails-core`** 仓库中
+
+详细信息见 [发布说明](https://github.com/apache/grails-core/releases/tag/v7.0.0-M4)。
+
+## 11 JBang
+
+[JBang](https://www.jbang.dev/) 0.126.0 发布，带来文档改进、Bug 修复和新特性，包括：
+
+- 将 **`ResourceRef`** 从类更改为接口
+- 引入 **`LazyResourceRef`** 和 **`LazyResourceResolver`**，支持开发者按需加载远程资源
+
+更多信息请查阅 [发布说明](https://github.com/jbangdev/jbang/releases/tag/v0.126.2)。
+
+## 12 Project Crema
+
+Oracle Labs 的 GraalVM 开发者倡导者 [Alina Yurenko](https://www.linkedin.com/in/alinayurenko/) 在 [X 平台](https://x.com/alina_yurenko/status/1930241191418708072)上分享了新项目 [Project Crema](https://github.com/oracle/graal/issues/11327) 的预览。
+
+该项目旨在“打破 Native Image 的默认封闭世界假设，允许在运行时动态加载和执行类”，主要包括：
+
+- Java 解释器，构建在 **Native Image Layers** 之上（一个支持依赖基础镜像链的新项目，[详情](https://github.com/oracle/graal/issues/7626)）
+- 支持 [Java 调试线协议（JDWP）](https://docs.oracle.com/en/java/javase/24/docs/specs/jdwp/jdwp-spec.html)
+
+Yurenko 表示，开发者应“持续关注更多更新！”
\ No newline at end of file
diff --git a/docs/md/kafka/13-KafkaAdminClient.md b/docs/md/kafka/kafka-operations-tool-exploring-adminclient-principles-and-practices.md
similarity index 50%
rename from docs/md/kafka/13-KafkaAdminClient.md
rename to docs/md/kafka/kafka-operations-tool-exploring-adminclient-principles-and-practices.md
index 8a128812e4..e7e90298e2 100644
--- a/docs/md/kafka/13-KafkaAdminClient.md
+++ b/docs/md/kafka/kafka-operations-tool-exploring-adminclient-principles-and-practices.md
@@ -1,20 +1,20 @@
-# 13-KafkaAdminClient
+# Kafka运维利器：深入解析AdminClient原理与实战
 
-## 引入原因
+## 1 Kafka脚本弊端
 
-Kafka自带的各种命令行脚本，这些脚本使用起来虽然方便，却有弊端：
+Kafka自带各种命令行脚本，用起来虽方便，但是：
 
-- 命令行的脚本都只能运行在控制台。若想在应用程序、运维框架或是监控平台中集成它们很难
-- 这些命令行脚本很多都是通过连接zk来提供服务。目前，社区越来越不推荐任何工具直连zk，因这会带来一些问题：可能绕过Kafka安全设置。kafka-topics脚本连接zk时，不会考虑Kafka设置的用户认证机制。即任何使用该脚本的用户，不论是否具有创建主题的权限，都能成功“跳过”权限检查，强行创建主题！
-- 运行这些脚本，要用Kafka内部的类实现，即Kafka**服务器端**代码。社区还是希望用户只使用Kafka**客户端**代码，通过现有请求机制运维管理集群。这样所有运维操作都能纳入统一处理机制下，方便功能演进。
+- 只能运行在控制台。若想在应用程序、运维框架或是监控平台中集成难
+- 很多通过连接zk来提供服务。而社区越来越不推荐任何工具直连zk，因为这可能绕过Kafka安全设置。kafka-topics脚本连接zk时，不会考虑Kafka设置的用户认证机制。即任何使用该脚本的用户，不论是否具有创建主题的权限，都成功“跳过”权限检查，强行创建主题
+- 运行它们要用Kafka内部类实现，即Kafka**服务器端**代码。社区希望用户只用Kafka**客户端**代码，通过现有请求机制运维管理集群。这样所有运维操作都能统一处理，方便功能演进
 
-因此，社区于0.11版本正式推出Java客户端版AdminClient，**服务器端也有一个AdminClient**，包路径是kafka.admin，是之前的老运维工具类，提供的功能也比较有限，社区已经不再推荐使用它了。
+因此，社区0.11版推出Java客户端版AdminClient，**服务器端也有一个AdminClient**，包路径是kafka.admin，是之前的老运维工具类，提供的功能也比较有限，社区已经不再推荐使用它了。
 
 ![](https://img-blog.csdnimg.cn/39a17bf7e6f647568e234db27608af0a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
 
 所以，现在统一使用客户端的AdminClient。
 
-## 如何使用？
+## 2 咋用？
 
 Java客户端提供的工具，要在你工程中显式增加依赖，以2.3版本为例。
 
@@ -30,54 +30,68 @@ Java客户端提供的工具，要在你工程中显式增加依赖，以2.3版
 compile group: 'org.apache.kafka', name: 'kafka-clients', version: '2.3.0'
 ```
 
-## 功能
+## 3 功能
 
-2.3版本中，AdminClient提供功能有9大类：
+2.3版的AdminClient支持：
 
-1. 主题管理：包括主题的创建、删除和查询。
-2. 权限管理：包括具体权限的配置与删除。
-3. 配置参数管理：包括Kafka各种资源的参数设置、详情查询。所谓的Kafka资源，主要有Broker、主题、用户、Client-id等。
+1. 主题管理：包括主题创建、删除和查询
+2. 权限管理：包括具体权限的配置与删除
+3. 配置参数管理：包括Kafka各种资源的参数设置、详情查询。所谓的Kafka资源，主要有Broker、主题、用户、Client-id等
 4. 副本日志管理：包括副本底层日志路径的变更和详情查询。
-5. 分区管理：即创建额外的主题分区。
-6. 消息删除：即删除指定位移之前的分区消息。
-7. Delegation Token管理：包括Delegation Token的创建、更新、过期和详情查询。
-8. 消费者组管理：包括消费者组的查询、位移查询和删除。
-9. Preferred领导者选举：推选指定主题分区的Preferred Broker为领导者。
+5. 分区管理：即创建额外的主题分区
+6. 消息删除：即删除指定位移之前的分区消息
+7. Delegation Token管理：包括Delegation Token的创建、更新、过期和详情查询
+8. 消费者组管理：包括消费者组的查询、位移查询和删除
+9. Preferred领导者选举：推选指定主题分区的Preferred Broker为领导者
 
-## 工作原理
+## 4 工作原理
 
-AdminClient是个双线程设计：
+AdminClient是双线程设计：
 
-- 前端主线程
+- 前端主线程：将用户要执行的操作转换成对应请求，发到后端I/O线程的队列
 
-  将用户要执行的操作转换成对应的请求，然后再将请求发送到后端I/O线程的队列
+- 后端I/O线程：从队列中读取相应请求，发到对应Broker节点，再把执行结果保存，待前端线程来获取
 
-- 后端I/O线程
-
-  从队列中读取相应请求，然后发到对应Broker节点，再把执行结果保存，等待前端线程来获取
 
 使用生产者-消费者模式将请求生成与处理解耦：
 
-![](/Users/javaedge/Downloads/IDEAProjects/java-edge-master/assets//4b520345918d0429801589217270d1eb.png)
+![](https://p.ipic.vip/81250j.png)
+
+### 前端主线程
+
+会创建名为Call的请求对象实例。该实例有两个主要的任务。
+
+#### 构建对应的请求对象
+
+如若要创建主题，那么就创建CreateTopicsRequest；如果是查询消费者组位移，就创建OffsetFetchRequest。
+
+#### 指定响应的回调逻辑
+
+如从Broker端接收到CreateTopicsResponse之后要执行的动作。一旦创建好Call实例，前端主线程会将其放入到新请求队列（New Call Queue）中，此时，前端主线程的任务就算完成了。它只需要等待结果返回即可。
 
-前端主线程会创建名为Call的请求对象实例。该实例有两个主要的任务。
+剩下工作都是
 
-1. **构建对应的请求对象**。比如，如果要创建主题，那么就创建CreateTopicsRequest；如果是查询消费者组位移，就创建OffsetFetchRequest。
-2. **指定响应的回调逻辑**。比如从Broker端接收到CreateTopicsResponse之后要执行的动作。一旦创建好Call实例，前端主线程会将其放入到新请求队列（New Call Queue）中，此时，前端主线程的任务就算完成了。它只需要等待结果返回即可。
+### 后端I/O线程
 
-剩下的所有事情就都是后端I/O线程的工作了。就像图中所展示的那样，该线程使用了3个队列来承载不同时期的请求对象，它们分别是新请求队列、待发送请求队列和处理中请求队列。为什么要使用3个呢？原因是目前新请求队列的线程安全是由Java的monitor锁来保证的。**为了确保前端主线程不会因为monitor锁被阻塞，后端I/O线程会定期地将新请求队列中的所有Call实例全部搬移到待发送请求队列中进行处理**。图中的待发送请求队列和处理中请求队列只由后端I/O线程处理，因此无需任何锁机制来保证线程安全。
+该线程用3个队列来承载不同时期的请求对象：
 
-当I/O线程在处理某个请求时，它会显式地将该请求保存在处理中请求队列。一旦处理完成，I/O线程会自动地调用Call对象中的回调逻辑完成最后的处理。把这些都做完之后，I/O线程会通知前端主线程说结果已经准备完毕，这样前端主线程能够及时获取到执行操作的结果。AdminClient是使用Java Object对象的wait和notify实现的这种通知机制。
+- 新请求队列
+- 待发送请求队列
+- 处理中请求队列
 
-严格来说，AdminClient并没有使用Java已有的队列去实现上面的请求队列，它是使用ArrayList和HashMap这样的简单容器类，再配以monitor锁来保证线程安全的。不过，鉴于它们充当的角色就是请求队列这样的主体，我还是坚持使用队列来指代它们了。
+为啥要用3个？目前新请求队列的线程安全是由Java monitor锁保证。为确保前端主线程不会因monitor锁被阻塞，后端I/O线程定期将新请求队列中的所有Call实例全部搬移到待发送请求队列中进行处理。图中的待发送请求队列和处理中请求队列只由后端I/O线程处理，因此无需任何锁机制保证线程安全。
 
-了解AdminClient工作原理的一个好处在于，**它能够帮助我们有针对性地对调用AdminClient的程序进行调试**。
+当I/O线程在处理某请求时，它会显式将该请求保存在处理中请求队列。一旦处理完成，I/O线程会自动地调用Call对象中的回调逻辑完成最后的处理。把这些都做完之后，I/O线程会通知前端主线程说结果已经准备完毕，这样前端主线程能够及时获取到执行操作的结果。AdminClient是使用Java Object对象的wait和notify实现的这种通知机制。
 
-提到的后端I/O线程有名字，前缀kafka-admin-client-thread。有时发现，AdminClient程序貌似正常工作，但执行操作没返回结果或hang住，现在你该知道这可能因为I/O线程出现问题导致。碰到类似问题，不妨jstack查看AdminClient程序，确认I/O线程是否在正常工作。
+ AdminClient没有用Java已有的队列去实现上面的请求队列，它用ArrayList、HashMap这样的简单容器类，再配monitor锁来保证线程安全的。但鉴于它们充当的角色就是请求队列，我还是坚持用队列来指代它们。
+
+### AdminClient工作原理
+
+好在它能帮助针对性地对调用AdminClient的程序调试。后端I/O线程名有前缀kafka-admin-client-thread。有时AdminClient貌似正常工作，但执行操作没返回结果或hang住，现在你该知道这可能因为I/O线程异常。碰到类似问题，不妨jstack看AdminClient程序，确认I/O线程是否正常。
 
 这是社区bug。这问题根本原因，就是I/O线程未捕获某些异常导致意外“挂”掉。由于AdminClient是双线程设计，前端主线程不受任何影响，依然可正常接收用户发送的命令请求，但此时程序已不能正常工作。
 
-## 构造和销毁AdminClient实例
+## 5 构造和销毁AdminClient实例
 
 如果你正确地引入了kafka-clients依赖，那么你应该可以在编写Java程序时看到AdminClient对象。**切记它的完整类路径是org.apache.kafka.clients.admin.AdminClient，而不是kafka.admin.AdminClient**。后者就是我们刚才说的服务器端的AdminClient，它已经不被推荐使用了。
 
@@ -85,9 +99,7 @@ AdminClient是个双线程设计：
 
 完整参数列表看[官网](https://kafka.apache.org/documentation/#adminclientconfigs)。如要销毁AdminClient实例，需显式调用AdminClient#close。
 
-## AdminClient实例的创建与销毁
-
-
+## 6 AdminClient实例的创建与销毁
 
 ```java
 Properties props = new Properties();
@@ -99,7 +111,7 @@ try (AdminClient client = AdminClient.create(props)) {
 }
 ```
 
-## 常见的AdminClient应用实例
+## 7 AdminClient应用
 
 讲完了AdminClient的工作原理和构造方法，接下来，我举几个实际的代码程序来说明一下如何应用它。这几个例子，都是我们最常见的。
 
@@ -142,15 +154,17 @@ try (AdminClient client = AdminClient.create(props)) {
 
 ### 获取Broker磁盘占用
 
-现在，我们来使用AdminClient实现一个稍微高级一点的功能：获取某台Broker上Kafka主题占用的磁盘空间量。有些遗憾的是，目前Kafka的JMX监控指标没有提供这样的功能，而磁盘占用这件事，是很多Kafka运维人员要实时监控并且极为重视的。
+获取某Broker上Kafka主题占用磁盘量。目前Kafka的JMX监控指标未提供该功能，而磁盘占用是很多Kafka运维需实时监控且重视。
 
-幸运的是，我们可以使用AdminClient来实现这一功能。代码如下：
+好在可用AdminClient实现：
 
 ```scala
 try (AdminClient client = AdminClient.create(props)) {
+  				// 使用AdminClient#describeLogDirs获取指定Broker上所有分区主题的日志路径信息
          DescribeLogDirsResult ret = client.describeLogDirs(Collections.singletonList(targetBrokerId)); // 指定Broker id
          long size = 0L;
          for (Map<String, DescribeLogDirsResponse.LogDirInfo> logDirInfoMap : ret.all().get().values()) {
+           				 // 然后把它们累积在一起，得出总磁盘占用量
                   size += logDirInfoMap.values().stream().map(logDirInfo -> logDirInfo.replicaInfos).flatMap(
                            topicPartitionReplicaInfoMap ->
                            topicPartitionReplicaInfoMap.values().stream().map(replicaInfo -> replicaInfo.size))
@@ -158,6 +172,4 @@ try (AdminClient client = AdminClient.create(props)) {
          }
          System.out.println(size);
 }
-```
-
-使用AdminClient的**describeLogDirs方法**获取指定Broker上所有分区主题的日志路径信息，然后把它们累积在一起，得出总磁盘占用量。
\ No newline at end of file
+```
\ No newline at end of file
diff --git a/docs/md/mysql/mysql-transaction-isolation-mechanism.md b/docs/md/mysql/mysql-transaction-isolation-mechanism.md
new file mode 100644
index 0000000000..4667d14894
--- /dev/null
+++ b/docs/md/mysql/mysql-transaction-isolation-mechanism.md
@@ -0,0 +1,497 @@
+# MySQL是怎么实现事务隔离的？
+
+## 0 前言
+
+一个事务要更新一行，若恰有另一事务持有该行的行锁，它会被锁住。既然进入等待状态，那等该事务自己获取到行锁要更新数据时，它读到的值又是啥？
+
+## 1 案例
+
+### 1.1 数据初始化
+
+```sql
+mysql> CREATE TABLE `t`
+    -> (
+    -> `id` int(11) NOT NULL,
+    -> `k` int(11) DEFAULT NULL,
+    -> PRIMARY KEY (`id`)
+    -> ) ENGINE = InnoDB;
+Query OK, 0 rows affected, 2 warnings (0.01 sec)
+
+mysql>
+mysql> insert into t(id, k)
+    -> values (1, 1),
+    ->        (2, 2);
+```
+
+### 1.2 事务执行流程
+
+| 事务A                                       | 事务B                                                        | 事务C                          |
+| ------------------------------------------- | ------------------------------------------------------------ | ------------------------------ |
+| start transaction with consistent snapshot; |                                                              |                                |
+|                                             | start transaction with consistent snapshot;                  |                                |
+|                                             |                                                              | update t set k=k+1 where id=1; |
+|                                             | update t set k=k+1 where id=1;  <br/>select k from t where id=1; |                                |
+| select k from t where id=1; <br>commit;     |                                                              |                                |
+|                                             | commit;                                                      |                                |
+
+### 1.3 事务启动时机
+
+- begin/start transaction：在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。一致性视图是在执行【第一个快照读语句】时创建
+- **start transaction with consistent snapshot**：想立马启动一个事务时用。一致性视图是在执行【start transaction with consistent snapshot】时创建
+
+默认`autocommit=1`。该案例中：
+
+- 事务C未显式用begin/commit，即该update语句本身就是个事务，语句完成时自动提交
+- 事务B更新行后，就查询
+- 事务A在一个只读事务中查询，时间上在事务B的查询后
+
+## 2 undo log链
+
+每条undo log有两个隐藏字段：
+
+- trx_id：最近一次更新这条数据的事务id
+
+- roll_pointer：指向更新这个事务之前生成的undo log
+
+
+若有一事务A（id=50）插入一条数据，则该数据隐藏字段及指向的undo log如下：roll_pointer指向一个空undo log，因为之前没这条数据
+
+![](https://img-blog.csdnimg.cn/887ff223849e46398e2dd152d2d1bb8b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+﻿再有一事务B修改该数据，改成值B，事务B的id是53，此时更新之前会生成一个undo log记录之前的值，然后roll_pointer指向这个实际的undo log回滚日志：
+
+![](https://img-blog.csdnimg.cn/af32cf5eaecd4610917d181d7e9a69f3.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+﻿roll_pointer指向undo log，这undo log就记录你更新之前的那条数据的值。
+
+再事务C来修改这值为C，其事务id=60，此时会把数据行里的txr_id改成60，然后生成一条undo log，记录之前事务B修改的那个值：
+
+![](https://img-blog.csdnimg.cn/bbc7ffed187c4ea59fbecc81f2f0c573.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+﻿多个事务串行执行时，每个人修改了一行数据，都会更新隐藏字段txr_id和roll_pointer，同时之前多个数据快照对应的undo log，会通过roll_pinter指针串联起来，形成版本链！
+
+## 3 视图（ReadView）
+
+执行一个事务时，就给你生成一个ReadView，其关键组成：
+
+- m_ids：此时有哪些事务在MySQL里执行还没提交
+
+- min_trx_id：m_ids里最小的值
+
+- max_trx_id：MySQL下一个要生成的事务id，就是最大事务id
+
+- creator_trx_id：你这个事务的id
+
+若原有一行数据，很早就有事务插入过了，事务id是32，他的值就是初始值：
+
+![](https://img-blog.csdnimg.cn/7522f99e1bca4407843806d070744c2a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+此时两个事务并发来执行了：
+
+- 事务A（id=45）：读取这行数据的值
+
+- 事务B（id=59）：更新这行数据的
+
+
+﻿现在A直接开启一个ReadView：
+
+- m_ids包含事务A、B的id：45和59
+- min_trx_id=45
+- max_trx_id=60
+- creator_trx_id=45，事务A自己
+
+事务A第一次查询该行数据，判断：
+
+```
+当前这行数据的txr_id ＜ReadView中的min_trx_id？
+```
+
+txr_id=32小于ReadView里的min_trx_id 45，说明事务开启前，修改这行数据的事务早就提交，所以此时可以查到这行数据。
+
+接着B把这行数据的值修改为了值b，然后这行数据txr_id设为自己的id=59，roll_pointer指向修改之前生成的一个undo log，接着这个事务B就提交了：
+
+![](https://img-blog.csdnimg.cn/97b7e42a361643c8a28ea54e39d33eec.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+A再次查询，发现此时数据行里的txr_id=59：
+
+ReadView里的max_trx_id（60) ＞ txr_id ＞ ReadView里的min_txr_id(45)
+
+说明更新这条数据的事务，很可能就跟自己差不多同时开启，于是会看txr_id=59是否在ReadView的m_ids列表。果然就有45和59两个事务id，证实这修改数据的事务是和自己同一时段并发执行然后提交的，所以对这行数据不能查询！
+
+那查啥？顺着这条数据的roll_pointer顺着undo log日志链条往下找，就会找到最近的一条undo log，发现trx_id=32，小于ReadView里的min_trx_id（45），说明该undo log版本在A开启前就执行且提交。那就查询最近那undo log里的值，这就是undo log多版本链的作用，可保存一个快照链，让你能读到之前的快照值：
+
+![](https://img-blog.csdnimg.cn/dc3062597ed344f788cbe780bc6745c3.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+多事务并发时，事务B更新的值，通过这套**ReadView+undo log**日志链机制，保证A不会读到并发执行的B更新的值，而只会读到之前最早的值。
+
+接着若事务A更新了这行数据的值，改成值a，trx_id修改为45，同时保存之前事务B修改的值的快照：
+
+![](https://img-blog.csdnimg.cn/2e5b2e26db8b465884b3160f13c792da.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+﻿此时A来查询这条数据的值，发现trx_id=45，和自己ReadView里的creator_trx_id（45）一样，说明这行数据就是自己修改的，自己修改的值当然可见。
+
+![](https://img-blog.csdnimg.cn/dfa8f7e7253c4914add54b99a85e30a9.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+﻿接着在事务A执行的过程中，突然开启事务C，事务id=78，然后他更新那行数据为值C，还提交了：
+
+![](https://img-blog.csdnimg.cn/1e0acc50194e4738824ebac3bf86063f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+这时A再查询，发现当前数据trx_id=78＞自己ReadView的max_trx_id（60)，说明A开启后，然后有个事务更新了数据，自己当然不能看到！
+
+﻿就顺undo log多版本链往下找，先找到值a，自己之前修改的过的那个版本，因为那个trx_id=45跟自己的ReadView里的creator_trx_id一样，所以此时直接读取自己之前修改的那个版本。
+
+## 4 小结
+
+通过undo log多版本链，加上开启事务时产生的ReadView，然后再有一个查询时，根据ReadView进行判断，就能知你应读取哪个版本数据，保证你
+
+### 能读到
+
+- 你事务开启前，其它已提交事务更新的值
+
+- 还有你自己事务更新的值
+
+### 读不到
+
+- 若你事务开启前，就有其它事务在运行，当你事务开启后，其它事务更新了值
+- 你事务开启后，比你晚开启的事务更新了值
+
+通过这套机制就可以实现多个事务并发执行时候的数据隔离。
+
+## 5 RC级实现
+
+事务运行期，只要其它事务修改数据并提交，即可读到人家修改的数据，所以会不可重复读、幻读。
+
+ReadView机制基于undo log版本链实现的一套读视图机制，事务生成一个ReadView：
+
+- 若为事务自己更新的数据，自己可读到
+- 或你生成ReadView之前的已提交的事务所修改值，也可读到
+- 但若你生成ReadView时，就已经活跃的事务，但如果它在你生成ReadView之后修改的数据并提交了，此时你读不到
+- 或你生成ReadView以后再开启的事务修改了数据，还提交了，也读不到
+
+所以上面那套机制就是ReadView的一个原理。咋基于ReadView实现RC？当一个事务设置RC，他是每次发起查询，都重新生成一个ReadView！
+
+数据库有行数据，是事务id=50的一个事务很久前插入的，而当前活跃事务：
+
+- 事务A（id=60）
+- 事务B（id=70）
+
+现在事务B发起update，更新这条数据为b，所以此时数据的trx_id会变为事务B的id=70，同时生成一条undo log：
+
+![](https://img-blog.csdnimg.cn/c55a614c17014744bf3e8f727412c0f1.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+这时，事务A要发起一次查询操作，就生成一个ReadView：
+
+![](https://img-blog.csdnimg.cn/e0114e59efb54cdd8fba780b5d9abc66.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+这时事务A发起查询，发现当前数据trx_id=70。即属于ReadView的事务id范围之间，说明是他生成ReadView之前就有这活跃的事务，是这事务修改了这条数据的值，但此时事务B还没提交，所以ReadView的m_ids活跃事务列表里，有[60, 70]两个id，此时根据ReadView机制，事务A无法查到事务B修改的值b。
+
+就顺undo log版本链往下找，就找到一个原始值，发现其trx_id是50，小于当前ReadView里的min_trx_id，说明是他生成ReadView之前，就有一个事务插入了这个值并且早就提交了，因此可以查到这个原始值。
+
+接着，假设事务B提交，提交了就说明事务B不会活跃于数据库里了。事务A下次再查询，就可以读到事务B修改过的值了。那到底是怎么让事务A能够读到提交的事务B修改过的值呢？
+
+让事务A下次发起查询，再生成一个ReadView，数据库内活跃的事务只有事务A，因此：
+
+- min_trx_id是60
+- mac_trx_id是71
+- m_ids=60，事务B的id=70不会出现在m_ids活跃事务列表
+
+此时事务A再基于这ReadView去查询，会发现这条数据的trx_id=70，虽然在ReadView的min_trx_id和max_trx_id范围之间，但是此时并不在m_ids列表内，说明事务B在生成本次ReadView之前就已提交。说明这次你查询就可以查到事务B修改过的这个值了， 此时事务A就会查到值B。
+
+## 6 RR级实现
+
+咋同时避免不可重复读问题、幻读？
+
+MySQL让多事务并发运行的时候能互相隔离，避免同时读写一条数据时有影响，是借助undo log版本链和ReadView机制。
+
+RR级别下，你这事务读一条数据，无论读多少次，都是一个值：
+
+- 别的事务修改数据了后即使提交了，你也看不到人家修改的值，这就解决了不可重复读
+- 其它事务插入一些新数据，你也读不到，这就避免幻读
+
+若有一条数据是事务id=50的一个事务插入的，此时有事务A、B同时在运行。﻿事务A发起一个查询，第一次查询就生成一个ReadView：
+
+- creator_trx_id=60
+- min_trx_id=60
+- max_trx_id=71
+- m_ids=[60, 70]
+
+这时，事务A基于该ReadView去查这条数据，发现这条数据的trx_id为50，小于ReadView﻿里的min_trx_id的，说明他发起查询之前，早就有事务插入这条数据还提交了，所以此时可以查到这条原始值的
+
+![](https://img-blog.csdnimg.cn/8db3a28dcea14f7da75098ca5e7212b6.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+接着事务B此时更新了这条数据的值为b，修改trx_id=70，同时生成一个undo log，事务B此时提交
+
+![](https://img-blog.csdnimg.cn/e9fc43838a4d477cac74c192568236c2.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+ReadView中的m_ids此时还是60、70，因为ReadView一旦生成了就不会改变！
+
+这时虽然事务B已提交，但事务A的ReadView里， 还是有60、70，即在你事务A开启查询时，事务B当时是在运行的意思而已。
+
+然后事务A查询这条数据，发现此时数据的trx_id=70，在ReadView的min_trx_id和max_trx_id的范围，还在m_ids列表，这说明啥？
+
+事务A开启查询时，id=70的这个事务B还在运行，然后由这个事务B更新了这条数据，所以此时事务A不能查询到事务B更新的这个值，因此顺着指针往历史版本链条上去找，找到trx_id=50，是小于ReadView的min_trx_id的，说明在他开启查询之前，就已提交该事务，所以事务A可查询到该值，此时事务A查到的就是原始值。这就解决了不可重复读。
+
+事务A多次读同一个数据，每次读到的都是一样的值，除非是他自己修改的值，否则读到的一直一样。不管别的事务如何修改数据，事务A的ReadView始终不变，他基于这ReadView看到的值始终如一！
+
+### 解决幻读
+
+假设事务A先
+
+```sql
+select * from x where id>10
+```
+
+此时可能查到的就是一条数据，而且读到的是这条数据的原始值的那个版本：
+
+![](https://img-blog.csdnimg.cn/47f75068dda147eab73288c81285540d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+现在，有个事务C插入一条数据，然后提交：
+
+![](https://img-blog.csdnimg.cn/78756b3a3f924daa9413d21dbe518cf8.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_SmF2YUVkZ2U=,size_20,color_FFFFFF,t_70,g_se,x_16)
+
+﻿接着，事务A再查询，发现符合条件的有2条数据：
+
+- 原始值那个数据
+
+- 事务C插入的那条数据
+
+  但C插入的那条数据的trx_id=80 ＞ ReadView的max_trx_id，说明是自己发起查询后，这个事务才启动，所以此时这条数据不能查询。
+
+﻿因此事务A本次查询，还是只能查到原始值那一条数据。所以这里事务A不会发生幻读，他根据条件范围查询的时候，每次读到的数据都是一样的，不会读到人家插入进去的数据，这都是依托ReadView机制实现的。
+
+## 7 MySQL的两个“视图”
+
+- view：一个用查询语句定义的虚拟表，调用时，执行查询语句并生成结果。创建视图的语法 create view … ，其查询方法与表一样
+- InnoDB实现MVCC时用的一致性读视图（consistent read view）：用于支持**读提交**、**可重复读**。没有物理结构，事务执行期间用来定义“我能看到啥数据”。
+
+## 8 “快照”在MVCC咋工作的？
+
+RR下，事务启动时就“拍了个快照”。该快照是基于整库的。若某库有100G，则启动一个事务，MySQL就要拷贝100G数据出来，这得多慢。实际上，并不需要拷贝出这100G数据。
+
+### 8.1 快照的实现
+
+InnoDB每个事务有**唯一事务ID**：transaction id，在事务开始时向InnoDB事务系统申请的，按申请顺序严格递增。
+
+#### 每行数据也有多版本
+
+每次事务更新数据时，都生成一个新**数据版本**，并把`transaction id`赋给该**数据版本**的**事务ID**，记为row trx_id。同时，旧数据版本要保留，并在新数据版本中，能有办法可直接拿到它。
+
+即一行记录可能有多个版本(row)，每个版本有自己的row trx_id。
+
+如图，就是一个记录被多个事务连续更新后的状态。行状态变更图：
+
+![](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/MySQL%e5%ae%9e%e6%88%9845%e8%ae%b2/assets/68d08d277a6f7926a41cc5541d3dfced.png)
+
+虚线框里是同一行数据的4个版本，当前最新版本是V4，k=22，它是被transaction id=25的事务更新，因此它的row trx_id=25。
+
+- 语句更新会生成undo log（回滚日志），在哪呢？
+  三个虚线箭头，就是undo log。V1、V2、V3并非物理上真实存在，而是每次需要时，根据当前版本和undo log计算而得。比如，需要V2时，就通过V4依次执行U3、U2计得。
+
+那InnoDB如何定义那个“100G”快照？
+按可重复读定义，一个事务启动时，能够看到所有已提交的事务结果。但之后，该事务执行期间，其他事务的更新对它不可见。
+
+因此，一个事务只需在启动时说，以我启动时刻为准：
+
+- 若一个数据版本是在我启动前生成，就认
+- 启动后才生成，我不认，我必须要找到它的上一个版本。若上个版本也不可见，就继续往前找。若是该事务自己更新的数据，它自己还是要认的。
+
+### 视图数组
+
+InnoDB为每个事务构造了一个数组，以保存该事务启动瞬间，当前正“活跃”（启动了，但尚未提交）的所有事务ID。
+
+在该数组里：
+
+- 事务ID的最小值，记为低水位
+- 当前系统里已创建过的事务ID的最大值加1，记为高水位
+
+这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
+
+而数据版本的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果而得。
+
+该视图数组把所有row trx_id 分成：
+数据版本可见性规则：
+
+![](https://img-blog.csdnimg.cn/20210615102540744.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_SmF2YUVkZ2U=,size_16,color_FFFFFF,t_70)
+
+对于当前事务的启动瞬间，一个数据版本的row trx_id，有如下可能：
+
+1. 若落在绿色，表示该版本是已提交的事务或当前事务自己生成的，这个数据是可见的
+2. 若落在土色，表示该版本是由将来启动的事务生成的，肯定不可见
+3. 若落在黄色，包括两种情况：
+   a. 若 row trx_id在数组中，表示该版本是由尚未提交的事务生成的，不可见
+   b. 若 row trx_id不在数组中，表示该版本是已提交的事务生成的，可见
+
+比如，对于【行状态变更图】的数据，若有一个事务，它的低水位是18，则当它访问这一行数据时，就会从V4通过U3计算出V3，所以在它看来，这一行值是11。
+
+有了该声明后，系统里随后发生的更新，就跟该事务看到的内容无关了。因为之后的更新，生成的版本一定属于上面的2或者3(a)，而对它来说，这些新的数据版本是不存在的，所以这个事务的快照，就是“静态”的了。
+
+所以InnoDB利用了“所有数据都有多版本”的特性，实现了“秒级创建快照”能力。
+
+接下来，我们开始分析一开始的三个事务
+
+## 事务案例分析
+
+假设：
+
+- 事务A开始前，系统里只有一个活跃事务ID=99
+- 事务A、B、C版本号分别是100、101、102，且当前系统里只有这四个事务
+- 三个事务开始前，(1,1）这一行数据的row trx_id是90
+
+于是：
+
+- 事务A的视图数组[99,100]
+- 事务B的视图数组是[99,100,101]
+- 事务C的视图数组是[99,100,101,102]
+
+为简化分析，先把其他干扰语句去掉，只画出跟事务A查询逻辑有关的操作：
+
+事务A查询数据逻辑图：
+
+![](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/MySQL%e5%ae%9e%e6%88%9845%e8%ae%b2/assets/9416c310e406519b7460437cb0c5c149.png)
+
+
+
+- 第一个有效更新是事务C，(1,1)=》(1,2)。这时，该数据的最新版本的row trx_id=102，版本90已成为历史版本
+- 第二个有效更新是事务B，(1,2)=》(1,3)。这时，该数据的最新版本（即row trx_id）=101，版本102成为历史版本
+
+事务A查询时，事务B还没提交，但它生成的(1,3)这版本已变成当前版本。但这版本对事务A必须不可见，否则就变成脏读。
+
+现在事务A要来读数据了，它的视图数组是[99,100]。读数据都是从当前版本读起的。所以，事务A查询语句的读数据流程是这样的：
+
+- 找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见
+- 接着，找到上一个历史版本，一看row trx_id=102，比高水位大，处于红色区域，不可见
+- 再往前找，终于找到了（1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见
+
+这样执行下来，虽然期间这一行数据被修改过，但是事务A不论在什么时候查询，看到这行数据的结果都是一致的，所以称之为一致性读。
+
+一个数据版本，对于一个事务视图来说，除了自己的更新总是可见之外，还有如下情况：
+
+1. 版本未提交，不可见
+2. 版本已提交，但是是在视图创建后提交的，不可见
+3. 版本已提交，而且是在视图创建前提交的，可见。
+
+现在，让我们用这些规则判断查询结果，事务A的查询语句的视图数组是在事务A启动时生成的，这时：
+
+- (1,3)还没提交，属于case1，不可见
+- (1,2)虽然提交了，但却在视图数组创建之后提交，属于case2，不可见
+- (1,1)是在视图数组创建之前提交的，可见
+
+现在只需通过时间先后分析即可。
+
+## 更新逻辑
+
+事务B的update语句，若按一致性读，好像结果不对呢？
+
+你看下图，事务B的视图数组是先生成的，之后事务C才提交，不是应该看不见(1,2)吗，怎么能算出(1,3)？
+
+事务B更新逻辑图：
+
+![](https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/MySQL%e5%ae%9e%e6%88%9845%e8%ae%b2/assets/86ad7e8abe7bf16505b97718d8ac149f.png)
+
+若事务B在更新前查询一次数据，该查询返回的k的值确实是1。
+但当它要去更新数据时，就不能再在历史版本上更新了，否则事务C的更新就丢失了。因此，事务B此时的set k=k+1是在（1,2）的基础上进行的操作。
+
+所以，这里用到规则：**更新数据，都是先读后写。这个读，只能读当前的值，即“当前读”（current read）。**
+
+因此，在更新时，当前读拿到的数据是(1,2)，更新后生成了新版本数据(1,3)，这个新版本的row trx_id是101。
+
+所以，在执行事务B查询语句时，一看自己的版本号是101，最新数据的版本号也是101，是自己的更新，可以直接使用，所以查询得到的k的值是3。
+
+#### 当前读（current read）
+
+除了update语句外，select语句若加锁，也是当前读。
+
+所以，若修改事务A的查询语句
+
+```sql
+select * from t where id=1
+```
+
+加上：
+
+- lock in share mode
+- 或for update
+
+都可读到version=101的数据，返回的k的值是3。
+
+```sql
+// 加了读锁（S锁，共享锁）
+mysql> select k from t where id=1 lock in share mode;
+// 写锁（X锁，排他锁）
+mysql> select k from t where id=1 for update;
+```
+
+假设事务C不是马上提交的，而是变成下面的事务C’，会咋样？
+事务A、B、C'的执行流程：
+
+| 事务A                                       | 事务B                                                        | 事务C'                                                       |
+| ------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| start transaction with consistent snapshot; |                                                              |                                                              |
+|                                             | start transaction with consistent snapshot;                  |                                                              |
+|                                             |                                                              | start transaction with consistent snapshot;<br>update t set k=k+1 where id=1; |
+|                                             | update t set k=k+1 where id=1;<br>select k from t where id=1; |                                                              |
+| select k from t where id=1;<br>commit;      |                                                              | commit;                                                      |
+|                                             | commit;                                                      |                                                              |
+
+事务C’不同在于更新后并没有马上提交，在它提交前，事务B的更新语句先发起了。前面说过了，虽然事务C’还没提交，但(1,2)这个版本也已经生成了，并且是当前的最新版本。
+
+### 事务B的更新语句会咋处理？
+
+“两阶段锁协议”。事务C’没提交，即(1,2)这个版本上的写锁还没释放。而事务B是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务C’释放这个锁，才能继续它的当前读。
+
+事务B更新逻辑图（配合事务C'）：
+
+![](https://p.ipic.vip/7zdjb8.png)
+
+至此，一致性读、当前读和行锁就串起来了。
+
+## 事务咋实现可重复读？
+
+- 可重复读的核心是一致性读（consistent read）
+- 而事务更新数据时，只能用当前读
+
+若当前记录的行锁被其他事务占用，需进入锁等待。
+
+RC和RR最主要区别：
+
+- RR，事务开始时创建一致性视图，之后事务里的其他查询都共用该一致性视图
+- RC，每个语句执行前都会重新算出一个新视图
+
+RC下的事务A、B的查询语句查到的k，分别是啥呢？
+
+```sql
+# 从这语句开始，创建一个持续整个事务的一致性快照
+start transaction with consistent snapshot; 
+```
+
+所以，RC下的这个用法就没意义，等于普通的start transaction。
+
+#### RC时的状态图
+
+这两个查询语句的创建视图数组的时机发生了变化，即图中的read view框。（这用的还是事务C的逻辑直接提交，而非事务C’）
+
+RC下的事务状态图：
+
+![](https://p.ipic.vip/9rwszj.png)
+
+事务A的查询语句的视图数组，是在执行这语句时创建的。时序上(1,2)、(1,3)的生成时间都在创建这个视图数组的时刻之前。但在这个时刻：
+
+- (1,3)还没提交，属于情况1，不可见
+- (1,2)提交了，属于情况3，可见
+
+所以，此时：
+
+- 事务A查询语句返回的是k=2
+- 事务B查询结果k=3
+
+## 总结
+
+InnoDB的行数据有多个版本，每个数据版本有自己的row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据`row trx_id`和`一致性视图`确定数据版本的可见性。
+
+- RR：查询只承认在事务启动前，就已提交完成的数据
+- RC：查询只承认在语句启动前，就已提交完成的数据
+- 当前读：总读取已提交完成的最新版本
+
+Q：为啥表结构不支持“可重复读”？
+
+A：表结构没有对应的行数据，也没row trx_id，因此只能遵循当前读的逻辑。MySQL 8.0已可将表结构放在InnoDB字典里了，也许以后会支持表结构的可重复读。
\ No newline at end of file
diff --git a/docs/md/mysql/optimize-slow-queries-massive-row-deletions.md b/docs/md/mysql/optimize-slow-queries-massive-row-deletions.md
new file mode 100644
index 0000000000..8a44e50ac2
--- /dev/null
+++ b/docs/md/mysql/optimize-slow-queries-massive-row-deletions.md
@@ -0,0 +1,105 @@
+# 千万级数据删除导致的慢查询优化
+
+## 0 前言
+
+有人删了千万级的数据，结果导致频繁的慢查询。
+
+线上收到大量慢查询告警，于是检查慢查询的SQL，发现不是啥复杂SQL，这些SQL主要针对一个表，基本都是单行查询，看起来应该不会有慢查询。这种SQL基本上都是直接根据索引查找出来的，性能应该极高。
+
+是否可能慢查询不是SQL问题，而是MySQL生产服务器的问题？特殊情况下，MySQL出现慢查询还真不是SQL问题，而是他自己生产服务器的负载太高，导致SQL语句执行慢。比如现在MySQL服务器的
+
+## 1 磁盘I/O
+
+磁盘I/O负载高，每秒执行大量高负载的随机I/O，但磁盘本身每秒能执行的随机I/O有限，导致正常SQL在磁盘执行时，若跑一些随机IO，你的磁盘太忙，顾不上你了，导致你本来很快的一个SQL，要等很久才能执行完毕，这时就可能导致正常SQL也变成慢查询。
+
+## 2 网络
+
+也许网络负载高，导致你一个SQL语句要发到MySQL，光是等待获取一个和MySQL的连接，都很难，要等很久或MySQL自己网络负载太高，带宽打满，带宽打满后，你一个SQL也许执行很快，但其查出来的数据返回给你，网络都送不出去，也会变成慢查询。
+
+## 3 CPU
+
+若CPU负载过高，也会导致CPU过于繁忙去执行别的任务，没时间执行你的SQL。
+
+所以慢查询不一定是SQL本身导致，若觉得SQL不应该会慢查询，结果他那个时间段跑这个SQL  就是慢，应排查当时MySQL服务器的负载，尤其看看磁盘、网络及 CPU 的负载，是否正常。
+
+## 4 案例
+
+当某个离线作业瞬间大批量把数据往MySQL里灌入的时，他一瞬间服务器磁盘、网络以及CPU的负载会超高。
+
+此时你一个正常SQL执行下去，短时间内一定会慢查询，类似问题，优化手段更多是控制你导致MySQL负载过高的那些行为，比如灌入大量数据，最好在业务低峰期灌入，别影响高峰期的线上系统运行。
+
+但看了下MySQL服务器的磁盘、网络以及CPU负载，一切正常，似乎也不是这问题导致。看起来无解了？
+
+## 5 总结
+
+慢 SQL 的头两步排查手段：
+
+- 检查SQL是否有问题，看执行计划
+- 检查MySQL服务器的负载
+
+这两种办法都不奏效之后，第三步：用MySQL proﬁlling工具去细致的分析SQL语句的执行过程和耗时。
+
+这个工具可以对SQL语句的执行耗时进行非常深入和细致的分析
+
+## 6 使用
+
+打开proﬁling，使用
+
+```sql
+set proﬁling=1
+```
+
+接着MySQL就会自动记录查询语句的proﬁling信息。此时若执行show   proﬁles，就会给你列出各种查询语句的proﬁling信息，会记录下来每个查询语句的query   id，所以你要针对你需要分析的query找到对他的query   id，我们当时就是针对慢查询的那个SQL语句找到了query id。
+
+然后针对单个查询语句，看其proﬁling信息，使用show proﬁle cpu, block io for query xx，这里的xx是数字，此时就可以看到具体的proﬁle信息。
+
+除了cpu以及block  io以外，还能指定去看这个SQL语句执行时候的其他各项负载和耗时。
+
+会给你展示出来SQL语句执行时候的各种耗时，比如磁盘IO的耗时，CPU等待耗时，发送数据耗时，拷贝数据到临时表的耗时等，SQL执行过程中的各种耗时都会展示。
+
+检查该SQL语句的proﬁling信息后，发现问题，其Sending Data耗时最高，几乎使用1s，占据SQL执行耗时的99%！其他环节耗时低可以理解，毕竟这种简单SQL执行速度真的很快，基本就是10ms级别，结果跑成1s，那肯定Sending Data就是问题根源！
+
+这Sending Data在干啥呢？
+
+MySQL官方释义：为一个SELECT语句读取和处理数据行，同时发送数据给客户端的过程，简单来说就是为你的SELECT语句把数据读出来，同时发送给客户端。
+
+但这过程为啥这么慢？proﬁling确实是提供给我们更多的线索了，但似乎还是没法解决问题。但已经捕获到异常关键点，就是Sending  Data的耗时很高！
+
+接着：
+
+```sql
+show engine innodb status
+```
+
+看innodb存储引擎的一些状态，此时发现一个奇怪的指标：history list length，值特别高，达到上万。
+
+MVCC就是多个事务在对同一个数据， 有人写，有人读，此时可以有多种隔离级别，对一个数据有个多版本快照链条，才能实现MVCC和各种隔离级别。
+
+所以当你有大量事务执行时，就会构建这种undo多版本快照链条，此时history list length就会很高。然后在事务提交后，会有一个多版本快照链条的自动purge清理机制，清理了，该值就会降低。一般该值不应过高，所以注意到第二个线索：history list length过高，即大量的undo多版本链条数据没有清理。推测可能有的事务长时间运行，所以其多版本快照不能被purge清理，进而导致history list length过高。
+
+经过这俩线索推测，在大量简单SQL变成慢查询时，SQL因为Sending  Data环节异常，耗时过高；同时此时出现一些长事务长时间运行，大量的频繁更新数据，导致有大量undo多版本快照链条，还无法purge清理。
+
+## 7 这俩线索之间的关系是啥？
+
+因为发现有大量的更新语句在活跃，而且有那种长期活跃的长事务一直在跑而没有结束，问了下系统负责人，在后台跑了个定时任务：他居然开了一个事务，然后在一个事务里删除上千万数据，导致该事务一直在运行。
+
+这种长事务的运行会导致你删除时，仅只是对数据加了一个删除标记，事实上并没有彻底删除。此时你若和长事务同时运行的其它事务里再查询，他在查询时可能会把那上千万被标记为删除的数据都扫描一遍。因为每次扫描到一批数据，都发现标记为删除了，接着就会再继续往下扫描，所以才导致一些查询语句很慢。
+
+那为何你启动一个事务，在事务里查询，凭什么就要去扫描之前那个长事务标记为删除状态的上千万的垃圾数据？讲道理，那些数据都被删了，跟你没关系了呀，你可以不去扫描他们 嘛！
+
+### 问题症结
+
+那删除千万级数据的事务是长事务！当你启动新事务查询时，那删除千万级数据的长事务一直在运行，它是活跃的！结合MVCC Read View机制，当你启动一个新事务查询时，会生成一个Read View。新事务查询时，会根据ReadView判断：
+
+- 哪些数据可见
+- 可见的数据版本号
+
+因为每个数据都有版本链，有时你可见的仅是该数据的一个历史版。
+
+所以，正是该长事务一直在运行，还在删除大量数据，而这些数据仅是逻辑删除，此时你新开事务的查询还是会读到所有逻辑删除数据，也就会出现千万级数据扫描，导致慢查询！
+
+所以禁止业务高峰期运行删除大量数据的语句，因其可能导致正常SQL都变慢查询，因为那些SQL也许会不断扫描你标记为删除的大量数据，好不容易扫描到一批数据，结果发现是标记为删除的，于是继续扫描下去，导致慢查询！
+
+## 8 解决方案
+
+直接kill那个正在删除千万级数据的长事务，所有SQL很快恢复正常。此后，大量数据清理全部放在凌晨执行，那个时候就没什么人使用系统了，所以查询也很少。
\ No newline at end of file
diff --git "a/docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md" b/docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
similarity index 86%
rename from "docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md"
rename to docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
index ab04d4d1ae..d4c6de7538 100644
--- "a/docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md"
+++ b/docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
@@ -28,11 +28,15 @@ java -Xss256k -jar demo-0.0.1-SNAPSHOT.jar
 
 线程栈大小指定256KB。对于测试程序，os默认值8192KB过大，因为需要创建4096个线程。
 
-top看到Java进程CPU使用率达961.6%，注意进程ID 55790：
+#### top
+
+见Java进程CPU使用率爆表：
 
 ![](https://img-blog.csdnimg.cn/ccc4bf66ef604b20a0875593d571c134.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_SmF2YUVkZ2U=,size_16,color_FFFFFF,t_70)
 
-精细化top查看这Java进程中各线程使用CPU情况：
+#### top细查
+
+这进程的各线程使用CPU情况：
 
 ```java
 $ top -H -p 55790
@@ -40,13 +44,17 @@ $ top -H -p 55790
 
 ![](https://img-blog.csdnimg.cn/513921500f344102b8857b0cf937b6f4.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_SmF2YUVkZ2U=,size_16,color_FFFFFF,t_70)
 
-有个“scheduling-1”线程占用较多CPU。下一步就找出这个线程在做啥。jstack生成线程快照。jstack输出较大，一般将其写入文件：
+“scheduling-1”线程占较多CPU。找这线程在做啥。
+
+#### jstack生成线程快照
+
+jstack输出较大，一般将其写入文件：
 
 ```java
 jstack 55790 > 55790.log
 ```
 
-打开55790.log，定位到第4步中找到的名为 **scheduling-1** 的线程，其线程栈：
+打开log并定位到第4步中找到的名为 **scheduling-1** 的线程，其线程栈：
 
 ![](https://img-blog.csdnimg.cn/fa069dc8e34e4c209d72b5b9a6fa8c40.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_SmF2YUVkZ2U=,size_16,color_FFFFFF,t_70)
 
@@ -89,5 +97,6 @@ grep -o 'pool-2-thread' 55790.log | wc -l
 
 ## 总结
 
-遇到CPU过高，首先定位哪个进程导致，之后可通过top -H -p pid命令定位到具体的线程。
-其次还要通jstack查看线程的状态，看看线程的个数或者线程的状态，如果线程数过多，可以怀疑是线程上下文切换的开销，我们可以通过vmstat和pidstat这两个工具进行确认。
\ No newline at end of file
+CPU过高，先定位啥进程导致，之后top -H -p pid定位具体线程。
+
+还要jstack查看线程状态，看线程个数或线程状态，若线程数过多，可怀疑是线程上下文切换开销，可通过vmstat和pidstat确认。
\ No newline at end of file
