![\"AIGuide](\"https://oss.javaguide.cn/github/aiguide/aiguide-overview.png\")
CodingMap 是协奏曲维护的开发者知识库，本页整理系统化的前端、后端、Java、计算机基础、数据库、分布式、系统设计与 AI 应用开发资料。当前内容以 Java 与后端工程为主，后续会继续补充前端开发、项目复盘和原创学习笔记。
\n如果你正在准备校招、社招或跳槽面试，可以按下面的模块逐步复习高频开发基础、工程实践和面试题。
\n本站 UI、工程搭建和学习整理方式参考 JavaGuide 与 面试鸭；因个人学习、整理笔记与沉淀知识体系而开发(注意：本站的内容只适合有一定基础的同学查看，如您从未学过或看过，那么请你去JavaGuide或者面试鸭进行问题的详解)，本站内容由 CodingMap 自行编写与维护。
\n知识点/面试题总结 : (必看👍 )：
\n\n重要知识点详解：
\n知识点/面试题总结：
\n源码分析：
\n知识点/面试题总结 : (必看 👍)
\n\n重要知识点详解：
\nJVM 这部分内容主要参考 JVM 虚拟机规范-Java8 和周志明老师的《深入理解 Java 虚拟机（第 3 版）》 （强烈建议阅读多遍！）。
\n\n\n计算机基础（计算机网络、操作系统、数据结构与算法）已独立为单独模块，详见 计算机基础知识总结。
\n
知识点/面试题总结：
\n重要知识点：
\n知识点/面试题总结 : (必看👍 )：
\n\n重要知识点：
\nGradle 核心概念总结（可选，目前国内还是使用 Maven 普遍一些）
\n知识点/面试题总结 :
\n\n重要知识点详解：
\n\n\n\n\n这两篇文章可能有内容重合部分，推荐都看一遍。
\n
相同的服务部署多份，避免单点故障。
\n灾备 = 容灾 + 备份。
\n异地多活 描述的是将服务部署在异地并且服务同时对外提供服务。和传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。异地多活是为了应对突发状况比如火灾、地震等自然或者人为灾害。
\n", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [] }, { "title": "AI 应用开发知识体系：大模型、Agent、RAG、MCP、Prompt 工程与系统设计", "url": "https://codingmap.strova.top/ai/", "id": "https://codingmap.strova.top/ai/", "summary": "AI 应用开发面试与学习路线，面向后端开发者梳理大模型调用、Agent、RAG、MCP、Prompt 工程、向量数据库、评测和系统设计。重点围绕 适合谁看、几个容易踩坑的地方、建议阅读顺序、核心文章、AI 等内容展开。结合 CodingMap 知识体系梳理 AI 的核心概念、实践方法、常见问题和高频面试考点等核心内容。", "content_html": "做 AI 应用不是把 Prompt 塞进接口就结束了。真到项目里，马上会遇到上下文长度、结构化输出、RAG 召回、工具权限、评测回归、成本和稳定性这些问题。
\n这些问题没法各解各的。大模型基础、Agent、RAG、工具调用、系统设计必须连起来理解——只懂调用 API，到了架构评审会卡住；只熟 RAG 论文，到了知识库维护还是不知道怎么处理增量更新和版本去重。
\n如果时间有限，先看 AI 应用开发面试指南，把大模型、Agent、RAG、MCP 和 AI 系统设计里最容易被追问的问题过一遍；如果想补得扎实一些，再按下面的阅读顺序推进。
\n这应该是当前最全面系统的讲解，每一篇都花费了大量时间完善和优化，每篇文章都画了大量配图辅助理解：
\n
本专栏所属 AIGuide 项目，对标 JavaGuide 质量（免费开源，欢迎 Star 鼓励）：
\n\n发布之后，也是收到了很多读者朋友的好评和推荐。非常感谢，一定会持续用心维护！
\n![\"AIGuide](\"https://oss.javaguide.cn/github/aiguide/ai-guide-received-many-positive-reviews-and-recommendations-from-readers.png\")
大模型真不能只当成一个黑盒 API 来调。Token 被截断、采样参数一变输出就飘、说好返回 JSON 结果还是乱了，这些问题靠 Prompt 很难彻底兜住。你在提示词里加一句“请严格按照 JSON 输出”，只能算第一层约束，真正上线时还是得在调用链路里做格式校验、重试、兜底和异常处理。
\nAgent 也不是能自动调工具就完事了。真正难的是 Memory 和 Context Engineering。上下文没管好，Agent 跑几轮之后就容易偏题，前面说过什么、当前任务做到哪一步、哪些工具结果还能用，全都可能乱掉。长任务里更明显，有时候它不是不会做，而是循环几次之后自己把自己绕进去了，一直跑到 token 快耗完才停。
\nRAG 答非所问，很多时候也别急着怪模型。大部分问题其实出在召回阶段：Chunk 切得太粗、Query 没改写、关键词检索和向量检索没结合、重排没做好。这个时候一项一项排查召回链路，往往比直接换一个更贵的模型有用。
\nMCP、Function Calling、Tool Calling 这些东西，解决的是工具怎么接进来的问题。协议统一之后，接工具确实方便了，但真到生产环境，麻烦的地方反而在后面：谁能调用这个工具、能操作哪些数据、调用记录怎么审计、失败了怎么回滚。这些如果没设计好，协议再标准也不够用。
\nAI 应用一旦上线，稳定性、可观测、成本控制、质量回归这些问题都会冒出来。Demo 阶段通常感受不到，因为调用量小、场景也干净。等真正接到业务流量里，第一次做生产级 AI 应用的团队，基本都会被这些问题教育一次。
\n这份 技术书籍精选 面向程序员系统学习和长期成长，整理 Java、数据库、分布式系统、计算机基础、搜索引擎、软件质量等方向的优质书单。
\n书单来自开源项目 CodingDocs/awesome-cs，会持续更新。欢迎在项目 issues 区 推荐你认可的技术书籍，一起维护一个更高质量的中文技术书单。
\n考虑到很多同学比较喜欢看视频，因此，这部分内容我不光会推荐书籍，还会顺便推荐一些我觉得不错的视频教程和各大高校的 Project。
\n为什么要学习操作系统？
\n从对个人能力方面提升来说，操作系统中的很多思想、很多经典的算法，你都可以在我们日常开发使用的各种工具或者框架中找到它们的影子。比如说我们开发的系统使用的缓存（比如 Redis）和操作系统的高速缓存就很像。CPU 中的高速缓存有很多种，不过大部分都是为了解决 CPU 处理速度和内存处理速度不对等的问题。我们还可以把内存可以看作外存的高速缓存，程序运行的时候我们把外存的数据复制到内存，由于内存的处理速度远远高于外存，这样提高了处理速度。同样地，我们使用的 Redis 缓存就是为了解决程序处理速度和访问常规关系型数据库速度不对等的问题。高速缓存一般会按照局部性原理（2-8 原则）根据相应的淘汰算法保证缓存中的数据是经常会被访问的。我们平常使用的 Redis 缓存很多时候也会按照 2-8 原则去做，很多淘汰算法都和操作系统中的类似。既说了 2-8 原则，那就不得不提命中率了，这是所有缓存概念都通用的。简单来说也就是你要访问的数据有多少能直接在缓存中直接找到。命中率高的话，一般表明你的缓存设计比较合理，系统处理速度也相对较快。
\n从面试角度来说，尤其是校招，对于操作系统方面知识的考察是非常非常多的。
\n简单来说，学习操作系统能够提高自己思考的深度以及对技术的理解力，并且，操作系统方面的知识也是面试必备。
\n如果你要系统地学习操作系统的话，最硬核最权威的书籍是 《操作系统导论》 。你可以再配套一个 《深入理解计算机系统》 加深你对计算机系统本质的认识，美滋滋！
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20201012191645919.png\")
另外，去年新出的一本国产的操作系统书籍也很不错：《现代操作系统：原理与实现》 （夏老师和陈老师团队的力作，值得推荐）。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210406132050845.png\")
如果你比较喜欢动手，对于理论知识比较抵触的话，我推荐你看看 《30 天自制操作系统》 ，这本书会手把手教你编写一个操作系统。
\n纸上学来终觉浅 绝知此事要躬行！强烈推荐 CS 专业的小伙伴一定要多多实践！！！
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409123802972.png\")
其他相关书籍推荐：
\n如果你比较喜欢看视频的话，推荐哈工大李治军老师主讲的慕课 《操作系统》，内容质量吊打一众国家精品课程。
\n课程的大纲如下：
\n![\"课程大纲\"](\"https://oss.javaguide.cn/github/javaguide/books/image-20220414144527747.png\")
主要讲了一个基本操作系统中的六个基本模块：CPU 管理、内存管理、外设管理、磁盘管理与文件系统、用户接口和启动模块 。
\n课程难度还是比较大的，尤其是课后的 lab。如果大家想要真正搞懂操作系统底层原理的话，对应的 lab 能做尽量做一下。正如李治军老师说的那样：“纸上得来终觉浅，绝知此事要躬行”。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/image-20220414145210679.png\")
如果你能独立完成几个 lab 的话，我相信你对操作系统的理解绝对要上升几个台阶。当然了，如果你仅仅是为了突击面试的话，那就不需要做 lab 了。
\n说点心里话，我本人非常喜欢李治军老师讲的课，我觉得他是国内不可多得的好老师。他知道我们国内的教程和国外的差距在哪里，也知道国内的学生和国外学生的差距在哪里，他自己在努力着通过自己的方式来缩小这个差距。真心感谢，期待李治军老师的下一个课程。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/image-20220414145249714.png\")
还有下面这个国外的课程 《深入理解计算机系统 》 也很不错。
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20201204140653318.png\")
计算机网络是一门系统性比较强的计算机专业课，各大名校的计算机网络课程打磨的应该都比较成熟。
\n要想学好计算机网络，首先要了解的就是 OSI 七层模型或 TCP/IP 五层模型，即应用层（应用层、表示层、会话层）、传输层、网络层、数据链路层、物理层。
\n![\"osi七层模型\"](\"https://oss.javaguide.cn/github/javaguide/booksosi七层模型2.png\")
关于这门课，首先强烈推荐参考书是机械工业出版社的《计算机网络——自顶向下方法》。该书目录清晰，按照 TCP/IP 五层模型逐层讲解，对每层涉及的技术都展开了详细讨论，基本上高校里开设的课程的教学大纲就是这本书的目录了。
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409123250570.png\")
如果你觉得上面这本书看着比较枯燥的话，我强烈推荐+安利你看看下面这两本非常有趣的网络相关的书籍：
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20201011215144139.png\")
除了理论知识之外，学习计算机网络非常重要的一点就是：“动手实践”。这点和我们编程差不多。
\nGitHub 上就有一些名校的计算机网络试验/Project：
\n我知道，还有很多小伙伴可能比较喜欢边看视频边学习。所以，我这里再推荐几个顶好的计算机网络视频讲解。
\n1、哈工大的计算机网络课程：国家精品课程，截止目前已经开了 10 次课了。大家对这门课的评价都非常高！所以，非常推荐大家看一下！
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20201218141241911.png\")
2、王道考研的计算机网络：非常适合 CS 专业考研的小朋友！这个视频目前在哔哩哔哩上已经有 1.6w+ 的点赞。
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20201218141652837.png\")
先来看三本入门书籍。 这三本入门书籍中的任何一本拿来作为入门学习都非常好。
\n![](\"https://oss.javaguide.cn/java-guide-blog/image-20210327104418851.png\")
我个人比较倾向于 《我的第一本算法书》 这本书籍，虽然它相比于其他两本书集它的豆瓣评分略低一点。我觉得它的配图以及讲解是这三本书中最优秀，唯一比较明显的问题就是没有代码示例。但是，我觉得这不影响它是一本好的算法书籍。因为本身下面这三本入门书籍的目的就不是通过代码来让你的算法有多厉害，只是作为一本很好的入门书籍让你进入算法学习的大门。
\n再推荐几本比较经典的算法书籍。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409123422140.png\")
这本书内容非常清晰易懂，适合数据结构和算法小白阅读。书中把一些常用的数据结构和算法都介绍到了！
\n我在大二的时候被我们的一个老师强烈安利过！自己也在当时购买了一本放在宿舍，到离开大学的时候自己大概看了一半多一点。因为内容实在太多了！另外，这本书还提供了详细的 Java 代码，非常适合学习 Java 的朋友来看，可以说是 Java 程序员的必备书籍之一了。
\n\n\n\n下面这些书籍都是经典中的经典，但是阅读起来难度也比较大，不做太多阐述，神书就完事了！
\n如果你仅仅是准备算法面试的话，不建议你阅读下面这些书籍。
\n
![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409145334093.png\")
经典名著，ACM 冠军、亚军这种算法巨佬都强烈推荐的一本书籍。这本书的作者也非常厉害，Java 之父 James Gosling 就是他的学生。
\n很多人都说这本书不是教你具体的算法，而是教你一种编程的思考方式。这种思考方式不仅仅在编程领域适用，在其他同样适用。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409145411049.png\")
这是一本被 GitHub 上的爆火的计算机自学项目 Teach Yourself Computer Science 强烈推荐的一本算法书籍。
\n类似的神书还有 《算法导论》、《计算机程序设计艺术（第 1 卷）》 。
\n如果说你要准备面试的话，下面这几本书籍或许对你有帮助！
\n\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409145506482.png\")
这本面试宝典上面涵盖了很多经典的算法面试题，如果你要准备大厂面试的话一定不要错过这本书。
\n《剑指 Offer》 对应的算法编程题部分的开源项目解析：CodingInterviews 。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409145622758.png\")
《程序员代码面试指南（第 2 版）》里的大部分题目相比于《剑指 offer》 来说要难很多，题目涵盖面相比于《剑指 offer》也更加全面。全书一共有将近 300 道真实出现过的经典代码面试题。
\n视频的话，推荐北京大学的国家精品课程—程序设计与算法（二）算法基础，讲的非常好！
\n![](\"https://oss.javaguide.cn/github/javaguide/books/22ce4a17dc0c40f6a3e0d58002261b7a.png\")
这个课程把七种基本的通用算法（枚举、二分、递归、分治、动态规划、搜索、贪心）都介绍到了。各种复杂算法问题的解决，都可能用到这些基本的思想。并且，这个课程的一部分的例题和 ACM 国际大学生程序设计竞赛中的中等题相当，如果你能够解决这些问题，那你的算法能力将超过绝大部分的高校计算机专业本科毕业生。
\n其实，上面提到的很多算法类书籍（比如 《算法》 和 《算法导论》）都详细地介绍了常用的数据结构。
\n我这里再另外补充基本和数据结构相关的书籍。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409145803440.png\")
入门类型的书籍，读起来比较浅显易懂，适合没有数据结构基础或者说数据结构没学好的小伙伴用来入门数据结构。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409145823973.png\")
质量很高，介绍了常用的数据结构和算法。
\n类似的还有 《数据结构与算法分析：C 语言描述》、《数据结构与算法分析：C++ 描述》
\n![](\"https://oss.javaguide.cn/github/javaguide/books/d9c450ccc5224a5fba77f4fa937f7b9c.png\")
视频的话推荐你看浙江大学的国家精品课程—《数据结构》 。
\n姥姥的数据结构讲的非常棒！不过，还是有一些难度的，尤其是课后练习题。
\n数学和英语属于通用课，一般在大一和大二两学年就可以全部修完，大二大三逐渐接触专业课。通用课作为许多高中生升入大学的第一门课，算是高中阶段到本科阶段的一个过渡，从职业生涯重要性上来说，远不及专业课重要，但是在本科阶段的学习生活规划中，有着非常重要的地位。由于通用课的课程多，学分重，占据了本科阶段绩点的主要部分，影响到学生在前两年的专业排名，也影响到大三结束时的推免资格分配，也就是保研。而从升学角度来看，对于攻读研究生和博士生的小伙伴来说，数学和英语这两大基础课，还是十分有用的。
\n微积分，即传说中的高数，成为了无数新大一心中的痛。但好在，大学的课程考核没那么严格，期末想要拿高分，也不至于像高中那样刷题刷的那么狠。微积分对于计算机专业学生的重要性，主要体现在计算机图形学中的函数变换，机器学习中的梯度算法，信号处理等领域。
\n微积分的知识体系包括微分和积分两部分，一般会先学微分，再学积分，也有的学校把高数分为两个学期。微分就是高中的导数的升级版，对于大一萌新来说还算比较友好。积分恰好是微分的逆运算，思想上对大一萌新来说比较新，一时半会可能接受不了。不过这门课所有的高校都有开设，而且大部分的名校都有配套的网课，教材也都打磨的非常出色，结合网课和教材的“啃书”学习模式，这门课一定不会落下。
\n书籍的话，推荐《普林斯顿微积分读本》。这本书详细讲解了微积分基础、极限、连续、微分、导数的应用、积分、无穷级数、泰勒级数与幂级数等内容。
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409155056751.png\")
线性代数的思维模式就更加复杂了一些，它定义了一个全新的数学世界，所有的符号、定理都是全新的，唯一能尝试的去理解的方式，大概就是用几何的方式去理解线性代数了。由于线性代数和几何学有着密不可分的关系，比如空间变换的理论支撑就是线性代数，因此，网上有着各种“可视化学习线性代数”的学习资源，帮助理解线性代数的意义，有助于公式的记忆。
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409153940473.png\")
书籍的话，推荐中科大李尚志老师的 《线性代数学习指导》 。
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409155325251.png\")
对于计算机专业的小伙伴来说，这门课可能是概率论更有用一点，而非数理统计。可能某些学校只开设概率论课程，也可能数理统计也教，但仅仅是皮毛。概率论的学习路线和微积分相似，就是一个个公式辅以实例，不像线性代数那么抽象，比较贴近生活。在现在的就业形势下，概率论与数理统计专业的学生，应该是数学专业最好就业的了，他们通常到岗位上会做一些数据分析的工作，因此，这门课程确实是数据分析的重要前置课程，概率论在机器学习中的重要性也就不言而喻了。
\n书籍的话，推荐 《概率论与数理统计教程》 。这本书共八章，前四章为概率论部分，主要叙述各种概率分布及其性质，后四章为数理统计部分，主要叙述各种参数估计与假设检验。
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409155738505.png\")
离散数学是计算机专业的专属数学，但实际上对于本科毕业找工作的小伙伴来说，离散数学还并没有发挥它的巨大作用。离散数学的作用主要在在图研究等领域，理论性极强，需要读研深造的小伙伴尽可能地扎实掌握。
\n英语算是大学里面比较灵活的一项技能了，有的人会说，“英语学的越好，对个人发展越有利”，此话说的没错，但是对于一些有着明确发展目标的小伙伴，可能英语技能并不在他们的技能清单内。接下来的这些话只针对计算机专业的小伙伴们哦。
\n英语课在大学本科一般只有前两年开设，小伙伴们可以记住，想用英语课来提升自己的英语水平的，可以打消这个念头了。 英语水平的提高全靠自己平时的积累和练习，以及有针对性的刷题。
\n英语的大学四六级一定要过。 这是必备技能，绝大部分就业岗位都要看四六级水平的，最起码要通过的。四级比高中英语稍微难一些，一般的小伙伴可能会卡在六级上，六级需要针对性的训练一下，因为大学期间能接触英语的实在太少了，每学期一门英语课是不足以保持自己的英语水平的。对于一些来自于偏远地区，高中英语基础薄弱的，考四六级会更加吃力。建议考前集中训练一下历年真题，辅以背一下高频词汇，四六级通过只需要 425 分，这个分数线还是比较容易达到的。稍微好一点的小伙伴可能冲一下 500 分，要是能考到 600 分的话，那是非常不错的水平了，算是简历上比较有亮点的一项。
\n英语的雅思托福考试只限于想要出国的小伙伴，以及应聘岗位对英语能力有特殊要求的。雅思托福考试裸考不容易通过，花钱去比较靠谱的校外补课班应该是一个比较好的选择。
\n对于计算机专业的小伙伴来说，英语能力还是比较重要的，虽然应聘的时候不会因为没有雅思托福成绩卡人，但是你起码要能够：
\n毕竟计算机语言就是字符语言，听说读写中最起码要满足读写这两项不过分吧。
\n编译原理相比于前面介绍的专业课，地位显得不那么重要了。编译原理的重要性主要体现在：
\n编译原理的重要前置课程就是形式语言与自动机，自动机的思想在词法分析当中有着重要应用，学习了这门课后，应该就会发现许多场景下，自动机算法的妙用了。
\n总的来说，这门课对于各位程序员的职业发展来说，相对不那么重要，但是从难度上来说，学习这门课可以对编程思想有一个较好的巩固。学习资源的话，除了课堂上的幻灯片课件以外，还可以把 《编译原理》 这本书作为参考书，用以辅助自己学不懂的地方（大家口中的龙书，想要啃下来还是有一定难度的）。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210406152148373.png\")
其他书籍推荐:
\n\n我上面推荐的书籍的难度还是比较高的，真心很难坚持看完。这里强烈推荐哈工大的编译原理视频课程，真心不错，还是国家精品课程，关键还是又漂亮有温柔的美女老师讲的！
\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210406152847824.png\")
数据库基础这块，如果你觉得书籍比较枯燥，自己坚持不下来的话，我推荐你可以先看看一些不错的视频，北京师范大学的《数据库系统原理》、哈尔滨工业大学的《数据库系统（下）：管理与技术》就很不错。
\n《数据库系统原理》这个课程的老师讲的非常详细，而且每一小节的作业设计的也与所讲知识很贴合，后面还有很多配套实验。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/up-e113c726a41874ef5fb19f7ac14e38e16ce.png\")
如果你比较喜欢动手，对于理论知识比较抵触的话，推荐你看看《如何开发一个简单的数据库》 ，这个 project 会手把手教你编写一个简单的数据库。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/up-11de8cb239aa7201cc8d78fa28928b9ec7d.png\")
GitHub 上也已经有大佬用 Java 实现过一个简易的数据库，介绍的挺详细的，感兴趣的朋友可以去看看。地址：https://github.com/alchemystar/Freedom 。
\n除了这个用 Java 写的之外，db_tutorial 这个项目是国外的一个大佬用 C 语言写的，朋友们也可以去瞅瞅。
\n只要利用好搜索引擎，你可以找到各种语言实现的数据库玩具。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/up-d32d853f847633ac7ed0efdecf56be1f1d2.png\")
纸上学来终觉浅 绝知此事要躬行！强烈推荐 CS 专业的小伙伴一定要多多实践！！！
\n《数据库系统概念》这本书涵盖了数据库系统的全套概念，知识体系清晰，是学习数据库系统非常经典的教材！不是参考书！
\n![](\"https://oss.javaguide.cn/github/javaguide/booksimage-20220409150441742.png\")
如果你也想要研究 MySQL 底层原理的话，我推荐你可以先阅读一下《数据库系统实现》。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/database-system-implementation.png\")
不管是 MySQL 还是 Oracle ，它们总体的架子是差不多的，不同的是其内部的实现比如数据库索引的数据结构、存储引擎的实现方式等等。
\n这本书有些地方还是翻译的比较蹩脚，有能力看英文版的还是建议上手英文版。
\n《数据库系统实现》 这本书是斯坦福的教材，另外还有一本《数据库系统基础教程》是前置课程，可以带你入门数据库。
\n我们网站或者 APP 的数据都是需要使用数据库来存储数据的。
\n一般企业项目开发中，使用 MySQL 比较多。如果你要学习 MySQL 的话，可以看下面这 3 本书籍：
\n![](\"https://oss.javaguide.cn/github/javaguide/books/up-3d31e762933f9e50cc7170b2ebd8433917b.png\")
视频的话，你可以看看动力节点的 《MySQL 数据库教程视频》。这个视频基本上把 MySQL 的相关一些入门知识给介绍完了。
\n另外，强推一波 《MySQL 是怎样运行的》 这本书，内容很适合拿来准备面试。讲的很细节，但又不枯燥，内容非常良心！
\n![](\"https://oss.javaguide.cn/github/javaguide/csdn/20210703120643370.png\")
和 MySQL 一样，PostgreSQL 也是开源免费且功能强大的关系型数据库。PostgreSQL 的 Slogan 是“世界上最先进的开源关系型数据库” 。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/image-20220702144954370.png\")
最近几年，由于 PostgreSQL 的各种新特性过于优秀，使用 PostgreSQL 代替 MySQL 的项目越来越多了。
\n如果你还在纠结是否尝试一下 PostgreSQL 的话，建议你看看这个知乎话题：PostgreSQL 与 MySQL 相比，优势何在？ - 知乎 。
\n《PostgreSQL 指南：内幕探索》这本书主要介绍了 PostgreSQL 内部的工作原理，包括数据库对象的逻辑组织与物理实现，进程与内存的架构。
\n刚工作那会需要用到 PostgreSQL ，看了大概 1/3 的内容，感觉还不错。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/PostgreSQL-Guide.png\")
《PostgreSQL 技术内幕：查询优化深度探索》这本书主要讲了 PostgreSQL 在查询优化上的一些技术实现细节，可以让你对 PostgreSQL 的查询优化器有深层次的了解。
\n![\"《PostgreSQL](\"https://oss.javaguide.cn/github/javaguide/books/PostgreSQL-TechnologyInsider.png\")
Redis 就是一个使用 C 语言开发的数据库，不过与传统数据库不同的是 Redis 的数据是存在内存中的 ，也就是它是内存数据库，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。
\n如果你要学习 Redis 的话，强烈推荐下面这两本书：
\n![\"《Redis](\"https://oss.javaguide.cn/github/javaguide/books/redis-books.png\")
另外，《Redis 开发与运维》 这本书也非常不错，既有基础介绍，又有一线开发运维经验分享。
\n![\"《Redis](\"https://oss.javaguide.cn/github/javaguide/books/redis-kaifa-yu-yunwei.png\")
![](\"https://oss.javaguide.cn/github/javaguide/books/deep-understanding-of-distributed-system.png\")
《深入理解分布式系统》 是 2022 年出版的一本分布式中文原创书籍，主要讲的是分布式领域的基本概念、常见挑战以及共识算法。
\n作者用了大量篇幅来介绍分布式领域中非常重要的共识算法，并且还会基于 Go 语言带着你从零实现了一个共识算法的鼻祖 Paxos 算法。
\n实话说，我还没有开始看这本书。但是！这本书的作者的博客上的分布式相关的文章我几乎每一篇都认真看过。作者从 2019 年开始构思《深入理解分布式系统》，2020 年开始动笔，花了接近两年的时间才最终交稿。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/image-20220706121952258.png\")
作者专门写了一篇文章来介绍这本书的背后的故事，感兴趣的小伙伴可以自行查阅：https://zhuanlan.zhihu.com/p/487534882 。
\n最后，放上这本书的代码仓库和勘误地址：https://github.com/tangwz/DistSysDeepDive 。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/ddia.png\")
强推一波 《Designing Data-Intensive Application》 （DDIA，数据密集型应用系统设计），值得读很多遍！豆瓣有接近 90% 的人看了这本书之后给了五星好评。
\n这本书主要讲了分布式数据库、数据分区、事务、分布式系统等内容。
\n书中介绍的大部分概念你可能之前都听过，但是在看了书中的内容之后，你可能会豁然开朗：“哇塞！原来是这样的啊！这不是某技术的原理么？”。
\n这本书我之前专门写过知乎回答介绍和推荐，没看过的朋友可以看看：有哪些你看了以后大呼过瘾的编程书？ 。另外，如果你在阅读这本书的时候感觉难度比较大，很多地方读不懂的话，我这里推荐一下《深入理解分布式系统》作者写的《DDIA 逐章精读》小册。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/In-depth-understanding-of-distributed-transactions-xiaoyu.png\"){kind=spacer}
《深入理解分布式事务》 这本书的其中一位作者是 Apache ShenYu（incubating）网关创始人、Hmily、RainCat、Myth 等分布式事务框架的创始人。
\n学习分布式事务的时候，可以参考一下这本书。虽有一些小错误以及逻辑不通顺的地方，但对于各种分布式事务解决方案的介绍，总体来说还是不错的。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/image-20211216161350118.png\")
《从 Paxos 到 Zookeeper》 是一本带你入门分布式理论的好书。这本书主要介绍几种典型的分布式一致性协议，以及解决分布式一致性问题的思路，其中重点讲解了 Paxos 和 ZAB 协议。
\nPS：Zookeeper 现在用的不多，可以不用重点学习，但 Paxos 和 ZAB 协议还是非常值得深入研究的。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/deep-dive-into-distributed-consensus-algorithms.png\")
《深入理解分布式共识算法》 详细剖析了 Paxos、Raft、Zab 等主流分布式共识算法的核心原理和实现细节。如果你想要了解分布式共识算法的话，不妨参考一下这本书的总结。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/microservices-patterns.png\")
《微服务架构设计模式》 的作者 Chris Richardson 被评为世界十大软件架构师之一、微服务架构先驱。这本书汇集了 44 个经过实践验证的架构设计模式，这些模式用来解决诸如服务拆分、事务管理、查询和跨服务通信等难题。书中的内容不仅理论扎实，还通过丰富的 Java 代码示例，引导读者一步步掌握开发和部署生产级别的微服务架构应用。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/f5bec14d3b404ac4b041d723153658b5.png\")
《凤凰架构》 这本书是周志明老师多年架构和研发经验的总结，内容非常干货，深度与广度并存，理论结合实践！
\n正如书名的副标题“构建可靠的大型分布式系统”所说的那样，这本书的主要内容就是讲：“如何构建一套可靠的分布式大型软件系统” ，涵盖了下面这些方面的内容：
\n这本书我推荐过很多次了。详见历史文章：
\n\n![\"《Head](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424103035793.png\")
《Head First Java》这本书的内容很轻松有趣，可以说是我学习编程初期最喜欢的几本书之一了。同时，这本书也是我的 Java 启蒙书籍。我在学习 Java 的初期多亏了这本书的帮助，自己才算是跨进 Java 语言的大门。
\n我觉得我在 Java 这块能够坚持下来，这本书有很大的功劳。我身边的很多朋友学习 Java 初期都是看的这本书。
\n有很多小伙伴就会问了：这本书适不适合编程新手阅读呢？
\n我个人觉得这本书还是挺适合编程新手阅读的，毕竟是 “Head First” 系列。
\n\n![\"《Java](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424101217849.png\")
这两本书也非常不错。不过，这两本书的内容很多，全看的话比较费时间。我现在是把这两本书当做工具书来用，就比如我平时写文章的时候，碰到一些 Java 基础方面的问题，经常就翻看这两本来当做参考！
\n我当时在大学的时候就买了两本放在寝室，没事的时候就翻翻。建议有点 Java 基础之后再读，介绍的还是比较深入和全面的，非常推荐。
\n\n![\"《Java](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424103124893.png\")
另外，这本书的作者去年新出版了《On Java》，我更推荐这本，内容更新，介绍了 Java 的 3 个长期支持版（Java 8、11、17）。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/on-java/6171657600353_.pic_hd.jpg\")
毕竟，这是市面上目前唯一一本介绍了 Java 的 3 个长期支持版（Java 8、11、17）的技术书籍。
\n\n![\"《Java](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424103202625.png\")
Java 8 算是一个里程碑式的版本，现在一般企业还是用 Java 8 比较多。掌握 Java 8 的一些新特性比如 Lambda、Stream API 还是挺有必要的。这块的话，我推荐 《Java 8 实战》 这本书。
\n\n![\"《Java编程的逻辑》\"](\"https://oss.javaguide.cn/github/javaguide/books/image-20230721153650488.png\")
一本非常低调的好书，相比于入门书来说，内容更有深度。适合初学者，同时也适合大家拿来复习 Java 基础知识。
\n![\"《Java](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424112413660.png\")
这本书还是非常适合我们用来学习 Java 多线程的，讲解非常通俗易懂，作者从并发编程基础到实战都是信手拈来。
\n另外，这本书的作者加多自身也会经常在网上发布各种技术文章。这本书也是加多大佬这么多年在多线程领域的沉淀所得的结果吧！他书中的内容基本都是结合代码讲解，非常有说服力！
\n\n![\"《实战](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424112554830.png\")
这个是我第二本要推荐的书籍，比较适合作为多线程入门/进阶书籍来看。这本书内容同样是理论结合实战，对于每个知识点的讲解也比较通俗易懂，整体结构也比较清。
\n\n![\"《深入浅出](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424112927759.png\")
这本开源书籍是几位大厂的大佬开源的。这几位作者为了写好《深入浅出 Java 多线程》这本书阅读了大量的 Java 多线程方面的书籍和博客，然后再加上他们的经验总结、Demo 实例、源码解析，最终才形成了这本书。
\n这本书的质量也是非常过硬！给作者们点个赞！这本书有统一的排版规则和语言风格、清晰的表达方式和逻辑。并且每篇文章初稿写完后，作者们就会互相审校，合并到主分支时所有成员会再次审校，最后再通篇修订了三遍。
\n在线阅读：https://redspider.gitbook.io/concurrent/。
\n\n![\"《Java](\"https://oss.javaguide.cn/github/javaguide/books/0b1b046af81f4c94a03e292e66dd6f7d.png\")
这本书主要是对 Java Concurrent 包中一些比较重要的源码进行了讲解，另外，像 JMM、happen-before、CAS 等等比较重要的并发知识这本书也都会一并介绍到。
\n不论是你想要深入研究 Java 并发，还是说要准备面试，你都可以看看这本书。
\n![\"《深入理解](\"https://oss.javaguide.cn/github/javaguide/books/20210710104655705.png\")
这本书就一句话形容：国产书籍中的战斗机，实实在在的优秀！ （真心希望国内能有更多这样的优质书籍出现！加油！💪）
\n这本书的第 3 版 2019 年底已经出来了，新增了很多实在的内容比如 ZGC 等新一代 GC 的原理剖析。目前豆瓣上是 9.5 的高分，🐂 不 🐂 我就不多说了！
\n不论是你面试还是你想要在 Java 领域学习的更深，你都离不开这本书籍。这本书不光要看，你还要多看几遍，里面都是干货。这本书里面还有一些需要自己实践的东西，我建议你也跟着实践一下。
\n类似的书籍还有 《实战 Java 虚拟机》、《虚拟机设计与实现:以 JVM 为例》 ，这两本都是非常不错的！
\n![\"《实战](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113158144.png\")
![\"《虚拟机设计与实现:以](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113210153.png\")
如果你对实战比较感兴趣，想要自己动手写一个简易的 JVM 的话，可以看看 《自己动手写 Java 虚拟机》 这本书。
\n![\"《自己动手写](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113445246.png\")
书中的代码是基于 Go 语言实现的，搞懂了原理之后，你可以使用 Java 语言模仿着写一个，也算是练练手！ 如果你当前没有能力独立使用 Java 语言模仿着写一个的话，你也可以在网上找到很多基于 Java 语言版本的实现，比如《zachaxy 的手写 JVM 系列》 。
\n这本书目前在豆瓣有 8.2 的评分，我个人觉得张秀宏老师写的挺好的，这本书值得更高的评分。
\n另外，R 大在豆瓣发的《从表到里学习 JVM 实现》这篇文章中也推荐了很多不错的 JVM 相关的书籍，推荐小伙伴们去看看。
\n非常重要！非常重要！特别是 Git 和 Docker。
\n除了这些工具之外，我强烈建议你一定要搞懂 GitHub 的使用。一些使用 GitHub 的小技巧，你可以看Github 实用小技巧总结这篇文章。
\n框架部分建议找官方文档或者博客来看。
\nSpring 和 SpringBoot 真的很重要！
\n一定要搞懂 AOP 和 IOC 这两个概念。Spring 中 bean 的作用域与生命周期、SpringMVC 工作原理详解等等知识点都是非常重要的，一定要搞懂。
\n企业中做 Java 后端，你一定离不开 SpringBoot ，这个是必备的技能了！一定一定一定要学好！
\n像 SpringBoot 和一些常见技术的整合你也要知识怎么做，比如 SpringBoot 整合 MyBatis、 ElasticSearch、SpringSecurity、Redis 等等。
\n下面是一些比较推荐的书籍/专栏。
\n\n![\"《Spring](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113512453.png\")
不建议当做入门书籍读，入门的话可以找点国人的书或者视频看。这本定位就相当于是关于 Spring 的一个概览，只有一些基本概念的介绍和示例，涵盖了 Spring 的各个方面，但都不够深入。就像作者在最后一页写的那样：“学习 Spring，这才刚刚开始”。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210328171223638.png\")
对于 Spring5 的新特性介绍的比较详细，也说不上好。另外，感觉全书翻译的有一点蹩脚的味道，还有一点枯燥。全书的内容比较多，我一般拿来当做工具书参考。
\n\n![\"《Spring](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113546513.png\")
稍微有点啰嗦，但是原理介绍的比较清楚。
\nSpringBoot 解析，不适合初学者。我是去年入手的，现在就看了几章，后面没看下去。书很厚，感觉很多很多知识点的讲解过于啰嗦和拖沓，不过，这本书对于 SpringBoot 内部原理讲解的还是很清楚。
\n\n![\"《Spring](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113614768.png\")
比较一般的一本书，可以简单拿来看一下。
\nMyBatis 国内用的挺多的，我的建议是不需要花太多时间在上面。当然了，MyBatis 的源码还是非常值得学习的，里面有很多不错的编码实践。这里推荐两本讲解 MyBatis 源码的书籍。
\n\n![\"《手写MyBatis：渐进式源码实践》\"](\"https://oss.javaguide.cn/github/javaguide/books/image-20230724123402784.png\")
我的好朋友小傅哥出版的一本书。这本书以实践为核心，摒弃 MyBatis 源码中繁杂的内容，聚焦于 MyBaits 中的核心逻辑，简化代码实现过程，以渐进式的开发方式，逐步实现 MyBaits 中的核心功能。
\n这本书的配套项目的仓库地址：https://github.com/fuzhengwei/small-mybatis 。
\n\n![\"《通用源码阅读指导书――MyBatis源码详解》\"](\"https://oss.javaguide.cn/github/javaguide/books/image-20230724123416741.png\")
这本书通过 MyBatis 开源代码讲解源码阅读的流程和方法！一共对 MyBatis 源码中的 300 多个类进行了详细解析，包括其背景知识、组织方式、逻辑结构、实现细节。
\n这本书的配套示例仓库地址：https://github.com/yeecode/MyBatisDemo 。
\n![\"《Netty](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113715369.png\")
这本书可以用来入门 Netty ，内容从 BIO 聊到了 NIO、之后才详细介绍为什么有 Netty、Netty 为什么好用以及 Netty 重要的知识点讲解。
\n这本书基本把 Netty 一些重要的知识点都介绍到了，而且基本都是通过实战的形式讲解。
\n\n![\"《Netty](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113747345.png\")
内容都是关于使用 Netty 的实践案例比如内存泄露这些东西。如果你觉得你的 Netty 已经完全入门了，并且你想要对 Netty 掌握的更深的话，推荐你看一下这本书。
\n《跟闪电侠学 Netty：Netty 即时聊天实战与底层原理》
\n![](\"https://oss.javaguide.cn/github/javaguide/open-source-project/image-20220503085034268.png\")
2022 年 3 月出版的一本书。这本书分为上下两篇，上篇通过一个即时聊天系统的实战案例带你入门 Netty，下篇通过 Netty 源码分析带你搞清 Netty 比较重要的底层原理。
\n![\"《Java](\"https://oss.javaguide.cn/github/javaguide/books/image-20220424113809644.png\")
希望能有更多这 Java 性能优化方面的好书！
\nO'Reilly 家族书，性能调优的入门书，我个人觉得性能调优是每个 Java 从业者必备知识。
\n这本书介绍的实战内容很不错，尤其是 JVM 调优，缺点也比较明显，就是内容稍微有点老。市面上这种书很少。这本书不适合初学者，建议对 Java 语言已经比价掌握了再看。另外，阅读之前，最好先看看周志明大佬的《深入理解 Java 虚拟机》。
\n看过很多网站架构方面的书籍，比如《大型网站技术架构：核心原理与案例分析》、《亿级流量网站架构核心技术》、《架构修炼之道——亿级网关、平台开放、分布式、微服务、容错等核心技术修炼实践》等等。
\n目前我觉得能推荐的只有李运华老师的 《从零开始学架构》 和 余春龙老师的 《软件架构设计：大型网站技术架构与业务架构融合之道》 。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210412224443177.png\")
《从零开始学架构》这本书对应的有一个极客时间的专栏—《从零开始学架构》，里面的很多内容都是这个专栏里面的，两者买其一就可以了。我看了很小一部分，内容挺全面的，是一本真正在讲如何做架构的书籍。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210412232441459.png\")
事务与锁、分布式（CAP、分布式事务……）、高并发、高可用 《软件架构设计：大型网站技术架构与业务架构融合之道》 这本书都有介绍到。
\n《JavaGuide 面试突击版》
\n![](\"https://oss.javaguide.cn/github/javaguide-mianshituji/image-20220830103023493.png\")
![](\"https://oss.javaguide.cn/github/javaguide-mianshituji/image-20220830102925775.png\")
JavaGuide 的面试版本，涵盖了 Java 后端方面的大部分知识点比如 集合、JVM、多线程还有数据库 MySQL 等内容。
\n公众号后台回复：“面试突击” 即可免费获取，无任何套路。
\n![\"JavaGuide](\"https://oss.javaguide.cn/github/javaguide/gongzhonghaoxuanchuan.png\")
Elasticsearch 在 Apache Lucene 的基础上开发而成，学习 ES 之前，建议简单了解一下 Lucene 的相关概念。
\n《Lucene 实战》 是国内为数不多的中文版本讲 Lucene 的书籍，适合用来学习和了解 Lucene 相关的概念和常见操作。
\n![\"《Lucene实战》-实战\"](\"https://oss.javaguide.cn/github/javaguide/books/vAJkdYEyol4e6Nr.png\")
《一本书讲透 Elasticsearch：原理、进阶与工程实践》
\n![](\"https://oss.javaguide.cn/github/javaguide/books/one-book-guide-to-elasticsearch.png\")
基于 8.x 版本编写，目前全网最新的 Elasticsearch 讲解书籍。内容覆盖 Elastic 官方认证的核心知识点，源自真实项目案例和企业级问题解答。
\n\n极客时间的这门课程基于 Elasticsearch 7.1 版本讲解，还算比较新。并且，作者是 eBay 资深技术专家，有 20 年的行业经验，课程质量有保障！
\n![\"《Elasticsearch](\"https://oss.javaguide.cn/github/javaguide/csdn/20210420231125225.png\")
![\"《Elasticsearch](\"https://oss.javaguide.cn/p3-juejin/f856485931a945639d5c23aaed74fb38~tplv-k3u1fbpfcp-zoom-1.png\")
如果你想进一步深入研究 Elasticsearch 原理的话，可以看看张超老师的这本书。这是市面上唯一一本写 Elasticsearch 源码的书。
\n", "image": "https://oss.javaguide.cn/github/javaguide/books/vAJkdYEyol4e6Nr.png", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "计算机书籍" ] }, { "title": "软件质量必读经典书籍", "url": "https://codingmap.strova.top/books/software-quality.html", "id": "https://codingmap.strova.top/books/software-quality.html", "summary": "软件质量与代码整洁书籍推荐，重构、Clean Code、Effective Java、架构整洁之道等经典书籍，提升代码质量和架构设计能力。重点围绕 代码整洁之道、程序员职业素养、架构整洁之道、项目管理 等内容展开。结合 CodingMap 知识体系梳理 技术书籍 / Software Quality.Html 的核心。", "content_html": "下面推荐都是我看过并且我觉得值得推荐的书籍。
\n不过，这些书籍都比较偏理论，只能帮助你建立一个写优秀代码的意识标准。 如果你想要编写更高质量的代码、更高质量的软件，还是应该多去看优秀的源码，多去学习优秀的代码实践。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210328174841577.png\")
必看书籍！无需多言。编程书籍领域的瑰宝。
\n世界顶级、国宝级别的 Martin Fowler 的书籍，可以说是软件开发领域最经典的几本书之一。目前已经出了第二版。
\n这是一本值得你看很多遍的书籍。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210328174824891.png\")
《Clean Code》是 Bob 大叔的一本经典著作，强烈建议小伙伴们一定要看看。
\nBob 大叔将自己对整洁代码的理解浓缩在了这本书中，真可谓是对后生的一大馈赠。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/books/82d510c951384383b325080428af6c0a.png\")
《Effective Java 》这本书是 Java 领域国宝级别的书，非常经典。Java 程序员必看！
\n这本书主要介绍了在 Java 编程中很多极具实用价值的经验规则，这些经验规则涵盖了大多数开发人员每天所面临的问题的解决方案。这篇文章能够非常实际地帮助你写出更加清晰、健壮和高效的代码。本书中的每条规则都以简短、独立的小文章形式出现，并通过例子代码加以进一步说明。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210314173253221.png\")
其实，《代码大全（第 2 版）》这本书我本身是不太想推荐给大家了。但是，看在它的豆瓣评分这么高的份上，还是拿出来说说吧！
\n这也是一本非常经典的书籍，第二版对第一版进行了重写。
\n我简单地浏览过全书的内容，感觉内容总体比较虚，对于大部分程序员的作用其实不大。如果你想要切实地提高自己的代码质量，《Clean Code》和 《编写可读代码的艺术》我觉得都要比《代码大全》这本书更好。
\n不过，最重要的还是要多看优秀的源码，多学习优秀的代码实践。
\n\n![](\"https://oss.javaguide.cn/github/javaguide/books/20210314175536443.png\")
《编写可读代码的艺术》这本书要表达的意思和《Clean Code》很像，你看它俩的目录就可以看出来了。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70-20230309230739963.png\")
在我看来，如果你看过 《Clean Code》 的话，就不需要再看这本书了。当然，如果你有时间和精力，也可以快速过一遍。
\n另外，我这里还要推荐一个叫做 write-readable-code 的仓库。这个仓库的作者免费分享了一系列基于《编写可读代码的艺术》这本书的视频。这一系列视频会基于 Java 语言来教你如何优化咱们的代码。
\n在实践中学习的效果肯定会更好！推荐小伙伴们都抓紧学起来啊！
\n![](\"https://oss.javaguide.cn/github/javaguide/books/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70-20230309230743258.png\")
![](\"https://oss.javaguide.cn/github/javaguide/books/20210314191210273.png\")
《 The Clean Coder》是 Bob 大叔的又一经典著作。
\n《Clean Code》和《 The Clean Coder》这两本书在国内都翻译为 《代码整洁之道》，我觉得这个翻译还是不够优雅的。
\n另外，两者的内容差异也很大。《Clean Code》这本书从代码层面来讲解如何提高自己的代码质量。而《The Clean Coder》这本书则是从如何成为一名更优秀的开发者的角度来写的，比如这书会教你如何在自己的领域更专业、如何说不、如何做时间管理、如何处理压力等等。
\n![](\"https://oss.javaguide.cn/github/javaguide/books/2021031412342771.png\")
你没看错，《架构整洁之道》这本书又是 Bob 大叔的经典之作。
\n这本书我强烈安利！认真读完之后，我保证你对编程本质、编程语言的本质、软件设计、架构设计可以有进一步的认识。
\n国内的很多书籍和专栏都借鉴了《架构整洁之道》 这本书。毫不夸张地说，《架构整洁之道》就是架构领域最经典的书籍之一。
\n正如作者说的那样：
\n\n\n如果深入研究计算机编程的本质，我们就会发现这 50 年来，计算机编程基本没有什么大的变化。编程语言稍微进步了一点，工具的质量大大提升了，但是计算机程序的基本构造没有什么变化。
\n虽然我们有了新的编程语言、新的编程框架、新的编程范式，但是软件架构的规则仍然和 1946 年阿兰·图灵写下第一行机器代码的时候一样。
\n这本书就是为了把这些永恒不变的软件架构规则展现出来。
\n
![](\"https://oss.javaguide.cn/2021/03/8ece325c-4491-4ffd-9d3d-77e95159ec40.png\")
这本书主要描述了软件开发的基本定律：一个需要 10 天才能干完的活，不可能让 10 个人在 1 天干完！
\n看书名的第一眼，感觉不像是技术类的书籍。但是，就是这样一个看似和编程不沾边的书名，却成了编程领域长久相传的经典。
\n这本书对于现代软件尤其是复杂软件的开发的规范化有深刻的意义。
\n\n![](\"https://oss.javaguide.cn/2021/03/7e80418d-20b1-4066-b9af-cfe434b1bf1a.png\")
这本领域驱动设计方面的经典之作一直被各种推荐，但是我还来及读。
\n最后再推荐两个相关的文档：
\n这份 计算机基础知识体系 面向后端学习和面试复习，按“计算机网络 -> 操作系统 -> 数据结构 -> 算法”的顺序整理本站计算机基础相关文章。
\n如果你时间有限，建议先看 计算机网络常见面试题总结 和 操作系统常见面试题总结，快速建立高频问题清单；如果你想系统补基础，可以按下面的专题顺序推进。
\n整站配有 300+ 张技术配图，用图解的方式把抽象概念讲清楚，不是干巴巴的文字堆砌。
\n![\"计算机基础知识总结内容概览\"](\"https://oss.javaguide.cn/github/javaguide/cs-basics/network/cs-basics-overview.png\")
这份 数据库知识体系 面向后端学习、工程实践和面试复习，按“数据库基础 -> SQL -> MySQL -> Redis -> NoSQL 与搜索”的顺序整理本站数据库相关文章。
\n如果你时间有限，建议先看 数据库基础常见面试题总结、SQL 语法基础知识总结、MySQL 常见面试题总结 和 Redis 常见面试题总结（上），快速建立高频问题清单。
\n这部分适合先建立数据库通用认知，重点理解数据库类型、事务语义、字符集、SQL 基础和常见查询题。
\nMySQL 是后端开发最核心的关系型数据库考点之一，学习时建议把“索引 -> 执行计划 -> 事务 -> MVCC -> 日志 -> 性能优化”连起来。
\nRedis 既是缓存，也是高频中间件考点。学习时不要只背命令，更要理解缓存策略、数据结构、持久化、阻塞原因和集群机制。
\n这部分适合在掌握关系型数据库和缓存之后补充，用来理解文档数据库、搜索引擎和非关系型存储的选型边界。
\n数据库知识基础，这部分内容一定要理解记忆。虽然这部分内容只是理论知识，但是非常重要，这是后面学习 MySQL 数据库的基础。PS: 这部分内容由于涉及太多概念性内容，所以参考了维基百科和百度百科相应的介绍。
\n这四个概念描述了从数据本身到管理整个体系的不同层次，我们常用一个图书馆的例子来把它们串联起来理解。
\nDB 和 DBMS 我们通常会搞混，这里再简单提一下：通常我们说“用 MySQL 数据库”，其实是用 MySQL（DBMS）来管理一个或多个数据库（DB）。
\nDBMS 通常提供四大核心功能：
\n除了我们最常用的关系型数据库（RDBMS），比如 MySQL（开源首选）、PostgreSQL（功能最全）、Oracle（企业级），它们基于严格的表结构和 SQL，非常适合结构化数据和需要事务保证的场景，例如银行交易、订单系统。
\n近年来，为了应对互联网应用带来的海量数据、高并发和多样化数据结构的需求，涌现出了一大批 NoSQL 和 NewSQL 数据库。
\n它们的共同特点是为了极致的性能和水平扩展能力，在某些方面（通常是事务）做了妥协。
\n1. 键值数据库，代表是 Redis。
\n2. 文档数据库，代表是 MongoDB。
\n3. 列式数据库，代表是 HBase, Cassandra。
\n4. 图形数据库，代表是 Neo4j。
\n由于 NoSQL 不支持事务，很多对于数据安全要求非常高的系统（比如财务系统、订单系统、交易系统）就不太适合使用了。不过，这类系统往往有存储大量数据的需求。
\n这些系统往往只能通过购买性能更强大的计算机，或者通过数据库中间件来提高存储能力。不过，前者的金钱成本太高，后者的开发成本太高。
\n于是，NewSQL 就来了！
\n简单来说，NewSQL 就是：分布式存储+SQL+事务 。NewSQL 不仅具有 NoSQL 对海量数据的存储管理能力，还保持了传统数据库支持 ACID 和 SQL 等特性。因此，NewSQL 也可以称为 分布式关系型数据库。
\nNewSQL 数据库设计的一些目标：
\nNewSQL 数据库代表：Google 的 F1/Spanner、阿里的 OceanBase、PingCAP 的 TiDB 。
\n在关系型数据库理论中，理解元组、码、候选码、主码、外码、主属性和非主属性这些核心概念，对于数据库设计和规范化至关重要。这些概念构成了关系数据库的理论基础。
\n我们做一个项目的时候一定要试着画 ER 图来捋清数据库设计，这个也是面试官问你项目的时候经常会被问到的。
\nER 图 全称是 Entity Relationship Diagram（实体联系图），提供了表示实体类型、属性和联系的方法。
\nER 图由下面 3 个要素组成：
\n下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M: N）。另外，还有其他两种实体之间的关系是：1 对 1（1:1）、1 对多（1: N）。
\n数据库范式有 3 种：
\n属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其他的字段了。1NF 是所有关系型数据库的最基本要求 ，也就是说关系型数据库中创建的表一定满足第一范式。
\n2NF 在 1NF 的基础之上，消除了非主属性对于码的部分函数依赖。如下图所示，展示了第一范式到第二范式的过渡。第二范式在第一范式的基础上增加了一个列，这个列称为主键，非主属性都依赖于主键。
\n![\"第二范式\"](\"https://oss.javaguide.cn/github/javaguide/csdn/bd1d31be3779342427fc9e462bf7f05c.png\")
一些重要的概念：
\n3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。符合 3NF 要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。
\n从定义和属性上看，它们的区别是：
\n用一个简单的电商例子来说明：假设我们有两张表：users (用户表) 和 orders (订单表)。
users 表中，user_id 列是主键。每个用户的 user_id 都是独一无二的，我们用它来区分张三和李四。orders 表中，order_id 是它自己的主键。同时，它会有一个 user_id 列，这个列就是一个外键，它引用了 users 表的 user_id 主键。这个外键约束就保证了：
\nuser_id 在 users 表中不存在）。对于外键和级联，阿里巴巴开发手册这样说到：
\n\n\n【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
\n说明: 以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度
\n
为什么不要用外键呢？大部分人可能会这样回答：
\n我个人觉得上面这种回答不是特别的全面，只是说了外键存在的一个常见的问题。实际上，我们知道外键也是有很多好处的，比如：
\n所以说，不要一股脑的就抛弃了外键这个概念，既然它存在就有它存在的道理，如果系统不涉及分库分表，并发量不是很高的情况还是可以考虑使用外键的。
\n存储过程是数据库中预编译的SQL语句集合，它将多条SQL语句和程序逻辑控制语句（如IF-ELSE、WHILE循环等）封装在一起，形成一个可重复调用的数据库对象。
\n存储过程的优势：
\n在传统企业级应用中，存储过程具有一定的实用价值。当业务逻辑复杂时，需要执行大量SQL语句才能完成一个业务操作，此时可以将这些语句封装成存储过程，简化调用过程。由于存储过程在创建时就已经编译并存储在数据库中，执行时无需重新编译，因此相比动态SQL语句具有更好的执行性能。同时，一旦存储过程调试完成，其运行相对稳定可靠。
\n存储过程的局限性：
\n然而，在现代互联网架构中，存储过程的使用越来越少。主要原因包括：调试困难，缺乏成熟的调试工具；扩展性差，修改业务逻辑需要直接修改数据库对象；移植性差，不同数据库系统的存储过程语法差异较大；占用数据库资源，增加数据库服务器负担；版本管理困难，不便于进行代码版本控制。
\n行业规范：
\n基于以上原因，许多互联网公司的开发规范中明确限制或禁止使用存储过程。例如，《阿里巴巴Java开发手册》中明确规定禁止使用存储过程，推荐将业务逻辑放在应用层实现，保持数据库的简单和高效。
\n![\"阿里巴巴Java开发手册:](\"https://oss.javaguide.cn/github/javaguide/csdn/0fa082bc4d4f919065767476a41b2156.png\")
在数据库操作中，DROP、DELETE 和 TRUNCATE 是三个常用的数据删除命令，它们在功能、性能和使用场景上存在显著差异。
DROP命令：
\nDROP TABLE 表名TRUNCATE命令：
\nTRUNCATE TABLE 表名DELETE命令：
\nDELETE FROM 表名 WHERE 条件TRUNCATE 和不带 WHERE子句的 DELETE、以及 DROP 都会删除表内的数据，但是 TRUNCATE 和 DELETE 只删除数据不删除表的结构(定义)，执行 DROP 语句，此表的结构也会删除，也就是执行DROP 之后对应的表不复存在。
DROP：删除表结构和所有数据，表将不复存在TRUNCATE：仅删除数据，保留表结构和定义DELETE：仅删除数据，保留表结构和定义DELETE 操作会触发相关的DELETE触发器TRUNCATE 和 DROP 不会触发DELETE触发器DROP 和 TRUNCATE 属于DDL操作，执行后立即生效，不能回滚DELETE 属于DML操作，可以回滚（在事务中）一般来说：DROP > TRUNCATE > DELETE（这个我没有实际测试过）。
DELETE命令执行的时候会产生数据库的binlog日志，而日志记录是需要消耗时间的，但是也有个好处方便数据回滚恢复。TRUNCATE命令执行的时候不会产生数据库日志，因此比DELETE要快。除此之外，还会把表的自增值重置和索引恢复到初始大小等。DROP命令会把表占用的空间全部释放掉。Tips：你应该更多地关注在使用场景上，而不是执行效率。
\n另外，由于SELECT不会对表进行破坏，所以有的地方也会把SELECT单独区分开叫做数据库查询语言 DQL（Data Query Language）。
目标： 深入了解和分析用户需求，明确系统边界
\n主要工作：
目标： 将需求转化为信息世界的概念模型
\n主要工作：
目标： 将概念模型转换为特定DBMS支持的逻辑模型
\n主要工作：
目标： 确定数据的物理存储方案和访问方法
\n主要工作：
目标： 将设计转化为实际运行的数据库系统
\n主要工作：
目标： 确保数据库系统稳定高效运行
\n主要工作：
在整个设计过程中应遵循：数据独立性原则、完整性原则、安全性原则、可扩展性原则和标准化原则。
\nMySQL 字符编码集中有两套 UTF-8 编码实现：utf8 和 utf8mb4。
如果使用 utf8 的话，存储 emoji 符号和一些比较复杂的汉字、繁体字就会出错。
为什么会这样呢？这篇文章可以从源头给你解答。
\n字符是各种文字和符号的统称，包括各个国家文字、标点符号、表情、数字等等。 字符集 就是一系列字符的集合。字符集的种类较多，每个字符集可以表示的字符范围通常不同，就比如说有些字符集是无法表示汉字的。
\n计算机只能存储二进制的数据，那英文、汉字、表情等字符应该如何存储呢？
\n我们要将这些字符和二进制的数据一一对应起来，比如说字符“a”对应“01100001”，反之，“01100001”对应 “a”。我们将字符对应二进制数据的过程称为"字符编码"，反之，二进制数据解析成字符的过程称为“字符解码”。
\n字符编码是一种将字符集中的字符与计算机中的二进制数据相互转换的方法，可以看作是一种映射规则。也就是说，字符编码的目的是为了让计算机能够存储和传输各种文字信息。
\n每种字符集都有自己的字符编码规则，常用的字符集编码规则有 ASCII 编码、 GB2312 编码、GBK 编码、GB18030 编码、Big5 编码、UTF-8 编码、UTF-16 编码等。
\n常见的字符集有：ASCII、GB2312、GB18030、GBK、Unicode……。
\n不同的字符集的主要区别在于：
\nASCII (American Standard Code for Information Interchange，美国信息交换标准代码) 是一套主要用于现代美国英语的字符集（这也是 ASCII 字符集的局限性所在）。
\n为什么 ASCII 字符集没有考虑到中文等其他字符呢？ 因为计算机是美国人发明的，当时，计算机的发展还处于比较雏形的时代，还未在其他国家大规模使用。因此，美国发布 ASCII 字符集的时候没有考虑兼容其他国家的语言。
\nASCII 字符集至今为止共定义了 128 个字符，其中有 33 个控制字符（比如回车、删除）无法显示。
\n一个 ASCII 码长度是一个字节也就是 8 个 bit，比如“a”对应的 ASCII 码是“01100001”。不过，最高位是 0 仅仅作为校验位，其余 7 位使用 0 和 1 进行组合，所以，ASCII 字符集可以定义 128（2^7）个字符。
\n由于，ASCII 码可以表示的字符实在是太少了。后来，人们对其进行了扩展得到了 ASCII 扩展字符集 。ASCII 扩展字符集使用 8 位（bits）表示一个字符，所以，ASCII 扩展字符集可以定义 256（2^8）个字符。
\n![\"ASCII字符编码\"](\"https://oss.javaguide.cn/github/javaguide/csdn/c1c6375d08ca268690cef2b13591a5b4.png\")
我们上面说了，ASCII 字符集是一种现代美国英语适用的字符集。因此，很多国家都捣鼓了一个适合自己国家语言的字符集。
\nGB2312 字符集是一种对汉字比较友好的字符集，共收录 6700 多个汉字，基本涵盖了绝大部分常用汉字。不过，GB2312 字符集不支持绝大部分的生僻字和繁体字。
\n对于英语字符，GB2312 编码和 ASCII 码是相同的，1 字节编码即可。对于非英字符，需要 2 字节编码。
\nGBK 字符集可以看作是 GB2312 字符集的扩展，兼容 GB2312 字符集，共收录了 20000 多个汉字。
\nGBK 中 K 是汉语拼音 Kuo Zhan（扩展）中的“Kuo”的首字母。
\nGB18030 完全兼容 GB2312 和 GBK 字符集，纳入中国国内少数民族的文字，且收录了日韩汉字，是目前为止最全面的汉字字符集，共收录汉字 70000 多个。
\nBIG5 主要针对的是繁体中文，收录了 13000 多个汉字。
\n为了更加适合本国语言，诞生了很多种字符集。
\n我们上面也说了不同的字符集可以表示的字符范围以及编码规则存在差异。这就导致了一个非常严重的问题：使用错误的编码方式查看一个包含字符的文件就会产生乱码现象。
\n就比如说你使用 UTF-8 编码方式打开 GB2312 编码格式的文件就会出现乱码。示例：“牛”这个汉字 GB2312 编码后的十六进制数值为 “C5A3”，而 “C5A3” 用 UTF-8 解码之后得到的却是 “ţ”。
\n你可以通过这个网站在线进行编码和解码：https://www.haomeili.net/HanZi/ZiFuBianMaZhuanHuan
\n![](\"https://oss.javaguide.cn/github/javaguide/csdn/836c49b117ee4408871b0020b74c991d.png\")
这样我们就搞懂了乱码的本质：编码和解码时用了不同或者不兼容的字符集 。
\n![](\"https://oss.javaguide.cn/javaguide/a8808cbabeea49caa3af27d314fa3c02-1.jpg\")
为了解决这个问题，人们就想：“如果我们能够有一种字符集将世界上所有的字符都纳入其中就好了！”。
\n然后，Unicode 带着这个使命诞生了。
\nUnicode 字符集中包含了世界上几乎所有已知的字符。不过，Unicode 字符集并没有规定如何存储这些字符（也就是如何使用二进制数据表示这些字符）。
\n然后，就有了 UTF-8（8-bit Unicode Transformation Format）。类似的还有 UTF-16、 UTF-32。
\nUTF-8 使用 1 到 4 个字节为每个字符编码， UTF-16 使用 2 或 4 个字节为每个字符编码，UTF-32 固定位 4 个字节为每个字符编码。
\nUTF-8 可以根据不同的符号自动选择编码的长短，像英文字符只需要 1 个字节就够了，这一点 ASCII 字符集一样 。因此，对于英语字符，UTF-8 编码和 ASCII 码是相同的。
\nUTF-32 的规则最简单，不过缺陷也比较明显，对于英文字母这类字符消耗的空间是 UTF-8 的 4 倍之多。
\nUTF-8 是目前使用最广的一种字符编码。
\n![](\"https://oss.javaguide.cn/javaguide/1280px-Utf8webgrowth.svg.png\")
MySQL 支持很多种字符集的方式，比如 GB2312、GBK、BIG5、多种 Unicode 字符集（UTF-8 编码、UTF-16 编码、UCS-2 编码、UTF-32 编码等等）。
\n你可以通过 SHOW CHARSET 命令来查看，支持 like 和 where 子句。
![](\"https://oss.javaguide.cn/javaguide/image-20211008164229671.png\")
在 MySQL5.7 中，默认字符集是 latin1 ；在 MySQL8.0 中，默认字符集是 utf8mb4
MySQL 中的字符集有以下的层次级别：
\nserver（MySQL 实例级别）database（库级别）table（表级别）column（字段级别）它们的优先级可以简单的认为是从上往下依次增大，也即 column 的优先级会大于 table 等其余层次的。如指定 MySQL 实例级别字符集是utf8mb4，指定某个表字符集是latin1，那么这个表的所有字段如果不指定的话，编码就是latin1。
不同版本的 MySQL 其 server 级别的字符集默认值不同，在 MySQL5.7 中，其默认值是 latin1 ；在 MySQL8.0 中，其默认值是 utf8mb4 。
当然也可以通过在启动 mysqld 时指定 --character-set-server 来设置 server 级别的字符集。
mysqld\nmysqld --character-set-server=utf8mb4\nmysqld --character-set-server=utf8mb4 \\\n --collation-server=utf8mb4_0900_ai_ci或者如果你是通过源码构建的方式启动的 MySQL，你可以在 cmake 命令中指定选项：
cmake . -DDEFAULT_CHARSET=latin1\n或者\ncmake . -DDEFAULT_CHARSET=latin1 \\\n -DDEFAULT_COLLATION=latin1_german1_ci此外，你也可以在运行时改变 character_set_server 的值，从而达到修改 server 级别的字符集的目的。
server 级别的字符集是 MySQL 服务器的全局设置，它不仅会作为创建或修改数据库时的默认字符集（如果没有指定其他字符集），还会影响到客户端和服务器之间的连接字符集，具体可以查看 MySQL Connector/J 8.0 - 6.7 Using Character Sets and Unicode。
database 级别的字符集是我们在创建数据库和修改数据库时指定的：
CREATE DATABASE db_name\n [[DEFAULT] CHARACTER SET charset_name]\n [[DEFAULT] COLLATE collation_name]\n\nALTER DATABASE db_name\n [[DEFAULT] CHARACTER SET charset_name]\n [[DEFAULT] COLLATE collation_name]如前面所说，如果在执行上述语句时未指定字符集，那么 MySQL 将会使用 server 级别的字符集。
可以通过下面的方式查看某个数据库的字符集：
\nUSE db_name;\nSELECT @@character_set_database, @@collation_database;SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME\nFROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'db_name';table 级别的字符集是在创建表和修改表时指定的：
CREATE TABLE tbl_name (column_list)\n [[DEFAULT] CHARACTER SET charset_name]\n [COLLATE collation_name]]\n\nALTER TABLE tbl_name\n [[DEFAULT] CHARACTER SET charset_name]\n [COLLATE collation_name]如果在创建表和修改表时未指定字符集，那么将会使用 database 级别的字符集。
column 级别的字符集同样是在创建表和修改表时指定的，只不过它是定义在列中。下面是个例子：
CREATE TABLE t1\n(\n col1 VARCHAR(5)\n CHARACTER SET latin1\n COLLATE latin1_german1_ci\n);如果未指定列级别的字符集，那么将会使用表级别的字符集。
\n前面说到了字符集的层次级别，它们是和存储相关的。而连接字符集涉及的是和 MySQL 服务器的通信。
\n连接字符集与下面这几个变量息息相关：
\ncharacter_set_client ：描述了客户端发送给服务器的 SQL 语句使用的是什么字符集。character_set_connection ：描述了服务器接收到 SQL 语句时使用什么字符集进行翻译。character_set_results ：描述了服务器返回给客户端的结果使用的是什么字符集。它们的值可以通过下面的 SQL 语句查询：
\nSELECT * FROM performance_schema.session_variables\nWHERE VARIABLE_NAME IN (\n'character_set_client', 'character_set_connection',\n'character_set_results', 'collation_connection'\n) ORDER BY VARIABLE_NAME;SHOW SESSION VARIABLES LIKE 'character\\_set\\_%';如果要想修改前面提到的几个变量的值，有以下方式：
\n1、修改配置文件
\n[mysql]\n# 只针对MySQL客户端程序\ndefault-character-set=utf8mb42、使用 SQL 语句
\nset names utf8mb4\n# 或者一个个进行修改\n# SET character_set_client = utf8mb4;\n# SET character_set_results = utf8mb4;\n# SET collation_connection = utf8mb4;不知道你们有没有碰到过存储 emoji 表情正常，但是使用类似 Navicat 之类的软件的进行查询的时候，发现 emoji 表情变成了问号的情况。这个问题很有可能就是 JDBC 驱动引起的。
\n根据前面的内容，我们知道连接字符集也是会影响我们存储的数据的，而 JDBC 驱动会影响连接字符集。
\nmysql-connector-java （JDBC 驱动）主要通过这几个属性影响连接字符集：
characterEncodingcharacterSetResults以 DataGrip 2023.1.2 来说，在它配置数据源的高级对话框中，可以看到 characterSetResults 的默认值是 utf8 ，在使用 mysql-connector-java 8.0.25 时，连接字符集最后会被设置成 utf8mb3 。那么这种情况下 emoji 表情就会被显示为问号，并且当前版本驱动还不支持把 characterSetResults 设置为 utf8mb4 ，不过换成 mysql-connector-java driver 8.0.29 却是允许的。
具体可以看一下 StackOverflow 的 DataGrip MySQL stores emojis correctly but displays them as?这个回答。
\n通常情况下，我们建议使用 UTF-8 作为默认的字符编码方式。
\n不过，这里有一个小坑。
\nMySQL 字符编码集中有两套 UTF-8 编码实现：
\nutf8：utf8编码只支持1-3个字节 。 在 utf8 编码中，中文是占 3 个字节，其他数字、英文、符号占一个字节。但 emoji 符号占 4 个字节，一些较复杂的文字、繁体字也是 4 个字节。utf8mb4：UTF-8 的完整实现，正版！最多支持使用 4 个字节表示字符，因此，可以用来存储 emoji 符号。为什么有两套 UTF-8 编码实现呢？ 原因如下：
\n![](\"https://oss.javaguide.cn/javaguide/image-20211008164542347.png\")
因此，如果你需要存储emoji类型的数据或者一些比较复杂的文字、繁体字到 MySQL 数据库的话，数据库的编码一定要指定为utf8mb4 而不是utf8 ，要不然存储的时候就会报错了。
演示一下吧！（环境：MySQL 5.7+）
\n建表语句如下，我们指定数据库 CHARSET 为 utf8 。
CREATE TABLE `user` (\n `id` varchar(66) CHARACTER SET utf8mb3 NOT NULL,\n `name` varchar(33) CHARACTER SET utf8mb3 NOT NULL,\n `phone` varchar(33) CHARACTER SET utf8mb3 DEFAULT NULL,\n `password` varchar(100) CHARACTER SET utf8mb3 DEFAULT NULL\n) ENGINE=InnoDB DEFAULT CHARSET=utf8;当我们执行下面的 insert 语句插入数据到数据库时，果然报错！
\nINSERT INTO `user` (`id`, `name`, `phone`, `password`)\nVALUES\n ('A00003', 'guide哥😘😘😘', '181631312312', '123456');报错信息如下：
\nIncorrect string value: '\\xF0\\x9F\\x98\\x98\\xF0\\x9F...' for column 'name' at row 1NoSQL（Not Only SQL 的缩写）泛指非关系型的数据库，主要针对的是键值、文档以及图形类型数据存储。并且，NoSQL 数据库天生支持分布式，数据冗余和数据分片等特性，旨在提供可扩展的高可用高性能数据存储解决方案。
\n一个常见的误解是 NoSQL 数据库或非关系型数据库不能很好地存储关系型数据。NoSQL 数据库可以存储关系型数据—它们与关系型数据库的存储方式不同。
\nNoSQL 数据库代表：HBase、Cassandra、MongoDB、Redis。
\n![](\"https://oss.javaguide.cn/github/javaguide/database/mongodb/sql-nosql-tushi.png\")
| | SQL 数据库 | NoSQL 数据库 |
\n| :
AI 编程工具好不好用，真不全看模型。很多时候，差别反而出在你怎么给上下文、怎么拆任务、怎么看 diff。
\n当然了，这不是说模型不重要，模型的质量是根本。但使用同样的模型，在不同的人手中最终达到的效果是差别很大的。
\n别把它想成“我把需求丢给 AI，然后代码自己就写好了”。真实项目里没这么轻松。更常见的是：AI 写到一半方向歪了，你得接回来；一次改太多文件，你得拆小；测试没过，你还得顺着错误往回追；它一本正经瞎编的时候，你得能看出来。
\n所以这个专题不会只聊“哪个工具最强”。Claude Code、Cursor、OpenAI Codex、Trae 都有能帮上忙的地方，关键是你得知道：什么时候让 AI 写代码，什么时候让它查资料、读代码，什么时候该自己上手。还有更重要的一点，出问题以后怎么回滚，怎么把影响控制住。
\n本专栏属于 AIGuide 项目，对标 JavaGuide 质量，免费开源，欢迎 Star 支持：
\n\nCLI 和 IDE 没有谁一定比谁强，主要看当前任务是什么。跨文件重构、批量修改、长任务自动化，用 CLI 会更顺手；局部补全、边看边改、随时调整，IDE 体验通常更好。把这条线分清楚，选工具就没那么纠结。
\n多模型协同也不是把所有任务都丢给最贵的模型。写代码、看架构、审 diff、排查问题，需要的能力不一样。分工清楚，多模型能放大效率；分工不清楚，它也会把错误一起放大。
\nAI 生成的代码，一定要过测试、审查和可回滚的提交管理。“看起来能跑”只是第一步。真正麻烦的不是它某一行写错了，而是一次改了几百行，最后出问题时你根本不知道从哪儿查。
\n面试里如果被问到“AI 对开发效率的影响”，也别只说“提升了多少多少”。更好的回答是讲清楚：它在哪些环节确实省时间，哪些环节反而增加了审查成本，以及你是怎么兜住风险的。
\n/simplify、/review、/loop、/batch 这些命令怎么用。腾讯面试的时候，面试官问我：“用过什么 AI 编程工具？”。我说：“Trae。”
\n空气突然安静了两秒。我搞不清楚为什么面试官沉默了，当时我还在想：“是不是我回答得不够高级？”。
\n面试被挂后才意识到：Trae 是字节的，腾讯家的是 CodeBuddy，阿里家的是 Qoder。
\n段子归段子！今天 Guide 分享 9 道当下校招和社招技术面试中经常会被问到的 AI 编程开放性问题，希望对你有帮助。
\n目前整体感觉是：AI 编程能力进步很快。它已经从几年前简单的代码补全，进化成了一个可以深度协作的工程助手。
\n我总结了一套自己的使用方法论：
\nAI 是一个强大的知识库和辅助工具，可以帮我们快速实现功能、学习新知识。但如果完全依赖 AI 写代码而不理解其原理，个人技术能力可能会退化。
\n几个原则：
\n我希望效率提升，但不以牺牲技术能力为代价。
\n\n\n这里是以 Cursor 为例，其他 AI IDE 都是类似的。
\n
.cursorrules 定义 AI 生成代码的规则、风格和常用片段；.cursorignore 指定不允许 AI 修改的文件 / 目录，保护核心代码。CLAUDE.md 自我进化——把纠正转化为规则，让 AI 越用越顺手。/compact 比反复纠正更有效——上下文被污染后，压缩或清空重来更好。Claude Code 详细内容我单独分享过：Claude Code 使用指南。
\nAI 不会取代后端工程师，但会改变后端工程师的工作方式和能力结构。
\nAI 能帮我们处理重复的、模式化的工作：
\nAI 让后端工程师能更专注于业务建模、复杂系统设计和架构决策这些更具创造性的核心工作。
\n拿我自己来说，我经常会和 AI 讨论业务和技术方案，它总能给我不错的启发——尤其是在需求拆解和技术选型时，AI 能提供多角度的思考。
\n从实战经验来看，AI 辅助编程的能力可以归纳为两个维度：
\n说句实话，前后端开发者的核心竞争力已经变了。
\n以前前端拼手速和还原度，后端拼 CRUD 和八股文。现在这些东西 AI 全能做，而且又快又不喊累，就废点 Token。你花半天切的页面，AI 十分钟搞定；你写两小时的增删改查，AI 三分钟交卷。不是说这些技能没用了，而是不稀缺了，就不值钱。
\n前端受冲击最直接。页面还原、组件编写、样式调整，模式化程度太高，大模型最擅长这类活。但死掉的不是前端这个岗位，是“只会写页面”的前端。
\n有竞争力的前端往两个方向走：要么往深扎——性能优化、渲染管线分析、工程化基建，AI 替代不了；要么往难走——WebGL、大规模可视化、跨端底层原理，AI 生成质量差，反而是护城河。
\n后端稍好，但也别乐观。AI 写单个接口已经很强了，它的短板是系统级思考——服务怎么拆、数据模型怎么设计、缓存一致性怎么保证、容量瓶颈在哪。这些需要结合业务场景和技术债综合判断，AI 给的方案“看起来对”，上生产就翻车。
\n后端的核心竞争力在往系统设计、稳定性治理、复杂业务建模转。
\n不管前端后端，有一件事已经是基本功：高效跟 AI 协作。不是会用 ChatGPT 就行，而是能拆解问题、引导输出、判断结果靠不靠谱、识别安全隐患。你从“写代码的人”变成了“AI 的技术审核官”。
\n那些生成代码不看逻辑的人，短期效率高，长期在给自己埋雷——线上出问题只会反复问 AI，自己毫无排查思路。
\n短期内不会淘汰，但会彻底改变初级程序员的能力结构。
\n以前初级工程师的价值在于：
\n现在这些工作 AI 都能做得很好，甚至更高效、更少出错。但初级程序员不会被淘汰，只是价值创造点发生了迁移。
\n未来初级工程师需要具备：
\nAI 让编程门槛变低，但对“理解能力”的要求反而更高。未来的初级工程师更像是一个“AI 协调者”，而非单纯的“代码编写者”。
\n从企业招聘角度看，纯编码能力的需求会减少，但对“能利用 AI 快速交付业务价值”的工程师需求会增加。
\n我认为主要有三个层面：
\n1. 技术能力退化
\n过度依赖 AI 会导致工程师自身技术能力的退化，尤其是：
\n2. 架构失控
\nAI 生成的代码往往关注“当前功能可用”，容易忽视长期架构健康度。这很大程度上源于 Vibe Coding（氛围编程）——依赖模糊意图让 AI“自由发挥”。
\n模块边界模糊：AI 倾向于“快速完成功能”，可能将多个职责混入同一模块。建议在编码前明确模块职责（DDD 风格的 Context Boundary），通过预先定义的接口契约约束 AI 生成范围。
\n技术债务累积：为快速实现功能，AI 可能使用硬编码、绕过标准异常处理、引入不必要的循环依赖等反模式。这些债务在项目规模增长后会显著增加重构成本。
\n风格一致性缺失：不同 Chat 会话中生成的代码可能采用不同的命名规范、错误处理模式和日志格式。建议通过 Spec Coding 的方式，预先定义统一的技术规范和代码风格（如 .cursorrules），让 AI 始终在同一套规则下工作。
资源治理缺失：AI 不会自动考虑连接池大小、线程池队列长度、缓存过期策略等资源约束。例如，生成的代码可能创建大量线程但无界队列，在流量激增时导致内存溢出；或使用默认数据库连接池配置，在高并发下成为瓶颈。
\n工程规范适配：AI 生成的代码架构虽然合理，但与既有工程规范的适配往往需要人工把关。比如文件名组织、代码风格差异、依赖管理策略——这些“看起来没问题”的代码，可能在团队协作中制造麻烦。
\n3. 安全风险（尤其需要重视）
\n4. 分布式场景下的失效模式（尤其危险）
\nAI 生成的代码在分布式环境中极易忽略关键约束，导致生产事故：
\n| 失效模式 | AI 常见问题 | 生产风险 |
\n|
大家好，我是 Guide。前面分享过 IDEA 搭配 Qoder 插件的实战和 Trae 接入大模型的实战，分别覆盖了 JetBrains 体系和 VS Code 体系下的 AI 辅助编码。这篇换个角度，聊聊 Claude Code 接入第三方模型 的实战体验。
\nClaude Code 本身是 Anthropic 官方的 CLI 编码工具，但它支持通过环境变量切换底层模型。这意味着你不必局限于 Claude 系列，完全可以接入其他模型来使用。本文以 GLM-5.1 作为示例，但接入方式是通用的——换成其他兼容模型，流程基本一致。
\n我选了两个比较有代表性的复杂场景来验证：
\n一个是从零开始的工程交付，另一个是面对既有系统的性能治理，正好覆盖 AI 辅助编程的两种典型工作模式。
\n在正式开始之前，需要完成 Claude Code 与第三方模型的对接。整个配置过程分三步：
\n第一步：安装 Claude Code
\nnpm i -g @anthropic-ai/claude-code@latest第二步：安装 cc-switch 完成模型切换（macOS 用户可通过 homebrew 安装，详情参考 cc-switch 官方文档：https://github.com/farion1231/cc-switch/blob/main/README_ZH.md）
\n第三步：按照模型提供方的说明，完成 Claude Code 内部模型环境变量与目标模型的对应关系配置。以 GLM-5.1 为例，参考：https://docs.bigmodel.cn/cn/coding-plan/tool/claude
\n配置过程截图如下：
\n点击加号添加模型：
\n![\"点击添加模型\"](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/add-model-entry.png\")
选择对应的模型：
\n![\"选择模型\"](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/select-model.png\")
配置参数：
\n![\"配置参数\"](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/config-params.png\")
Claude Code 内部模型环境变量与目标模型对应关系的 JSON 配置：
\n![\"Claude](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/model-env-json-config.png\")
如果你更偏向页面开发，推荐通过 VSCode + Claude Code for VS Code 方式进行交互和编码验收。完成插件安装之后，可以直接在 IDE 中与模型对话和代码审查，相对于 CLI 界面会更直观一些：
\n![\"VSCode](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/vscode-claude-code.png\")
JVM 线上诊断一直以来都是 Java 开发最棘手的问题。在传统开发模式下，面对性能瓶颈或线上故障，研发人员的排查路径基本固定：
\n在 AI 出现以前，这套流程虽然繁琐，但确实是最直接有效的手段。但随着业务越来越复杂，故障响应时效要求也越来越高，传统模式的弊端越来越明显：
\n随着 AI 技术的演进，特别是 Agent 和 Skill 等概念的成熟，笔者就有了一个工程化的构想：能否借助 AI 将诊断经验沉淀复用，让 AI 根据既有经验构建明确的决策路径？同时结合它的决策方案赋予对应的工具，使其基于用户给定的服务名和故障表象，自动化连接线上服务器完成诊断，定位具体代码段，最终输出问题根因和解决方案。
\n有了构想之后，接下来就是技术选型和方案落地。笔者将完整的需求描述交给 AI：
\n研发一款基于Arthas的智能体诊断工具，该工具需实现以下核心功能：\n1. 当用户输入线上故障服务名称及具体故障现象后，系统能够自动定位至目标故障服务器，主动对目标服务进行实时监控与深度分析。\n2. 通过集成Arthas的反编译功能，精准定位到引发故障的具体代码段\n3. 基于分析结果生成包含问题根因、代码修复建议及实施步骤的完整解决思路。\n\n请提供该工具的技术选型方案，包括但不限于开发语言（优先考虑Java技术栈）、核心框架、数据库表设计、部署架构等，并设计详细的系统实现方案，涵盖功能模块划分、数据流程设计、关键技术难点及解决方案等内容。AI 收到需求后，没有立刻开始写代码，而是先结合项目上下文（完全空的文件夹）进行推理分析，自主完成了一份包含十几个阶段的完整技术方案。”给一个目标，AI 自己拆出整条路径”——这是 AI 辅助编程的一大优势，你可以把精力放在需求描述和方案评审上，让 AI 负责路径规划。
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/ai-tech-plan.png\")
AI 结合需求，针对 Agent 拆解出技术选型和 Arthas 集成方案的检索。从检索关键字可以看出，它在方案选取上优先考虑成熟稳定的解决方案：
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/agent-arthas-integration-research.png\")
AI 检索了大量资料和 Arthas 官方文档后，输出了下面这份系统架构设计图。从上到下分三层：用户层输入服务名和故障现象，Agent 层由 Skill 引擎、Arthas HTTP Client 和 AI 分析引擎三大核心模块协同工作，最底层通过 Arthas 内置 HTTP API 对接多个目标服务实例。架构的模块划分和职责边界清晰，从故障输入到定位代码再到生成报告的完整链路设计到位：
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/system-architecture-design.png\")
AI 给出了架构图之后，还进一步拆解了 6 个核心组件的职责分工——从 AI Agent Server 的流程编排，到 Arthas HTTP Client 的会话管理，到 Skill 引擎的诊断步骤链定义，再到 AI 分析引擎的报告生成，每个组件的边界和协作关系都交代得比较清楚：
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/core-component-roles.png\")
最后来看最重要的数据流设计。架构设计明确之后，只要数据流链路完整清晰，基本就可以着手开发了。AI 结合一个常见的 RT 超时场景，给出了完整的诊断链路——从 Skill 匹配、诊断步骤执行、问题追踪、根因定位，到 Arthas 反编译和最终的诊断报告输出。AI 针对 Arthas HTTP API 设计了完整的会话模式交互流程（init_session → async_exec → pull_results → interrupt_job → close_session），连watch、trace这类持续监听型命令的异步轮询机制都考虑到了。这一点在评审时需要重点关注——如果 AI 对底层工具的通信模型理解有偏差，后续编码阶段就会出现问题：
![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/data-flow-design.png\")
其他细节就不多做赘述了。整体来说，架构和数据流链路都比较到位。AI 不仅针对既有需求给出了方案，还主动输出了 6 个后续扩展方向——WebSocket 实时推送、诊断知识库向量化存储、已知 Pattern 的自动修复补丁、告警联动自动触发诊断、自定义 Skill 市场、多语言支持。这些扩展方向都紧扣当前架构的技术延伸：知识库基于现有的诊断报告数据，自动修复基于已有的 Skill 引擎，告警联动基于现有的服务实例查询机制。
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/extension-suggestions.png\")
确认方案没有问题后，笔者直接下达开发指令：
\n整体方案没有问题，请完成开发工作吧AI 收到指令后，开始自主编码。按照之前的架构设计，逐模块推进——从父 POM 和 Maven 多模块骨架搭建，到通用工具类、数据模型、数据访问层、Arthas 客户端封装、Skill 引擎、AI 分析引擎、业务逻辑层、Web 控制器，直到启动模块和部署配置，11 个子步骤全部完成：
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/ai-coding-process.png\")
片刻之后，AI 完成了全部编码工作，并输出了一份详细的交付清单。9 个模块、46 个文件全部到位——从通用工具类到 7 个内置诊断 Skill，从 Arthas HTTP API 的 exec+session 双模式封装到 Spring AI Alibaba 诊断分析器，一个不少：
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/delivery-checklist.png\")
先看整体模块结构，AI 按照 Java 多模块的标准规范完成了工程划分，从上到下严格遵循 common→model→dal→client→skill→ai→service→web→bootstrap 的依赖层级，命名规范统一。
\nagent-skill 模块值得关注，AI 设计了 Skill 引擎的抽象接口，并内置了 7 个覆盖常见 JVM 故障场景的诊断技能（CPU 飙高、OOM、死锁、慢接口、GC 异常、线程泄漏、类找不到），每个 Skill 都定义了完整的诊断步骤链。这种”框架 + 内置实现”的设计思路，扩展性不错：
\njvm-ai-agent/\n├── jvm-ai-agent-server/ # 智能体服务端（核心）\n│ ├── agent-common/ # 通用模块：工具类、常量、DTO\n│ ├── agent-model/ # 数据模型：实体、数据库映射\n│ ├── agent-dal/ # 数据访问层：Mapper、Repository\n│ ├── agent-arthas-client/ # Arthas HTTP API 客户端封装\n│ ├── agent-skill/ # Skill 引擎（诊断方法论）\n│ ├── agent-ai/ # AI 分析引擎\n│ ├── agent-service/ # 业务逻辑层（含服务实例查询）\n│ ├── agent-web/ # Web 层：REST API、WebSocket\n│ └── agent-server-bootstrap/ # 启动模块\n│\n└── pom.xml # 父 POM再看诊断核心逻辑，AI 严格按照架构设计中定义的数据流完成了完整的诊断业务链开发。整个 executeDiagnosis 方法按照 Skill 匹配、实例定位、诊断链执行、动态命令解析、AI 分析、报告生成的流程推进，异常处理也考虑到了非关键步骤失败时继续执行的容错策略：
DefaultSkillMatcher根据故障现象关键词匹配最佳诊断技能ServiceInstanceLocator根据服务名解析目标实例 IP 和 Arthas 端口private void executeDiagnosis(DiagnosisRecord record, DiagnosisRequest request) {\n try {\n // 1. 匹配 Skill\n Optional<SkillDefinition> skillOpt = skillMatcher.findBestMatch(request.getSymptom());\n if (skillOpt.isEmpty()) {\n failDiagnosis(record, \"无法匹配到合适的诊断技能\");\n return;\n }\n SkillDefinition skill = skillOpt.get();\n // ......\n\n // 2. 定位目标实例\n ServiceRegistry instance = instanceLocator.resolveInstance(\n request.getServiceName(), request.getInstanceIp());\n // ......\n\n // 3. 执行诊断步骤链\n List<DiagnosticStep> chain = skill.getDiagnosticChain();\n StringBuilder allDiagnosticData = new StringBuilder();\n String decompiledCode = \"\";\n Map<String, String> contextVars = new HashMap<>();\n\n for (int i = 0; i < chain.size(); i++) {\n DiagnosticStep step = chain.get(i);\n // ...... 初始化步骤实体\n\n try {\n // 解析动态命令（支持上下文变量注入）\n String command = resolveCommand(step, contextVars);\n // ......\n\n // 执行Arthas命令并记录耗时\n String result = executeStep(host, port, step, command);\n\n // 如果是 jad 结果，记录为反编译代码\n if (\"jad\".equals(step.getResultType())) {\n decompiledCode = result;\n }\n\n // 从结果中提取上下文变量供后续步骤使用\n extractContextVars(result, contextVars);\n } catch (Exception e) {\n // 非关键步骤失败时继续执行\n // ......\n }\n }\n\n // 4. AI 分析\n String report = diagnosisAnalyzer.analyze(\n request.getSymptom(), allDiagnosticData.toString(), decompiledCode, skill);\n\n // 5. 保存报告（从Markdown报告中提取根因、严重程度等结构化字段）\n // ......\n\n // 6. 更新诊断记录状态\n record.setStatus(DiagnosisStatus.COMPLETED.getCode());\n // ......\n } catch (Exception e) {\n failDiagnosis(record, e.getMessage());\n }\n}在 AI 编码期间，笔者查阅了 Spring AI Alibaba 的官方文档，发现它提供了现成的 Agent Chat UI。与其让 AI 从头生成前端页面，不如直接集成这个交互组件，实现 SSE 流式输出的诊断体验。于是笔者给了一条简短的指令：
\n根据Spring AI Alibaba官方文档（参考链接https://java2ai.com/docs/frameworks/studio/quick-start：），实现agent智能体交互页面开发工作只给了一个文档链接和一句话，AI 就自己去读官方文档、理解集成步骤、完成了页面开发。这也是使用 AI 辅助编程的一个实用技巧：当你只需要集成某个现成组件时，直接给出文档链接往往比详细描述需求更高效。
\n![\"AI](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/agent-chat-ui-integration.png\")
到这里，一个完整的智能诊断 Agent 就构建完成了。为了验收功能，笔者在本地起了一个 CPU 飙升的测试接口：
\n@Slf4j\n@RestController\npublic class TestController {\n @RequestMapping(\"cpu-100\")\n public void cpu() {\n while (true){\n }\n }\n}启动 Agent 服务，访问 http://localhost:{应用端口}/chatui/index.html，在聊天框输入：order-service 程序CPU飙升,请协助排查。Agent 在收到故障表象后，完成了完整的诊断链路——先通过 Dashboard 获取概览定位到 CPU 占用最高的线程 ID，再基于线程栈帧信息定位到问题代码段，最后通过 Arthas 反编译（jad）输出热点代码并生成包含根因分析和修复建议的完整诊断报告。整个过程 Agent 全程自主完成，SSE 流式输出让每一步诊断进度都清晰可见：
![\"Agent](\"https://oss.javaguide.cn/ai/coding/glm5.1-cc/agent-diagnosis-demo.png\")
场景一验证的是 AI”从 0 到 1 的规划与交付能力”，那场景二要验证的就是另一个维度：在一个已有一定复杂度的代码库中，AI 能否准确理解既有架构、定位问题、并完成增量优化。
\n这是一个基于 Spring Boot + MyBatis 的订单查询服务（glm-testing-service），核心业务围绕订单的查询和分析展开，包含四个接口：
\n| 接口 | 路径 | 说明 |
\n|
说实话，Claude Code 里有些命令我用了一次就离不开了，但问身边朋友知道的人反而不多。这个系列文章就来聊聊这些被严重低估的命令——/simplify、/review、/loop、/batch、/run、/verify。
这些命令你知道有就行了，不用硬背。打个斜杠 / 就出来了，比你吭哧吭哧打字快多了。
\n\n版本说明：本文基于 2026 年 5 月 Claude Code 官方 Commands 文档和当前客户端行为整理。Claude Code 命令更新很快，最终以
\n/help、/命令列表和官方 Commands 页面为准。
Claude Code 里 / 开头的东西，来源有两层：
/clear、/compact、/model、/cost、/help、/review、/diff、/context、/permissions 等。逻辑写死在 CLI 代码里，直接与终端交互，不涉及 AI 推理，执行速度快且不消耗 Token。/simplify、/batch、/debug、/loop、/run、/verify、/code-review、/claude-api。本质是基于 Prompt 的能力：调用时，Claude 会载入特定的 Markdown 指令集到上下文，然后调动子代理（Sub-agents）执行多步工作流。\n\n注意：
\n/review是内置 PR review 命令，不是 bundled skill；深度多 Agent 审查应使用/ultrareview。
下面详细介绍这几个实用的内置能力。
\n/simplify 做的事很简单：审查你刚写的代码，找出隐藏的问题，然后直接帮你改掉。现在官方文档已把 /simplify 列为 bundled skill。
第一步：确定审查范围。 通常围绕最近变更文件工作；不带参数时，它跑 git diff 拿增量变更；如果工作区没有未提交的修改，它会自动审查最近一次 commit。指定具体类名时（比如 /simplify MarketDataService），它会读取整个文件做全量审查。具体范围以当前 Claude Code 版本行为为准。
第二步：并行启动三个审查 Agent。 不是串行地逐条检查，而是同时派出三个"审查员"，各自带着不同的视角去读同一份 diff：
\n三个 Agent 各管一摊：
\nrequireNonBlank()，它会在项目里搜一圈，发现已经有一个 InputValidator.requireNonBlank() 做了同样的事。ConcurrentHashMap、该用缓存的结果每次都重新算。第三步：汇总并修复。 三个 Agent 各自报告发现，Claude Code 会自动判断哪些是真问题、哪些是误报，然后直接动手改代码。
\n\n\n⚠️ 风险提示：
\n/simplify会应用修复，但仍建议通过 diff、测试和 review 复核，尤其是涉及事务、安全、并发的改动。它是 prompt-based skill，可能误判。
也可以给它指定关注方向：
\n/simplify thread safety\n/simplify SQL performance\n/simplify exception swallowing\n/simplify MarketDataService在你已经知道哪块大概有问题、想让 AI 帮你精确定位的时候，这个功能很实用。
\n有一次我写了一个用户认证模块，自测通过就准备提交了。习惯性地先跑了一遍 /simplify，它直接帮我找到了 6 个潜在问题，经过确认，确实都是实际存在的问题。
![\"直接运行](\"https://oss.javaguide.cn/github/javaguide/ai/coding/claudecode/simplify-command-run.png\")
![\"扫描到的问题\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/claudecode/simplify-issues-found.png\")
最值得说的是一个 Spring 事务失效 的问题。三个 Agent 中有两个独立地从不同角度捕获到了同一个 Bug。
\n问题代码是这样的——WatchlistService 里，外层方法获取 Redis 分布式锁做 double-check，内部调一个 protected 方法执行数据库写入：
public void initializeDefaultWatchlist(Long userId) {\n // Redis 分布式锁 + double-check（幂等）\n // ...\n doInitializeDefaultWatchlist(userId); // 同一类内部调用\n // ...\n}\n\n@Transactional(rollbackFor = Exception.class)\nprotected void doInitializeDefaultWatchlist(Long userId) {\n groupService.save(defaultGroup); // INSERT 分组\n stockService.saveBatch(initialStocks); // INSERT 5 只股票\n}代码结构看起来合理：外层管锁和幂等，内层管事务。但 @Transactional 写在这实际上完全不起作用——因为 Spring AOP 基于动态代理，同一个类内部的直接调用会绕过代理，注解根本不会被拦截到。
这意味着如果 saveBatch 中途抛异常，save 已经提交的分组记录不会回滚，数据库里会出现一个没有股票的空壳分组。
\n\n前提条件：在 Spring 默认代理式 AOP 下，同类内部直接调用会绕过代理，
\n@Transactional不会生效；如果使用 AspectJ weaving 或通过代理对象调用，结论不同。
@Transactional 失效，评为高严重性。/simplify 给出的修复方案是把声明式事务换成编程式事务，用 TransactionTemplate 直接控制事务边界。其他修复方式包括：把事务方法移动到另一个 Spring Bean、通过代理对象调用、调整事务边界到外层 public 方法。
@RequiredArgsConstructor\npublic class WatchlistService {\n\n private final TransactionTemplate transactionTemplate;\n\n private void doInitializeDefaultWatchlist(Long userId) {\n transactionTemplate.executeWithoutResult(status -> {\n groupService.save(defaultGroup);\n stockService.saveBatch(initialStocks);\n });\n }\n}![\"开启优化\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/claudecode/simplify-optimization-start.png\")
![\"所有修改完成\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/claudecode/simplify-all-fixes-done.png\")
这次扫描还发现了另外 5 个问题，涵盖代码复用、安全性和效率：
\n| 发现 | Agent | 修复方式 |
\n|
大家好，我是 Guide。前面写过 IDEA 搭配 Qoder 插件的实战、Trae 接入大模型的实战 和 Claude Code 接入第三方模型的实战，这篇专门把 Claude Code 的日常用法拎出来讲一遍。
\n很多人第一次用 Claude Code，会把它当成“能在终端里聊天的 AI”。这其实低估它了。
\n它好用的地方，是能自己读仓库、搜代码、跑命令、看报错、改文件，再根据验证结果继续迭代。你给它一句“修一下登录超时后无法刷新 token 的问题”，它会去找认证流程、读测试、改实现、跑命令。问题也在这里：如果上下文、权限和验收标准没管好，它会越跑越远，最后你面对一堆 diff 发呆。
\n这篇文章按 2026-05-29 的 Anthropic 官方文档整理，并结合我自己的使用习惯重写。
\nClaude Code 迭代很快，部分命令和版本门槛会变，具体以 claude --version 和官方文档为准。比如 /run、/verify 需要 Claude Code v2.1.145+；新版 /simplify 的官方说明出现在 v2.1.154+ 之后；--enable-auto-mode 已经移除，现在用 --permission-mode auto。
国内使用 Claude Code 还有现实门槛：账号、网络、成本、第三方中转稳定性都要考虑。GLM、MiniMax、Kimi、DeepSeek 这类模型可以作为替代或补充，但如果任务是大规模代码修改、复杂重构、长链路排错，Claude 目前仍然是很值得单独研究的工具。
\nCLAUDE.md 非常重要CLAUDE.md 可以理解成写给 Claude Code 的项目规则文件。
它不是普通 README，也不是越长越好。Claude 每次启动都会读它，所以这里面只应该放每次会话都值得知道的东西。
\n千万别写成项目说明书！应该写 Claude 容易猜错、代码里读不出来、团队又必须遵守的规则。重点放技术栈版本、常用命令、架构取舍、团队约定和项目坑点；别塞空话、默认行为和大段文档。
\n判断标准很简单：这行删掉后，Claude 会不会更容易犯错？
\n![\"多智能股票分析项目中的](\"https://oss.javaguide.cn/github/javaguide/ai/coding/claude-agents-md.png\")
Claude Code 的配置有几层作用域，不同文件解决不同问题：
\n| 作用域 | 位置 | 适合放什么 |
\n|
说实话，这个话题我酝酿很久了。很早就想聊聊，但一直拖着没有抽出时间写（其实就是懒！）。
\n每次在群里聊 AI Coding 或者公众号分享 AI Coding 技巧，总有人问："Claude Code 那个黑窗口到底好在哪？我 Cursor 用得好好的为什么要换？" 然后另一边马上有人回："都 2026 年了还在用 IDE？CLI 才是正道。"
\n两边都有道理，但两边说的又都不全面。今天我把自己这大半年从 IDE 到 CLI 再到两者混用的经历，结合最近行业里几款重磅产品的实际体验，一次性讲清楚。
\n在 AI 编程的语境下，这两个词的含义和传统开发稍有不同，别搞混了。
\nAI IDE 工具，就是带图形界面的编程环境，代码编辑、运行调试，AI 对话全整合在一个窗口里。你熟悉的 Cursor、Kiro、Qoder、TRAE，Windsurf 都属于这类。其中大部分（Cursor，Windsurf、Kiro、TRAE）是基于 VS Code 二次开发的，界面风格和操作逻辑与 VS Code 一脉相承；另一类则是独立开发的原生产品，如 Zed、JetBrains + Qoder 插件。
\n![\"Qoder](\"https://oss.javaguide.cn/github/javaguide/ai/coding/qoder-view.png\")
AI CLI 工具，就是纯终端交互的命令行工具，没有图形界面。Claude Code、Codex、Qwen Code、OpenCode 都属于这类。你在终端里输入自然语言指令，AI 直接读仓库、改代码、跑测试，看报错，再改——全程在黑窗口里完成，你的角色从"写代码的人"变成了"指挥 AI 干活的人"。
\n
一句话区分：CLI 适合"告诉 AI 要什么，等它交付"的场景；IDE 适合"边看边改、逐行审核"的场景。
\n| 维度 | AI IDE 工具 | AI CLI 工具 |
\n| :
大家好，我是 Guide。前面聊了 Claude Code 的使用技巧，这篇来看看 OpenAI 阵营的主力编程工具——Codex。
\nOpenAI 在 2025 年推出了 Codex 系列产品线，涵盖基于 o3 模型的云端软件工程智能体（codex-1）和开源的终端编码助手 Codex CLI。它和传统的代码补全不同，能自己读代码、跑测试、提 PR，完成从理解到交付的完整闭环。但想让它真正好用，提示工程、工具配置、安全策略这几环缺一不可。
\n这篇文章综合 OpenAI 官方博客、Codex CLI 开源仓库 README、官方提示工程指南等多个来源，整理成一份实践指南。通过本文你将搞懂：
\nOpenAI 发布了基于 o3 模型微调的 codex-1 云端智能体。它运行在 OpenAI 的安全沙箱中，可以读写代码、运行测试和命令行工具，甚至直接提交 Pull Request。三个核心特性：
\n.cursorrules 或 CLAUDE.md，你可以在仓库中放置 AGENTS.md 文件来定义项目级别的编码规范和约束Codex 云端智能体目前通过 ChatGPT Pro、Business 和 Enterprise 计划提供访问，Plus 计划也于 2025 年 6 月起陆续开放。它支持两种工作模式：交互式对话和后台任务。后台模式下，你可以同时派发多个任务，每个任务在独立容器中并行执行。
\n\n\n一句话区分：云端智能体适合“挂后台跑大任务”，CLI 适合“坐电脑前盯着改代码”。 两者定位不同，核心理念一致——长期自主、减少人工干预、以可交付的代码为目标。
\n
Codex CLI 是一个完全开源的终端工具，用 Rust 编写，可以在本地机器上执行代码修改和 shell 命令。跟云端智能体的区别主要在运行环境和安全模型上：
\n| 维度 | Codex 云端智能体 | Codex CLI |
\n|
这几天 AI 圈基本被一件事刷屏了——DeepSeek V4 发布，同步开源。从技术报告里的 benchmark 数据到社区的实测反馈，到处都在讨论。
\n开源模型在对话和写作上已经做得相当成熟，各家你追我赶，迭代速度肉眼可见。但 Agent Coding 是另一回事。
\n让模型自主分析项目结构、理解多文件依赖、给出能直接落地的工程方案——这种活没有捷径，全靠硬实力。
\n之前各家模型在这个方向上一直在进步，但实际用过就知道，离"放心交给它独立完成"始终还差那么一点。
\n所以这次 V4 发布，Guide 第一反应就是直接接入 Claude Code 上手干活。
\n这篇文章接近 7000 字，建议收藏，通过本文你将搞懂：
\nClaude Code 强在它的工具链和执行力，但 Claude 官方模型太贵，加上现在 Claude 太容易封号。这次 DeepSeek V4 提供了一个 Anthropic 兼容接口，这意味着 Claude Code 可以直接对接 DeepSeek，不需要任何第三方适配层。
\n如果你本机没有安装 Claude Code 的话，先运行下面这行命令安装（Node.js 18+）：
\nnpm install -g @anthropic-ai/claude-code编辑或新增 Claude Code 配置文件 ~/.claude/settings.json，添加 env 字段，把后端地址、模型和 API Key 都写进去：
{\n \"env\": {\n \"ANTHROPIC_AUTH_TOKEN\": \"your_deepseek_api_key\",\n \"ANTHROPIC_BASE_URL\": \"https://api.deepseek.com/anthropic\",\n \"ANTHROPIC_MODEL\": \"DeepSeek-V4-Pro\",\n \"API_TIMEOUT_MS\": \"3000000\",\n \"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC\": \"1\"\n }\n}注意替换 your_deepseek_api_key 为你的 DeepSeek API Key。
API Key 创建地址：https://platform.deepseek.com/ 。
\n![\"DeepSeek](\"https://oss.javaguide.cn/github/javaguide/ai/coding/deepseek-api-keys.png\")
如果你使用的是 DeepSeek-V4-Flash，把 ANTHROPIC_MODEL 改为 DeepSeek-V4-Flash 即可。
配置完成后启动 Claude Code：
\nclaude首次启动需要选择信任当前文件夹。
\n如果你想在 DeepSeek、Claude、MiniMax 等多个 Provider 之间灵活切换，推荐安装 CC Switch。这是一个专门管理 Claude Code 模型切换的小工具，支持一键横跳，还支持管理 Skills、MCP 和提示词。
\n![\"CC](\"https://oss.javaguide.cn/github/javaguide/ai/coding/cc-switch-main-interface.png\")
启动 CC Switch，点击右上角 "+" ，选择自定义供应商，Base URL 填写 https://api.deepseek.com/anthropic，API Key 填写你的 DeepSeek API Key。
![\"CC](\"https://oss.javaguide.cn/github/javaguide/ai/coding/deepseek-v4/cc-switch-add-deepseek-provider.png\")
将模型名称改为 DeepSeek-V4-Pro（或 DeepSeek-V4-Flash），完成后点击右下角的"添加"。
直接在命令行输入 claude 或者进入 Claude Code 界面之后再次输入 /status 确认，model 为 DeepSeek-V4-Pro 即表示接入成功。
![\"验证是否生效\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/deepseek-v4/verify-deepseek-v4-ready.png\")
之后你就可以用 DeepSeek V4-Pro 来驱动 Claude Code 的所有能力了。
\n我手头有一个多智能体股票分析项目，已经快一个月没启动了。这次重新启动，第一件事就是把过时的模型配置更新掉。
\n项目 Settings 页面之前只有一个纯文本输入框让用户手动填写模型名，不够友好。
\n我需要做两件事：搜索各家 LLM 的最新模型版本，然后给前端加一个下拉选择。
\n提示词很简单：
\n\n\n/tavily-search 搜索当前 deepseek、glm 和 openai 最新的模型，然后调整全局配置中默认模型推荐和示例。并且，当前这几个 LLM 图标太 AI 味了，帮我换一个上档次点。
\n
任务不大，但有个细节值得说——如果不配 /tavily-search Skill，单纯靠大模型的训练数据截止日期来猜最新版本，大概率会出错。我之前用其他模型没配 Tavily 的时候，反复提示了好几遍才把各家最新模型版本搞对。
关于 Tavily 的使用可以参考：Claude Code 对接 AI Agent 搜索引擎 Tavily 实现高质量搜索。
\nDeepSeek V4-Pro 一次搞定。
\n![\"搜索并更新最新](\"https://oss.javaguide.cn/github/javaguide/ai/coding/deepseek-v4/search-and-update-latest-models.png\")
模型配置全部更新成功，各家推荐的模型示例都切到了最新版本。改了三个文件：
\napplication.yml——新增 DeepSeek 预设 Provider，GLM 默认模型升级到 glm-5.env.example——补上 DeepSeek 环境变量，Kimi 默认改为 kimi-k2.6SettingsPage.tsx——加了 PROVIDER_PRESETS 常量，Model 和 Embedding Model 改成 combo box最终四个 Provider 的推荐模型列表（截至 2026.04.25）：
\n| Provider | 推荐模型 |
\n|
大家好，我是 Guide。如果你是 JetBrains IDE 的重度用户，大概率有过这样的纠结：想用 AI 辅助编程，但主流工具——Cursor、Trae、Qoder——大多基于 VS Code。切过去？舍不得 JetBrains 调试和重构体验。不切？又感觉错过了 AI 的效率红利。
\n有朋友会说：Claude Code、Gemini CLI 这些终端工具不是挺香的吗？确实香，但说实话，CLI 模式也有明显的短板：没有原生 UI 交互，看代码、审 diff 都不够直观。虽然可以通过一些开源项目（如 vibe kanban、1Code）来缓解，但在做复杂项目时，还是存在一些局限性。
\n现在的后端开发者，大致分成了四大阵营：
\n| 阵营 | 工具组合 | 特点 |
\n|
之前写了篇万字详解 Agent Skills，聊了 Skills 是什么、怎么用、和 Prompt / MCP 有什么区别。这篇不聊概念，直接分享 6 个我日常在用的 Skills，覆盖开发流程、代码审查、UI 设计、网页操作这些场景：
\n下面一个个来看。
\nSuperpowers 是一个专为 AI 编程 Agent（Claude Code、Cursor 等）设计的软件开发工作流框架，把 TDD、Code Review、Spec-Driven、Git Worktree、子 Agent 协作等实践封装成 Skills。内置的核心技能如下：
\n| 技能名称 | 触发方式 | 核心功能 |
\n|
你好，我是小 G。拖了蛮久，来填坑了。
\nSpec Coding 很早之前就有群友提到说建议写一下。确实还蛮重要的，工作中能用到，面试也开始问了。
\n![\"spec](\"https://oss.javaguide.cn/github/javaguide/cs-basics/network/readers-urging-spec-coding-to-be-written.png\")
上周和同事聊天，他问我还在折腾 Spec Coding 干嘛。原话大概是：“Claude Code 都能自己写代码了，你花时间写规范不是多此一举？”
\n我当时没忍住怼了一句：“AI 写出来的屎山代码，你来维护？”
\n他愣了一下。
\n说实话我理解他的想法。AI 写代码确实快，扔一句需求过去，几秒钟一个函数就出来了，跑起来还挺像那么回事。Demo、脚本、一次性页面，这么搞没毛病。
\n但问题是——你把这套玩法搬到一个多人协作、要长期维护的项目里，过两周再回来看那段代码，你大概率不想碰，也不敢碰。因为需求里没写清的部分，AI 自己脑补了；边界条件你没提，它按“常见写法”猜了一个；你们团队的错误码格式、权限校验约定，AI 一个都不知道。它只是按照训练数据里出现频率最高的方案，给你拼了一段“看起来能跑”的代码。
\n这篇文章聊 Spec Coding 的核心思路，内容不少，建议收藏。通过本文你将搞懂：
\nVibe Coding（氛围编程），凭感觉走。给 AI 一句模糊的意图，它就直接开始输出代码。
\nKarpathy 最早提这个词时，说的也是那种把需求丢给 AI、顺着感觉不断调整、甚至暂时不太管代码细节的写法。
\nVibe Coding 不是原罪。下面这些场景，用它反而很合适：
\n这些情况下，硬写一大堆 Spec 反而是浪费时间。
\n真正的问题是：很多人验证完想法之后，顺手就把 Vibe 出来的代码推上了生产。
\n这就不一样了。
\nDemo 阶段你可以靠感觉走，因为错了就改，坏了就删。生产代码不行，它后面会接数据库、接支付、接用户数据、接别人的维护成本。你今天省下来的半小时，可能会变成后面几天的排查时间。
\n我的判断标准就一条： 这段代码要活多久？
\n而且，很多时候搭配轻量级 Spec 也没问题，不需要太死板。
\n轻量 Spec 可以简单到这种程度：
\n## 任务目标\n\n实现一个订单导出接口，支持按时间范围导出 CSV。\n\n## 关键约束\n\n- 单次导出最多 5000 条\n- 时间范围不能超过 31 天\n- 必须校验用户权限，只能导出当前租户的数据\n- 查询必须命中 order_tenant_time_idx 联合索引\n- 导出失败要记录失败原因，不能只返回 unknown error\n\n## 验收标准\n\n- 正常导出 CSV，字段顺序符合产品约定\n- 超过 5000 条时返回明确错误\n- 越权租户数据不能被导出\n- 单元测试覆盖空时间、越界时间、无权限、无数据四种场景Spec Coding，直译过来叫规范驱动编程。简单来说就是：先把规范写清楚，再让 AI 干活。
\n平时让 AI 写代码，很多人会直接丢一句：
\n\n\n帮我做一个用户系统。
\n
AI 当然能写，而且看起来还挺像那么回事。但问题也在这里：你没告诉它用户系统到底长什么样，它就只能自己猜。
\n用户怎么注册？邮箱能不能重复？密码怎么存？接口失败时返回什么格式？哪些功能这期不做？管理员有没有禁用用户的能力？这些东西如果一开始没写清楚，AI 不会停下来反问你，它大概率会先补一套自己觉得合理的方案。
\nSpec Coding 做的事情，就是把这些规则提前写下来。
\n这里的 Spec 不是随便写两句需求，而是一份 AI 能照着执行的技术约定。接口、数据结构、错误码、边界条件、安全要求、技术栈限制，甚至哪些操作不允许碰，都要写在里面。
\n它和 Vibe Coding 的差别，也就在这。
\nVibe Coding 更像是你给 AI 一个大方向，然后让它自由发挥。代码生成出来以后，你再去验收、改 bug、补细节。短平快的小脚本这么干没啥问题，甚至很爽。
\n但项目稍微复杂一点，就容易出事。等你发现 AI 理解错了，代码已经写了一堆。你回头查，也很难说清楚到底是需求没讲明白，还是 AI 自己乱发挥。
\n简单总结下 Spec Coding 和 Vibe Coding 的差别：AI 的行为是由你定义的，还是由它猜的？
\n一般会把 Spec Coding 拆成四步：Specify、Plan、Tasks、Implement。
\n| 阶段 | 干什么 | 产出 | 关键动作 |
\n|
大家好，我是 Guide。前面分享过一篇 IDEA 搭配 Qoder 插件的实战，那篇主要讲在 JetBrains 体系内用 AI 辅助编码。这篇换个角度，聊聊 Trae IDE 接入大模型 的实战体验。
\nTrae 是字节跳动推出的 AI 编程 IDE，基于 VS Code 生态，支持接入多种大模型。本文使用 MiniMax M2.7 作为示例，但 Trae 的接入方式是通用的——换成 Claude、GPT 等其他模型，流程基本一致。
\n我这里使用 MiniMax 是因为我刚好订阅了 MiniMax Code Plan 想要实际测试一些，并非广告，你可以换成其他模型，思路都是一样的。
\n我选了两个比较有代表性的复杂场景来实际验证：
\nTrae 支持接入多种大模型，下面以接入自定义模型为例，演示通用配置流程。
\n第一步：到 Trae 官网下载安装并完成初始化，同时到对应模型平台完成注册和 API Key 创建（本文示例使用 MiniMax 平台）：
\nhttps://platform.minimaxi.com/subscribe/token-plan
\n第二步：在 Trae 中点击"Add Model"添加自定义模型：
\n![\"Trae添加模型入口\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/trae-add-model-entry.png\")
第三步：选择"Other Models"并手动输入模型 ID 和 API Key：
\n![\"选择Other](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/select-other-models.png\")
第四步：输入模型 ID（如 MiniMax-M2.7）和申请的 API Key，点击"Add Model"。若无报错提示，即表示接入成功：
![\"输入模型ID和API](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/input-minimax-m2.7-api-key.png\")
接入完成后，就可以在 Trae 中使用该模型进行 AI 辅助编程了。接下来通过两个实战场景，分享具体的使用方式和技巧。
\n第一个案例是某次真实线上故障的复现（已脱敏）。当时部门同学反馈某列表查询接口报错，页面无数据。线上监控系统定位到接口信息如下：
\n接口：GET http://localhost:8080/api/rbac/user/list
返回结果：
\n{\n \"code\": 500,\n \"message\": \"系统繁忙，请稍后重试\",\n \"data\": null,\n \"timestamp\": \"2026-03-19T10:11:02.632242\"\n}结合异常堆栈信息关键字Read timed out，以及对应代码段的get(key)操作，我们可以初步认为该报错只是表象并非根因。
@Override\npublic String getConfigValue(String configKey, String environment) {\n String cacheKey = CONFIG_CACHE_PREFIX + configKey + \":\" + environment;\n String value = stringRedisTemplate.opsForValue().get(cacheKey);\n if (value != null) {\n return value;\n }\n // 后续逻辑省略\n}按照常规处理流程，我们需要快速定位问题根因、完成止血，再联系运维深入排查。但项目中多处用到Redis，逐一排查耗时长，期间可能影响业务稳定性。
\n为了验证 AI 辅助排查的实际效果，笔者复刻了该故障场景（已脱敏），让模型接手处理。按照企业级线上故障处理流程，首先需要定位根因并完成止血。于是向模型下达了第一条指令：
\n针对访问 http://localhost:8080/api/rbac/user/list 接口时出现的500错误（错误信息：\"系统繁忙，请稍后重试\"），请执行以下操作：\n1. 分析提供的异常堆栈信息，准确定位导致服务器内部错误的根本原因；\n2. 提供详细的线上紧急止血方案，包括但不限于：临时回滚策略、流量限制措施、服务降级方案或紧急重启流程；\n3. 解释错误产生的技术原因，指出具体的代码模块或配置问题；\n\n...... 异常堆栈关键信息：`java.net.SocketTimeoutException: Read timed out`![\"向M2.7下达的诊断指令截图\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-diagnostic-instruction.png\")
模型收到请求后，很快定位到指定代码的上下文，并推理出4种可能的根因：
\n![\"M2.7推理结果截图\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-inference-result.png\")
到这一步，模型已经把问题空间从"N处Redis调用"压缩到了"4种可能根因"——这种快速收敛问题范围的能力，是 AI 辅助排查的核心价值。接下来看它的止血思路。
\n模型针对既定异常栈帧快速梳理了代码调用逻辑，准确地指出：列表查询接口被切面拦截，连接池耗尽是500错误的根因。另外一个关键点，它指出了这段代码缺乏降级策略——这一点笔者是在复盘会上才意识到的。
\n![\"M2.7代码调用链路分析截图\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-call-chain-analysis.png\")
针对线上问题，止血策略是最关键的环节。模型给出了几个解决方案，第一个就是临时关闭权限校验开关——原因在于方案一需要清除Redis缓存数据。虽然方案有些激进，不过，它详细指出了代码的调用链路和表结构信息，这也能很好地辅助我通过业务语义猜测可能的场景和原因。
\n![\"M2.7调用链路分析\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-call-chain-analysis-2.png\")
基于模型提供的调用链路信息，笔者进一步询问方案一的技术依据，确保业务理解上快速对齐：
\n结合代码开发的完整工作流程，详细阐述方案一的技术依据、设计思路及实施合理性。这也是让笔者比较满意的地方，模型给出了问题代码的调用链路图，让我快速了解到列表查询期间所经过的完整切面和具体故障所处位置，帮助理解当前问题的影响面以及本次异常的直接原因。
\n经过不到10分钟的交互，笔者不仅迅速获得一个宏观的架构视角，理解了当前复杂架构的故障和各解决方案的依据，例如方案一：通过修改数据库配置重启刷新缓存来规避权限校验。
\n![\"M2.7调用链路图截图\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-call-chain-diagram.png\")
我们再来看看方案三的思路：当Redis不可用时，使用本地缓存或默认值，避免级联失败。模型结合当前工程代码段给出了修改建议：
\n![\"M2.7方案三代码片段\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-solution-3-code.png\")
模型分析后，我们对问题有了初步的判断：Redis客户端连接池耗尽，导致日常业务接口基于缓存开关查询逻辑崩溃，进而引发雪崩效应。综合模型的多个建议，本着保守、快速止血、业务高峰期不压垮数据库的原则，得出以下hotfix方案：
\n根据提供的方案，创建一个hotfix止血分支，用于紧急修复Redis异常问题。具体实施步骤如下：\n1. 基于当前生产环境代码创建hotfix分支，命名规范为\"hotfix/redis-exception-handler\"\n2. 按照方案三实现Redis异常捕获机制，在所有Redis操作处添加try-catch块\n3. 当捕获到Redis异常时，自动降级为直接查询数据库获取数据\n4. 实现JVM本地缓存机制，将查询结果缓存至内存中，设置合理的缓存过期时间\n5. 完成单元测试和集成测试，覆盖率需达到80%以上\n6. 准备回滚方案，确保在紧急情况下能够快速恢复到上一版本![\"hotfix方案指令\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/hotfix-instruction.png\")
模型收到指令后，准确理解了问题，完成任务拆解并逐步执行：
\n![\"M2.7任务拆解过程\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-task-breakdown.png\")
最终输出的代码结果如下：模型在原有权限校验逻辑中整合了数据库降级查询，对权限校验逻辑的理解和复杂设计的整合做得比较到位。
\n@Around(\"permissionCheck()\")\npublic Object checkPermission(ProceedingJoinPoint joinPoint) throws Throwable {\n try {\n // 从配置中心读取权限校验开关\n String checkEnabled = configService.getConfigValue(\"permission.check.enabled\", \"PROD\");\n if (!\"true\".equalsIgnoreCase(checkEnabled)) {\n return joinPoint.proceed();\n }\n\n // ... 原有权限校验逻辑 ...\n\n // 尝试从Redis缓存获取权限信息\n Boolean hasPermission = checkPermissionFromCache(redisKey);\n\n if (hasPermission != null) {\n // ... 命中缓存处理 ...\n }\n\n // 降级：从数据库查询权限\n boolean hasPermissionFromDB = checkPermissionFromDatabase(userId, apiPath, httpMethod);\n // ... 降级逻辑处理 ...\n\n } catch (Exception e) {\n if (e instanceof RuntimeException && \"无权限访问\".equals(e.getMessage())) {\n throw e;\n }\n // 发生异常时，触发监控告警并采用保守策略放行\n AlertManager.notify(\"PERMISSION_CHECK_ERROR\", e.getMessage());\n return joinPoint.proceed();\n }\n}getConfigValue同样补充了本地缓存逻辑，多级缓存设计在容错处理上做得不错。
\n/**\n * 获取配置值（指定环境）\n */\n@Override\npublic String getConfigValue(String configKey, String environment) {\n String cacheKey = CONFIG_CACHE_PREFIX + configKey + \":\" + environment;\n\n // 【第一步：尝试从本地缓存获取】\n String localValue = localCacheManager.get(cacheKey);\n if (localValue != null) {\n return localValue;\n }\n\n // 【第二步：尝试从Redis获取】\n try {\n if (isRedisAvailable()) {\n String value = stringRedisTemplate.opsForValue().get(cacheKey);\n if (value != null) {\n localCacheManager.put(cacheKey, value, LOCAL_CACHE_TTL);\n return value;\n }\n }\n } catch (Exception e) {\n // Redis异常，降级到数据库\n handleRedisFailure(e);\n }\n\n // 【第三步：降级到数据库】\n // ... 其他逻辑 ...\n return getConfigValueFromDatabaseWithFallback(configKey, environment);\n}这其中值得注意的一个细节是本地缓存的设计：模型采用开闭原则，基于ConcurrentHashMap完成了本地缓存工具类的封装，考虑到了堆内存溢出风险，配合LRU算法实现缓存清理：
\n@Component\npublic class LocalCacheManager {\n // 核心存储：ConcurrentHashMap保证线程安全\n private final Map<String, CacheEntry> cache = new ConcurrentHashMap<>();\n private final ScheduledExecutorService cleanupExecutor;\n\n // 缓存配置\n private static final long DEFAULT_TTL_MILLIS = 300000; // 5分钟\n private static final long MAX_CACHE_SIZE = 10000;\n\n public LocalCacheManager() {\n // 守护线程执行定时清理\n this.cleanupExecutor = Executors.newSingleThreadScheduledExecutor(r -> {\n Thread t = new Thread(r, \"local-cache-cleanup\");\n t.setDaemon(true);\n return t;\n });\n this.cleanupExecutor.scheduleAtFixedRate(this::cleanupExpiredEntries, 1, 1, TimeUnit.MINUTES);\n }\n\n public void put(String key, String value) {\n put(key, value, DEFAULT_TTL_MILLIS);\n }\n\n public void put(String key, String value, long ttlMillis) {\n // 容量满时触发LRU清理\n if (cache.size() >= MAX_CACHE_SIZE) {\n cleanupExpiredEntries();\n if (cache.size() >= MAX_CACHE_SIZE) {\n evictOldestHalf();\n }\n }\n cache.put(key, new CacheEntry(value, System.currentTimeMillis() + ttlMillis));\n }\n\n public String get(String key) {\n CacheEntry entry = cache.get(key);\n if (entry == null || entry.isExpired()) {\n cache.remove(key);\n return null;\n }\n return entry.getValue();\n }\n\n // ... 其他方法省略 ...\n\n // LRU清理：删除最老的50%数据\n private void evictOldestHalf() {\n // ...... 省略排序和清理逻辑 ......\n }\n\n // 缓存条目\n private static class CacheEntry {\n private final String value;\n private final long expirationTime;\n\n public CacheEntry(String value, long expirationTime) {\n this.value = value;\n this.expirationTime = expirationTime;\n }\n\n public String getValue() {\n return value;\n }\n\n public boolean isExpired() {\n return System.currentTimeMillis() > expirationTime;\n }\n }\n}通过hotfix分支针对线上故障止血之后，我们再来深入排查Redis连接池耗尽的原因。按照模型的输出结果和推断，一个常规的get指令操作按照Redis 10w qps的性能表现来看，10个连接（平均每个指令1~2ms），理想情况下每秒处理约6600条指令，远低于Redis的极限处理能力，所以问题可能出在代码层面，我们需要进一步推断项目中是否存在不合理的Redis操作：
\n结合本次发生的具体故障现象和表现特征，对项目进行全面的系统性全局分析。分析范围应覆盖项目架构、代码实现、依赖管理、环境配置、数据交互等多个维度，重点识别并输出可能导致生产故障的直接原因。![\"M2.7全局分析指令\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-global-analysis-instruction.png\")
此时模型开始基于全局项目结构和上下文进行详细的阅读和推理分析：
\n![\"M2.7项目结构分析\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-project-structure-analysis.png\")
最终模型给出了详细的故障分析报告，指出根因：不当的Redis数据结构设计使用scan操作导致连接池夯死。同时，还结合上下文给出了该操作的业务流程，便于我们迅速理解这条故障链路：
\n![\"M2.7故障根因分析\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-root-cause-analysis.png\")
而解决方案也是非常干净利落，通过优化数据结构的方式降低Redis读写操作的时间复杂度，避免连接池夯死：
\n![\"M2.7优化方案建议\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-optimization-suggestion.png\")
场景一整体体验不错。从N处Redis调用中精准定位根因，到给出完整止血方案，整个推理链条清晰完整。
\n不过也发现了一些问题：它给出的方案一（清除Redis缓存）略显激进，实际生产环境可能需要更保守的策略。另外，部分边界条件的防御性代码还是需要人工补充——AI能帮你走到90%，剩下的10%还得靠自己。
\n接下来我们再来一个高难度场景——复刻Redis慢查询指令。mini-redis是采用Go语言goroutine-per-connection理念提升吞吐量，并以C语言的风格实现符合RESP协议的缓存中间件，由于语言在设计理念上存在偏差，涉及复杂逻辑梳理和异构方案落地。用于验证大模型的跨语言架构设计能力再合适不过。
\n针对项目重构类需求，按传统开发流程，我们需要大量时间阅读源代码梳理逻辑，期间因历史原因代码无注释，需结合上下文推理调试。了解原有逻辑后，还需结合新项目架构制定实施步骤，并设计单元测试确保既有逻辑稳定运行。整个流程（研发、测试到发布）保守估计需要3个工作日。抱着试试看的心态，笔者将源代码阅读和技术文档整理工作交给 AI 负责。
\n我现在需要通过Go语言复刻Redis慢查询指令的实现。请你详细阅读Redis源代码，深入理解慢查询功能的完整实现原理、数据结构设计、处理流程和关键步骤。具体包括但不限于：慢查询日志的存储机制、慢查询阈值的配置与调整、慢查询命令的收集与记录流程、相关API接口的设计与实现，以及慢查询信息的查询与展示方式。请基于这些理解，整理出清晰的技术文档，包括核心原理说明、关键数据结构分析、实现步骤分解以及可能的性能优化考量。等待片刻后，模型明确指出技术要求，自底向上地介绍数据结构到执行链路，进行了详尽的分析和介绍：
\n![\"M2.7慢查询数据结构分析\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-slowlog-data-structure.png\")
查看其对慢查询切面逻辑的定位非常准确，在主流程上输出了必要的注释，让我快速了解慢查询的整体处理流程：
\n![\"M2.7慢查询切面逻辑\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-slowlog-aspect-logic.png\")
再看其对slot get指令的理解，也非常到位，思路和资深开发一样，抓大放小，明确核心逻辑，在主流程上输出必要的注释：
\n![\"M2.7](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-slot-get-instruction.png\")
确认模型对慢查询有了准确的理解后，接下来让它以开发专家的视角进行功能拆解、落地、测试回归的完整设计文档：
\n按照测试驱动开发(TDD)方法论，使用Go语言创建一个全面详细的开发教程文档，指导复刻Redis的实现。该教程必须符合以下规范：\n\n1. 开发方法：\n - 严格执行测试驱动开发工作流程：先编写会失败的测试，然后实现最简代码以通过测试，最后进行重构\n - 采用类似于原始Redis C语言实现的面向过程的编程风格\n - 尽可能使用纯Go语法和标准库\n\n2. 教程结构：\n - 从项目设置和环境配置说明开始\n - 按Redis功能拆分为逻辑模块进行开发\n - 针对每个模块/特性，提供：\n a. 明确的测试用例定义，包含预期输入和输出\n b. 逐步的代码实现，附带逐行解释\n c. 明确的测试命令和验证流程\n d. 预期测试结果和成功标准\n\n3. 技术要求：\n - 包含所有组件的完整代码片段\n - 指定确切的文件结构和命名规范\n - 详细说明编译和测试命令\n - 解释常见问题的调试流程\n - 在适用时参考相关的Redis C源代码模式\n\n4. 实现细节：\n - 从核心数据结构（字符串、列表、哈希等）开始\n - 逐步推进到命令处理和协议实现\n - 包含网络层和客户端-服务器通信\n - 涵盖持久化机制（RDB/AOF）\n - 按照相同的行为模式实现基本的Redis命令\n\n5. 测试要求：\n - 为每个组件提供完整的测试代码\n - 解释测试断言和验证方法\n - 包含单元测试和集成测试\n - 指定如何运行测试并解读结果\n - 详细说明如何根据Redis规范验证正确行为\n\n该教程应足够全面，让具备中级Go知识的开发者能够按照指定方法成功构建一个功能类似的Redis系统。等待片刻后，我们收到一份设计文档。模型结合Redis源代码上下文，梳理出慢查询的核心脉络和关键定义，并规划出完整的开发步骤：
\n![\"慢查询设计文档\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-slowlog-design-doc.png\")
我们从Redis源代码中抽取设计文档后，为确保C语言工程的设计思路能在个人Go语言项目工程规范中准确落地，将其复制到mini-redis项目，让模型分析方案的可行性和修改建议：
\n![\"M2.7可行性分析\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-feasibility-analysis.png\")
等待片刻后模型完成文档最后的可行性分析和整理，我们开始对其设计方案进行进一步的复核确认。从项目概述上可以看到，模型针对mini-redis项目结构进行了分析，准确地定位到慢查询可以直接复用的链表结构体并完成文档微调：
\n![\"M2.7链表结构体分析\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-linked-list-structure.png\")
再来看看最关键的数据结构实现思路，模型也结合mini-redis的编码规范，生成了Go语言风格的结构体：
\n![\"M2.7](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-go-style-struct.png\")
针对慢查询时间测量，有个细节值得提一下。个人实现的指令处理入口和原生Redis有些设计上的出入：由于Go语言语法糖特性，笔者对指针、指针函数以及文件编排做了特殊处理。模型准确地基于笔者的协程模型定位到时间测量的切面，完成前置计时和后置统计，实现慢查询监控。
\n![\"M2.7时间测量切面\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-time-measurement-aspect.png\")
最后就是核心的慢查询指令实现，无论是参数解析还是指令查询和响应处理函数，模型都结合笔者的当前项目封装的逻辑给出了明确的编码方案：
\n![\"M2.7慢查询指令实现\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-slowlog-command-implementation.png\")
经过仔细复核设计文档，整体开发思路基本一致，但在代码组织细节上仍有调优空间——例如模型将slowlog指令独立成文件，而未遵循项目惯例统一放入command.go。考虑到慢查询功能并非核心内存读写指令，且其日志管理逻辑相对独立，这一处理也算合理折中。权衡之后，我们决定保留模型的实现方式，同时手动调整部分文件布局以符合既有工程规范，随后推进剩余开发工作。
这一细节也说明：AI生成的代码架构虽然合理，但与既有工程规范的适配仍然需要人工把关。
\n另外提一句，整个慢查询功能的实现过程中，模型有两次生成了不符合项目风格的代码（比如错误处理方式），需要手动调整。这不是大问题，但说明完全依赖AI生成还是不行的。
\n因为笔者明确指定了TDD的开发模型，所以模型在这期间结合输出反馈和文档说明完成自循环修复，最终结合mini-redis的项目风格完成了慢查询指令的复刻。
\n得益于 AI 的推理和重构能力，在验收过程中我们有了更多的构思空间。之前一直因为源代码梳理总结和技术验收成本过大，导致 redis.conf 配置加载逻辑一直没有实现。
\n因为笔者需要将慢查询时间设置为0，方便对慢查询指令做最后的验收工作，所以笔者索性再次对其提出加载配置的需求：
\n![\"M2.7配置加载实现\"](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/m2.7-config-loading.png\")
整个逻辑梳理和开发工作不到1小时，笔者顺利完成了慢查询指令复刻和验收，为了演示慢查询功能，将mini-redis的慢查询阈值设置为0：
\n# 慢查询阈值（微秒）\n# 执行时间超过此值的命令会被记录到慢查询日志中\n# 负值表示禁用慢查询日志，0 表示记录所有命令\n# 默认值：10000（10毫秒）\nslowlog-log-slower-than 0启动mini-redis服务端后，键入slowlog get 默认返回空：
\n![\"slowlog](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/slowlog-get-initial-state.png\")
执行简单的set操作后，键入slowlog get，这条指令如预期被判定为慢查询指令并输出：
\n![\"slowlog](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/slowlog-get-record-set-command.png\")
同理，我们依次键入后续几条指令，也都准确按照链表头插法入队，实现按照时间降序排列输出：
\n![\"slowlog](\"https://oss.javaguide.cn/github/javaguide/ai/coding/m2.7/slowlog-get-multiple-records.png\")
通过两个典型场景的实战，总结一下使用 Trae + 大模型辅助编程的一些经验和思考。
\n在上述两个场景中，AI 辅助编程体现了几个核心能力：
\n| 能力维度 | 场景表现 | 说明 |
\n|
这份 分布式系统知识体系 面向后端学习、系统设计和面试复习，按“理论基础 -> 通信调用 -> 服务治理 -> 一致性与协调 -> 工程实践”的顺序整理本站分布式相关文章。
\n如果你时间有限，建议先看 分布式系统面试题总结，快速建立高频问题清单；如果你想系统补基础，可以按下面的专题顺序阅读。
\n这部分适合先建立分布式系统的底层认知，重点理解一致性、可用性、分区容错、共识算法和数据分布。
\nRPC 解决的是远程服务调用的工程复杂度，包括序列化、网络传输、服务发现、负载均衡、超时重试和服务治理。
\nAPI 网关负责统一接入、路由转发、认证鉴权、限流熔断、灰度发布和跨域处理，是微服务体系里的重要入口层。
\n这部分偏工程落地，常见于订单、支付、秒杀、库存扣减、数据一致性和跨服务协作场景。
\n配置中心和 ZooKeeper 主要解决服务配置、注册发现、分布式协调和集群一致性问题。
\nAPI 网关（API Gateway）是位于客户端与后端服务之间的统一入口，所有客户端请求先经过网关，再由网关路由到具体的目标服务。
\n在微服务架构下，一个系统被拆分为多个服务。像安全认证、流量控制、日志、监控等功能是每个服务都需要的。如果没有网关，我们需要在每个服务中单独实现这些功能，导致：
\n![\"网关示意图\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway-overview.png\")
网关的功能虽然繁多，但核心可以概括为两件事：
\n| 职责 | 说明 | 典型功能 |
\n|
微服务架构下，应用被拆分为大量独立部署的服务，每个服务都有自己的配置（服务地址、数据库参数、功能开关等）。配置项数量会随着服务数量、环境数量和集群数量一起增长。传统配置文件方式存在以下问题：
\n此外，配置中心通常提供以下增强能力：
\n![\"Apollo](\"https://oss.javaguide.cn/github/javaguide/config-center/view-release-history.png\")
当然，不是所有系统都需要上配置中心。单体应用、单环境、配置项很少且变更频率低的场景，application-{profile}.yml、环境变量或 Kubernetes ConfigMap + 滚动重启通常就够了。配置中心会带来额外的运维成本、故障域和排查链路，小团队或低频配置场景不必过度工程化。
| 方案 | 状态 | 特点 |
\n|
提示
\n看到百度 Geek 说的一篇结合具体场景聊分布式 ID 设计的文章，感觉挺不错的。于是，我将这篇文章的部分内容整理到了这里。原文传送门：分布式 ID 生成服务的技术原理和项目实战 。
\n网上绝大多数的分布式 ID 生成服务，一般着重于技术原理剖析，很少见到根据具体的业务场景去选型 ID 生成服务的文章。
\n本文结合一些使用场景，进一步探讨业务场景中对 ID 有哪些具体的要求。
\n我们在商场买东西一码付二维码，下单生成的订单号，使用到的优惠券码，联合商品兑换券码，这些是在网上购物经常使用到的单号，那么为什么有些单号那么长，有些只有几位数？有些单号一看就知道年月日的信息，有些却看不出任何意义？下面展开分析下订单系统中不同场景的 id 服务的具体实现。
\n我们常见的一码付，指的是一个二维码可以使用支付宝或者微信进行扫码支付。
\n二维码的本质是一个字符串。聚合码的本质就是一个链接地址。用户使用支付宝微信直接扫一个码付钱，不用担心拿支付宝扫了微信的收款码或者用微信扫了支付宝的收款码，这极大减少了用户扫码支付的时间。
\n实现原理是当客户用 APP 扫码后，网站后台就会判断客户的扫码环境。（微信、支付宝、QQ 钱包、京东支付、云闪付等）。
\n判断扫码环境的原理就是根据打开链接浏览器的 HTTP header。任何浏览器打开 http 链接时，请求的 header 都会有 User-Agent(UA、用户代理)信息。
\nUA 是一个特殊字符串头，服务器依次可以识别出客户使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等很多信息。
\n各渠道对应支付产品的名称不一样，一定要仔细看各支付产品的 API 介绍。
\n其本质均为在 APP 内置浏览器中实现 HTML5 支付。
\n![\"文库会员支付示例\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/distributed-id-design-pay-one-card.png\")
文库的研发同学在这个思路上，做了优化迭代。动态生成一码付的二维码预先绑定用户所选的商品信息和价格，根据用户所选的商品动态更新。这样不仅支持一码多平台调起支付，而且不用用户选择商品输入金额，即可完成订单支付的功能，很丝滑。用户在真正扫码后，服务端才通过前端获取用户 UID，结合二维码绑定的商品信息，真正的生成订单，发送支付信息到第三方（qq、微信、支付宝），第三方生成支付订单推给用户设备，从而调起支付。
\n区别于固定的一码付，在文库的应用中，使用到了动态二维码，二维码本质是一个短网址，ID 服务提供短网址的唯一标志参数。唯一的短网址映射的 ID 绑定了商品的订单信息，技术和业务的深度结合，缩短了支付流程，提升用户的支付体验。
\n订单号在实际的业务过程中作为一个订单的唯一标识码存在，一般实现以下业务场景：
\n很多时候搜索订单相关信息的时候都是以订单 ID 作为唯一标识符，这是由于订单号的生成规则的唯一性决定的。从技术角度看，除了 ID 服务必要的特性之外，在订单号的设计上需要体现几个特性：
\n（1）信息安全
\n编号不能透露公司的运营情况，比如日销、公司流水号等信息，以及商业信息和用户手机号，身份证等隐私信息。并且不能有明显的整体规律（可以有局部规律），任意修改一个字符就能查询到另一个订单信息，这也是不允许的。
\n类比于我们高考时候的考生编号的生成规则，一定不能是连号的，否则只需要根据顺序往下查询就能搜索到别的考生的成绩，这是绝对不可允许。
\n（2）部分可读
\n位数要便于操作，因此要求订单号的位数适中，且局部有规律。这样可以方便在订单异常，或者退货时客服查询。
\n过长的订单号或易读性差的订单号会导致客服输入困难且易错率较高，影响用户体验的售后体验。因此在实际的业务场景中，订单号的设计通常都会适当携带一些允许公开的对使用场景有帮助的信息，如时间，星期，类型等等，这个主要根据所涉及的编号对应的使用场景来。
\n而且像时间、星期这些自增长的属于作为订单号的设计的一部分元素，有助于解决业务累积而导致的订单号重复的问题。
\n（3）查询效率
\n常见的电商平台订单号大多是纯数字组成，兼具可读性的同时，int 类型相对 varchar 类型的查询效率更高，对在线业务更加友好。
\n优惠券、兑换券是运营推广最常用的促销工具之一，合理使用它们，可以让买家得到实惠，商家提升商品销量。常见场景有：
\n![\"优惠编码兑换奖品\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/distributed-id-design-coupon.png\")
从技术角度看，有些场景适合 ID 即时生成，比如电商平台购物领取的优惠券，只需要在用户领取时分配优惠券信息即可。有些线上线下结合的场景，比如疫情优惠券，瓶盖开奖，京东卡，超市卡这种，则需要预先生成，预先生成的券码具备以下特性：
\n1.预先生成，在活动正式开始前提供出来进行活动预热；
\n2.优惠券体量大，以万为单位，通常在 10 万级别以上；
\n3.不可破解、仿制券码；
\n4.支持用后核销；
\n5.优惠券、兑换券属于广撒网的策略，所以利用率低，也就不适合使用数据库进行存储 （占空间，有效的数据又少）。
\n设计思路上，需要设计一种有效的兑换码生成策略，支持预先生成，支持校验，内容简洁，生成的兑换码都具有唯一性，那么这种策略就是一种特殊的编解码策略，按照约定的编解码规则支撑上述需求。
\n既然是一种编解码规则，那么需要约定编码空间(也就是用户看到的组成兑换码的字符)，编码空间由字符 a-z,A-Z,数字 0-9 组成，为了增强兑换码的可识别度，剔除大写字母 O 以及 I,可用字符如下所示，共 60 个字符：
\nabcdefghijklmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXZY0123456789
\n之前说过，兑换码要求尽可能简洁，那么设计时就需要考虑兑换码的字符数，假设上限为 12 位，而字符空间有 60 位，那么可以表示的空间范围为 60^12=130606940160000000000000(也就是可以 12 位的兑换码可以生成天量,应该够运营同学挥霍了)，转换成 2 进制：
\n1001000100000000101110011001101101110011000000000000000000000(61 位)
\n兑换码组成成分分析
\n兑换码可以预先生成，并且不需要额外的存储空间保存这些信息，每一个优惠方案都有独立的一组兑换码(指运营同学组织的每一场运营活动都有不同的兑换码,不能混合使用, 例如双 11 兑换码不能使用在双 12 活动上)，每个兑换码有自己的编号，防止重复，为了保证兑换码的有效性，对兑换码的数据需要进行校验，当前兑换码的数据组成如下所示：
\n优惠方案 ID + 兑换码序列号 i + 校验码
\n编码方案
\n深耕业务还会有区分通用券和单独券的情况，分别具备以下特点，技术实现需要因地制宜地思考。
\n在分布式服务架构下，一个 Web 请求从网关流入，有可能会调用多个服务对请求进行处理，拿到最终结果。这个过程中每个服务之间的通信又是单独的网络请求，无论请求经过的哪个服务出了故障或者处理过慢都会对前端造成影响。
\n处理一个 Web 请求要调用的多个服务，为了能更方便的查询哪个环节的服务出现了问题，现在常用的解决方案是为整个系统引入分布式链路跟踪。
\n![\"在分布式链路跟踪\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/distributed-id-design-tracing.png\")
在分布式链路跟踪中有两个重要的概念：跟踪（trace）和 跨度（ span)。trace 是请求在分布式系统中的整个链路视图，span 则代表整个链路中不同服务内部的视图，span 组合在一起就是整个 trace 的视图。
\n在整个请求的调用链中，请求会一直携带 traceid 往下游服务传递，每个服务内部也会生成自己的 spanid 用于生成自己的内部调用视图，并和 traceid 一起传递给下游服务。
\n这种场景下，生成的 ID 除了要求唯一之外，还要求生成的效率高、吞吐量大。traceid 需要具备接入层的服务器实例自主生成的能力，如果每个 trace 中的 ID 都需要请求公共的 ID 服务生成，纯纯的浪费网络带宽资源。且会阻塞用户请求向下游传递，响应耗时上升，增加了没必要的风险。所以需要服务器实例最好可以自行计算 tracid，spanid，避免依赖外部服务。
\n产生规则：服务器 IP + ID 产生的时间 + 自增序列 + 当前进程号 ，比如：
\n0ad1348f1403169275002100356696
\n前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，我们把这个数字，按每两位转成 10 进制即可得到常见的 IP 地址表示方式 10.209.52.143，您也可以根据这个规律来查找到请求经过的第一个服务器。
\n后面的 13 位 1403169275002 是产生 TraceId 的时间。之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，到达 9000 后回到 1000 再开始往上涨。最后的 5 位 56696 是当前的进程 ID，为了防止单机多进程出现 TraceId 冲突的情况，所以在 TraceId 末尾添加了当前的进程 ID。
\nspan 是层的意思，比如在第一个实例算是第一层， 请求代理或者分流到下一个实例处理，就是第二层，以此类推。通过层，SpanId 代表本次调用在整个调用链路树中的位置。
\n假设一个 服务器实例 A 接收了一次用户请求，代表是整个调用的根节点，那么 A 层处理这次请求产生的非服务调用日志记录 spanid 的值都是 0，A 层需要通过 RPC 依次调用 B、C、D 三个服务器实例，那么在 A 的日志中，SpanId 分别是 0.1，0.2 和 0.3，在 B、C、D 中，SpanId 也分别是 0.1，0.2 和 0.3；如果 C 系统在处理请求的时候又调用了 E，F 两个服务器实例，那么 C 系统中对应的 spanid 是 0.2.1 和 0.2.2，E、F 两个系统对应的日志也是 0.2.1 和 0.2.2。
\n根据上面的描述可以知道，如果把一次调用中所有的 SpanId 收集起来，可以组成一棵完整的链路树。
\nspanid 的生成本质：在跨层传递透传的同时，控制大小版本号的自增来实现的。
\n短网址主要功能包括网址缩短与还原两大功能。相对于长网址，短网址可以更方便地在电子邮件，社交网络，微博和手机上传播，例如原来很长的网址通过短网址服务即可生成相应的短网址，避免折行或超出字符限制。
\n![\"短网址作用\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/distributed-id-design-short-url.png\")
常用的 ID 生成服务比如：MySQL ID 自增、 Redis 键自增、号段模式，生成的 ID 都是一串数字。短网址服务把客户的长网址转换成短网址，
\n实际是在 dwz.cn 域名后面拼接新产生的数字类型 ID，直接用数字 ID，网址长度也有些长，服务可以通过数字 ID 转更高进制的方式压缩长度。这种算法在短网址的技术实现上越来越多了起来，它可以进一步压缩网址长度。转进制的压缩算法在生活中有广泛的应用场景，举例：
\n日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 唯一标识一个用户，商品 ID 唯一标识一件商品，订单 ID 唯一标识一笔订单。
\n我们现实生活中也有各种 ID，比如身份证 ID 唯一标识一个人，地址 ID 唯一标识一个地址。
\n简单来说，ID 就是数据的唯一标识。
\n这里说的分布式 ID，主要指分布式系统中用于跨节点、跨库、跨服务唯一标识数据的 ID。它解决的是多节点并发生成 ID 时不能冲突的问题。
\n我简单举一个分库分表的例子。
\n我司的一个项目，使用的是单机 MySQL。但是，没想到的是，项目上线一个月之后，随着使用人数越来越多，整个系统的数据量将越来越大。单机 MySQL 已经没办法支撑了，需要进行分库分表，可以考虑 Apache ShardingSphere-JDBC 这类方案，具体还要看 SQL 复杂度、事务要求、运维能力和团队经验。
\n在分库之后，数据分散在不同数据库节点上，数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢？
\n这个时候就需要生成分布式 ID了。
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/id-after-the-sub-table-not-conflict.png\")
![](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/distributed-id-requirements.png\")
分布式 ID 作为分布式系统中必不可少的一环，很多地方都要用到分布式 ID。
\n一个最基本的分布式 ID 需要满足下面这些要求：
\n除了这些之外，一个比较好的分布式 ID 还应保证：
\n还需要注意，不同方案的“唯一性”来源并不一样：
\n这种方式就比较简单直白了，就是通过关系型数据库的自增主键来生成唯一 ID。
\n![\"数据库主键自增\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/the-primary-key-of-the-database-increases-automatically.png\")
以 MySQL 举例，我们通过下面的方式即可。
\n1. 创建一个数据库表。
\nCREATE TABLE `sequence_id` (\n `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,\n `stub` char(10) NOT NULL DEFAULT '',\n PRIMARY KEY (`id`),\n UNIQUE KEY `stub` (`stub`)\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;stub 字段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。
2. 通过 REPLACE INTO 来插入数据。
BEGIN;\nREPLACE INTO sequence_id (stub) VALUES ('stub');\nSELECT LAST_INSERT_ID();\nCOMMIT;⚠️ REPLACE INTO 的生产隐患：
\nREPLACE INTO 的语义是：如果新行不会和 PRIMARY KEY 或 UNIQUE 索引冲突，就直接插入；如果冲突，则先删除旧行，再插入新行。受影响行数可能是删除行数加插入行数。
替代方案：如果只是为了推进序列表，可以使用 INSERT ... ON DUPLICATE KEY UPDATE 或单行 UPDATE 来避免 REPLACE 的删除语义。生产环境更常见的是号段模式：一次更新 current_max_id = current_max_id + step，再在内存中分配。
这种方式的优缺点也比较明显：
\n数据库主键自增这种模式，每次获取 ID 都要访问一次数据库，ID 需求比较大的时候，肯定是不行的。
\n如果我们可以批量获取，然后存在内存里面，需要用到的时候直接从内存里拿，就能减少访问数据库的次数，延迟和数据库压力都会下降。这也就是我们说的 基于数据库的号段模式来生成分布式 ID。
\n数据库号段模式是目前比较主流的一种分布式 ID 生成方式。像滴滴开源的 Tinyid 就是基于这种方式来做的。不过，Tinyid 使用了双号段缓存、增加多数据库支持等方式来进一步优化。
\n以 MySQL 举例，我们通过下面的方式即可。
\n1. 创建一个数据库表。
\nCREATE TABLE `sequence_id_generator` (\n `id` INT NOT NULL,\n `current_max_id` BIGINT NOT NULL COMMENT '当前最大ID',\n `step` INT NOT NULL COMMENT '号段的长度',\n `version` INT NOT NULL COMMENT '版本号',\n `biz_type` INT NOT NULL COMMENT '业务类型',\n PRIMARY KEY (`id`),\n UNIQUE KEY `uk_biz_type` (`biz_type`)\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;current_max_id 字段和 step 字段主要用于获取批量 ID。获取的批量 ID 区间为 (current_max_id, current_max_id + step]，也就是不包含 current_max_id 的旧值本身。例如，旧 current_max_id = 0、step = 100 时，成功更新后本次可分配的 ID 区间为 1~100。
![\"数据库号段模式\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/database-number-segment-mode.png\")
version 字段主要用于解决并发问题（乐观锁），完整流程如下：
-- 1. 读取当前值\nSELECT current_max_id, step, version FROM sequence_id_generator WHERE biz_type = 101;\n-- 2. CAS 更新（version 作为乐观锁版本号）\nUPDATE sequence_id_generator\nSET current_max_id = current_max_id + step, version = version + 1\nWHERE version = {当前读取的version} AND biz_type = 101;\n-- 3. 检查 affected_rows，为 1 表示成功，为 0 表示被其他线程抢先，需重试UPDATE ... WHERE version = ? 执行后必须检查 affected_rows。如果结果为 0，说明号段已经被其他实例抢走，需要重新读取 current_max_id 和 version 后再重试。
\n\n⚠️ 高并发重试提醒：在号段耗尽瞬间，多个线程可能同时争抢新号段，CAS 更新可能失败。代码层面需要实现有限次数的重试循环（如 3 次）和指数退避，确保请求稳定性。若重试仍失败，应阻塞等待下一个号段加载完成，或触发告警并进入熔断降级流程。不建议返回所谓“降级 ID”，否则可能破坏全局唯一性保证。
\n
biz_type 主要用于表示业务类型。
2. 先插入一行数据。
\nINSERT INTO `sequence_id_generator` (`id`, `current_max_id`, `step`, `version`, `biz_type`)\nVALUES\n (1, 0, 100, 0, 101);3. 通过 SELECT 获取指定业务下的批量唯一 ID
\nSELECT `current_max_id`, `step`, `version` FROM `sequence_id_generator` WHERE `biz_type` = 101结果：
\nid current_max_id step version biz_type\n1 0 100 0 1014. 不够用的话，更新之后重新 SELECT 即可。
\nUPDATE sequence_id_generator SET current_max_id = 0 + 100, version = version + 1 WHERE version = 0 AND `biz_type` = 101\nSELECT `current_max_id`, `step`, `version` FROM `sequence_id_generator` WHERE `biz_type` = 101结果：
\nid current_max_id step version biz_type\n1 100 100 1 101相比于数据库主键自增的方式，数据库的号段模式对于数据库的访问次数更少，数据库压力更小。
\n另外，为了避免单点问题，可以通过主从模式或多库部署提高可用性。如果使用主从模式，发号更新必须走主库，并确保故障切换后不会回到旧的 current_max_id；多库模式则要保证每个库分配的号段范围、步长或业务分片互不重叠。
号段模式还会带来“跳号”问题：实例申请号段后通常会缓存在内存中，实例宕机或重启时，未使用完的号段会被浪费。浪费号段不影响唯一性，但会导致 ID 不连续；不要为了追求连续性回收已分配但未使用的号段，否则可能产生重复 ID。生产环境需要监控号段消耗速度、加载失败率和重试次数。
\n数据库号段模式的优缺点:
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/nosql-distributed-id.png\")
一般情况下，NoSQL 方案使用 Redis 多一些。我们通过 Redis 的 INCR 命令即可实现对 ID 原子顺序递增。
127.0.0.1:6379> set sequence_id_biz_type 1\nOK\n127.0.0.1:6379> incr sequence_id_biz_type\n(integer) 2\n127.0.0.1:6379> get sequence_id_biz_type\n\"2\"为了提高可用性和并发，我们可以使用 Redis Cluster。Redis Cluster 是 Redis 官方提供的 Redis 集群解决方案（3.0+版本）。
\nCodis 曾经是常见的开源 Redis 集群方案，但项目长期不活跃。新项目一般优先评估 Redis Cluster、云厂商 Redis 集群或兼容 Redis 协议的托管服务；Codis 更适合存量系统继续维护，使用前需要单独评估维护状态。
\n除了高可用和并发之外，我们知道 Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。Redis 支持两种不同的持久化方式：快照（snapshotting，RDB）、只追加文件（append-only file, AOF）。并且，Redis 4.0 开始支持 RDB 和 AOF 的混合持久化，由配置项 aof-use-rdb-preamble 控制：Redis 4.0 示例配置默认关闭，Redis 5.0+ 示例配置默认开启。具体默认值要以目标 Redis 版本、配置文件以及云厂商托管版配置为准。
关于 Redis 持久化，我这里就不过多介绍。不了解这部分内容的小伙伴，可以看看 Redis 持久化机制详解这篇文章。
\n虽然 Redis INCR 性能优异，但 Redis 持久化只能降低进程重启后的数据丢失风险，不能完全消除 ID 回退。尤其是 appendfsync everysec、RDB 快照、主从异步复制和故障切换场景，都可能丢失最近一段 INCR 结果。下面这些失败路径需要特别注意：
持久化延迟导致 ID 回退
\nINCR 后，Redis 在 RDB/AOF 刷盘前崩溃。AOF 重写导致短暂阻塞
\nRedis Cluster 单分片热点
\n主从异步复制故障切换
\nINCR 值可能落后于主节点。生产配置建议：
\n# Redis 7.0+ 可参考配置\nappendonly yes\nappendfsync everysec\naof-use-rdb-preamble yes # 混合持久化（RDB+AOF 组合）fsync 策略仍可能带来抖动。Redis 方案的优缺点：
\n除了 Redis 之外，MongoDB ObjectId 经常也会被拿来当做分布式 ID 的解决方案。
\n![\"MongoDB](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/mongodb9-objectId-distributed-id.png\")
MongoDB ObjectId 一共需要 12 个字节存储：
\nObjectId 是无需中心协调的近似有序唯一标识，通常可满足文档 _id 场景，但它不是全局严格单调序列：它只有秒级时间精度，同一秒内生成的 ObjectId 不保证严格顺序；不同客户端机器的系统时间也可能不同。
MongoDB 方案的优缺点：
\nUUID 是 Universally Unique Identifier（通用唯一标识符）的缩写，本质上是一个 128 bit 的标识符。它的标准字符串形式通常是 36 个字符（包含连字符），去掉连字符后是 32 个十六进制字符。
\nJDK 就提供了现成的生成 UUID 的方法，一行代码就行了。
\n//输出示例：cb4a9ede-fa5e-4585-b9bb-d60bce986eaa\nUUID.randomUUID()RFC 9562 已经取代 RFC 4122，重新规范了 UUID，并新增了 v6、v7、v8。旧资料里仍会看到 RFC 4122 的说法，但新文章建议以 RFC 9562 为主。RFC 9562 中关于 UUID 的示例是这样的：
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/rfc-4122-uuid.png\")
我们这里重点关注一下这个 Version（版本），不同的版本对应的 UUID 的生成规则是不同的。
\n8 种不同的 Version（版本）值分别对应的含义（参考维基百科对于 UUID 的介绍）：
\n下面是 UUID v1 生成结果的示例：
\n![\"UUID](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/version1-uuid.png\")
JDK 中通过 UUID 的 randomUUID() 方法生成的 UUID 的版本默认为 4。
UUID uuid = UUID.randomUUID();\nint version = uuid.version();// 4另外，Variant（变体）也有 4 种不同的值，这种值分别对应不同的含义。这里就不介绍了，貌似平时也不怎么需要关注。
\n需要用到的时候，去看看维基百科对于 UUID 的 Variant（变体）相关的介绍即可。
\n从上面的介绍中可以看出，UUID 在正确实现和足够随机性的前提下，工程上可认为唯一。v4 的唯一性本质上是概率保证；v1/v6 依赖节点 ID 和时间戳，可能存在隐私泄露风险；v7/v8 的唯一性则依赖实现策略。
\n虽然，UUID 在工程上可认为全局唯一，但是，我们一般很少会使用它。
\n比如使用 UUID v4 这类非时序 UUID 作为 MySQL 数据库主键的时候就非常不合适：
\nUUID v7（RFC 9562）是一个标准化、趋势有序、无需 Worker ID 分配的可选方案：
\nUUID v7 不需要像 Snowflake 一样分配 Worker ID，接入成本低；但它仍然依赖随机数质量和生成器实现。对不能容忍重复的主键场景，数据库唯一约束仍然不能省。
\n| 特性 | Snowflake | UUID v7 |
\n|
通常情况下，我们一般会选择基于 Redis 或者 ZooKeeper 实现分布式锁，Redis 用的要更多一点，我这里也先以 Redis 为例介绍分布式锁的实现。
\n不论是本地锁还是分布式锁，核心都在于“互斥”。
\n在 Redis 中，SETNX 命令可以帮助我们实现互斥。SETNX 即 SET if Not eXists（对应 Java 中的 setIfAbsent 方法），如果 key 不存在的话，才会设置 key 的值。如果 key 已经存在，SETNX 啥也不做。
> SETNX lockKey uniqueValue\n(integer) 1\n> SETNX lockKey uniqueValue\n(integer) 0释放锁的话，直接通过 DEL 命令删除对应的 key 即可。
> DEL lockKey\n(integer) 1为了防止误删到其他的锁，这里我们建议使用 Lua 脚本先比对 key 对应的 value 是否为加锁时写入的唯一值，校验通过后再删除。
\n选用 Lua 脚本是为了保证解锁操作的原子性。因为 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，从而保证了锁释放操作的原子性。
\n-- 释放锁时，先比对 key 对应的 value 是否为加锁时写入的唯一值，校验通过后再删除，避免误删其他客户端持有的锁\nif redis.call(\"get\", KEYS[1]) == ARGV[1] then\n return redis.call(\"del\", KEYS[1])\nelse\n return 0\nend![\"Redis](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/distributed-lock-setnx.png\")
这是一种最简易的 Redis 分布式锁实现，实现方式比较简单，性能也很高效。不过，这种方式实现分布式锁存在一些问题。就比如应用程序遇到一些问题比如释放锁的逻辑突然挂掉，可能会导致锁无法被释放，进而造成共享资源无法再被其他线程/进程访问。
\n为了避免锁无法被释放，我们可以想到的一个解决办法就是：给这个 key（也就是锁）设置一个过期时间。
\n127.0.0.1:6379> SET lockKey uniqueValue EX 3 NX\nOKEX 3 表示这个锁有一个 3 秒的自动过期时间。与 EX 对应的是 PX（毫秒为单位），这两个都是过期时间设置。一定要保证设置指定 key 的值和过期时间是一个原子操作！！！ 不然的话，依然可能会出现锁无法被释放的问题。
\n为什么要用 SET NX EX，而不是先 SETNX 再 EXPIRE 呢？早期常见的 SETNX 后再 EXPIRE 是两步操作，如果客户端在 SETNX 成功后、EXPIRE 前崩溃，会留下永久锁。Redis 2.6.12 起支持 SET key value NX EX seconds 这类原子写法，应优先使用这种方式避免死锁风险。
这样确实可以解决问题，不过，这种解决办法同样存在漏洞：如果操作共享资源的时间大于过期时间，就会出现锁提前过期的问题，进而导致分布式锁直接失效。如果锁的超时时间设置过长，又会影响到性能。
\n这也是后文需要 Fencing Token 的根源：单纯延长 TTL 不能消除“客户端 A 仍以为自己持锁，但锁实际已过期并被客户端 B 获取”的窗口。
\n你或许在想：如果操作共享资源的操作还未完成，锁过期时间能够自己续期就好了！
\n对于 Java 开发的小伙伴来说，已经有了现成的解决方案：Redisson。其他语言的解决方案，可以在 Redis 官方文档中找到，地址：https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/。
\n![\"Distributed](\"https://oss.javaguide.cn/github/javaguide/redis-distributed-lock.png\")
Redisson 是一个开源的 Java 语言 Redis 客户端，提供了很多开箱即用的功能，不仅仅包括多种分布式锁的实现。并且，Redisson 还支持 Redis 单机、Redis Sentinel、Redis Cluster 等多种部署架构。
\nRedisson 中的分布式锁自带自动续期机制，使用起来非常简单，原理也比较简单，其提供了一个专门用来监控和续期锁的 Watch Dog（看门狗），如果操作共享资源的线程还未执行完成的话，Watch Dog 会不断地延长锁的过期时间，进而保证锁不会因为超时而被释放。
\n![\"Redisson](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/distributed-lock-redisson-renew-expiration.png\")
看门狗名字的由来于 getLockWatchdogTimeout() 方法，这个方法返回的是看门狗给锁续期的过期时间，默认为 30 秒（基于 redisson-3.17.6）。Redisson 当前已进入 4.x 版本，具体配置语义建议以项目实际使用版本的 Config#getLockWatchdogTimeout 和 RedissonBaseLock#renewExpiration 源码为准。
// 默认 30 秒，支持修改\nprivate long lockWatchdogTimeout = 30 * 1000;\n\npublic Config setLockWatchdogTimeout(long lockWatchdogTimeout) {\n this.lockWatchdogTimeout = lockWatchdogTimeout;\n return this;\n}\npublic long getLockWatchdogTimeout() {\n return lockWatchdogTimeout;\n}renewExpiration() 方法包含了看门狗的主要逻辑：
private void renewExpiration() {\n //......\n Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {\n @Override\n public void run(Timeout timeout) throws Exception {\n //......\n // 异步续期，基于 Lua 脚本\n CompletionStage<Boolean> future = renewExpirationAsync(threadId);\n future.whenComplete((res, e) -> {\n if (e != null) {\n // 无法续期\n log.error(\"Can't update lock \" + getRawName() + \" expiration\", e);\n EXPIRATION_RENEWAL_MAP.remove(getEntryName());\n return;\n }\n\n if (res) {\n // 通过定时器回调链式触发下一次续期，非栈式递归，不会导致调用栈无限增长\n renewExpiration();\n } else {\n // 取消续期\n cancelExpirationRenewal(null);\n }\n });\n }\n // 延迟 internalLockLeaseTime/3（默认 10s，也就是 30/3）再调用\n }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);\n\n ee.setTimeout(task);\n }默认情况下，每过 10 秒，看门狗就会执行续期操作，将锁的超时时间设置为 30 秒。看门狗续期前也会先判断是否需要执行续期操作，需要才会执行续期，否则取消续期操作。
\nWatch Dog 通过调用 renewExpirationAsync() 方法实现锁的异步续期：
protected CompletionStage<Boolean> renewExpirationAsync(long threadId) {\n return evalWriteAsync(getRawName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,\n // 判断是否为持锁线程，如果是就执行续期操作，将锁的过期时间设置为 30s（默认）\n \"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then \" +\n \"redis.call('pexpire', KEYS[1], ARGV[1]); \" +\n \"return 1; \" +\n \"end; \" +\n \"return 0;\",\n Collections.singletonList(getRawName()),\n internalLockLeaseTime, getLockName(threadId));\n}可以看出，renewExpirationAsync 方法其实是调用 Lua 脚本实现的续期，这样做主要是为了保证续期操作的原子性。
我这里以 Redisson 的可重入锁实现 RLock 为例来说明如何使用 Redisson 实现分布式锁：
// 1.获取指定的分布式锁对象\nRLock lock = redisson.getLock(\"lock\");\n// 2.拿锁且不设置锁超时时间，具备 Watch Dog 自动续期机制\nlock.lock();\n// 3.执行业务\n...\n// 4.释放锁\nlock.unlock();只有未指定锁超时时间，才会使用到 Watch Dog 自动续期机制。
\n// 手动给锁设置过期时间，不具备 Watch Dog 自动续期机制\nlock.lock(10, TimeUnit.SECONDS);如果使用 Redis 来实现分布式锁的话，还是比较推荐直接基于 Redisson 来做的。
\n所谓可重入锁指的是在一个线程中可以多次获取同一把锁，比如一个线程在执行一个带锁的方法，该方法中又调用了另一个需要相同锁的方法，则该线程可以直接执行调用的方法即可重入，而无需重新获得锁。像 Java 中的 synchronized 和 ReentrantLock 都属于可重入锁。
不可重入的分布式锁基本可以满足绝大部分业务场景了，一些特殊的场景可能会需要使用可重入的分布式锁。
\n可重入分布式锁的实现核心思路是线程在获取锁的时候判断是否为自己的锁，如果是的话，就不用再重新获取了。为此，我们可以为每个锁关联一个可重入计数器和一个占有它的线程。当可重入计数器大于 0 时，则锁被占有，需要判断占有该锁的线程和请求获取锁的线程是否为同一个。
\n实际项目中，我们不需要自己手动实现，推荐使用我们上面提到的 Redisson，其内置了多种类型的锁比如可重入锁（Reentrant Lock）、自旋锁（Spin Lock）、公平锁（Fair Lock）、多重锁（MultiLock）、红锁（RedLock）、读写锁（ReadWriteLock）。
\n![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/redisson-readme-locks.png\")
为了避免单点故障，生产环境下的 Redis 服务通常是集群化部署的。
\nRedis 集群下，上面介绍到的分布式锁的实现会存在一些问题。Redis 主从复制默认是异步的：主节点写入锁成功后会立即返回客户端，再异步同步给从节点。如果主节点在同步前宕机，Sentinel 或 Redis Cluster 故障转移可能把尚未收到锁数据的从节点提升为新主，导致原锁丢失，其他客户端可以再次加锁，从而破坏互斥性。
\n![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/redis-master-slave-distributed-lock.png\")
针对这个问题，Redis 之父 antirez 设计了 Redlock 算法 来解决。
\n![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/distributed-lock-redis.io-realock.png\")
Redlock 算法的思想是让客户端向多个相互独立的 Redis master 依次请求申请加锁，如果客户端能够在严格多数派实例上成功完成加锁操作，那么就可以认为客户端成功获得分布式锁，否则加锁失败。
\nRedlock 的完整判断条件如下：
\nN/2 + 1 个节点成功，且总耗时小于 TTL，才算加锁成功。TTL - 加锁耗时 - 时钟漂移余量。Redlock 是直接操作独立 Redis 节点的，并不是通过 Redis Cluster 操作的，这样才可以避免单个主从分片故障转移导致的锁丢失问题。
\nRedlock 实现比较复杂，性能比较差，发生时钟变迁的情况下还存在安全性隐患。《数据密集型应用系统设计》一书的作者 Martin Kleppmann 曾经专门发文（How to do distributed locking - Martin Kleppmann - 2016）批评过 Redlock，他认为这是一个很差的分布式锁实现。感兴趣的朋友可以看看Redis 锁从面试连环炮聊到神仙打架这篇文章，有详细介绍到 antirez 和 Martin Kleppmann 关于 Redlock 的讨论。
\n如何判断是否该用 Redlock？核心是先区分锁的使用场景：
\nZooKeeper 相比于 Redis 实现分布式锁，除了提供相对更高的可靠性之外，在功能层面还有一个非常有用的特性：Watch 机制。这个机制可以用来实现公平的分布式锁。不过，使用 ZooKeeper 实现的分布式锁在性能方面相对较差，因此如果对性能要求比较高的话，ZooKeeper 可能就不太适合了。
\nZooKeeper 分布式锁是基于 临时顺序节点 和 Watcher（事件监听器） 实现的。
\n获取锁：
\n/locks，客户端获取锁就是在 /locks 下创建临时顺序节点。/locks/lock1 节点，创建成功之后，会判断 lock1 是否是 /locks 下最小的子节点。lock1 是最小的子节点，则获取锁成功。否则，获取锁失败。/locks/lock0 上注册一个事件监听器。这个监听器的作用是当前一个节点释放锁之后通知客户端 1（避免无效自旋），这样客户端 1 就加锁成功了。释放锁：
\n![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/distributed-lock-zookeeper.png\")
实际项目中，推荐使用 Curator 来实现 ZooKeeper 分布式锁。Curator 是 Netflix 公司开源的一套 ZooKeeper Java 客户端框架，相比于 ZooKeeper 自带的客户端 zookeeper 来说，Curator 的封装更加完善，各种 API 都可以比较方便地使用。
\nCurator主要实现了下面四种锁：
InterProcessMutex：分布式可重入排它锁InterProcessSemaphoreMutex：分布式不可重入排它锁InterProcessReadWriteLock：分布式读写锁InterProcessMultiLock：将多个锁作为单个实体管理的容器，获取锁的时候获取所有锁，释放锁也会释放所有锁资源（忽略释放失败的锁）。CuratorFramework client = ZKUtils.getClient();\nclient.start();\n// 分布式可重入排它锁\nInterProcessLock lock1 = new InterProcessMutex(client, lockPath1);\n// 分布式不可重入排它锁\nInterProcessLock lock2 = new InterProcessSemaphoreMutex(client, lockPath2);\n// 将多个锁作为一个整体\nInterProcessMultiLock lock = new InterProcessMultiLock(Arrays.asList(lock1, lock2));\n\nif (!lock.acquire(10, TimeUnit.SECONDS)) {\n throw new IllegalStateException(\"不能获取多锁\");\n}\nSystem.out.println(\"已获取多锁\");\nSystem.out.println(\"是否有第一个锁: \" + lock1.isAcquiredInThisProcess());\nSystem.out.println(\"是否有第二个锁: \" + lock2.isAcquiredInThisProcess());\ntry {\n // 资源操作\n resource.use();\n} finally {\n System.out.println(\"释放多个锁\");\n lock.release();\n}\nSystem.out.println(\"是否有第一个锁: \" + lock1.isAcquiredInThisProcess());\nSystem.out.println(\"是否有第二个锁: \" + lock2.isAcquiredInThisProcess());\nclient.close();每个数据节点在 ZooKeeper 中被称为 znode，它是 ZooKeeper 中数据的最小单元。
\n我们通常是将 znode 分为 4 大类：
\n/node1/app0000000001、/node1/app0000000002。可以看出，临时节点相比持久节点，最主要的是对会话失效的情况处理不一样，临时节点会话消失则对应的节点消失。这样的话，如果客户端发生异常导致没来得及释放锁也没关系，会话失效节点会自动被删除，可以避免客户端进程崩溃后永久占锁。
\n不过，ZooKeeper 同样需要考虑 GC 停顿、网络分区和 session timeout。客户端长时间 GC 或网络分区导致 session 过期时，ZooKeeper 会删除临时节点并允许新客户端加锁，而旧客户端可能还没感知到会话失效，仍以为自己持锁。对于正确性要求高的场景，仍应结合 Fencing Token 防止旧客户端恢复后写入陈旧数据。
\n使用 Redis 实现分布式锁的时候，我们是通过过期时间来避免锁无法被释放导致死锁问题的，而 ZooKeeper 可以利用临时节点的特性处理客户端崩溃后的锁释放问题。
\n假设不使用顺序节点的话，所有尝试获取锁的客户端都会对持有锁的子节点加监听器。当该锁被释放之后，势必会造成所有尝试获取锁的客户端来争夺锁，这样对性能不友好。使用顺序节点之后，只需要监听前一个节点就好了，对性能更友好。
\n\n\nWatcher（事件监听器），是 ZooKeeper 中的一个很重要的特性。ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。
\n
同一时间段内，可能会有很多客户端同时获取锁，但只有一个可以获取成功。如果获取锁失败，则说明有其他的客户端已经成功获取锁。获取锁失败的客户端并不会不停地循环去尝试加锁，而是在前一个节点注册一个事件监听器。
\n这个事件监听器的作用是：当前一个节点对应的客户端释放锁之后（也就是前一个节点被删除之后，监听的是删除事件），通知获取锁失败的客户端（唤醒等待的线程，Java 中的 wait/notifyAll），让它尝试去获取锁，然后就成功获取锁了。
这里以 Curator 的 InterProcessMutex 对可重入锁的实现来介绍（源码地址：InterProcessMutex.java）。
当我们调用 InterProcessMutex#acquire 方法获取锁的时候，会调用 InterProcessMutex#internalLock 方法。
// 获取可重入互斥锁，直到获取成功为止\n@Override\npublic void acquire() throws Exception {\n if (!internalLock(-1, null)) {\n throw new IOException(\"Lost connection while trying to acquire lock: \" + basePath);\n }\n}internalLock 方法会先获取当前请求锁的线程，然后从 threadData（ConcurrentMap<Thread, LockData> 类型）中获取当前线程对应的 lockData。lockData 包含锁的信息和加锁的次数，是实现可重入锁的关键。
第一次获取锁的时候，lockData 为 null。获取锁成功之后，会将当前线程和对应的 lockData 放到 threadData 中。
private boolean internalLock(long time, TimeUnit unit) throws Exception {\n // 获取当前请求锁的线程\n Thread currentThread = Thread.currentThread();\n // 拿对应的 lockData\n LockData lockData = threadData.get(currentThread);\n // 第一次获取锁的话，lockData 为 null\n if (lockData != null) {\n // 当前线程获取过一次锁之后\n // 因为当前线程的锁存在，lockCount 自增后返回，实现锁重入\n lockData.lockCount.incrementAndGet();\n return true;\n }\n // 尝试获取锁\n String lockPath = internals.attemptLock(time, unit, getLockNodeBytes());\n if (lockPath != null) {\n LockData newLockData = new LockData(currentThread, lockPath);\n // 获取锁成功之后，将当前线程和对应的 lockData 放到 threadData 中\n threadData.put(currentThread, newLockData);\n return true;\n }\n\n return false;\n}LockData 是 InterProcessMutex 中的一个静态内部类。
private final ConcurrentMap<Thread, LockData> threadData = Maps.newConcurrentMap();\n\nprivate static class LockData\n{\n // 当前持有锁的线程\n final Thread owningThread;\n // 锁对应的子节点\n final String lockPath;\n // 加锁的次数\n final AtomicInteger lockCount = new AtomicInteger(1);\n\n private LockData(Thread owningThread, String lockPath)\n {\n this.owningThread = owningThread;\n this.lockPath = lockPath;\n }\n}如果已经获取过一次锁，后面再来获取锁的话，直接就会在 if (lockData != null) 这里被拦下了，然后就会执行 lockData.lockCount.incrementAndGet(); 将加锁次数加 1。
整个可重入锁的实现逻辑非常简单，直接在客户端判断当前线程有没有获取锁，有的话直接将加锁次数加 1 就可以了。
\n需要注意可重入的边界：Curator InterProcessMutex 的可重入仅限同一 JVM 内的同一线程。Redisson 的 RLock 也是通过 UUID:threadId 记录持锁线程和重入计数，并不表示同一业务用户跨 JVM、跨线程天然可重入。如果需要跨进程或跨 JVM 的业务级可重入，需要在应用层设计业务身份、幂等和去重逻辑。
Fencing Token（隔离令牌）本身只是一个单调递增的版本号，只有资源端配合校验才能发挥作用。客户端访问数据库、对象存储或外部资源时必须携带 token；资源端需要保存已见过的最大 token，并拒绝任何更小 token 的写入。否则，单独生成 token 没有意义。
\n常见落地方式如下：
\n| 存储/系统 | Token 来源 | 校验方式 |
\n|
网上有很多分布式锁相关的文章，这里写了一个相对简洁易懂的版本。面向面试和日常工作场景，先把最常见的概念和边界讲清楚。
\n这篇文章我们先介绍一下分布式锁的基本概念。
\n在多线程环境中，如果多个线程同时访问并修改同一份共享资源（例如商品库存、外卖订单），且没有互斥、原子更新、乐观锁或唯一约束等保护，就可能出现数据不一致、重复处理、超卖等问题，影响程序的正确性和稳定性。
\n举个例子，假设现在有 100 个用户参与某个限时秒杀活动，每位用户限购 1 件商品，且商品的数量只有 3 个。如果不对共享资源进行互斥访问，就可能出现以下情况：
\n这里的限购校验和库存扣减是两个不同的约束：限购主要解决同一用户重复购买的问题，库存扣减主要解决多个用户竞争同一份库存的问题。
\n![\"共享资源未互斥访问导致出现问题\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/oversold-without-locking.png\")
锁的思路是把某段临界区串行化：同一时刻只允许一个执行单元进入这段逻辑。它能降低并发冲突，但也会牺牲吞吐；如果能用数据库原子更新、唯一约束、乐观锁、CAS 或消息串行化解决，就不一定要上分布式锁。
\n比如防超卖不一定要用分布式锁：数据库条件更新 UPDATE stock SET count = count - 1 WHERE sku_id = ? AND count > 0 可以保证库存不扣成负数；用户限购可以对 user_id + activity_id 建唯一索引；创建订单可以使用幂等键防重复提交。高并发场景还可以结合 Redis 预扣库存、MQ 异步落库和对账补偿。
这里讨论的分布式锁，本质上是一种悲观互斥方案：先拿到锁，再进入临界区，拿不到锁就等待、失败或重试。
\n悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候都可能出现问题（比如共享数据被修改），所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，共享资源每次只给一个线程使用，其他线程阻塞，用完后再把资源转让给其他线程。
\n对于单机多线程来说，在 Java 中，我们通常使用 ReentrantLock 类、synchronized 关键字这类 JDK 自带的 本地锁 来控制一个 JVM 进程内的多个线程对本地共享资源的访问。
下面是我对本地锁画的一张示意图。
\n![\"本地锁\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/jvm-local-lock.png\")
从图中可以看出，这些线程访问共享资源是互斥的，同一时刻只有一个线程可以获取到本地锁访问共享资源。
\n分布式系统下，不同的服务/客户端通常运行在独立的 JVM 进程上。如果多个 JVM 进程共享同一份资源，使用本地锁就没办法实现资源的互斥访问。这时就需要把锁的状态放到所有进程都能访问的外部系统中，也就是 分布式锁。
\n举个例子：系统的订单服务一共部署了 3 份，都对外提供服务。为了防止超卖，需要保护的不是单独的“检查库存”，而是“校验库存 → 扣减库存 → 记录购买/创建订单”这段临界区；否则只锁查询、不锁扣减，仍然可能并发写错。由于订单服务位于不同的 JVM 进程中，本地锁在这种情况下就没办法正常工作。我们需要用到分布式锁，这样即使多个线程不在同一个 JVM 进程中，也能获取到同一把锁，进而实现共享资源的互斥访问。
\n下面是我对分布式锁画的一张示意图。
\n![\"分布式锁\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-lock/distributed-lock.png\")
从图中可以看出，这些独立的进程中的线程访问共享资源是互斥的，同一时刻只有一个线程可以获取到分布式锁访问共享资源。
\n一个最基本的分布式锁需要满足：
\nstock:{skuId}、order:{orderId}，避免把无关资源都塞进一把全局大锁。除了上面这三个基本条件之外，一个好的分布式锁还需要满足下面这些条件：
\n常见分布式锁实现方案如下：
\n数据库实现大致有三类：唯一索引插入锁表、基于事务的 SELECT ... FOR UPDATE 行锁、MySQL GET_LOCK() 这类命名锁。它们都能实现一定程度的互斥，但性能、释放时机、超时语义和故障恢复方式不同。
数据库方案不是不能做失效，而是失效语义和性能通常不如 Redis/ZooKeeper/etcd 这类方案自然。比如锁表可以加过期时间字段，但要处理过期锁抢占、时钟一致性、清理任务和事务隔离；GET_LOCK() 依赖 MySQL 连接/session 语义，不适合所有业务链路。
Redis 锁更常用于高性能、短临界区、允许通过业务幂等兜底的场景；ZooKeeper/etcd 更适合需要会话语义、顺序节点、租约和更强一致性的协调场景，但吞吐、延迟和运维成本通常更高。我专门写了一篇文章来详细介绍 Redis 和 ZooKeeper 这两种方案：分布式锁常见实现方案总结。
\n最后提醒一句：分布式锁不是分布式事务。锁只能控制临界区并发进入，不保证数据库提交一定成功，也不保证消息发送和订单写入原子一致。业务一致性仍要依赖本地事务、幂等、状态机、补偿任务等机制。
\n面试可以按“为什么需要、怎么实现、有什么坑、如何兜底”来回答。
\n为什么需要：
\n常见实现：
\nSET key value NX PX ttl 获取锁，用 Lua 脚本校验 value 后删除锁。优点是性能好、实现简单；缺点是要处理 TTL、续约、主从切换和业务幂等。Redis 锁必须注意：
\n兜底手段：
\n这篇文章我们主要介绍了：
\n准备分布式系统面试，最容易踩的坑是把知识点背成一堆孤立概念：CAP 是一个点、RPC 是一个点、分布式锁是一个点、分布式事务又是一个点。
\n真正到面试里，面试官更关心的是：你能不能把这些技术放回真实系统里，讲清楚它们解决什么问题、带来什么代价、适合什么场景。
\n这篇文章是 JavaGuide 分布式系统内容的面试复习导航，不会重复搬运所有答案，而是帮你把分布式相关文章串起来，按面试准备顺序建立一条清晰路径。
\n分布式系统面试通常围绕 4 条主线展开：
\n其中，最重要的是：API 网关、配置中心、分布式 ID、分布式锁和分布式事务。这几块内容需要你花费更多的时间。
\n如果时间有限，建议先看面试突击版：分布式系统常见面试题总结。它已经把面试最高频的问题整理了出来，非常适合时间有限的情况下面试突击。
\n如果你还有时间系统补基础，可以按下面这条路线阅读 JavaGuide 正站文章。
\n分布式理论是很多系统设计题的底层语言。它不一定每天都写进代码，但会决定你回答问题时有没有“架构感”。
\n![\"分布式系统通信机制：中心化](\"https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/gossip-centralized-vs-decentralized.png\")
重点文章：
\n\n高频面试问题：
\n这一阶段的复习重点不是背定义，而是能说清楚：当网络不可靠、节点会宕机、数据要多副本存储时，系统为什么必须做取舍。
\n微服务面试里，RPC 和 API 网关经常一起出现。RPC 关注服务之间如何调用，网关关注外部流量如何进入系统。
\nAPI 网关示意图如下：
\n
RPC 示意图如下：
\n![\"RPC](\"https://oss.javaguide.cn/github/javaguide/distributed-system/rpc/rpc-overview.png\")
重点文章：
\n\n高频面试问题：
\n这一阶段建议把“调用链路”画出来：客户端请求如何进网关，网关如何路由到服务，服务之间如何通过 RPC 调用，失败时如何超时、重试、降级。
\n这部分是后端面试的高频区，也是最容易被追问工程细节的部分，一定一定要花费更多时间准备。
\n重点文章：
\n\n高频面试问题：
\n准备这部分时，一定要讲“异常路径”：网络超时、锁过期、业务执行一半失败、消息重复投递、事务补偿失败。这些才是面试官真正想听的工程判断。
\n配置中心和 ZooKeeper 通常不是单独考一个大题，而是穿插在注册发现、配置变更、分布式协调、Leader 选举等问题里。
\nZooKeeper 可以选择跳过，目前面试问的不多。有一种情况必须准备，那就是你的项目明确用到了或者你的技能介绍中提到了。
\n重点文章：
\n\n高频面试问题：
\n如果你是临近面试，建议先用“高频题目定范围，再用专题文章补细节”的方式复习：
\n如果你准备的是社招或中高级岗位，不要只背标准答案。更重要的是能把方案放进具体业务场景里，讲清楚为什么这么选、失败后怎么兜底、系统压力上来后怎么扩展。
\n这篇文章主要是 JavaGuide 正站的分布式学习导航。如果你想直接刷高频问答，可以看我已经整理好的面试突击版： 分布式系统常见面试题总结。
\n面试突击版更适合临考前快速过一遍；正站文章更适合系统学习和补齐细节。两者配合使用，效果会更稳。
\n", "image": "https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/gossip-centralized-vs-decentralized.png", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "分布式" ] }, { "title": "分布式事务解决方案详解：XA、AT、TCC、Saga、本地消息表与事务消息", "url": "https://codingmap.strova.top/distributed-system/distributed-transaction.html", "id": "https://codingmap.strova.top/distributed-system/distributed-transaction.html", "summary": "分布式事务解决方案详解，覆盖 2PC、3PC、XA、Seata AT、TCC、Saga、本地消息表、RocketMQ 事务消息、最大努力通知等方案的原理、优缺点、适用场景和面试考点。重点围绕 事务、数据库事务、分布式事务、分布式事务基础理论、分布式事务 等内容展开。结合 CodingMap 知识体系梳理 分布式系统 。", "content_html": "网上已经有很多关于分布式事务的文章了，为啥还要写一篇？
\n开始聊分布式事务之前，我们先来回顾一下事务相关的概念。
\n\n\n版本说明：本文 Seata 相关内容基于 1.7+ / 2.x 文档，RocketMQ 事务消息基于 4.9+ / 5.x 文档。不同版本的默认参数、API 和部署方式可能存在差异，落地时要以项目实际版本文档为准。
\n
我们设想一个场景，这个场景中我们需要插入多条相关联的数据到数据库，不幸的是，这个过程可能会遇到下面这些问题：
\n上面的任何一个问题都可能会导致数据的不一致性。为了保证数据的一致性，系统必须能够处理这些问题。事务就是我们抽象出来简化这些问题的首选机制。事务的概念起源于数据库，目前，已经成为一个比较广泛的概念。
\n何为事务？ 一言以蔽之，事务是逻辑上的一组操作，要么都执行，要么都不执行。
\n事务最经典、最常被引用的例子就是转账。假如小明要给小红转账 1000 元，这个转账会涉及到两个关键操作，这两个操作必须都成功或者都失败。
\n事务会把这两个操作看成逻辑上的一个整体，这个整体包含的操作要么都成功，要么都失败。这样就不会出现小明余额减少而小红的余额却并没有增加的情况。
\n![](\"https://oss.javaguide.cn/github/javaguide/mysql/事务示意图.png\")
大多数情况下，我们在谈论事务的时候，如果没有特指分布式事务，往往指的就是数据库事务。
\n数据库事务在我们日常开发中接触的最多了。如果你的项目属于单体架构的话，你接触到的往往就是数据库事务了。
\n那数据库事务有什么作用呢？
\n简单来说，数据库事务可以保证多个对数据库的操作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循：要么全部执行成功，要么全部不执行。
\n# 开启一个事务\nSTART TRANSACTION;\n# 多条 SQL 语句\nSQL1,SQL2...\n## 提交事务\nCOMMIT;![\"数据库事务示意图\"](\"https://oss.javaguide.cn/github/javaguide/mysql/数据库事务示意图.png\")
另外，关系型数据库（例如：MySQL、SQL Server、Oracle 等）事务都有 ACID 特性：
![\"ACID\"](\"https://oss.javaguide.cn/github/javaguide/mysql/ACID.png\")
Atomicity）：事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；Consistency）：执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；Isolation）：并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；Durability）：一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。🌈 这里要额外补充一点：只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！ 想必大家和我一样，被 ACID 这个概念误导了很久！我也是看周志明老师的公开课《周志明的软件架构课》才搞清楚的（多看好书！！！）。
\n![\"AID->C\"](\"https://oss.javaguide.cn/github/javaguide/mysql/AID->C.png\")
另外，DDIA 也就是 《Designing Data-Intensive Application（数据密集型应用系统设计）》 的作者在他的这本书中如是说：
\n\n\nAtomicity, isolation, and durability are properties of the database, whereas consis‐
\n
\ntency (in the ACID sense) is a property of the application. The application may rely
\non the database’s atomicity and isolation properties in order to achieve consistency,
\nbut it’s not up to the database alone.翻译过来的意思是：原子性，隔离性和持久性是数据库的属性，而一致性（在 ACID 意义上）是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。因此，字母 C 不属于 ACID 。
\n
《Designing Data-Intensive Application（数据密集型应用系统设计）》这本书强推一波，值得读很多遍！豆瓣有接近 90% 的人看了这本书之后给了五星好评。另外，中文翻译版本已经在 GitHub 开源，地址：https://github.com/Vonng/ddia。
\n![](\"https://img-blog.csdnimg.cn/20210526162552353.png\")
数据库事务的实现原理呢？
\n我们这里以 MySQL 的 InnoDB 引擎为例来简单说一下。
\nMySQL InnoDB 引擎使用 redo log（重做日志） 保证事务的持久性，使用 undo log（回滚日志） 来保证事务的原子性。MySQL InnoDB 引擎通过 锁机制、MVCC 等手段来保证事务的隔离性（默认支持的隔离级别是 REPEATABLE-READ）。
微服务架构下，一个系统被拆分为多个小的微服务。每个微服务都可能存在不同的机器上，并且每个微服务可能都有一个单独的数据库供自己使用。这种情况下，一组操作可能会涉及到多个微服务以及多个数据库。举个例子：电商系统中，你创建一个订单往往会涉及到订单服务（订单数加一）、库存服务（库存减一）等等服务，这些服务会有供自己单独使用的数据库。
\n![\"分布式事务示意图\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/distributed-transaction-with-two-services.png\")
那么如何保证这一组操作要么都执行成功，要么都执行失败呢？
\n这个时候单单依靠数据库事务就不行了！我们就需要引入 分布式事务 这个概念了！
\n实际上，只要跨数据库的场景都需要用到引入分布式事务。比如说单个数据库的性能达到瓶颈或者数据量太大的时候，我们需要进行 分库。分库之后，同一个数据库中的表分布在了不同的数据库中，如果单个操作涉及到多个数据库，那么数据库自带的事务就无法满足我们的要求了。
\n一言以蔽之，分布式事务的终极目标就是保证系统中多个相关联的数据库中的数据的一致性！
\n那既然分布式事务也属于事务，理论上就应该遵守事务的 ACID 四大特性。但是，考虑到性能、可用性等各方面因素，我们往往是无法完全满足 ACID 的，只能选择一个比较折中的方案。
\n针对分布式事务，又诞生了一些新的理论。
\nCAP 理论和 BASE 理论是分布式领域非常非常重要的两个理论。不夸张地说，只要问到分布式相关的内容，面试官几乎是必定会问这两个分布式相关的理论。
\n不论是你面试也好，工作也罢，都非常有必要将这两个理论搞懂，并且能够用自己的理解给别人讲出来。
\n我这里就不多提这两个理论了，不了解的小伙伴，可以看我前段时间写过的一篇相关的文章：《CAP 和 BASE 理论了解么？可以结合实际案例说下不？》 。
\n我们可以把对于系统一致性的要求分为下面 3 种级别：
\n除了上面这 3 个比较常见的一致性级别之外，还有读写一致性、因果一致性等一致性模型，具体可以参考《Operational Characterization of Weak Memory Consistency Models》这篇论文。因为日常工作中这些一致性模型很少见，我这里就不多做阐述（因为我自己也不是特别了解 😅）。
\n业界比较推崇是 最终一致性，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。
\n互联网应用最关键的就是要保证高可用，分布式系统几秒钟无法使用都可能造成巨大损失。在此场景下，一些大佬们在 CAP 理论和 BASE 理论的基础上，提出了 柔性事务 的概念。柔性事务追求的是最终一致性。
\n实际上，柔性事务就是 BASE 理论 + 业务实践。柔性事务追求的目标是：我们根据自身业务特性，通过适当的方式来保证系统数据的最终一致性。像 TCC、Saga、MQ 事务、本地消息表 就属于柔性事务。
\n与柔性事务相对的就是 刚性事务 了。前面我们说了，柔性事务追求的是最终一致性。那么，与之对应，刚性事务追求的就是 强一致性。像 2PC、3PC 就属于刚性事务。
\n![\"分布式事务解决方案总结\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/distributed-transaction-solution-summary.png\")
分布式事务的解决方案有很多，比如：XA / 2PC、3PC、AT、TCC、Saga、本地消息表、MQ 事务（Kafka 和 RocketMQ 都提供了事务相关功能）、最大努力通知等等。
\n2PC、3PC 属于业务代码无侵入方案。XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，定义了 TM 与 RM 之间的接口，并通常通过 2PC 完成提交。TCC、Saga 属于业务侵入方案，AT 介于 XA 与 TCC 之间，MQ 事务依赖于使用消息队列的场景，本地消息表和最大努力通知主要追求最终一致性，不支持自动回滚。
\n这些方案的适用场景有所区别，我们需要根据具体的场景选择适合自己项目的解决方案。
\n一个简单的选型思路：
\n开始介绍 2PC 和 3PC 之前，我们先来介绍一下 2PC 和 3PC 涉及到的一些角色（XA 规范的角色组成）：
\n![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/xa-specification-roles.png\")
![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/2pc-work-flow.png\")
2PC（Two-Phase Commit）这三个字母的含义：
\n2PC 将事务的提交过程分为 2 个阶段：准备阶段 和 提交阶段 。
\n准备阶段的核心是“询问”事务参与者执行本地数据库事务操作是否成功。
\n准备阶段的工作流程：
\n提交阶段的核心是“询问”事务参与者提交本地事务是否成功。
\n当所有事务参与者都是“就绪”状态的话：
\n![\"2PC示意图-就绪\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/distributed-transaction-2pc-ready.png\")
当任一事务参与者是“未就绪”状态的话：
\n![\"2PC示意图-未就绪\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/distributed-transaction-2pc-not-ready.png\")
简单总结一下 2PC 两阶段中比较重要的一些点：
\n2PC 的优点：
\n2PC 的权衡：
\n2PC 存在的问题：
\nXA 可以理解为 2PC 在数据库等资源层面的标准化落地。2PC 是提交协议，XA 是 X/Open 定义的 DTP 接口规范，规定了 TM 如何协调多个 RM 参与同一个全局事务。
\n典型流程是：
\nprepare，所有 RM 都准备成功后再调用 commit，否则调用 rollback。XA 的优势是业务侵入低，数据库本身负责事务隔离和回滚能力，适合短事务、强一致、并发压力不太高的场景。缺点也很明显：事务期间数据库资源会被长时间占用，性能和可用性都容易受到影响。
\nSeata 从 1.2 版本开始支持 XA 模式。Seata XA 模式利用数据库、消息服务等资源对 XA 协议的支持来管理分支事务，整体一致性更强，但吞吐通常不如 AT / TCC / Saga 这类柔性方案。
\n![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/3pc-work-flow.png\")
3PC 是在 2PC 基础上的优化版本。它将 2PC 的 Prepare 阶段拆成两个独立阶段：CanCommit（只询问能否提交，不执行事务预操作）和 PreCommit（执行事务预操作、写 redo/undo log）。再加上最后的 DoCommit，共三个阶段：
\n![\"3PC示意图-就绪\"](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/distributed-transaction-3pc-ready.png\")
准备阶段 RM 不会执行事务操作，TM 只是向 RM 发送 准备请求 ，顺便询问一些信息比如事务参与者能否执行本地数据库事务操作。RM 回复“Yes”、“No”或者直接超时未回复。
\n如果准备阶段所有的 RM 回复 “Yes”的话，TM 就会向所有的 RM 发送 PreCommit 消息（预提交请求） ，RM 收到消息之后会执行本地数据库事务预操作比如写 redo log/undo log 日志。
\n如果准备阶段有任一 RM 回复“NO” 或者直接超时未回复的话，TM 就会给所有 RM 发送 Abort 消息（中断请求） ，RM 收到消息后直接中断事务。这样其实对 RM 来说损失并不大，因为本质上 RM 到现在还并没有实际做什么事情。
\n如果 RM 成功的执行了事务预操作，就返回 “YES”。否则，返回“No”（最后的反悔机会）。
\n预提交阶段 TM 与 RM 都引入了超时机制，如果 参与者 没有收到 TM 的 PreCommit 消息，或者 TM 没有收到参与者返回的预执行结果状态，那么在超过等待时间后，事务就会中断，这就避免了事务的阻塞。
\n执行事务提交（DoCommit） 阶段就开始进行真正的事务提交。
\n如果预提交阶段所有的 RM 回复 “YES”的话，TM 就会向所有的 RM 发送 DoCommit 消息（执行事务提交请求） ，RM 收到消息之后会执行本地数据库事务提交，并在完成后释放占用的资源。当事务提交成功后，RM 会返回 “YES”。
\n如果预提交阶段有任一 RM 回复“NO”或者直接超时未回复的话，TM 就会给所有 RM 发送 Abort 消息（中断请求） ，RM 收到消息后会进行事务回滚，释放资源，中断本次事务。
\n如果 RM 在设定时间内没有收到 TM 的 DoCommit 消息，RM 会认为 TM 可能发生了故障，会直接进行事务提交。
\n只要预提交阶段所有 RM 都返回了 Yes，那么进入第三阶段后，事务大概率可以执行成功。
但这里要特别注意：RM 超时后默认提交是 3PC 的“双刃剑”。它缓解了 2PC 中 TM 宕机导致 RM 永久阻塞的问题，但也引入了新的不一致风险。比如 TM 原本决定 Abort，但只有部分 RM 收到 Abort 消息，其他 RM 因超时默认提交，就会造成同一个事务在不同 RM 上出现“部分提交、部分回滚”的状态。这也是 3PC 在工程上很少真正落地的重要原因。
\n3PC 除了将 2PC 中的 Prepare 阶段做了进一步拆分之外，还做了哪些改进？
\n3PC 同时在 TM 和 RM 中引入了 超时机制。如果 TM 在一定时间内没有收到 RM 的消息，就默认失败并中断事务；如果 RM 长时间收不到 TM 的下一步指令，也会根据所处阶段选择中断或提交，尽量避免资源长期阻塞。
\n不过，3PC 并没有完美解决 2PC 的阻塞问题，还引入了性能更差、仍可能数据不一致等新问题。因此，3PC 的实际应用并不广泛。工程上更主流的方向是使用 Paxos / Raft 等共识协议（通常结合复制状态机模式）来解决协调者单点和状态一致性问题，而不是直接使用 3PC。
\nTCC 属于目前比较常见的一种柔性事务解决方案。数据库专家帕特 · 赫兰德（Pat Helland）于 2007 年发表的 《Life beyond Distributed Transactions: an Apostate’s Opinion》 讨论了避免传统分布式事务、改用业务补偿的思路，感兴趣的小伙伴可以阅读一下这篇论文。
\n简单来说，TCC 是 Try、Confirm、Cancel 三个词的缩写，它分为三个阶段：
\n每个阶段由业务代码控制，这样可以避免数据库层面的长事务和长期持锁，但代价是业务代码侵入更强，开发者需要自己处理资源预留、确认、取消、重试和异常补偿。
\n我们拿转账场景来说：
\n一般情况下，当我们使用 TCC 模式的时候，需要自己实现 try、confirm、cancel 这三个方法，来达到最终一致性。
正常情况下，会执行 try、confirm 方法。
![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/distributed-transaction-tcc-confirm.png\"){kind=spacer}
出现异常的话，会执行 try、cancel 方法。
![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/distributed-transaction-tcc-cancel.png\"){kind=spacer}
Try 阶段出现问题的话，可以执行 Cancel。那如果 Confirm 或者 Cancel 阶段失败了怎么办呢？
\nTCC 会记录事务日志并持久化事务日志到某种存储介质上比如本地文件、关系型数据库、ZooKeeper，事务日志包含了事务的执行状态，通过事务执行状态可以判断出事务是提交成功了还是提交失败了，以及具体失败在哪一步。如果发现是 Confirm 或者 Cancel 阶段失败的话，会进行重试，继续尝试执行 Confirm 或者 Cancel 阶段的逻辑。重试次数由具体框架决定，超过最大重试次数仍未成功的，通常需要告警并进入人工介入流程。
\n如果代码没有特殊 Bug 的话，Confirm 或者 Cancel 阶段出现问题的概率是比较小的。
\nTCC 落地时有三个非常经典的工程问题：
\n事务日志会被删除吗？ 会的。如果事务提交成功（没有抛出任何异常），就可以删除对应的事务日志，节省资源。
\nTCC 模式不需要依赖于底层数据资源的事务支持，但是需要我们手动实现更多的代码，属于 侵入业务代码 的一种分布式解决方案。
\nTCC 事务模型的思想类似 2PC，我简单花了一张图对比一下二者。
\n![\"2PC](\"https://oss.javaguide.cn/github/javaguide/distributed-system/distributed-transaction/2pc-vs-tcc.png\")
TCC 和 2PC/3PC 有什么区别呢？
\n针对 TCC 的实现，业界也有一些不错的开源框架。不同的框架对于 TCC 的实现可能略有不同，不过大致思想都一样。
\nAT（Automatic Transaction）模式是 Seata 的核心模式之一，目标是在尽量少改业务代码的前提下提供最终一致能力。它可以理解为“自动补偿”方案：业务仍然按本地事务提交，但框架会记录回滚所需的信息。
\nAT 模式大致分为两个阶段：
\nundo_log 表，并向 TC 注册分支事务。undo_log。undo_log 生成反向补偿 SQL，将数据恢复到 before image。AT 模式的优点是业务侵入低，适合大量基于关系型数据库的常规 CRUD 场景；缺点是对 SQL 类型、表主键、全局锁、隔离级别等有要求，不适合所有复杂 SQL 和跨非关系型资源场景。
\n| 维度 | TCC | Saga |
\n|
\n\n本文重构完善自6000 字 | 16 图 | 深入理解 Spring Cloud Gateway 的原理 - 悟空聊架构这篇文章。
\n
Spring Cloud Gateway 属于 Spring Cloud 生态系统中的网关，其诞生的目标主要是为了替代 Zuul 1.x。Zuul 1.x 基于 Servlet 阻塞 I/O 架构，在高并发场景下性能有限。而 Zuul 2.x 虽然采用了 Netty 非阻塞架构，但 Spring Cloud 官方并未正式集成 Zuul 2.x。Spring Cloud Gateway 起步要比 Zuul 2.x 更早。
\n为了提升网关的性能，Spring Cloud Gateway 基于 Spring WebFlux 。Spring WebFlux 使用 Reactor 库来实现响应式编程模型，底层基于 Netty 实现同步非阻塞的 I/O。
\nSpring Cloud Gateway 不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，限流。
\nSpring Cloud Gateway 和 Zuul 2.x 的差别不大，也是通过过滤器来处理请求。不过，目前更加推荐使用 Spring Cloud Gateway 而非 Zuul，Spring Cloud 生态对其支持更加友好。
\nSpring Cloud Gateway 的工作流程如下图所示：
\n![\"Spring](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway/spring-cloud-gateway-workflow.png\")
这是 Spring 官方博客中的一张图，原文地址：https://spring.io/blog/2022/08/26/creating-a-custom-spring-cloud-gateway-filter。
\n具体的流程分析：
\n总结：客户端的请求先通过匹配规则找到合适的路由，就能映射到具体的服务。然后请求经过过滤器处理后转发给具体的服务，服务处理后，再次经过过滤器处理，最后返回给客户端。
\n断言（Predicate）这个词听起来极其深奥，它是一种编程术语，我们生活中根本就不会用它。说白了它就是对一个表达式进行 if 判断，结果为真或假，如果为真则做这件事，否则做那件事。
\n在 Gateway 中，如果客户端发送的请求满足了断言的条件，则映射到指定的路由器，就能转发到指定的服务上进行处理。
\n断言配置的示例如下，配置了两个路由规则，有一个 predicates 断言配置，当请求 url 中包含 api/thirdparty，就匹配到了第一个路由 route_thirdparty。
![\"断言配置示例\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway/spring-cloud-gateway-predicate-example.png\")
常见的路由断言规则如下图所示：
\n![\"Spring](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway/spring-cloud-gateway-predicate-rules.png\")
Route 路由和 Predicate 断言的对应关系如下：：
\n![\"路由和断言的对应关系\"](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway/spring-cloud-gateway-predicate-route.png\")
在使用 Spring Cloud Gateway 的时候，官方文档提供的方案总是基于配置文件或代码配置的方式。
\nSpring Cloud Gateway 作为微服务的入口，需要尽量避免重启，而现在配置更改需要重启服务不能满足实际生产过程中的动态刷新、实时变更的业务需求，所以我们需要在 Spring Cloud Gateway 运行时动态配置网关。
\n实现动态路由的方式有很多种，其中一种推荐的方式是基于 Nacos 注册中心来做。 Spring Cloud Gateway 可以从注册中心获取服务的元数据（例如服务名称、路径等），然后根据这些信息自动生成路由规则。这样，当你添加、移除或更新服务实例时，网关会自动感知并相应地调整路由规则，无需手动维护路由配置。
\n其实这些复杂的步骤并不需要我们手动实现，通过 Nacos Server 和 Spring Cloud Alibaba Nacos Config 即可实现配置的动态变更，官方文档地址：https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-config 。
\n过滤器 Filter 按照请求和响应可以分为两种：
\n另外一种分类是按照过滤器 Filter 作用的范围进行划分：
\n常见的局部过滤器如下图所示：
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway/spring-cloud-gateway-gatewayfilters.png\")
具体怎么用呢？这里有个示例，如果 URL 匹配成功，则去掉 URL 中的 “api”。
\nfilters: #过滤器\n - RewritePath=/api/(?<segment>.*),/$\\{segment} # 将跳转路径中包含的 “api” 替换成空当然我们也可以自定义过滤器，本篇不做展开。
\n常见的全局过滤器如下图所示：
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/distributed-system/api-gateway/spring-cloud-gateway-globalfilters.png\")
全局过滤器最常见的用法是进行负载均衡。配置如下所示：
\nspring:\n cloud:\n gateway:\n routes:\n - id: route_member # 第三方微服务路由规则\n uri: lb://passjava-member # 负载均衡，将请求转发到注册中心注册的 passjava-member 服务\n predicates: # 断言\n - Path=/api/member/** # 如果前端请求路径包含 api/member，则应用这条路由规则\n filters: #过滤器\n - RewritePath=/api/(?<segment>.*),/$\\{segment} # 将跳转路径中包含的api替换成空这里有个关键字 lb，用到了全局过滤器 LoadBalancerClientFilter，当匹配到这个路由后，会将请求转发到 passjava-member 服务，且支持负载均衡转发，也就是先将 passjava-member 解析成实际的微服务的 host 和 port，然后再转发给实际的微服务。
Spring Cloud Gateway 自带了限流过滤器，对应的接口是 RateLimiter，RateLimiter 接口只有一个实现类 RedisRateLimiter （基于 Redis + Lua 实现的限流），提供的限流功能比较简易且不易使用。
从 Sentinel 1.6.0 版本开始，Sentinel 引入了 Spring Cloud Gateway 的适配模块，可以提供两种资源维度的限流：route 维度和自定义 API 维度。也就是说，Spring Cloud Gateway 可以结合 Sentinel 实现更强大的网关流量控制。
\n在 SpringBoot 项目中，我们捕获全局异常只需要在项目中配置 @RestControllerAdvice和 @ExceptionHandler就可以了。不过，这种方式在 Spring Cloud Gateway 下不适用。
Spring Cloud Gateway 提供了多种全局处理的方式，比较常用的一种是实现ErrorWebExceptionHandler并重写其中的handle方法。
@Order(-1)\n@Component\n@RequiredArgsConstructor\npublic class GlobalErrorWebExceptionHandler implements ErrorWebExceptionHandler {\n private final ObjectMapper objectMapper;\n\n @Override\n public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {\n // ...\n }\n}这份 高可用系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少故障、隔离故障、快速恢复、降低重复请求和异常流量影响”整理本站高可用相关文章。
\n如果你时间有限，建议先看 高可用系统设计面试题总结，快速建立高频问题清单；如果你想系统补基础，可以按下面的阅读顺序推进。
\n在微服务架构里，一个请求往往要经过好几个服务的调用链。如果链路上某个服务出了问题——比如响应变慢、超时甚至直接挂掉——很容易把上游的资源也拖垮，最后演变成整条链路雪崩。服务降级和熔断就是应对这类问题的两道防线：降级负责在系统压力大的时候主动"丢车保帅"，熔断负责在下游持续异常的时候及时"断路"止损。
\n这篇文章会把降级和熔断的核心原理讲清楚，包括 Fallback 兜底、降级开关、熔断器状态机、隔离策略，以及 Sentinel、Hystrix、Resilience4j 的选型对比。
\n服务降级，说白了就是：系统快扛不住的时候，先牺牲不重要的功能，把资源留给核心链路。
\n比如电商大促时，推荐模块、广告位、活动氛围图这些非核心功能可以先关掉，但下单、支付、库存扣减这些链路必须尽量保住。用户少看一个推荐还能接受，但下不了单就是真事故。
\n所以，降级是一套提前设计好的兜底方案，不是系统挂了以后随便返回个默认值。什么时候触发、关哪些功能、返回什么内容、怎么恢复，都应该提前想清楚。
\n很多人会把降级理解成“机器负载太高才降级”，其实不止这一种情况。
\n常见触发场景有几类：
\n不管触发原因是什么，降级的核心目标都一样：保核心，弃非核心。
\n降级的粒度可以粗，也可以细。
\n粗一点，可以直接降级整个服务。比如推荐服务异常时，所有推荐结果都返回空列表。
\n细一点，可以只降级页面里的某个区块。比如商品详情页还正常展示，但“猜你喜欢”区域先隐藏。
\n再细一点，可以只降级某个接口、某个功能开关，甚至某一类用户、某一个业务场景。
\n实际项目里，通常会给功能分优先级。比如：
\n这里的 L0-L4、1-10 级都只是团队内部约定，不是行业统一标准。关键不在于怎么命名，而是要提前分清楚：哪些功能可以牺牲，哪些功能必须保。
\n有些操作没必要同步完成，可以先放到 MQ 里慢慢处理。
\n比如评论后发积分、统计用户行为、生成报表，这类操作即使晚几秒完成，用户一般也感知不到。主流程只要先返回成功，后面的事情交给异步任务处理即可。
\n但这里有个坑：MQ 也可能积压。如果消费者已经处理不过来了，生产者还一直重试，反而会把系统打得更严重。所以重试要加退避和随机抖动，必要时还要限流。
\n这是最直观的一种方式：页面主体保留，把非核心区块关掉。
\n比如商品详情页里，商品标题、价格、库存要保；推荐区、广告位、活动挂件可以先隐藏。
\n这种方式简单有效，但前提是你提前做好了开关和兜底逻辑。真出问题时再改代码、再发版，基本就来不及了。
\n页面里有些接口是异步加载的，比如配送时效、价格预测、推荐列表。它们如果超时，可以直接返回默认值或缓存值。
\n比如配送时效接口异常时，可以先展示“预计 2-3 天送达”；推荐接口异常时，可以返回缓存里的热门商品。
\n这里要注意一点：兜底数据最好提前准备好。不要等接口已经挂了，才临时去查数据库或重新生成缓存，那样很可能把故障继续放大。
\n如果完整页面太重，可以把用户导到一个简版页面或静态页面。
\n比如大促活动页访问量太大时，可以临时切到静态活动页；系统维护时，可以跳到维护提示页。
\n这种方案看起来简单，但一定要提前准备好静态页、路由规则和切换开关。线上出事后再临时做，基本不现实。
\n写降级适合一些“可以晚一点落库”的场景。
\n比如积分发放、消息通知、库存流水这类操作，可以先写 Redis、消息表或本地持久化队列，再由 MQ 或定时任务慢慢同步到数据库。
\n但写降级的代价也比较明显：你要处理最终一致性问题。比如消息有没有丢、数据有没有重复写、同步失败后怎么补偿、对账怎么做，这些都要提前设计。
\n尤其要注意，纯内存队列不适合保存关键数据。节点一重启，数据就没了。
\n读降级通常是“只读缓存，不再访问后端服务”。
\n比如商品详情、店铺信息、热门榜单这种读多写少的数据，就很适合做缓存兜底。后端服务异常时，先返回缓存里的旧数据，至少页面还能打开。
\n如果缓存也没命中，就不要继续硬调下游了。可以直接返回默认值、空结果或降级页。否则用户一次请求可能会把一串后端服务都拖进去。
\n降级必须能快速打开和关闭。不能每次都靠改代码、发版、重启。
\n常见方案有这些：
\n| 方案 | 特点 | 适合场景 |
\n|
高可用系统面试考的不是“系统永远不出问题”，而是你是否理解：故障一定会发生，关键是系统能不能限制故障范围、快速恢复，并避免把小故障放大成全站事故。
\n这篇文章把 JavaGuide 现有高可用相关文章串成一条面试复习路线，适合准备后端开发、系统设计和中高级岗位面试。
\n高可用设计可以从 5 个问题开始拆：
\n只要围绕这 5 个问题展开，高可用系统设计题就不会答散。
\n先建立整体框架，再看具体手段。
\n重点文章：
\n\n高频面试问题：
\n这一阶段重点理解“系统会坏”这个前提。高可用设计的核心不是追求零故障，而是让故障可预期、可隔离、可恢复。
\n限流、降级、熔断经常一起被问，但它们解决的问题不一样。
\n重点文章：
\n\n高频面试问题：
\n回答这类问题时，要说明触发条件和恢复机制。比如熔断不是“一失败就立刻切断”，而是需要错误率、慢调用比例、最小请求数、恢复探测等规则配合。不同实现（如 Sentinel、Resilience4j）的默认参数和窗口机制有差异，面试时最好能说出你用过的一种具体配置。
\n超时、重试、幂等是线上事故里非常常见的组合题。
\n重点文章：
\n\n高频面试问题：
\n这部分最重要的结论是：重试必须和超时、限流、幂等一起设计。没有幂等的重试可能造成重复下单、重复扣款；没有退避的重试可能把下游彻底打挂。读操作重试相对安全，写操作重试必须配合幂等，重试次数通常建议控制在 3 次以内。
\n很多同学准备高可用面试时只背方案，忽略验证视角。真实系统里，如果没有压测和监控，高可用设计就只是纸面设计。
\n重点文章：
\n\n高频面试问题：
\n面试里可以这样收束答案：上线前通过压测确认容量边界，上线后通过监控发现异常，通过限流降级保护系统，通过预案和演练缩短恢复时间。
\n遇到“如何设计一个高可用系统”这类题，可以按下面的顺序回答：
\n这样答的好处是不会堆概念，而是沿着故障传播路径一步步收敛风险。
\n临近面试可以按这个顺序复习：
\n\n高可用面试的核心不是把每个概念背得很长，而是能把它们串成一套故障治理体系：出问题前能预防，出问题时能止损，出问题后能恢复和复盘。
\n", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "高可用" ] }, { "title": "高可用系统设计详解：SLA、限流熔断、降级容灾、缓存与灰度发布", "url": "https://codingmap.strova.top/high-availability/high-availability-system-design.html", "id": "https://codingmap.strova.top/high-availability/high-availability-system-design.html", "summary": "高可用系统设计指南，讲解 SLA 和多少个 9、单点故障治理、限流熔断、服务降级、缓存高可用、异步削峰、冗余容灾、灰度发布和故障恢复等核心方案。重点围绕 什么是高可用？可用性的判断标准是啥？、哪些情况会导致系统不可用？、有哪些提高系统可用性的方法？、高可用、系统设计 等内容展开。结合 CodingMap 知识体系梳理。", "content_html": "不管是平时刷的购物网站、用的在线支付，还是公司内部的核心业务系统，用户对"服务不可用"的容忍度越来越低。一次持续几分钟的故障，可能就会带来大量用户流失甚至直接的经济损失。
\n所以，如何让系统在各种异常情况下依然能提供稳定的服务，就成了后端开发和架构设计中绕不开的话题。这篇文章会把高可用系统设计的核心思路和常见方案梳理一遍，包括 SLA 指标、单点故障治理、限流熔断、服务降级、缓存高可用、异步削峰、冗余容灾、灰度发布和故障恢复等。
\n高可用（High Availability，简称 HA） 是指系统在绝大部分时间内能够持续提供正常服务的能力。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的。
\n一般情况下，我们使用 多少个 9 来评判一个系统的可用性，比如 99.9999% 就是代表该系统在所有的运行时间中只有 0.0001% 的时间是不可用的，这样的系统就是非常非常高可用的了！可用性较差的系统可能连 90%（1 个 9）都达不到。
\n| 可用性等级 | 可用性百分比 | 年度停机时间 | 典型场景 |
\n|
这部分内容摘自 JavaGuide 下面几篇文章的重点：
\n高可用设计：
\n\n限流、降级、熔断：
\n\n超时、重试、幂等：
\n\n高可用（High Availability）指系统在面对机器故障、网络抖动、依赖异常、流量突增等情况时，仍然能够尽可能持续提供服务。
\n它不是追求系统永远不出故障，而是关注 3 件事：
\n面试里不要把高可用理解成“多部署几台机器”。多副本只能减少单点故障，但真正的高可用还要覆盖流量控制、依赖保护、数据安全、故障发现和恢复闭环。
\n可用性通常用一段时间内系统可正常服务的比例衡量。
\n粗略换算：
\n| 可用性 | 年不可用时间量级 |
\n|
接口幂等性是面试中常见的问题，也是日常开发过程中经常需要解决的问题。
\n幂等（idempotency）本身是一个数学概念，常见于抽象代数中，表示一个操作执行一次和执行多次产生的效果相同。放到函数上，可以理解为 $f(f(x)) = f(x)$。例如，$f(x)=|x|$ 就是幂等的，因为对一个数取一次绝对值和取多次绝对值，结果都一样。
\n在接口语义里，幂等主要指多次相同请求对服务端资源产生的预期效果，和执行一次请求一致。至于响应内容是否完全相同，要看业务设计；资金类接口通常会额外要求返回稳定的业务结果。
\n针对数据操作来说：
\nupdate set status = 'PAID' 这类赋值更新更容易做到幂等，update set balance = balance - 100 这类累加更新必须额外控制重复执行。接口幂等性问题通常由网络波动、用户重复操作、客户端/网关超时重试、消息重复投递等触发；响应慢会放大这些重复请求的概率。
\n不保证幂等会有什么后果？
\n没有保证幂等会导致产生严重的生产级别的 Bug，比较典型的就是涉及到钱的业务场景。就比如在没有保证幂等性的情况下，我作为用户在付款的时候，同时点击了多次付款按钮，后端处理了多次相同的扣款请求，结果导致账户被扣了多次钱。这类问题在资金类业务中属于高风险生产事故。
\n所以，资金、库存、订单、优惠券这类场景都需要认真处理幂等。另外，保证幂等性并不是说前端做了就可以，后端同样也要做。
\n前端可以在用户提交请求后将按钮置灰，或者将按钮置为不可点击。这只能降低重复提交概率，不能作为幂等保证。用户可以刷新页面、重放请求、绕过前端，也可能由网关超时重试、消息队列重复投递触发重复调用。真正的幂等边界必须放在服务端，尤其是资金、库存、订单这类会改变业务状态的接口。
\n后端保证幂等性就稍微麻烦一点，方法也有很多种，比如悲观锁、唯一索引、去重表、乐观锁、分布式锁、Token 机制等。
\n悲观锁和分布式锁的核心思想都是通过加锁来保证同一时刻只有一个请求能被执行。但仅仅这样是不够的，还需要配合根据业务逻辑进行幂等性判断，例如，注册场景检测指定的电话/邮箱/用户名是否已经被注册、订单支付场景检测订单的状态。
\n实际项目里更常见的是组合方案：业务唯一键 / 幂等号负责识别重复请求，数据库唯一索引或去重表负责兜底，状态机负责防止状态回退；分布式锁只在需要串行化同一业务资源操作时使用。
\n常见场景可以先这样理解：
\n方案选择时可以遵循几个优先级：
\n在 Java 中，可以使用 ReentrantLock 类、synchronized 关键字这类 JDK 自带的悲观锁来保证同一时刻只有一个线程能够进行修改。不过，JDK 自带的锁属于本地锁，分布式环境下无法使用。
除了利用 JDK 提供的悲观锁之外，数据库自身也自带排他锁（X 锁）。排他锁又称写锁/独占锁，事务在修改记录的时候获取排他锁，不允许多个事务同时获取。如果一条记录已经被加了排他锁，其他事务不能再对这条记录加不兼容的锁。
\n在 MySQL 里使用排他锁：
\nSELECT ... FOR UPDATE排他锁只能在支持事务的存储引擎（如 InnoDB）中使用，且只能在事务中使用。SELECT ... FOR UPDATE 最好命中合适索引，否则 InnoDB 可能扫描并锁住大量记录，甚至接近全表锁定效果，严重影响并发。在 MySQL 默认的 RR（REPEATABLE READ）隔离级别下，InnoDB 可能使用 Next-Key Lock（记录锁 + 间隙锁），更要通过 EXPLAIN 确认执行计划命中索引。
高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行。使用悲观锁时，要保证加锁顺序一致、事务尽量短、查询命中索引，并结合 EXPLAIN 和死锁日志排查锁等待问题。
乐观锁一般会使用版本号机制或 CAS 算法实现。
\n拿版本号机制来说，通过在表中增加一个版本号字段，每次更新数据时，检查当前版本号是否和数据库中的一致。如果一致，则更新成功，并且版本号加一。如果不一致，则更新失败，表示数据已经被其他请求修改过。
\n-- 更新数据，修改 price 并将 version 加一，并且检查 version 是否为 1（假设 version 的初始值为 1）\nupdate goods set price = price + 100, version = version + 1 where id = 1 and version = 1;\n-- 由于 version 已经变为 2，因此，下面的 SQL 执行无效\nupdate goods set price = price + 100, version = version + 1 where id = 1 and version = 1;高并发的场景下，乐观锁通常不会像悲观锁那样长时间阻塞等待，能减少锁竞争带来的线程堆积，在性能上往往会更胜一筹。但数据库更新仍可能涉及行锁，复杂事务下不能说完全没有死锁风险。如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试（悲观锁的开销是固定的），这样同样会非常影响性能，导致 CPU 飙升。不过，这种方法主要适用于更新数据的场景。
\n乐观锁更新失败后要提前设计处理策略：可以返回明确的冲突提示，由调用方决定是否重试；也可以在服务端有限重试 2～3 次；还可以查询当前状态并返回已有结果。资金类场景不建议盲目自动重试，应优先返回冲突或查询最终状态。
\n通过在表中加上唯一索引，保证数据的唯一性。如果有重复的数据插入，会抛出异常，程序可以捕获异常并处理。不过，这种方法只适用于插入数据的场景。
\ncreate table t_order(\n id int unsigned PRIMARY KEY AUTO_INCREMENT COMMENT \"主键\",\n `code` varchar(200) not null COMMENT \"流水号\",\n `customer_id` int unsigned COMMENT \"会员id\",\n `amount` decimal(10,2) unsigned not null COMMENT \"总金额\",\n -- 省略其他订单字段\n -- 省略其他索引\n -- 订单流水号唯一\n UNIQUE unq_code(`code`)\n) COMMENT=\"订单表\";不要只依靠唯一索引完成全部幂等逻辑，但插入类场景建议把唯一索引作为数据库层兜底，避免并发下产生重复数据。
\n去重表本质上也是一种唯一索引方案。去重表是一张专门用于记录请求信息的表，其中某个字段需要建立唯一索引，用于标识请求的唯一性。当客户端发出请求时，服务端会将这次请求的一些信息（如订单号、交易流水号等）插入到去重表中，如果插入成功，说明这是第一次请求，可以执行后续的业务逻辑；如果插入失败，说明这是重复请求，可以直接返回或者忽略。
\nCREATE TABLE deduplication_table (\n id int unsigned PRIMARY KEY AUTO_INCREMENT COMMENT \"主键\",\n processed_code varchar(200) not null COMMENT \"已处理的订单流水号\",\n -- 省略其他字段\n UNIQUE unq_processed_code(processed_code)\n) COMMENT=\"去重表\";去重表的插入要和后续业务操作放在同一个数据库事务中。事务提交成功，才表示“去重记录存在 = 业务已经处理完成”；如果业务逻辑失败回滚，去重记录也要一起回滚，后续请求才能正常重入。否则可能出现“去重记录已写入，但业务实际没完成”的不一致状态。分库分表导致去重表和业务表不在同一物理库时，需要额外考虑 TCC / Saga 等分布式事务方案，或者改用其他能保证一致性的设计。
\n分布式系统下，不同的服务/客户端通常运行在独立的 JVM 进程上。如果需要跨 JVM 串行化同一业务资源的操作，就可以考虑使用分布式锁。
\n
基于 MySQL 虽然也能实现分布式锁（如利用 SELECT ... FOR UPDATE 或唯一索引），但性能和可靠性通常不如专门的协调服务，生产中较少采用。
通常情况下，我们一般会选择基于 Redis 或者 ZooKeeper 实现分布式锁，Redis 用的要更多一点。
\n关系型数据库也可以参与分布式场景下的并发控制，比如唯一索引兜底、状态机校验、行锁串行化；但乐观锁和唯一索引通常不归类为分布式锁。
\n关于分布式锁的详细介绍以及如何基于 Redis 和 ZooKeeper 实现分布式锁，我写过专门的文章介绍，推荐看看：
\n需要注意的是，这里的分布式锁是根据唯一标识（比如订单号）生成的。获取到锁只说明当前可以进入临界区，不代表历史上没有处理过。进入临界区后仍必须查询业务状态或幂等记录。例如支付接口要检查订单是否已支付、交易流水号是否已处理，再决定执行业务逻辑还是直接返回历史结果。
\n以下示例基于 Redisson 3.x，使用 RLock 实现幂等的伪代码如下：
// 唯一标识\nString uniqueId = \"order123\";\n\n// 1. 根据唯一标识生成分布式锁对象\nRLock lock = redisson.getLock(\"lock:\" + uniqueId);\nboolean locked = false;\n\ntry {\n // 2. 尝试获取锁，最多等待 3 秒，拿到锁后 30 秒自动释放\n locked = lock.tryLock(3, 30, TimeUnit.SECONDS);\n if (!locked) {\n // 获取锁失败：返回处理中、稍后重试，或查询历史处理结果\n return;\n }\n\n // 3. 进入临界区后，仍要做业务幂等判断\n // 例如：查询订单状态 / 幂等流水是否已存在\n // 未处理才执行业务逻辑，已处理则直接返回历史结果\n ...\n} finally {\n // 4. 只有当前线程持有锁时才能释放\n if (locked && lock.isHeldByCurrentThread()) {\n lock.unlock();\n }\n}如果不显式指定 leaseTime，Redisson 会通过 Watchdog 给持有中的锁续期；如果指定了 leaseTime，锁会在租约时间后自动释放。上面的 30 秒只是示例值，实际使用时应根据业务最长执行时间选择，通常建议设置为预估耗时的 2～3 倍。
使用分布式锁还要额外关注这些问题：
\nleaseTime 时，锁可能提前释放。Token 机制的核心思想是为每一次操作生成一个唯一性的凭证 token。Token 应由服务端生成，保证随机性、不可预测和短有效期。如果服务端存储 token，可以用 Redis 记录并一次性消费；如果做无状态 token，才需要考虑签名、防篡改和过期时间。
\n这样的话，就需要两次请求才能完成一次业务操作：
\n服务端验证 token 时，不能先 GET 再 DEL。Redis 6.2.0 及以上版本可以使用 GETDEL，低版本可以使用 Lua 脚本完成“校验 + 删除”的原子操作，确保同一个 token 只能被一个请求消费。
得物技术的分布式系统设计中的并发访问解决方案这篇文章把这个过程图解得挺清晰。
\n![](\"https://oss.javaguide.cn/github/javaguide/distributed-system/idempotent-token.png\")
先执行业务逻辑再删除 token 还是先删除 token 再执行业务逻辑呢？两者似乎都有风险：
\n一般更推荐先原子消费 token，再执行业务逻辑；但要配套失败提示、重新获取 token、业务事务回滚和幂等流水记录。资金类场景不能只靠 token，还要用订单状态和交易流水兜底。
\nToken 机制依赖 Redis 保存 token 生命周期，也要提前设计 Redis 不可用时的降级策略。普通表单可以提示稍后重试；资金类接口不建议熔断放行，宁可返回失败，也要避免重复扣款或重复入账。
\n支付回调是幂等设计里非常典型的场景，第三方支付平台可能因为网络超时、响应丢失等原因多次回调同一笔交易。一个更稳妥的流程如下：
\ntransaction_id。transaction_id 建唯一索引。UNPAID -> PAID 这类合法状态流转才允许更新。幂等方案不能只看代码，还要通过测试和数据校验确认它真的有效。尤其是订单、支付、库存这类场景，不能只测“正常请求成功一次”，还要故意制造重复请求、超时、失败和回滚。
\n比较实用的验证方式有这几类：
\nUNPAID 变成 PAID 一次，库存扣减数量要和成功业务单数一致。简单来说，验证幂等不是看“接口会不会返回成功”，而是看重复请求和异常路径下，业务数据是否始终只被正确处理一次。
\n针对软件系统来说，限流就是对请求的速率进行限制，避免瞬时的大量请求击垮软件系统。毕竟，软件系统的处理能力是有限的。如果请求量超过了系统的处理能力，软件系统可能直接就挂掉了。
\n限流可能会导致用户的请求无法被正确处理或者无法立即被处理，不过，这往往也是权衡了软件系统的稳定性之后得到的最优解。
\n现实生活中，处处都有限流的实际应用，就比如排队买票是为了避免大量用户涌入购票而导致售票员无法处理。
\n简单介绍 4 种非常好理解并且容易实现的限流算法！
\n\n\n图片来源于 InfoQ 的一篇文章《分布式服务限流实战，已经为你排好坑了》。
\n
固定窗口其实就是时间窗口，其原理是将时间划分为固定大小的窗口，在每个窗口内限制请求的数量或速率，即固定窗口计数器算法规定了系统单位时间处理的请求数量。
\n假如我们规定系统中某个接口 1 分钟只能被访问 33 次的话，使用固定窗口计数器算法的实现思路如下：
\ncounter 来记录当前接口处理的请求数量，初始值为 0（代表接口当前 1 分钟内还未处理请求）。counter+1 ，当 counter=33 之后（也就是说在这 1 分钟内接口已经被访问 33 次的话），后续的请求就会被全部拒绝。counter 重置 0，重新开始计数。![\"固定窗口计数器算法\"](\"https://static001.infoq.cn/resource/image/8d/15/8ded7a2b90e1482093f92fff555b3615.png\")
优点：实现简单，易于理解。
\n缺点：
\n1000/60≈16.7。滑动窗口计数器算法 算得上是固定窗口计数器算法的升级版，限流的粒度更小。
\n滑动窗口计数器算法相比于固定窗口计数器算法的优化在于：它将一个固定窗口划分为多个更小的子窗口（格子） 。
\n例如我们的接口限流每分钟处理 60 个请求，我们可以把 1 分钟分为 60 个窗口。每隔 1 秒移动一次，每个窗口一秒只能处理不大于 60(请求数)/60（窗口数） 的请求， 如果当前窗口的请求计数总和超过了限制的数量的话就不再处理其他请求。
很显然， 当滑动窗口的格子划分得越多，滑动窗口的滚动就越平滑，限流的统计就会越精确。
\n![\"滑动窗口计数器算法\"](\"https://static001.infoq.cn/resource/image/ae/15/ae4d3cd14efb8dc7046d691c90264715.png\")
优点：
\n缺点：
\n我们可以把发请求的动作比作成注水到桶中，我们处理请求的过程可以比喻为漏桶漏水。我们往桶中以任意速率流入水，以一定速率流出水。当流入的水超过桶的容量时，多余的水会被丢弃，因为桶容量是不变的，保证了整体的速率。
\n如果想要实现这个算法的话也很简单，准备一个队列用来保存请求，然后我们定期从队列中拿请求来执行就好了（和消息队列削峰/限流的思想是一样的）。
\n![\"漏桶算法\"](\"https://static001.infoq.cn/resource/image/75/03/75938d1010138ce66e38c6ed0392f103.png\")
优点：
\n缺点：
\n实际业务场景中，漏桶算法的适用范围相对窄一些。当业务需要允许一定程度的突发流量时，令牌桶通常更合适；但在需要严格控制输出速率的场景（如对接有明确 QPS 限制的第三方 API）中，漏桶仍然是合适的方案。
\n令牌桶算法也比较简单。和漏桶算法一样，我们的主角还是桶（这限流算法和桶过不去啊）。不过现在桶里装的是令牌了，请求在被处理之前需要从桶中获取一个令牌（获取即消费）。如果桶中没有令牌，请求就需要等待或被拒绝。我们根据限流大小，按照一定的速率往桶里添加令牌。如果桶装满了，就不能继续往里面继续添加令牌了。
\n![\"令牌桶算法\"](\"https://static001.infoq.cn/resource/image/ec/93/eca0e5eaa35dac938c673fecf2ec9a93.png\")
优点：
\n缺点：
\n实际项目中，还需要确定限流对象，也就是针对什么来进行限流。常见的限流对象如下：
\n针对 IP 进行限流是目前比较常用的一个方案。不过，实际应用中需要注意用户真实 IP 地址的正确获取。常用的真实 IP 获取方法有 X-Forwarded-For 和 TCP Options 字段承载真实源 IP 信息。虽然 X-Forwarded-For 字段可能会被伪造，但因为其实现简单方便，很多项目还是直接用的这种方法。
\n除了我上面介绍到的限流对象之外，还有一些其他较为复杂的限流对象策略，比如阿里的 Sentinel 还支持 基于调用关系的限流（包括基于调用方限流、基于调用链入口限流、关联流量限流等）以及更细维度的 热点参数限流（实时的统计热点参数并针对热点参数的资源调用进行流量控制）。
\n另外，一个项目可以根据具体的业务需求选择多种不同的限流对象搭配使用。
\n单机限流针对的是单体架构应用。
\n单机限流可以直接使用 Google Guava 自带的限流工具类 RateLimiter 。 RateLimiter 基于令牌桶算法，可以应对突发流量。
\n\nGuava 地址：https://github.com/google/guava
\n
除了最基本的令牌桶算法(平滑突发限流)实现之外，Guava 的RateLimiter还提供了 平滑预热限流 的算法实现。
平滑突发限流就是按照指定的速率放令牌到桶里，而平滑预热限流会有一段预热时间，预热时间之内，速率会逐渐提升到配置的速率。
\n下面通过两个简单的示例来了解。
\n我们直接在项目中引入 Guava 相关依赖即可使用。
\n<dependency>\n <groupId>com.google.guava</groupId>\n <artifactId>guava</artifactId>\n <version>31.0.1-jre</version>\n</dependency>\n\n本文示例基于 Guava 31.x，
\nRateLimiter的核心 API 在更高版本中仍保持兼容。
下面是一个简单的 Guava 平滑突发限流的 Demo。
\nimport com.google.common.util.concurrent.RateLimiter;\n\n/**\n * 微信搜 JavaGuide 回复\"面试突击\"即可免费领取个人原创的 Java 面试手册\n *\n * @author Guide哥\n * @date 2021/10/08 19:12\n **/\npublic class RateLimiterDemo {\n\n public static void main(String[] args) {\n // 1s 放 5 个令牌到桶里也就是 0.2s 放 1个令牌到桶里\n RateLimiter rateLimiter = RateLimiter.create(5);\n for (int i = 0; i < 10; i++) {\n double sleepingTime = rateLimiter.acquire(1);\n System.out.printf(\"get 1 tokens: %ss%n\", sleepingTime);\n }\n }\n}输出：
\nget 1 tokens: 0.0s\nget 1 tokens: 0.188413s\nget 1 tokens: 0.197811s\nget 1 tokens: 0.198316s\nget 1 tokens: 0.19864s\nget 1 tokens: 0.199363s\nget 1 tokens: 0.193997s\nget 1 tokens: 0.199623s\nget 1 tokens: 0.199357s\nget 1 tokens: 0.195676s需要注意的是，acquire() 是阻塞式获取令牌，在生产环境中通常更建议使用 tryAcquire(timeout) 设置等待上限，避免线程长时间阻塞。第一次输出等待时间为 0.0s，是因为 RateLimiter.create(5) 创建后桶里初始就有可用令牌。
下面是一个简单的 Guava 平滑预热限流的 Demo。
\nimport com.google.common.util.concurrent.RateLimiter;\nimport java.util.concurrent.TimeUnit;\n\n/**\n * 微信搜 JavaGuide 回复\"面试突击\"即可免费领取个人原创的 Java 面试手册\n *\n * @author Guide哥\n * @date 2021/10/08 19:12\n **/\npublic class RateLimiterDemo {\n\n public static void main(String[] args) {\n // 1s 放 5 个令牌到桶里也就是 0.2s 放 1个令牌到桶里\n // 预热时间为3s,也就说刚开始的 3s 内发牌速率会逐渐提升到 0.2s 放 1 个令牌到桶里\n RateLimiter rateLimiter = RateLimiter.create(5, 3, TimeUnit.SECONDS);\n for (int i = 0; i < 20; i++) {\n double sleepingTime = rateLimiter.acquire(1);\n System.out.printf(\"get 1 tokens: %sds%n\", sleepingTime);\n }\n }\n}输出：
\nget 1 tokens: 0.0s\nget 1 tokens: 0.561919s\nget 1 tokens: 0.516931s\nget 1 tokens: 0.463798s\nget 1 tokens: 0.41286s\nget 1 tokens: 0.356172s\nget 1 tokens: 0.300489s\nget 1 tokens: 0.252545s\nget 1 tokens: 0.203996s\nget 1 tokens: 0.198359s另外，Bucket4j 是一个非常不错的基于令牌/漏桶算法的限流库。
\n\n\nBucket4j 地址：https://github.com/vladimir-bukhtoyarov/bucket4j
\n
相对于 Guava 的限流工具类来说，Bucket4j 提供的限流功能更加全面。不仅支持单机限流和分布式限流，还可以集成监控，搭配 Prometheus 和 Grafana 使用。
\n不过，毕竟 Guava 也只是一个功能全面的工具类库，其提供的开箱即用的限流功能在很多单机场景下还是比较实用的。
\nSpring Cloud Gateway 的内置限流器 RedisRateLimiter 基于 Redis + Lua 实现。Bucket4j 和 Resilience4j 更多是通过独立扩展或 Spring 生态组件与网关集成，并不是 Spring Cloud Gateway 内置限流器的替代演进关系。
Resilience4j 是一个轻量级的容错组件，其灵感来自于 Hystrix。自Netflix 宣布不再积极开发 Hystrix 之后，Spring 官方和 Netflix 都更推荐使用 Resilience4j 来做限流熔断。
\n\n\nResilience4j 地址: https://github.com/resilience4j/resilience4j
\n
一般情况下，为了保证系统的高可用，项目的限流和熔断都是要一起做的。
\nResilience4j 不仅提供限流，还提供了熔断、负载保护、自动重试等保障系统高可用开箱即用的功能。并且，Resilience4j 的生态也更好，很多网关都使用 Resilience4j 来做限流熔断的。
\n因此，在绝大部分场景下 Resilience4j 或许会是更好的选择。如果是一些比较简单的限流场景的话，Guava 或者 Bucket4j 也是不错的选择。
\n分布式限流针对的是分布式/微服务应用架构。在这种架构下，一种服务可能会被部署多份，如果需要控制全局配额，就要让多个实例共享限流状态。不过，并非所有微服务场景都必须使用分布式限流：如果配额可以按实例数均分（例如总配额 1000 QPS，10 个实例各限制 100 QPS），单机限流在性能和实现复杂度上反而更有优势。
\n分布式限流常见的方案：
\nRedisRateLimiter 就是基于 Redis+Lua 来实现的，再比如 Spring Cloud Gateway 还可以整合 Sentinel 来做限流。如果你要基于 Redis 来手动实现限流逻辑的话，建议配合 Lua 脚本来做。
\n为什么建议 Redis+Lua 的方式？ 主要有两点原因：
\n需要注意的是，Lua 脚本在 Redis 中会原子执行，也意味着脚本执行期间会阻塞 Redis 的其他操作。因此，限流脚本要尽量保持轻量，避免复杂计算或大范围遍历，并结合 Redis 的 lua-time-limit 配置防止脚本执行时间失控。
我这里就不放具体的限流脚本代码了，网上也有很多现成的优秀的限流脚本供你参考，就比如 Apache 网关项目 ShenYu 的 RateLimiter 限流插件就基于 Redis + Lua 实现了令牌桶算法/并发令牌桶算法、漏桶算法、滑动窗口算法。
\n\n\nShenYu 地址: https://github.com/apache/incubator-shenyu
\n
![\"ShenYu](\"https://oss.javaguide.cn/github/javaguide/high-availability/limit-request/shenyu-ratelimit-lua-scripts.png\")
另外，如果不想自己写 Lua 脚本的话，也可以直接利用 Redisson 中的 RRateLimiter 来实现分布式限流，其底层实现就是基于 Lua 代码+令牌桶算法。
Redisson 是一个开源的 Java 语言 Redis 客户端，提供了很多开箱即用的功能，比如 Java 中常用的数据结构实现、分布式锁、延迟队列等等。并且，Redisson 还支持 Redis 单机、Redis Sentinel、Redis Cluster 等多种部署架构。
\nRRateLimiter 的使用方式非常简单。我们首先需要获取一个RRateLimiter对象，直接通过 Redisson 客户端获取即可。然后，设置限流规则就好。
// 创建一个 Redisson 客户端实例\nRedissonClient redissonClient = Redisson.create();\n// 获取一个名为 \"javaguide.limiter\" 的限流器对象\nRRateLimiter rateLimiter = redissonClient.getRateLimiter(\"javaguide.limiter\");\n// 尝试设置限流器的速率为每小时 100 次\n// RateType 有两种，OVERALL 是全局限流，PER_CLIENT 是单 Client 限流（可以认为就是单机限流）\nrateLimiter.trySetRate(RateType.OVERALL, 100, 1, RateIntervalUnit.HOURS);接下来我们调用acquire()方法或tryAcquire()方法即可获取许可。
// 获取一个许可，如果超过限流器的速率则会等待\n// acquire()是同步方法，对应的异步方法：acquireAsync()\nrateLimiter.acquire(1);\n// 尝试在 5 秒内获取一个许可，如果成功则返回 true，否则返回 false\n// tryAcquire()是同步方法，对应的异步方法：tryAcquireAsync()\nboolean res = rateLimiter.tryAcquire(1, 5, TimeUnit.SECONDS);RRateLimiter 的限流精度会受到 Redis 性能和网络延迟影响，在超高并发场景下可能出现轻微超限。Redis 故障或主从切换时，tryAcquire() 可能抛出异常，业务层需要提前确定降级策略：回退到本地限流、直接拒绝，还是短时间放行，取决于业务对稳定性和可用性的取舍。
这篇文章主要介绍了常见的限流算法、限流对象的选择以及单机限流和分布式限流分别应该怎么做。
\n性能测试通常由专业的测试团队负责，那还需要我们开发学这个干嘛呢？了解性能测试的指标、分类以及工具等知识有助于我们更好地去写出性能更好的程序，另外作为开发这个角色，如果你会性能测试的话，相信也会为你的履历加分不少。
\n本文结合了笔者的实践经验以及向测试团队请教所得，除此之外，我还借鉴了一些优秀书籍，希望对你有帮助。
\n当用户打开一个网站的时候，最关注的是什么？当然是 网站响应速度的快慢。比如我们点击了淘宝的主页，淘宝需要多久将首页的内容呈现在我的面前，我点击了提交订单按钮需要多久返回结果等等。
\n所以，用户在体验我们系统的时候往往根据你的响应速度的快慢来评判你的网站的性能。
\n用户与开发人员都关注速度，这个速度实际上就是我们的系统 处理用户请求的速度。
\n开发人员一般情况下很难直观的去评判自己网站的性能，我们往往会根据网站当前的架构以及基础设施情况给一个大概的值，比如：
\n测试人员一般会根据性能测试工具来测试，然后一般会做出一个表格。这个表格可能会涵盖下面这些重要的内容：
\n运维人员会倾向于根据 基础设施和资源的利用率 来判断网站的性能，比如我们的服务器资源使用是否合理、数据库资源是否存在滥用的情况、当然，这是传统的运维人员，现在 Devops 火起来后，单纯干运维的很少了。我们这里暂且还保留有这个角色。
\n几乎没有文章在讲性能测试的时候提到这个问题，大家都会讲如何去性能测试，有哪些性能测试指标这些东西。
\n性能测试之前更需要你了解当前的系统的业务场景。 对系统业务了解得不够深刻，我们很容易犯测试方向偏执的错误，从而导致我们忽略了对系统某些更需要性能测试的地方进行测试。
\n比如我们的系统可以为用户提供发送邮件的功能，用户配置成功邮箱后只需输入相应的邮箱之后就能发送，系统每天大概能处理上万次发邮件的请求。很多人看到这个可能就直接开始使用相关工具测试邮箱发送接口，但是，发送邮件这个场景可能不是当前系统的性能瓶颈，这么多人用我们的系统发邮件，还可能有很多人一起发邮件，单单这个场景就这么人用，那用户管理可能才是性能瓶颈吧！
\n当前系统所留下的历史数据非常重要，一般情况下，我们可以通过一些历史数据初步判定这个系统哪些接口调用的比较多、哪些服务承受的压力最大，这样的话，我们就可以针对这些地方进行更细致的性能测试与分析。
\n另外，这些地方也就像这个系统的一个短板一样，优化好了这些地方会为我们的系统带来质的提升。
\n性能指标是衡量系统性能的核心度量标准，理解各指标之间的关系对于性能分析至关重要。
\n响应时间 RT（Response Time） 是用户发出请求到收到系统处理结果所需的时间，包括网络传输、服务端处理与客户端渲染等环节。
\n响应时间指标（Latency Percentiles）：生产环境中看平均 RT 毫无意义，必须监控 P90、P99 和 P999 分位值。例如 P99 = 500ms 意味着 99% 的请求在 500ms 内返回。剩下 1% 的长尾慢调用（可能由 Cache Miss、慢 SQL 或 GC STW 引起）会长时间占用连接和工作线程；在极高并发下，线程池耗尽会导致新请求排队或被拒绝，上游继续超时重试后又会放大流量，最终可能引发雪崩。大量超快响应会拉低平均值，掩盖致命的长尾问题，此为典型的 “均值陷阱”。
\n分位值参考标准如下：
\n| 分位值 | RT 范围（示例） | 说明 |
\n|
不管是硬件故障、机房断电，还是某个服务突然挂掉，单点永远是系统里最脆弱的环节。想让系统在各种意外情况下还能扛得住，最基本也最有效的办法就是 冗余——关键资源多备几份，坏了一份还有其他的顶上。
\n这篇文章会把冗余设计的核心概念和常见方案梳理一遍：从 RTO/RPO 这两个容灾指标，到高可用集群、同城灾备、异地多活，再到 Redis Sentinel、Keepalived 这些具体的故障转移方案。
\n冗余（Redundancy） 是提升系统可用性和数据持久性的常见手段，其核心思想是 通过部署多份相同的资源，当某一份资源出现故障时，其他资源可以接管其工作，从而保证系统的持续可用。
\n冗余是提升系统可用性的基础手段，但冗余本身不等于高可用。只有配合故障检测、流量切换、数据复制、恢复演练和监控告警，才能真正降低故障影响。
\n冗余设计可以从以下几个维度来理解：
\n![\"冗余设计类型\"](\"https://oss.javaguide.cn/github/javaguide/high-availability/redundancy-optimized-redundancy-types.png\")
| 冗余类型 | 说明 | 典型实现 |
\n|
由于网络抖动、硬件故障、进程异常、依赖服务不可用等问题的不确定性，我们的系统或者服务永远不可能保证时刻都是可用的状态。
\n为了最大限度地减小系统或者服务出现故障之后带来的影响，我们需要用到 超时（Timeout） 和 重试（Retry） 机制。
\n超时和重试的核心思想确实不难理解，但在生产环境中正确使用它们却有不少门道。你平时接触到的绝大部分涉及远程调用的系统或者服务都会应用超时和重试机制。尤其是对于微服务系统来说，正确设置超时和重试非常重要。单体服务通常只涉及数据库、缓存、第三方 API、中间件等的网络调用，而微服务系统内部各个服务之间还存在着网络调用。
\n![\"超时机制\"](\"https://oss.javaguide.cn/github/javaguide/high-availability/timeout-mechanism-overview.png\")
超时机制 说的是当一个请求超过指定的时间（比如 1s）还没有被处理的话，这个请求就会直接被取消并抛出指定的异常或者错误（比如 504 Gateway Timeout）。
我们平时接触到的超时可以简单分为下面 2 种：
\n| 超时类型 | 说明 | 建议值 |
\n|
这份 高性能系统知识体系 面向后端学习、系统设计和面试复习，围绕“减少延迟、提升吞吐、削峰填谷、降低数据库压力、优化数据访问路径”整理本站高性能相关文章。
\n如果你时间有限，建议先看 高性能系统设计面试题总结，快速建立高频问题清单；如果你想系统补基础，可以按下面的阅读顺序推进。
\nCDN 全称是 Content Delivery Network/Content Distribution Network，翻译过的意思是 内容分发网络 。
\n我们可以将内容分发网络拆开来看：
\n简单来说，CDN 就是将静态资源分发到多个不同的地方以实现就近访问，进而加快静态资源的访问速度，减轻源站服务器以及带宽的负担。
\n类似于京东建立的庞大仓储运输体系，京东物流在全国拥有非常多的仓库，仓储网络几乎覆盖全国所有区县。这样的话，用户下单的第一时间，商品就从距离用户最近的仓库直接发往对应的配送站，再由京东小哥送到你家。
\n![\"京东仓配系统\"](\"https://oss.javaguide.cn/github/javaguide/high-performance/cdn/jingdong-wuliu-cangpei.png\")
你可以将 CDN 看作是服务上一层的特殊缓存服务，分布在全国各地，主要用来处理静态资源的请求。
\n![\"CDN](\"https://oss.javaguide.cn/github/javaguide/high-performance/cdn/cdn-101.png\")
我们经常拿全站加速和内容分发网络做对比，不要把两者搞混了！全站加速（不同云服务商叫法不同，腾讯云叫 ECDN、阿里云叫 DCDN）既可以加速静态资源又可以加速动态资源，而内容分发网络（CDN） 主要针对的是 静态资源 。
\n![\"阿里云文档：https://help.aliyun.com/document_detail/64836.html\"](\"https://oss.javaguide.cn/github/javaguide/high-performance/cdn/cdn-aliyun-dcdn.png\")
绝大部分公司都会在项目开发中使用 CDN 服务，但很少会有自建 CDN 服务的公司。基于成本、稳定性和易用性考虑，建议直接选择专业的云厂商（比如阿里云、腾讯云、华为云、青云）或者 CDN 厂商（比如网宿、蓝汛）提供的开箱即用的 CDN 服务。
\n很多朋友可能要问了：既然是就近访问，为什么不直接将服务部署在多个不同的地方呢？
\n这涉及到静态资源与动态请求的架构分离问题：
\n\n\n注意：同一个服务在多个不同地方部署多份（比如同城灾备、异地灾备、同城多活、异地多活）是为了实现系统的高可用，而不是就近访问。
\n
理解 CDN 的工作原理，需要搞懂以下三个核心问题：
\nCDN 缓存静态资源的方式主要有两种：预热和回源。
\n预热（Prefetch）：主动将源站的资源推送到 CDN 节点中。这样用户首次请求资源时可以直接从 CDN 节点获取，无需回源，适用于大促活动、热点内容发布等场景。
\n回源（Origin Pull）：当 CDN 节点上没有用户请求的资源或该资源的缓存已过期时，CDN 节点需要从源站获取最新的资源内容。
\n\n\n注意：当用户请求触发回源时，该请求的响应速度会比未使用 CDN 还慢，因为相比于直接访问源站，多了一层 CDN 节点的调用流程。因此，提高缓存命中率是 CDN 优化的关键目标。
\n
CDN 缓存的完整生命周期如下图所示：
\n![\"CDN](\"https://oss.javaguide.cn/github/javaguide/high-performance/cdn/cdn-full-life-cycle-of-cdn-cache.png\")
如果资源有更新，可以对其进行刷新操作，删除 CDN 节点上缓存的旧资源，并强制 CDN 节点在下次请求时回源获取最新资源。
\n几乎所有云厂商提供的 CDN 服务都具备缓存的刷新和预热功能（下图是阿里云 CDN 服务提供的相应功能）：
\n![\"CDN](\"https://oss.javaguide.cn/github/javaguide/high-performance/cdn/cdn-refresh-warm-up.png\")
命中率和回源率是衡量 CDN 服务质量的两个核心指标：
\nGSLB（Global Server Load Balance，全局负载均衡） 是 CDN 的大脑，负责多个 CDN 节点之间的协调调度，最常用的实现方式是基于 DNS 的 GSLB。
\nCDN 请求的完整调度流程如下图所示：
\n详细流程说明：
\n\n\n补充说明：上图做了一定简化。实际上，GSLB 内部可以看作是 CDN 专用 DNS 服务器和负载均衡系统的组合。CDN 专用 DNS 服务器会返回负载均衡系统的 IP 地址，浏览器通过该 IP 请求负载均衡系统，进而找到对应的 CDN 节点。
\n
如果静态资源被其他用户或网站非法盗刷，将会产生大量额外的带宽费用。常见的防盗链机制有以下几种：
\n| 防盗链机制 | 原理 | 安全强度 | 实现成本 | 绕过难度 |
\n|
数据冷热分离是指根据数据的访问频率和业务重要性，将数据划分为冷数据和热数据，并分别存储在不同性能和成本的存储介质中的架构策略。
\n这种架构的核心目标有三个：
\n热数据是指被频繁访问和修改、且需要快速响应的数据；冷数据是指访问频率极低、对当前业务价值较小、但需要长期保留的数据。
\n冷热数据的区分方法主要有两种：
\n如何选择区分策略？
\n实际落地时，"冷"与"热"往往不是非此即彼的二分法，而是渐进式多级分层：
\n| 层级 | 数据特性 | 判定规则示例 | 存储策略 |
\n|
查询偏移量过大的场景我们称为深度分页，这会导致查询性能较低，例如：
\n# MySQL 在无法利用索引的情况下跳过1000000条记录后，再获取10条记录\nSELECT * FROM t_order ORDER BY id LIMIT 1000000, 10当查询偏移量过大时，MySQL 的查询优化器可能会选择全表扫描而不是利用索引来优化查询。
\n深度分页变慢的根本原因在于 MySQL 的执行机制：对于 LIMIT offset, N，MySQL 并非直接跳到 offset 处，而是必须从头扫描 offset + N 条记录。如果查询依赖二级索引且不满足覆盖索引，这意味着 MySQL 需要对前 offset 条记录执行毫无意义的回表查询（产生海量的随机 I/O），最后再将这些辛苦查出的数据丢弃。即便优化器最终因代价过高退化为全表扫描，顺序扫描百万行的成本依然巨大。
![\"深度分页问题\"](\"https://oss.javaguide.cn/github/javaguide/mysql/deep-pagination-phenomenon.png\")
不同机器上这个查询偏移量过大的临界点可能不同，取决于多个因素，包括硬件配置（如 CPU 性能、磁盘速度）、表的大小、索引的类型和统计信息等。
\n![\"转全表扫描的临界点\"](\"https://oss.javaguide.cn/github/javaguide/mysql/deep-pagination-phenomenon-critical-point.png\")
MySQL 的查询优化器采用基于成本的策略来选择最优的查询执行计划。它会根据 CPU 和 I/O 的成本来决定是否使用索引扫描或全表扫描。如果优化器认为全表扫描的成本更低，它就会放弃使用索引。不过，即使偏移量很大，如果查询中使用了覆盖索引（covering index），MySQL 仍然可能会使用索引，避免回表操作。
\n\n\n本文基于 MySQL 8.0 + InnoDB 存储引擎，不同版本优化器行为可能存在差异。
\n
通过记录上一页最后一条记录的 ID，使用 WHERE id > last_id LIMIT n 获取下一页数据：
# 通过记录上次查询结果的最后一条记录的 ID 进行下一页的查询\nSELECT * FROM t_order WHERE id > 100000 ORDER BY id LIMIT 10游标分页的核心优势：不依赖 ID 的连续性。MySQL 只需要在 B+ 树上定位到 last_id 的位置，然后顺序向后读取 n 条记录即可，中间是否有断层（如 ID 被删除）完全不影响结果的准确性和性能。
这种方式的限制：
\n(sort_field, id) 保证唯一性和顺序。我们先查询出 limit 第一个参数对应的主键值，再根据这个主键值再去过滤并 limit，这样效率会更快一些。
\n阿里巴巴《Java 开发手册》中也有对应的描述：
\n\n\n利用延迟关联或者子查询优化超多分页场景。
\n\n
![](\"https://oss.javaguide.cn/github/javaguide/mysql/alibaba-java-development-handbook-paging.png\")
-- 先通过子查询在主键索引上进行偏移，快速找到起始ID\nSELECT * FROM t_order\nWHERE id >= (\n SELECT id FROM t_order ORDER BY id LIMIT 1000000, 1\n) ORDER BY id LIMIT 10;工作原理:
\n(SELECT id FROM t_order ORDER BY id LIMIT 1000000, 1) 利用主键索引扫描并跳过前 1000000 条记录，返回第 1000001 条记录的主键值。SELECT * FROM t_order WHERE id >= ... ORDER BY id LIMIT 10 以该主键为起点，获取后续 10 条完整记录。不过，某些情况下子查询可能会产生临时表，影响性能，因此在复杂查询中建议优先考虑延迟关联。
\n\n\n复杂过滤场景：在包含复杂过滤条件的分页场景中（如
\nWHERE status = 1 ORDER BY id LIMIT 1000000, 10），符合条件的 ID 往往是离散的。此时子查询的优势更加明显：通过在子查询中利用联合索引（如(status, id)）实现覆盖索引扫描，可以高效地跳过前 100 万条符合条件的记录，定位到目标 ID 后，主查询只需回表 10 次。
当然，我们也可以利用子查询先去获取目标分页的 ID 集合，然后再根据 ID 集合获取内容，但这种写法非常繁琐，不如使用 INNER JOIN 延迟关联。
\n延迟关联与子查询的优化思路类似，都是通过将 LIMIT 操作转移到主键索引树上，减少回表次数。相比直接使用子查询，延迟关联通过 INNER JOIN 将子查询结果集成到主查询中，避免了子查询可能产生的临时表。在执行 INNER JOIN 时，MySQL 优化器能够利用索引进行高效的连接操作（如索引扫描或其他优化策略），因此在深度分页场景下，性能通常优于直接使用子查询。
-- 使用 INNER JOIN 进行延迟关联\nSELECT t1.*\nFROM t_order t1\nINNER JOIN (\n -- 这里的子查询可以利用覆盖索引，性能极高\n SELECT id FROM t_order ORDER BY id LIMIT 1000000, 10\n) t2 ON t1.id = t2.id;工作原理:
\n(SELECT id FROM t_order ORDER BY id LIMIT 1000000, 10) 利用主键索引扫描并跳过前 1000000 条记录，返回目标分页的 10 条记录的 ID。INNER JOIN 将子查询结果与主表 t_order 关联，获取完整的记录数据。除了使用 INNER JOIN 之外，还可以使用逗号连接子查询。
\n-- 使用逗号进行延迟关联\nSELECT t1.* FROM t_order t1,\n(SELECT id FROM t_order ORDER BY id LIMIT 1000000, 10) t2\nWHERE t1.id = t2.id;注意: 虽然逗号连接子查询也能实现类似的效果，但为了代码可读性和可维护性，建议使用更规范的 INNER JOIN 语法。
索引中已经包含了所有需要获取的字段的查询方式称为覆盖索引。
\n覆盖索引的好处：
\n假设建立了 (code, type) 联合索引，下面的查询即可使用覆盖索引：
# 在 InnoDB 中，辅助索引天然包含主键 id\n# 如果只需要查询 id, code, type 这三列，只需建立 (code, type) 的联合索引即可实现覆盖\nSELECT id, code, type FROM t_order\nORDER BY code\nLIMIT 1000000, 10;⚠️注意:
\nFORCE INDEX 强制查询优化器走索引，但这种方式可能会导致查询优化器无法选择更优的执行计划，效果并不总是理想。LIMIT 偏移量过大的 SQL，及时发现问题。long_query_time 阈值捕获深度分页查询。EXPLAIN 定期检查关键分页 SQL 的执行计划，确保优化器按预期使用索引。| 误区 | 事实 |
\n|
高性能系统面试不是问你会不会背几个优化手段，而是看你能不能把请求链路拆开：用户请求进来后，哪里可能慢，哪里可能扛不住，哪里需要削峰，哪里需要减少数据库压力，哪里需要用监控和压测验证效果。
\n这篇文章把 JavaGuide 现有高性能相关文章串成一条面试复习路线，适合准备后端开发、系统设计和架构设计相关面试。
\n高性能问题通常可以按请求链路拆成 4 层：
\n面试回答时，不要一上来就说“加缓存”。更好的方式是先确认场景和指标：QPS 多大、RT 和 P99 要求是多少、读写比例如何、数据量级多大、瓶颈出现在 CPU、I/O、数据库还是外部依赖。只有先判断瓶颈在哪里，后面的方案才不会像硬套模板。
\n入口层优化解决的是“流量怎么更快、更稳地进来”。这一层通常不直接改业务代码，但会明显影响用户访问延迟、源站压力和系统可用性。
\n重点文章：
\n高频面试问题：
\n准备这一部分时，可以把一次页面访问拆成：DNS 解析、CDN 命中、回源、浏览器缓存、静态资源加载。再补上“命中率下降怎么办”“某个机房故障如何摘流量”“负载均衡算法为什么会影响后端压力分布”这类追问，答案会更像真实项目经验。
\n数据库是后端系统最常见的性能瓶颈，也是面试最爱追问的地方。很多高性能方案最终都会落到一个问题上：如何在数据规模变大之后，继续把查询、写入和存储成本控制住。
\n重点文章：
\n\n高频面试问题：
\n数据库优化不要只记方案名。面试官通常会继续问：数据量多大、查询模式是什么、写入压力如何、是否能接受最终一致、迁移成本怎么控制。这些边界决定方案是否靠谱。
\n这一阶段建议重点准备 3 类回答：慢 SQL 如何定位和优化、单库压力太大如何拆、历史数据太多如何迁移和归档。能把这 3 类问题讲清楚，基本就覆盖了大部分数据库性能追问。
\n消息队列的核心价值不是“解耦”两个字，而是让系统在高峰流量下有缓冲、有重试、有异步处理能力。它适合处理“写入突增、下游处理慢、多个系统需要协作”的场景，但也会引入一致性、重复消费和运维复杂度。
\n重点文章：
\n\n高频面试问题：
\n这一部分最重要的是讲清楚“可靠性”。生产环境里，消息系统真正难的不是发出去，而是失败、重复、乱序、积压之后系统还能恢复。
\n复习时不要只比较 Kafka、RocketMQ、RabbitMQ 的概念差异，还要能结合场景说明选择依据：日志采集更看重吞吐，交易链路更看重可靠性和事务语义，普通业务异步化更看重接入成本和运维复杂度。
\n面试里的高性能问题经常以系统设计题出现，比如：
\n回答这类问题时，建议按这个顺序展开：
\n这样回答不会显得像在背八股，而是在做真实系统设计。尤其是社招和中高级岗位，面试官更关注你是否能讲清楚取舍：为什么用这个方案，不用它会发生什么，它会引入什么新问题，后续如何验证和治理。
\n临近面试可以按“先数据层，再消息队列，最后入口层”的顺序复习。原因很简单：数据库优化和消息队列最容易被追问工程细节，入口层更适合放在最后补齐系统设计链路。
\n如果你能把这些内容串成一条完整链路：入口流量如何进来、应用如何削峰、数据库如何减压、消息系统如何兜底、系统效果如何验证，高性能系统设计题就会好答很多。
\n", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "高性能" ] }, { "title": "高性能系统常见面试题总结", "url": "https://codingmap.strova.top/high-performance/high-performance-system-interview-questions.html", "id": "https://codingmap.strova.top/high-performance/high-performance-system-interview-questions.html", "summary": "高性能系统常见面试题总结：涵盖 CDN、负载均衡、读写分离、分库分表、SQL 优化、深度分页、冷热分离、消息队列、Kafka、RocketMQ、RabbitMQ 等核心知识点。重点围绕 高性能基础、数据库性能优化、消息队列、系统设计综合题、高性能 等内容展开。结合 CodingMap 知识体系梳理 高性能 / Hig。", "content_html": "这部分内容摘自 JavaGuide 下面几篇文章的重点：
\n高性能基础：
\n数据库性能优化：
\n\n消息队列：
\n\nCDN（Content Delivery Network，内容分发网络）本质上是把静态资源缓存到离用户更近的边缘节点，用户访问资源时不一定回源站，而是优先从附近 CDN 节点获取。
\n
它能提升访问速度，主要靠两点：
\n典型适合 CDN 缓存的内容包括图片、CSS、JS、字体、下载文件等。HTML 是否缓存要谨慎，尤其是 VuePress/Vite 这类带 hash 静态资源的站点，HTML 长期缓存可能引用到已经不存在的旧资源。
\n面试里如果继续追问“CDN 为什么一定能更快”，可以从 就近接入、边缘缓存、跨运营商优化、源站减压 这 4 个角度回答。它不是让源站本身变快，而是把大量重复请求拦在离用户更近的位置。
\n当 CDN 节点没有缓存用户请求的资源，或者缓存过期时，CDN 节点会向源站请求资源，这个过程叫 回源。
\n回源后，CDN 会根据缓存规则决定是否把资源缓存到边缘节点。后续用户再访问同一个资源时，如果缓存命中，就不需要再访问源站。
\n
面试里可以这样总结：
\n回源并不是坏事，但回源量过大通常说明缓存策略、资源 URL 设计或刷新预热策略有问题。比如资源没有设置合理 Cache-Control、静态资源文件名没有 hash、部署后没有预热热点资源，都可能让 CDN 边缘节点频繁回源。
推荐策略如下：
\n| 资源类型 | 推荐缓存策略 | 原因 |
\n|
负载均衡 指的是将用户请求分摊到不同的服务器上处理，以提高系统整体的并发处理能力以及可靠性。负载均衡服务可以有由专门的软件或者硬件来完成，一般情况下，硬件的性能更好，软件的价格更便宜（后文会详细介绍到）。
\n下图是《Java 面试指北》 「高并发篇」中的一篇文章的配图，从图中可以看出，系统的商品服务部署了多份在不同的服务器上，为了实现访问商品服务请求的分流，我们用到了负载均衡。
\n![\"多服务实例-负载均衡\"](\"https://oss.javaguide.cn/github/javaguide/high-performance/load-balancing/multi-service-load-balancing.drawio.png\")
负载均衡是一种比较常用且实施起来较为简单的提高系统并发能力和可靠性的手段，不论是单体架构的系统还是微服务架构的系统几乎都会用到。
\n负载均衡可以简单分为 服务端负载均衡 和 客户端负载均衡 这两种。
\n服务端负载均衡涉及到的知识点更多，工作中遇到的也比较多，因此，我会花更多时间来介绍。
\n服务端负载均衡 主要应用在 系统外部请求 和 网关层 之间，可以使用 软件 或者 硬件 实现。
\n下图是我画的一个简单的基于 Nginx 的服务端负载均衡示意图：
\n![\"基于](\"https://oss.javaguide.cn/github/javaguide/high-performance/load-balancing/server-load-balancing.png\")
硬件负载均衡 通过专门的硬件设备（比如 F5、A10、Array ）实现负载均衡功能。
\n硬件负载均衡的优势是性能很强且稳定，缺点就是实在是太贵了。像基础款的 F5 最低也要 20 多万，绝大部分公司是根本负担不起的，业务量不大的话，真没必要非要去弄个硬件来做负载均衡，用软件负载均衡就足够了！
\n在我们日常开发中，一般很难接触到硬件负载均衡，接触的比较多的还是 软件负载均衡 。软件负载均衡通过软件（比如 LVS、Nginx、HAproxy ）实现负载均衡功能，性能虽然差一些，但价格便宜啊！像基础款的 Linux 服务器也就几千，性能好一点的 2~3 万的就很不错了。
\n根据 OSI 模型，服务端负载均衡还可以分为：
\n最常见的是四层和七层负载均衡，因此，本文也是重点介绍这两种负载均衡。
\n\n\nNginx 官网对四层负载和七层负载均衡均衡做了详细介绍，感兴趣的可以看看。
\n\n
![\"OSI](\"https://oss.javaguide.cn/github/javaguide/cs-basics/network/osi-7-model.png\")
七层负载均衡比四层负载均衡会消耗更多的性能，不过，也相对更加灵活，能够更加智能地路由网络请求，比如说你可以根据请求的内容进行优化如缓存、压缩、加密。
\n简单来说，四层负载均衡性能很强，七层负载均衡功能更强！ 不过，对于绝大部分业务场景来说，四层负载均衡和七层负载均衡的性能差异基本可以忽略不计的。
\n下面这段话摘自 Nginx 官网的 What Is Layer 4 Load Balancing? 这篇文章。
\n\n\nLayer 4 load balancing was a popular architectural approach to traffic handling when commodity hardware was not as powerful as it is now, and the interaction between clients and application servers was much less complex. It requires less computation than more sophisticated load balancing methods (such as Layer 7), but CPU and memory are now sufficiently fast and cheap that the performance advantage for Layer 4 load balancing has become negligible or irrelevant in most situations.
\n第 4 层负载平衡是一种流行的流量处理体系结构方法，当时商用硬件没有现在这么强大，客户端和应用程序服务器之间的交互也不那么复杂。它比更复杂的负载平衡方法(如第 7 层)需要更少的计算量，但是 CPU 和内存现在足够快和便宜，在大多数情况下，第 4 层负载平衡的性能优势已经变得微不足道或无关紧要。
\n
在工作中，我们通常会使用 Nginx 来做七层负载均衡，LVS(Linux Virtual Server 虚拟服务器， Linux 内核的 4 层负载均衡)来做四层负载均衡。
\n关于 Nginx 的常见知识点总结，《Java 面试指北》 中「技术面试题篇」中已经有对应的内容了，感兴趣的小伙伴可以去看看。
\n![](\"https://oss.javaguide.cn/github/javaguide/image-20220328105759300.png\")
不过，LVS 这个绝大部分公司真用不上，像阿里、百度、腾讯、eBay 等大厂才会使用到，用的最多的还是 Nginx。
\n客户端负载均衡 主要应用于系统内部的不同的服务之间，可以使用现成的负载均衡组件来实现。
\n在客户端负载均衡中，客户端会自己维护一份服务器的地址列表，发送请求之前，客户端会根据对应的负载均衡算法来选择具体某一台服务器处理请求。
\n客户端负载均衡器和服务运行在同一个进程或者说 Java 程序里，不存在额外的网络开销。不过，客户端负载均衡的实现会受到编程语言的限制，比如说 Spring Cloud Load Balancer 就只能用于 Java 语言。
\nJava 领域主流的微服务框架 Dubbo、Spring Cloud 等都内置了开箱即用的客户端负载均衡实现。Dubbo 属于是默认自带了负载均衡功能，Spring Cloud 是通过组件的形式实现的负载均衡，属于可选项，比较常用的是 Spring Cloud Load Balancer（官方，推荐） 和 Ribbon（Netflix，已被弃用）。
\n下图是我画的一个简单的基于 Spring Cloud Load Balancer（Ribbon 也类似） 的客户端负载均衡示意图：
\n![](\"https://oss.javaguide.cn/github/javaguide/high-performance/load-balancing/spring-cloud-lb-gateway.png\")
随机法 是最简单粗暴的负载均衡算法。
\n如果没有配置权重的话，所有的服务器被访问到的概率都是相同的。如果配置权重的话，权重越高的服务器被访问的概率就越大。
\n未加权重的随机算法适合于服务器性能相近的集群，其中每个服务器承载相同的负载。加权随机算法适合于服务器性能不等的集群，权重的存在可以使请求分配更加合理化。
\n不过，随机算法有一个比较明显的缺陷：部分机器在一段时间之内无法被随机到，毕竟是概率算法，就算是大家权重一样， 也可能会出现这种情况。
\n于是，轮询法 来了！
\n轮询法是挨个轮询服务器处理，也可以设置权重。
\n如果没有配置权重的话，每个请求按时间顺序逐一分配到不同的服务器处理。如果配置权重的话，权重越高的服务器被访问的次数就越多。
\n未加权重的轮询算法适合于服务器性能相近的集群，其中每个服务器承载相同的负载。加权轮询算法适合于服务器性能不等的集群，权重的存在可以使请求分配更加合理化。
\n在加权轮询的基础上，还有进一步改进得到的负载均衡算法，比如平滑的加权轮训算法。
\n平滑的加权轮训算法最早是在 Nginx 中被实现，可以参考这个 commit：https://github.com/phusion/nginx/commit/27e94984486058d73157038f7950a0a36ecc6e35。如果你认真学习过 Dubbo 负载均衡策略的话，就会发现 Dubbo 的加权轮询就借鉴了该算法实现并进一步做了优化。
\n![\"Dubbo](\"https://oss.javaguide.cn/github/javaguide/high-performance/load-balancing/dubbo-round-robin-load-balance.png\")
两次随机法在随机法的基础上多增加了一次随机，多选出一个服务器。随后再根据两台服务器的负载等情况，从其中选择出一个最合适的服务器。
\n两次随机法的好处是可以动态地调节后端节点的负载，使其更加均衡。如果只使用一次随机法，可能会导致某些服务器过载，而某些服务器空闲。
\n将请求的参数信息通过哈希函数转换成一个哈希值，然后根据哈希值来决定请求被哪一台服务器处理。
\n在服务器数量不变的情况下，相同参数的请求总是发到同一台服务器处理，比如同个 IP 的请求、同一个用户的请求。
\n和哈希法类似，一致性 Hash 法也可以让相同参数的请求总是发到同一台服务器处理。不过，它解决了哈希法存在的一些问题。
\n常规哈希法在服务器数量变化时，哈希值会重新落在不同的服务器上，这明显违背了使用哈希法的本意。而一致性哈希法的核心思想是将数据和节点都映射到一个哈希环上，然后根据哈希值的顺序来确定数据属于哪个节点。当服务器增加或删除时，只影响该服务器的哈希，而不会导致整个服务集群的哈希键值重新分布。
\n当有新的请求出现时，遍历服务器节点列表并选取其中连接数最小的一台服务器来响应当前请求。相同连接的情况下，可以进行加权随机。
\n最少连接数基于一个服务器连接数越多，负载就越高这一理想假设。然而， 实际情况是连接数并不能代表服务器的实际负载，有些连接耗费系统资源更多，有些连接不怎么耗费系统资源。
\n最少活跃法和最小连接法类似，但要更科学一些。最少活跃法以活动连接数为标准，活动连接数可以理解为当前正在处理的请求数。活跃数越低，说明处理能力越强，这样就可以使处理能力强的服务器处理更多请求。相同活跃数的情况下，可以进行加权随机。
\n不同于最小连接法和最少活跃法，最快响应时间法以响应时间为标准来选择具体是哪一台服务器处理。客户端会维持每个服务器的响应时间，每次请求挑选响应时间最短的。相同响应时间的情况下，可以进行加权随机。
\n这种算法可以使得请求被更快处理，但可能会造成流量过于集中于高性能服务器的问题。
\n简单介绍两种项目中常用的七层负载均衡解决方案：DNS 解析和反向代理。
\n除了我介绍的这两种解决方案之外，HTTP 重定向等手段也可以用来实现负载均衡，不过，相对来说，还是 DNS 解析和反向代理用的更多一些，也更推荐一些。
\nDNS 解析是比较早期的七层负载均衡实现方式，非常简单。
\nDNS 解析实现负载均衡的原理是这样的：在 DNS 服务器中为同一个主机记录配置多个 IP 地址，这些 IP 地址对应不同的服务器。当用户请求域名的时候，DNS 服务器采用轮询算法返回 IP 地址，这样就实现了轮询版负载均衡。
\n![](\"https://oss.javaguide.cn/github/javaguide/high-performance/load-balancing/6997605302452f07e8b28d257d349bf0.png\")
现在的 DNS 解析几乎都支持 IP 地址的权重配置，这样的话，在服务器性能不等的集群中请求分配会更加合理化。像我自己目前正在用的阿里云 DNS 就支持权重配置。
\n![](\"https://oss.javaguide.cn/github/javaguide/aliyun-dns-weight-setting.png\")
客户端将请求发送到反向代理服务器，由反向代理服务器去选择目标服务器，获取数据后再返回给客户端。对外暴露的是反向代理服务器地址，隐藏了真实服务器 IP 地址。反向代理“代理”的是目标服务器，这一个过程对于客户端而言是透明的。
\nNginx 就是最常用的反向代理服务器，它可以将接收到的客户端请求以一定的规则（负载均衡策略）均匀地分配到这个服务器集群中所有的服务器上。
\n反向代理负载均衡同样属于七层负载均衡。
\n![](\"https://oss.javaguide.cn/github/javaguide/nginx-load-balance.png\")
我们上面也说了，客户端负载均衡可以使用现成的负载均衡组件来实现。
\nNetflix Ribbon 和 Spring Cloud Load Balancer 就是目前 Java 生态最流行的两个负载均衡组件。
\nRibbon 是老牌负载均衡组件，由 Netflix 开发，功能比较全面，支持的负载均衡策略也比较多。 Spring Cloud Load Balancer 是 Spring 官方为了取代 Ribbon 而推出的，功能相对更简单一些，支持的负载均衡也少一些。
\nRibbon 支持的 7 种负载均衡策略：
\nRandomRule：随机策略。RoundRobinRule（默认）：轮询策略WeightedResponseTimeRule：权重（根据响应时间决定权重）策略BestAvailableRule：最小连接数策略RetryRule：重试策略（按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null）AvailabilityFilteringRule：可用敏感性策略（先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例）ZoneAvoidanceRule：区域敏感性策略（根据服务所在区域的性能和服务的可用性来选择服务实例）Spring Cloud Load Balancer 支持的 2 种负载均衡策略：
\nRandomLoadBalancer：随机策略RoundRobinLoadBalancer（默认）：轮询策略public class CustomLoadBalancerConfiguration {\n\n @Bean\n ReactorLoadBalancer<ServiceInstance> randomLoadBalancer(Environment environment,\n LoadBalancerClientFactory loadBalancerClientFactory) {\n String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);\n return new RandomLoadBalancer(loadBalancerClientFactory\n .getLazyProvider(name, ServiceInstanceListSupplier.class),\n name);\n }\n}不过，Spring Cloud Load Balancer 支持的负载均衡策略其实不止这两种，ServiceInstanceListSupplier 的实现类同样可以让其支持类似于 Ribbon 的负载均衡策略。这个应该是后续慢慢完善引入的，不看官方文档还真发现不了，所以说阅读官方文档真的很重要！
这里举两个官方的例子：
\nZonePreferenceServiceInstanceListSupplier：实现基于区域的负载平衡HintBasedServiceInstanceListSupplier：实现基于 hint 提示的负载均衡public class CustomLoadBalancerConfiguration {\n // 使用基于区域的负载平衡方法\n @Bean\n public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(\n ConfigurableApplicationContext context) {\n return ServiceInstanceListSupplier.builder()\n .withDiscoveryClient()\n .withZonePreference()\n .withCaching()\n .build(context);\n }\n}关于 Spring Cloud Load Balancer 更详细更新的介绍，推荐大家看看官方文档：https://docs.spring.io/spring-cloud-commons/docs/current/reference/html/#spring-cloud-loadbalancer ，一切以官方文档为主。
\n轮询策略基本可以满足绝大部分项目的需求，我们的实际项目中如果没有特殊需求的话，通常使用的就是默认的轮询策略。并且，Ribbon 和 Spring Cloud Load Balancer 都支持自定义负载均衡策略。
\n个人建议如非必需 Ribbon 某个特有的功能或者负载均衡策略的话，就优先选择 Spring 官方提供的 Spring Cloud Load Balancer。
\n最后再说说为什么我不太推荐使用 Ribbon 。
\nSpring Cloud 2020.0.0 版本移除了 Netflix 除 Eureka 外的所有组件。Spring Cloud Hoxton.M2 是第一个支持 Spring Cloud Load Balancer 来替代 Netfix Ribbon 的版本。
\n我们早期学习微服务，肯定接触过 Netflix 公司开源的 Feign、Ribbon、Zuul、Hystrix、Eureka 等知名的微服务系统构建所必须的组件，直到现在依然有非常非常多的公司在使用这些组件。不夸张地说，Netflix 公司引领了 Java 技术栈下的微服务发展。
\n![](\"https://oss.javaguide.cn/github/javaguide/SpringCloudNetflix.png\")
那为什么 Spring Cloud 这么急着移除 Netflix 的组件呢？ 主要是因为在 2018 年的时候，Netflix 宣布其开源的核心组件 Hystrix、Ribbon、Zuul、Eureka 等进入维护状态，不再进行新特性开发，只修 BUG。于是，Spring 官方不得不考虑移除 Netflix 的组件。
\nSpring Cloud Alibaba 是一个不错的选择，尤其是对于国内的公司和个人开发者来说。
\n顾名思义，根据读写分离的名字，我们就可以知道：读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 这样的话，就能够小幅提升写性能，大幅提升读性能。
\n我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。
\n![\"读写分离示意图\"](\"https://oss.javaguide.cn/github/javaguide/high-performance/read-and-write-separation-and-library-subtable/read-and-write-separation.png\")
一般情况下，我们都会选择一主多从，也就是一台主数据库负责写，其他的从数据库负责读。主库和从库之间会进行数据同步，以保证从库中数据的准确性。这样的架构实现起来比较简单，并且也符合系统的写少读多的特点。
\n不论是使用哪一种读写分离具体的实现方案，想要实现读写分离一般包含如下几步：
\n落实到项目本身的话，常用的方式有两种：
\n1. 代理方式
\n![\"代理方式实现读写分离\"](\"https://oss.javaguide.cn/github/javaguide/high-performance/read-and-write-separation-and-library-subtable/read-and-write-separation-proxy.png\")
我们可以在应用和数据中间加了一个代理层。应用程序所有的数据请求都交给代理层处理，代理层负责分离读写请求，将它们路由到对应的数据库中。
\n提供类似功能的中间件有 MySQL Router（官方， MySQL Proxy 的替代方案）、Atlas（基于 MySQL Proxy）、MaxScale、MyCat。
\n关于 MySQL Router 多提一点：在 MySQL 8.2 的版本中，MySQL Router 能自动分辨对数据库读写/操作并把这些操作路由到正确的实例上。这是一项有价值的功能，可以优化数据库性能和可扩展性，而无需在应用程序中进行任何更改。具体介绍可以参考官方博客：MySQL 8.2 – transparent read/write splitting。
\n2. 组件方式
\n在这种方式中，我们可以通过引入第三方组件来实现读写请求的路由。
\n这也是我比较推荐的一种方式。这种方式目前在各种互联网公司中用的最多的，相关的实际的案例也非常多。如果你要采用这种方式的话，推荐使用 ShardingSphere-JDBC ，直接引入 jar 包即可使用，非常方便。同时，也节省了很多运维的成本。
\n你可以在 ShardingSphere 官方找到 ShardingSphere-JDBC 读写分离配置。
\nMySQL binlog(binary log 即二进制日志文件) 主要记录了 MySQL 数据库中数据的所有变化(数据库执行的所有 DDL 和 DML 语句)。因此，我们根据主库的 MySQL binlog 日志就能够将主库的数据同步到从库中。
\n更具体和详细的过程是这个样子的（图片来自于：《MySQL Master-Slave Replication on the Same Machine》）：
\n![\"MySQL主从复制\"](\"https://oss.javaguide.cn/java-guide-blog/78816271d3ab52424bfd5ad3086c1a0f.png\")
怎么样？看了我对主从复制这个过程的讲解，你应该搞明白了吧!
\n你一般看到 binlog 就要想到主从复制。当然，除了主从复制之外，binlog 还能帮助我们实现数据恢复。
\n🌈 拓展一下：
\n不知道大家有没有使用过阿里开源的一个叫做 canal 的工具。这个工具可以帮助我们实现 MySQL 和其他数据源比如 Elasticsearch 或者另外一台 MySQL 数据库之间的数据同步。很显然，这个工具的底层原理肯定也是依赖 binlog。canal 的原理就是模拟 MySQL 主从复制的过程，解析 binlog 将数据同步到其他的数据源。
\n另外，像咱们常用的分布式缓存组件 Redis 也是通过主从复制实现的读写分离。
\n🌕 简单总结一下：
\nMySQL 主从复制是依赖于 binlog 。另外，常见的一些同步 MySQL 数据到其他数据源的工具（比如 canal）的底层一般也是依赖 binlog 。
\n读写分离对于提升数据库的并发非常有效，但是，同时也会引来一个问题：主库和从库的数据存在延迟，比如你写完主库之后，主库的数据同步到从库是需要时间的，这个时间差就导致了主库和从库的数据不一致性问题。这也就是我们经常说的 主从同步延迟 。
\n如果我们的业务场景无法容忍主从同步延迟的话，应该如何避免呢（注意：我这里说的是避免而不是减少延迟）？
\n这里提供两种我知道的方案（能力有限，欢迎补充），你可以根据自己的业务场景参考一下。
\n对于极少数必须强一致的业务（如支付后立刻查询余额），可以通过 Hint 强制查主库。
\n// ShardingSphere-JDBC 强制读主库\nHintManager hintManager = HintManager.getInstance();\nhintManager.setMasterRouteOnly();\n// 继续JDBC操作\n\n⚠️ 注意：严禁大范围使用此方案！读写分离的初衷就是为了分担主库的读压力，若大量读请求因延迟而回退到主库，在促销、秒杀等高并发场景下极易压垮主库导致全站宕机。正确的 Trade-off：仅核心强一致链路读主库，非核心链路必须在业务层容忍最终一致性（如页面提示"数据同步中"）。
\n
HintManager hintManager = HintManager.getInstance();\nhintManager.setMasterRouteOnly();\n// 继续JDBC操作对于这种方案，你可以将那些必须获取最新数据的读请求都交给主库处理。
\n还有一些朋友肯定会想既然主从同步存在延迟，那我就在延迟之后读取啊，比如主从同步延迟 0.5s,那我就 1s 之后再读取数据。这样多方便啊！方便是方便，但是也很扯淡。
\n不过，如果你是这样设计业务流程就会好很多：对于一些对数据比较敏感的场景，你可以在完成写请求之后，避免立即进行请求操作。比如你支付成功之后，跳转到一个支付成功的页面，当你点击返回之后才返回自己的账户。
\n关于如何避免主从延迟，我们这里介绍了两种方案。实际上，延迟读取这种方案没办法完全避免主从延迟，只能说可以减少出现延迟的概率而已，实际项目中一般不会使用。
\n总的来说，要想不出现延迟问题，一般还是要强制将那些必须获取最新数据的读请求都交给主库处理。如果你的项目的大部分业务场景对数据准确性要求不是那么高的话，这种方案还是可以选择的。
\n我们在上面的内容中也提到了主从延迟以及避免主从延迟的方法，这里我们再来详细分析一下主从延迟出现的原因以及应该如何尽量减少主从延迟。
\n要搞懂什么情况下会出现主从延迟，我们需要先搞懂什么是主从延迟。
\nMySQL 主从同步延时是指从库的数据落后于主库的数据，这种情况可能由以下两个原因造成：
\n与主从同步有关的时间点主要有 3 个：
\n\n\n注意：上述描述基于 MySQL 默认的异步复制模式。如果在 MySQL 5.7+ 开启了增强半同步复制（
\nrpl_semi_sync_master_wait_point=AFTER_SYNC），主库在写入 binlog 后会等待至少一个从库接收并写入 relay log 才向客户端返回提交成功，这在一定程度上将 T2-T1 的网络传输时间算入了主库事务的响应时间中，从而牺牲写性能换取更高的数据安全性。
结合我们上面讲到的主从复制原理，可以得出：
\n那什么情况下会出现出从延迟呢？这里列举几种常见的情况：
\nslave_parallel_type=DATABASE）。MySQL 5.7 进一步完善，支持按组提交并行（slave_parallel_type=LOGICAL_CLOCK），大幅提升并行效率。建议在从库配置 slave_parallel_workers > 0 启用并行复制。读写分离主要应对的是数据库读并发，没有解决数据库存储问题。试想一下：如果 MySQL 一张表的数据量过大怎么办?
\n换言之，我们该如何解决 MySQL 的存储压力呢？
\n答案之一就是 分库分表。
\n分库 就是将数据库中的数据分散到不同的数据库上，可以垂直分库，也可以水平分库。
\n垂直分库 就是把单一数据库按照业务进行划分，不同的业务使用不同的数据库，进而将一个数据库的压力分担到多个数据库。
\n举个例子：说你将数据库中的用户表、订单表和商品表分别单独拆分为用户数据库、订单数据库和商品数据库。
\n\n水平分库 是把同一个表按一定规则拆分到不同的数据库中，每个库可以位于不同的服务器上，这样就实现了水平扩展，解决了单表的存储和性能瓶颈的问题。
\n举个例子：订单表数据量太大，你对订单表进行了水平切分（水平分表），然后将切分后的 2 张订单表分别放在两个不同的数据库。
\n\n分表 就是对单表的数据进行拆分，可以是垂直拆分，也可以是水平拆分。
\n垂直分表 是对数据表列的拆分，把一张列比较多的表拆分为多张表。
\n举个例子：我们可以将用户信息表中的一些列单独抽出来作为一个表。
\n水平分表 是对数据表行的拆分，把一张行比较多的表拆分为多张表，可以解决单一表数据量过大的问题。
\n举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。
\n水平拆分只能解决单表数据量大的问题，为了提升性能，我们通常会选择将拆分后的多张表放在不同的数据库中。也就是说，水平分表通常和水平分库同时出现。
\n\n遇到下面几种场景可以考虑分库分表：
\n不过，分库分表的成本太高，如非必要尽量不要采用。而且，并不一定是单表千万级数据量就要分表，毕竟每张表包含的字段不同，它们在不错的性能下能够存放的数据量也不同，还是要具体情况具体分析。
\n之前看过一篇文章分析 “InnoDB 中高度为 3 的 B+ 树最多可以存多少数据”，写的挺不错，感兴趣的可以看看。
\n分片算法主要解决了数据被水平分片之后，数据究竟该存放在哪个表的问题。
\n常见的分片算法有：
\nid 为 1~299999 的记录分到第一个表， 300000~599999 的分到第二个表。范围分片适合需要经常进行范围查找且数据分布均匀的场景，不太适合随机读写的场景（数据未被分散，容易出现热点数据的问题）。在上述基础算法之上，还可以结合业务衍生出更复杂的路由策略：
\n分片键（Sharding Key）是数据分片的关键字段。分片键的选择非常重要，它关系着数据的分布和查询效率。一般来说，分片键应该具备以下特点：
\n实际项目中，分片键很难满足上面提到的所有特点，需要权衡一下。并且，分片键可以是表中多个字段的组合，例如取用户 ID 后四位作为订单 ID 后缀。
\n记住，你在公司做的任何技术决策，不光是要考虑这个技术能不能满足我们的要求，是否适合当前业务场景，还要重点考虑其带来的成本。
\n引入分库分表之后，会给系统带来什么挑战呢？
\n另外，引入分库分表之后，一般需要 DBA 的参与，同时还需要更多的数据库服务器，这些都属于成本。
\nApache ShardingSphere 是一款分布式的数据库生态系统， 可以将任意数据库转换为分布式数据库，并通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。
\nShardingSphere 项目（包括 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar）是当当捐入 Apache 的，目前主要由京东数科的一些巨佬维护。
\nShardingSphere 绝对可以说是当前分库分表的首选！ShardingSphere 的功能完善，除了支持读写分离和分库分表，还提供分布式事务、数据库治理、影子库、数据加密和脱敏等功能。
\nShardingSphere 提供的功能如下：
\n![\"ShardingSphere](\"https://oss.javaguide.cn/github/javaguide/high-performance/shardingsphere-features.png\")
ShardingSphere 的优势如下（摘自 ShardingSphere 官方文档：https://shardingsphere.apache.org/document/current/cn/overview/）：
\n另外，ShardingSphere 的生态体系完善，社区活跃，文档完善，更新和发布比较频繁。
\n不过，还是要多提一句：现在很多公司都是用的类似于 TiDB 这种分布式关系型数据库，不需要我们手动进行分库分表（数据库层面已经帮我们做了），也不需要解决手动分库分表引入的各种问题，直接一步到位，内置很多实用的功能（如无感扩容和缩容、冷热存储分离）！如果公司条件允许的话，个人也是比较推荐这种方式！
\n分库分表之后，我们如何将老库（单库单表）的数据迁移到新库（分库分表后的数据库系统）呢？
\n比较简单同时也是非常常用的方案就是停机迁移，写个脚本老库的数据写到新库中。比如你在凌晨 2 点，系统使用的人数非常少的时候，挂一个公告说系统要维护升级预计 1 小时。然后，你写一个脚本将老库的数据都同步到新库中。
\n如果你不想停机迁移数据的话，也可以考虑双写方案。双写方案是针对那种不能停机迁移的场景，实现起来要稍微麻烦一些。具体原理是这样的：
\n\n\n⚠️注意：
\n\n
\n- 双写应尽量保证原子性：可以先写老库成功后再异步写新库，若新库写入失败则记录日志待重试；
\n- 数据比对应在业务低峰期进行，避免比对期间新写入导致的数据不一致；
\n- 建议借助 Canal 等工具监听 binlog 实现增量同步，降低双写的开发和维护成本。
\n双写并发问题如何解决？ 在存量数据迁移和增量双写并行的阶段，极易发生旧数据覆盖新数据的并发问题。必须在新库表中引入
\nupdate_time或version字段，无论是双写还是脚本补齐，写入新库前必须带上条件WHERE new_version < old_version（乐观锁校验），确保只有较新的数据才能写入。
想要在项目中实施双写还是比较麻烦的，很容易会出现问题。我们可以借助上面提到的数据库同步工具 Canal 做增量数据迁移（还是依赖 binlog，开发和维护成本较低）。
\nSELECT * 会消耗更多的 CPU。SELECT * 无用字段增加网络带宽资源消耗，增加数据传输时间，尤其是大字段（如 varchar、blob、text）。SELECT * 无法使用 MySQL 优化器覆盖索引的优化（基于 MySQL 优化器的“覆盖索引”策略又是速度极快，效率极高，业界极为推荐的查询优化方式）SELECT <字段列表> 可减少表结构变更带来的影响。阿里巴巴《Java 开发手册》中有这样一段描述：
\n\n\n【强制】超过三个表禁止 join。需要 join 的字段，数据类型保持绝对一致;多表关联查询时，保证被关联 的字段需要有索引。
\n
![\"尽量避免多表做](\"https://oss.javaguide.cn/github/javaguide/mysql/alibaba-java-development-handbook-multi-table-join.png\")
join 的效率比较低，主要原因是因为其使用嵌套循环（Nested Loop）来实现关联查询，以前常见的实现效率都不是很高：
\n实际业务场景避免多表 join 常见的做法有两种：
\n更加推荐第一种，这种在实际项目中的使用率比较高，除了性能不错之外，还有如下优势：
\n不过，如果系统要求的并发量不大的话，我觉得多表 join 也是没问题的。很多公司内部复杂的系统，要求的并发量不高，很多数据必须 join 5 张以上的表才能查出来。
\n深度分页问题的根本原因在于：当 LIMIT 的偏移量过大时，MySQL 需要扫描并跳过大量记录才能获取目标数据，查询优化器可能放弃索引而选择全表扫描。此时即使有索引，也无法避免大量的回表操作，导致查询性能急剧下降。
本文介绍了四种常见的深度分页优化方案，各方案的特点及适用场景对比如下：
\n| 优化方案 | 核心思路 | 适用场景 | 限制 |
\n|
这份 高质量技术文章精选 收录程序员成长、工作经验、面试复盘、职业选择和技术学习方法相关内容。它不是具体技术点清单，更适合在学习、求职、入职、转岗、晋升等阶段反复阅读。
\n如果你时间有限，建议先看 程序员如何快速学习新技术 和 从面试官和候选者的角度谈如何准备技术初试，一个解决学习方法，一个解决面试准备。
\n这份 Java 知识体系 面向 Java 后端学习和面试复习，按“基础语法 -> 集合容器 -> 并发编程 -> IO/NIO -> JVM -> 新特性”的顺序整理本站 Java 相关文章。
\n如果你时间有限，建议先看 Java 基础、集合、并发和 JVM 的面试题总结，快速建立高频问题清单；如果你想系统补基础，可以按下面的专题顺序阅读。
\nString、StringBuilder、StringBuffer 有什么区别？equals() 和 hashCode() 有什么关系？ArrayList 和 LinkedList 如何选择？HashMap 为什么线程不安全？ConcurrentHashMap 在 JDK 7 和 JDK 8 中有什么变化？synchronized 和 ReentrantLock 有什么区别？Executors？这份 Java 开源项目精选 面向 Java 后端学习、项目实战和工具选型，整理 GitHub 和 Gitee 上优质的 Java 开源项目、教程资料、工具库和开发工具。
\n内容来自开源项目 CodingDocs/awesome-java，可以看作是 awesome-java 的中文本土版本，项目类型更全面，也加入了更多中文开源项目。欢迎在项目 issues 区 推荐你认可的 Java 开源项目。
\n很多小伙伴私下问我：现在 AI 这么火，咱们写 Java 的是不是只能在旁边看戏？
\n说实话，以前确实有点难受。 毕竟主流的 AI 框架大多是 Python 的天下。但现在，时代变了！随着 Spring AI 以及各种 Java AI 框架的爆发，咱们 Java 开发者完全可以像平时写 CRUD 一样，优雅地把大模型集成到应用里。
\n今天就带大家盘点一下，目前 Java 生态里最硬核的几个 AI 框架。
\nSpring AI 是 Spring 官方亲自下场打造的 AI 应用开发框架 。它的核心哲学非常直观：将 AI 能力无缝集成到 Spring 生态中 。
\n对于习惯了 Spring Boot 的开发者来说，这玩意儿几乎没有学习门槛。它提供了一套构建 AI 应用所需的“底层原子能力抽象” ：
\nVectorStore 等抽象，方便地实现 RAG 模式，将外部知识库与模型结合，提升回答的准确性和时效性。官方文档：https://spring.io/projects/spring-ai#learn。
\nSpring AI Alibaba 集成 Spring AI 生态，它是一个专为多智能体系统和工作流编排设计的项目。项目从架构上包含如下三层：
\n![\"Spring](\"https://oss.javaguide.cn/github/javaguide/open-source-project/ai/springai-alibaba-architecture-new.png\")
另外它还有非常“工程化”的组件：
\n官方文档：https://java2ai.com/。
\n如果说 Spring AI 是官方正规军，那 LangChain4j 就是目前社区里非常强势的 Java LLM 框架，它是 LangChain 的 Java 版本。
\n它的优势在于功能全面，各种大模型的适配速度快得离谱，但在 Spring 体系里总有一种“外来客”的违和感。
\n如果你追求“多模型快速切换 + 能力覆盖面广 + 原型推进快”，LangChain4j 通常是第一梯队选择；代价是你需要自己在工程结构、治理、可观测、平台化上多做一点“工程化拼装”。
\n官方文档：https://docs.langchain4j.dev/。
\nAgentScope 是一个多智能体框架，旨在提供一种简单高效的方式来构建基于大语言模型的智能体应用程序。
\n如果说大模型（LLM）是 AI 应用的大脑，那么 AgentScope 就是它的“中枢神经系统”和“手脚”。它不仅提供了多智能体协作的架构，还内置了 ReAct 推理、工具调用、记忆管理等核心能力。
\nAgentScope 提供了 Python 和 Java 版本，二者核心能力完全对齐！
\nAgentScope 也是阿里开源的，那和 Spring AI Alibaba 有何不同呢？
\n官方文档：https://java.agentscope.io/zh/intro.html。
\n| 框架名称 | 核心特点 | 适用场景 |
\n|
下面这几个项目都是非常适合 Spring Boot 初学者学习的，下面的大部分项目的总体代码架构我都看过，个人觉得还算不错，不会误导没有实际做过项目的朋友。
\n下面的商城系统大多比较复杂比如 mall ,如果没有 Java 基础和 Spring Boot 都还没有摸熟的话不推荐过度研究下面几个项目或者使用这些项目当作毕业设计。
\nSet，SortedSet，Map，List，Queue，Deque 等）、分布式锁等。详细介绍请看：Redisson 项目介绍。其他：Flinkx （基于 Flink 的分布式数据同步工具）。
\n相关阅读：
\nquartz 开发的，比如当当网的elastic-job就是基于quartz二次开发之后的分布式调度解决方案相关阅读：Skywalking 官网对于主流开源链路追踪系统的对比
\nCompletableFuture ，可以解决任意的多线程并行、串行、阻塞、依赖、回调的并行框架，可以任意组合各线程的执行顺序，带全链路执行结果回调。分布式队列：
\n内存队列：
\n分布式限流：
\n相关阅读：Sentinel 与 Hystrix 的对比。
\n单机限流：
\ngetter、setter、equals、hashCode、toString 方法，以及构造器、日志变量等内容。Multimap（多值映射）、Multiset（多重集合）、BiMap（双向映射）和不可变集合，此外还包含图形处理库和并发工具。Guava 还支持 I/O 操作、哈希算法、字符串处理、缓存等多种实用功能。对于简单的 PDF 创建需求，OpenPDF 是一个不错的选择，它开源免费，API 简单易用。对于需要解析、转换和提取文本等操作的复杂场景，可以选择 Apache PDFBox。当然了，复杂场景如果不介意 LGPL 许可也可以选择 iText。
\nBuffers、Lists、Maps、Scalable Timer Wheel……）和实用方法。开源的数据库建模工具比较少，以下是一些非开源的数据库建模工具（部分需要付费才能使用） :
\n相关文章：GitHub 点赞接近 100k 的 SpringBoot 学习教程+实战推荐！牛批！
\n相关文章：GitHub 点赞接近 70k 的 Spring Cloud 学习教程+实战项目推荐！牛批！
\n在 Java Web 程序中，Servlet主要负责接收用户请求 HttpServletRequest,在doGet(),doPost()中做相应的处理，并将回应HttpServletResponse反馈给用户。Servlet 可以设置初始化参数，供 Servlet 内部使用。一个 Servlet 类只会有一个实例，在它初始化时调用init()方法，销毁时调用destroy()方法。Servlet 需要在 web.xml 中配置（MyEclipse 中创建 Servlet 会自动配置），一个 Servlet 可以设置多个 URL 访问。Servlet 不是线程安全，因此要谨慎使用类变量。
1，需要为每个请求启动一个操作 CGI 程序的系统进程。如果请求频繁，这将会带来很大的开销。
\n2，需要为每个请求加载和运行一个 CGI 程序，这将带来很大的开销
\n3，需要重复编写处理网络协议的代码以及编码，这些工作都是非常耗时的。
\n1，只需要启动一个操作系统进程以及加载一个 JVM，大大降低了系统的开销
\n2，如果多个请求需要做同样处理的时候，这时候只需要加载一个类，这也大大降低了开销
\n3，所有动态加载的类可以实现对网络协议以及请求解码的共享，大大降低了工作量。
\n4，Servlet 能直接和 Web 服务器交互，而普通的 CGI 程序不能。Servlet 还能在各个程序之间共享数据，使数据库连接池之类的功能很容易实现。
\n补充：Sun Microsystems 公司在 1996 年发布 Servlet 技术就是为了和 CGI 进行竞争，Servlet 是一个特殊的 Java 程序，一个基于 Java 的 Web 应用通常包含一个或多个 Servlet 类。Servlet 不能够自行创建并执行，它是在 Servlet 容器中运行的，容器将用户的请求传递给 Servlet 程序，并将 Servlet 的响应回传给用户。通常一个 Servlet 会关联一个或多个 JSP 页面。以前 CGI 经常因为性能开销上的问题被诟病，然而 Fast CGI 早就已经解决了 CGI 效率上的问题，所以面试的时候大可不必信口开河的诟病 CGI，事实上有很多你熟悉的网站都使用了 CGI 技术。
\n参考：《javaweb 整合开发王者归来》P7
\nServlet 接口定义了 5 个方法，其中前三个方法与 Servlet 生命周期相关：
\nvoid init(ServletConfig config) throws ServletExceptionvoid service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOExceptionvoid destroy()java.lang.String getServletInfo()ServletConfig getServletConfig()生命周期： Web 容器加载 Servlet 并将其实例化后，Servlet 生命周期开始，容器运行其init()方法进行 Servlet 的初始化；请求到达时调用 Servlet 的service()方法，service()方法会根据需要调用与请求对应的doGet 或 doPost等方法；当服务器关闭或项目被卸载时服务器会将 Servlet 实例销毁，此时会调用 Servlet 的destroy()方法。init 方法和 destroy 方法只会执行一次，service 方法客户端每次请求 Servlet 都会执行。Servlet 中有时会用到一些需要初始化与销毁的资源，因此可以把初始化资源的代码放入 init 方法中，销毁资源的代码放入 destroy 方法中，这样就不需要每次处理客户端的请求都要初始化与销毁资源。
\n参考：《javaweb 整合开发王者归来》P81
\n这个问题在知乎上被讨论的挺火热的，地址：https://www.zhihu.com/question/28586791 。
\n![](\"https://static001.geekbang.org/infoq/04/0454a5fff1437c32754f1dfcc3881148.png\")
GET 和 POST 是 HTTP 协议中两种常用的请求方法，它们在不同的场景和目的下有不同的特点和用法。一般来说，可以从以下几个方面来区分它们：
\n重点搞清了，两者在语义上的区别即可。不过，也有一些项目所有的请求都用 POST，这个并不是固定的，项目组达成共识即可。
\nForm 标签里的 method 的属性为 get 时调用 doGet()，为 post 时调用 doPost()。
\n转发是服务器行为，重定向是客户端行为。
\n转发（Forward）
\n通过 RequestDispatcher 对象的 forward（HttpServletRequest request,HttpServletResponse response）方法实现的。RequestDispatcher 可以通过 HttpServletRequest 的 getRequestDispatcher()方法获得。例如下面的代码就是跳转到 login_success.jsp 页面。
request.getRequestDispatcher(\"login_success.jsp\").forward(request, response);重定向（Redirect） 是利用服务器返回的状态码来实现的。客户端浏览器请求服务器的时候，服务器会返回一个状态码。服务器通过 HttpServletResponse 的 setStatus(int status) 方法设置状态码。如果服务器返回 301 或者 302，则浏览器会到新的网址重新请求该资源。
从地址栏显示来说
\nforward 是服务器请求资源,服务器直接访问目标地址的 URL,把那个 URL 的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址.
\nredirect 是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的 URL.
从数据共享来说
\nforward:转发页面和转发到的页面可以共享 request 里面的数据.
\nredirect:不能共享数据.
从运用地方来说
\nforward:一般用于用户登陆的时候,根据角色转发到相应的模块.
\nredirect:一般用于用户注销登陆时返回主页面和跳转到其它的网站等
从效率来说
\nforward:高.
\nredirect:低.
自动刷新不仅可以实现一段时间之后自动跳转到另一个页面，还可以实现一段时间之后自动刷新本页面。Servlet 中通过 HttpServletResponse 对象设置 Header 属性实现自动刷新例如：
\nResponse.setHeader(\"Refresh\",\"5;URL=http://localhost:8080/servlet/example.htm\");其中 5 为时间，单位为秒。URL 指定就是要跳转的页面（如果设置自己的路径，就会实现每过 5 秒自动刷新本页面一次）
\nServlet 不是线程安全的，多线程并发的读写会导致数据不同步的问题。 解决的办法是尽量不要定义 name 属性，而是要把 name 变量分别定义在 doGet()和 doPost()方法内。虽然使用 synchronized(name){}语句块可以解决问题，但是会造成线程的等待，不是很科学的办法。
\n注意：多线程的并发的读写 Servlet 类属性会导致数据不同步。但是如果只是并发地读取属性而不写入，则不存在数据不同步的问题。因此 Servlet 里的只读属性最好定义为 final 类型的。
参考：《javaweb 整合开发王者归来》P92
\n其实这个问题在上面已经阐述过了，Servlet 是一个特殊的 Java 程序，它运行于服务器的 JVM 中，能够依靠服务器的支持向浏览器提供显示内容。JSP 本质上是 Servlet 的一种简易形式，JSP 会被服务器处理成一个类似于 Servlet 的 Java 程序，可以简化页面内容的生成。Servlet 和 JSP 最主要的不同点在于，Servlet 的应用逻辑是在 Java 文件中，并且完全从表示层中的 HTML 分离开来。而 JSP 的情况是 Java 和 HTML 可以组合成一个扩展名为.jsp 的文件。有人说，Servlet 就是在 Java 中写 HTML，而 JSP 就是在 HTML 中写 Java 代码，当然这个说法是很片面且不够准确的。JSP 侧重于视图，Servlet 更侧重于控制逻辑，在 MVC 架构模式中，JSP 适合充当视图（view）而 Servlet 适合充当控制器（controller）。
\nJSP 是一种 Servlet，但是与 HttpServlet 的工作方式不太一样。HttpServlet 是先由源代码编译为 class 文件后部署到服务器下，为先编译后部署。而 JSP 则是先部署后编译。JSP 会在客户端第一次请求 JSP 文件时被编译为 HttpJspPage 类（接口 Servlet 的一个子类）。该类会被服务器临时存放在服务器工作目录里面。下面通过实例给大家介绍。
\n工程 JspLoginDemo 下有一个名为 login.jsp 的 Jsp 文件，把工程第一次部署到服务器上后访问这个 Jsp 文件，我们发现这个目录下多了下图这两个东东。
\n.class 文件便是 JSP 对应的 Servlet。编译完毕后再运行 class 文件来响应客户端请求。以后客户端访问 login.jsp 的时候，Tomcat 将不再重新编译 JSP 文件，而是直接调用 class 文件来响应客户端请求。
![\"JSP工作原理\"](\"https://oss.javaguide.cn/github/javaguide/1.jpeg\")
由于 JSP 只会在客户端第一次请求的时候被编译 ，因此第一次请求 JSP 时会感觉比较慢，之后就会感觉快很多。如果把服务器保存的 class 文件删除，服务器也会重新编译 JSP。
\n开发 Web 程序时经常需要修改 JSP。Tomcat 能够自动检测到 JSP 程序的改动。如果检测到 JSP 源代码发生了改动。Tomcat 会在下次客户端请求 JSP 时重新编译 JSP，而不需要重启 Tomcat。这种自动检测功能是默认开启的，检测改动会消耗少量的时间，在部署 Web 应用的时候可以在 web.xml 中将它关掉。
\n参考：《javaweb 整合开发王者归来》P97
\nJSP 有 9 个内置对象：
\nsetAttribute(String name,Object)：设置名字为 name 的 request 的参数值getAttribute(String name)：返回由 name 指定的属性值getAttributeNames()：返回 request 对象所有属性的名字集合，结果是一个枚举的实例getCookies()：返回客户端的所有 Cookie 对象，结果是一个 Cookie 数组getCharacterEncoding()：返回请求中的字符编码方式 = getContentLength()`：返回请求的 Body 的长度getHeader(String name)：获得 HTTP 协议定义的文件头信息getHeaders(String name)：返回指定名字的 request Header 的所有值，结果是一个枚举的实例getHeaderNames()：返回所以 request Header 的名字，结果是一个枚举的实例getInputStream()：返回请求的输入流，用于获得请求中的数据getMethod()：获得客户端向服务器端传送数据的方法getParameter(String name)：获得客户端传送给服务器端的有 name 指定的参数值getParameterNames()：获得客户端传送给服务器端的所有参数的名字，结果是一个枚举的实例getParameterValues(String name)：获得有 name 指定的参数的所有值getProtocol()：获取客户端向服务器端传送数据所依据的协议名称getQueryString()：获得查询字符串getRequestURI()：获取发出请求字符串的客户端地址getRemoteAddr()：获取客户端的 IP 地址getRemoteHost()：获取客户端的名字getSession([Boolean create])：返回和请求相关 SessiongetServerName()：获取服务器的名字getServletPath()：获取客户端所请求的脚本文件的路径getServerPort()：获取服务器的端口号removeAttribute(String name)：删除请求中的一个属性从获取方向来看：
\ngetParameter()是获取 POST/GET 传递的参数值；
getAttribute()是获取对象容器中的数据值；
从用途来看：
\ngetParameter()用于客户端重定向时，即点击了链接或提交按扭时传值用，即用于在用表单或 url 重定向传值时接收数据用。
getAttribute() 用于服务器端重定向时，即在 sevlet 中使用了 forward 函数,或 struts 中使用了
\nmapping.findForward。 getAttribute 只能收到程序用 setAttribute 传过来的值。
另外，可以用 setAttribute(),getAttribute() 发送接收对象.而 getParameter() 显然只能传字符串。
\nsetAttribute() 是应用服务器把这个对象放在该页面所对应的一块内存中去，当你的页面服务器重定向到另一个页面时，应用服务器会把这块内存拷贝另一个页面所对应的内存中。这样getAttribute()就能取得你所设下的值，当然这种方法可以传对象。session 也一样，只是对象在内存中的生命周期不一样而已。getParameter()只是应用服务器在分析你送上来的 request 页面的文本时，取得你设在表单或 url 重定向时的值。
总结：
\ngetParameter()返回的是 String,用于读取提交的表单中的值;（获取之后会根据实际需要转换为自己需要的相应类型，比如整型，日期类型啊等等）
getAttribute()返回的是 Object，需进行转换,可用setAttribute()设置成任意对象，使用很灵活，可随时用
include 指令： JSP 可以通过 include 指令来包含其他文件。被包含的文件可以是 JSP 文件、HTML 文件或文本文件。包含的文件就好像是该 JSP 文件的一部分，会被同时编译执行。 语法格式如下：
\n<%@ include file="文件相对 url 地址" %>
include 动作： <jsp:include>动作元素用来包含静态和动态的文件。该动作把指定文件插入正在生成的页面。语法格式如下：
\n<jsp:include page="相对 URL 地址" flush="true" />
JSP 中的四种作用域包括 page、request、session 和 application，具体来说：
\n对于 JSP 页面，可以通过 page 指令进行设置。
\n<%@page isThreadSafe="false"%>
对于 Servlet，可以让自定义的 Servlet 实现 SingleThreadModel 标识接口。
\n说明：如果将 JSP 或 Servlet 设置成单线程工作模式，会导致每个请求创建一个 Servlet 实例，这种实践将导致严重的性能问题（服务器的内存压力很大，还会导致频繁的垃圾回收），所以通常情况下并不会这么做。
\n使用 Cookie
\n向客户端发送 Cookie
\nCookie c =new Cookie(\"name\",\"value\"); //创建Cookie\nc.setMaxAge(60*60*24); //设置最大时效，此处设置的最大时效为一天\nresponse.addCookie(c); //把Cookie放入到HTTP响应中从客户端读取 Cookie
\nString name =\"name\";\nCookie[]cookies =request.getCookies();\nif(cookies !=null){\n for(int i= 0;i<cookies.length;i++){\n Cookie cookie =cookies[i];\n if(name.equals(cookis.getName()))\n //something is here.\n //you can get the value\n cookie.getValue();\n\n }\n }优点: 数据可以持久保存，不需要服务器资源，简单，基于文本的 Key-Value
\n缺点: 大小受到限制，用户可以禁用 Cookie 功能，由于保存在本地，有一定的安全风险。
\nURL 重写
\n在 URL 中添加用户会话的信息作为请求的参数，或者将唯一的会话 ID 添加到 URL 结尾以标识一个会话。
\n优点： 在 Cookie 被禁用的时候依然可以使用
\n缺点： 必须对网站的 URL 进行编码，所有页面必须动态生成，不能用预先记录下来的 URL 进行访问。
\n隐藏的表单域
\n<input type=\"hidden\" name=\"session\" value=\"...\" />优点： Cookie 被禁时可以使用
\n缺点： 所有页面必须是表单提交之后的结果。
\nHttpSession
\n在所有会话跟踪技术中，HttpSession 对象是最强大也是功能最多的。当一个用户第一次访问某个网站时会自动创建 HttpSession，每个用户可以访问他自己的 HttpSession。可以通过 HttpServletRequest 对象的 getSession 方 法获得 HttpSession，通过 HttpSession 的 setAttribute 方法可以将一个值放在 HttpSession 中，通过调用 HttpSession 对象的 getAttribute 方法，同时传入属性名就可以获取保存在 HttpSession 中的对象。与上面三种方式不同的 是，HttpSession 放在服务器的内存中，因此不要将过大的对象放在里面，即使目前的 Servlet 容器可以在内存将满时将 HttpSession 中的对象移到其他存储设备中，但是这样势必影响性能。添加到 HttpSession 中的值可以是任意 Java 对象，这个对象最好实现了 Serializable 接口，这样 Servlet 容器在必要的时候可以将其序列化到文件中，否则在序列化时就会出现异常。
\nCookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。
\nCookie 一般用来保存用户信息 比如 ① 我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；② 一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③ 登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
\nCookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
\nCookie 存储在客户端中，而 Session 存储在服务器上，相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
\n", "image": "https://static001.geekbang.org/infoq/04/0454a5fff1437c32754f1dfcc3881148.png", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "系统设计" ] }, { "title": "系统设计知识体系：设计模式、工程基础、认证授权、数据安全与常用框架", "url": "https://codingmap.strova.top/system-design/", "id": "https://codingmap.strova.top/system-design/", "summary": "系统设计面试与知识体系学习路线，涵盖设计模式、RESTful API、软件工程、代码重构、单元测试、认证授权、数据安全、Spring 和实时消息推送。重点围绕 适合谁看、学习重点、建议阅读顺序、核心文章、系统设计 等内容展开。结合 CodingMap 知识体系梳理 系统设计 的核心概念、实践方法等核心内容。", "content_html": "这份 系统设计知识体系 面向后端学习、工程实践和面试复习，围绕“把业务需求拆成稳定、可维护、可扩展的工程方案”整理本站系统设计相关文章。
\n系统设计不是只背秒杀、短链、Feed 流这类场景题。真正落到后端开发里，还需要理解 API 设计、代码质量、设计模式、框架原理、认证授权、数据安全、定时任务和实时消息推送等基础能力。
\n如果你时间有限，建议先看 系统设计常见面试题总结，快速建立高频问题清单；如果想系统补基础，可以按下面的阅读顺序推进。
\n#{}、${}、动态 SQL、缓存、分页插件和 Mapper 映射。#{} 和 ${} 有什么区别？一级缓存和二级缓存如何工作？设计模式 相关的面试题已经整理到了 PDF 手册中，你可以在我的公众号“JavaGuide”后台回复“PDF” 获取。
\n
《设计模式》PDF 电子书内容概览：
\n![\"《设计模式》PDF文档概览\"](\"https://oss.javaguide.cn/github/javaguide/system-design/design-pattern-pdf.png\")
我们来看一下几个非常常见的业务场景：
\n这些场景往往都要求我们在某个特定的时间去做某个事情，也就是定时或者延时去做某个事情。
\n尽管二者的适用场景有所区别，但它们的核心思想都是将任务的执行时间安排在未来的某个点上，以达到预期的调度效果。
\njava.util.Timer是 JDK 1.3 开始就已经支持的一种定时任务的实现方式。
Timer 内部使用一个叫做 TaskQueue 的类存放定时任务，它是一个基于最小堆实现的优先级队列。TaskQueue 会按照任务距离下一次执行时间的大小将任务排序，保证在堆顶的任务最先执行。这样在需要执行任务时，每次只需要取出堆顶的任务运行即可！
Timer 使用起来比较简单，通过下面的方式我们就能创建一个 1s 之后执行的定时任务。
// 示例代码：\nTimerTask task = new TimerTask() {\n public void run() {\n System.out.println(\"当前时间: \" + new Date() + \"n\" +\n \"线程名称: \" + Thread.currentThread().getName());\n }\n};\nSystem.out.println(\"当前时间: \" + new Date() + \"n\" +\n \"线程名称: \" + Thread.currentThread().getName());\nTimer timer = new Timer(\"Timer\");\nlong delay = 1000L;\ntimer.schedule(task, delay);\n\n\n//输出：\n当前时间: Fri May 28 15:18:47 CST 2021n线程名称: main\n当前时间: Fri May 28 15:18:48 CST 2021n线程名称: Timer不过其缺陷较多，比如一个 Timer 一个线程，这就导致 Timer 的任务的执行只能串行执行，一个任务执行时间过长的话会影响其他任务（性能非常差），再比如发生异常时任务直接停止（Timer 只捕获了 InterruptedException ）。
Timer 类上的有一段注释是这样写的：
* This class does not offer real-time guarantees: it schedules\n * tasks using the <tt>Object.wait(long)</tt> method.\n *Java 5.0 introduced the {@code java.util.concurrent} package and\n * one of the concurrency utilities therein is the {@link\n * java.util.concurrent.ScheduledThreadPoolExecutor\n * ScheduledThreadPoolExecutor} which is a thread pool for repeatedly\n * executing tasks at a given rate or delay. It is effectively a more\n * versatile replacement for the {@code Timer}/{@code TimerTask}\n * combination, as it allows multiple service threads, accepts various\n * time units, and doesn't require subclassing {@code TimerTask} (just\n * implement {@code Runnable}). Configuring {@code\n * ScheduledThreadPoolExecutor} with one thread makes it equivalent to\n * {@code Timer}.大概的意思就是：ScheduledThreadPoolExecutor 支持多线程执行定时任务并且功能更强大，是 Timer 的替代品。
ScheduledExecutorService 是一个接口，有多个实现类，比较常用的是 ScheduledThreadPoolExecutor 。
![](\"https://oss.javaguide.cn/javaguide/20210607154324712.png\")
ScheduledThreadPoolExecutor 本身就是一个线程池，支持任务并发执行。并且，其内部使用 DelayedWorkQueue 作为任务队列。
// 示例代码：\nTimerTask repeatedTask = new TimerTask() {\n @SneakyThrows\n public void run() {\n System.out.println(\"当前时间: \" + new Date() + \"n\" +\n \"线程名称: \" + Thread.currentThread().getName());\n }\n};\nSystem.out.println(\"当前时间: \" + new Date() + \"n\" +\n \"线程名称: \" + Thread.currentThread().getName());\nScheduledExecutorService executor = Executors.newScheduledThreadPool(3);\nlong delay = 1000L;\nlong period = 1000L;\nexecutor.scheduleAtFixedRate(repeatedTask, delay, period, TimeUnit.MILLISECONDS);\nThread.sleep(delay + period * 5);\nexecutor.shutdown();\n//输出：\n当前时间: Fri May 28 15:40:46 CST 2021n线程名称: main\n当前时间: Fri May 28 15:40:47 CST 2021n线程名称: pool-1-thread-1\n当前时间: Fri May 28 15:40:48 CST 2021n线程名称: pool-1-thread-1\n当前时间: Fri May 28 15:40:49 CST 2021n线程名称: pool-1-thread-2\n当前时间: Fri May 28 15:40:50 CST 2021n线程名称: pool-1-thread-2\n当前时间: Fri May 28 15:40:51 CST 2021n线程名称: pool-1-thread-2\n当前时间: Fri May 28 15:40:52 CST 2021n线程名称: pool-1-thread-2不论是使用 Timer 还是 ScheduledExecutorService 都无法使用 Cron 表达式指定任务执行的具体时间。
DelayQueue 是 JUC 包(java.util.concurrent)为我们提供的延迟队列，用于实现延时任务比如订单下单 15 分钟未支付直接取消。它是 BlockingQueue 的一种，底层是一个基于 PriorityQueue 实现的一个无界队列，是线程安全的。关于PriorityQueue可以参考笔者编写的这篇文章：PriorityQueue 源码分析 。
![\"BlockingQueue](\"https://oss.javaguide.cn/github/javaguide/java/collection/blocking-queue-hierarchy.png\")
DelayQueue 和 Timer/TimerTask 都可以用于实现定时任务调度，但是它们的实现方式不同。DelayQueue 是基于优先级队列和堆排序算法实现的，可以实现多个任务按照时间先后顺序执行；而 Timer/TimerTask 是基于单线程实现的，只能按照任务的执行顺序依次执行，如果某个任务执行时间过长，会影响其他任务的执行。另外，DelayQueue 还支持动态添加和移除任务，而 Timer/TimerTask 只能在创建时指定任务。
关于 DelayQueue 的详细介绍，请参考我写的这篇文章：DelayQueue 源码分析。
我们直接通过 Spring 提供的 @Scheduled 注解即可定义定时任务，非常方便！
/**\n * cron：使用Cron表达式。 每分钟的1，2秒运行\n */\n@Scheduled(cron = \"1-2 * * * * ? \")\npublic void reportCurrentTimeWithCronExpression() {\n log.info(\"Cron Expression: The time is now {}\", dateFormat.format(new Date()));\n}我在大学那会做的一个 SSM 的企业级项目，就是用的 Spring Task 来做的定时任务。
\n并且，Spring Task 还是支持 Cron 表达式 的。Cron 表达式主要用于定时作业(定时任务)系统定义执行时间或执行频率的表达式，非常厉害，你可以通过 Cron 表达式进行设置定时任务每天或者每个月什么时候执行等等操作。咱们要学习定时任务的话，Cron 表达式是一定是要重点关注的。推荐一个在线 Cron 表达式生成器：http://cron.qqe2.com/ 。
\n但是，Spring 自带的定时调度只支持单机，并且提供的功能比较单一。之前写过一篇文章:《5 分钟搞懂如何在 Spring Boot 中 Schedule Tasks》 ，不了解的小伙伴可以参考一下。
\nSpring Task 底层是基于 JDK 的 ScheduledThreadPoolExecutor 线程池来实现的。
优缺点总结：
\nKafka、Dubbo、ZooKeeper、Netty、Caffeine、Akka 中都有对时间轮的实现。
\n时间轮简单来说就是一个环形的队列（底层一般基于数组实现），队列中的每一个元素（时间格）都可以存放一个定时任务列表。
\n时间轮中的每个时间格代表了时间轮的基本时间跨度或者说时间精度，假如时间一秒走一个时间格的话，那么这个时间轮的最高精度就是 1 秒（也就是说 3 s 和 3.9s 会在同一个时间格中）。
\n下图是一个有 12 个时间格的时间轮，转完一圈需要 12 s。当我们需要新建一个 3s 后执行的定时任务，只需要将定时任务放在下标为 3 的时间格中即可。当我们需要新建一个 9s 后执行的定时任务，只需要将定时任务放在下标为 9 的时间格中即可。
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/schedule-task/one-layers-of-time-wheel.png\")
那当我们需要创建一个 13s 后执行的定时任务怎么办呢？这个时候可以引入一叫做 圈数/轮数 的概念，也就是说这个任务还是放在下标为 1 的时间格中， 不过它的圈数为 2 。
\n除了增加圈数这种方法之外，还有一种 多层次时间轮 （类似手表），Kafka 采用的就是这种方案。
\n针对下图的时间轮，我来举一个例子便于大家理解。
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/schedule-task/three-layers-of-time-wheel.png\")
上图的时间轮(ms -> s)，第 1 层的时间精度为 1 ，第 2 层的时间精度为 20 ，第 3 层的时间精度为 400。假如我们需要添加一个 350s 后执行的任务 A 的话（当前时间是 0s），这个任务会被放在第 2 层（因为第二层的时间跨度为 20*20=400>350）的第 350/20=17 个时间格子。
\n当第一层转了 17 圈之后，时间过去了 340s ，第 2 层的指针此时来到第 17 个时间格子。此时，第 2 层第 17 个格子的任务会被移动到第 1 层。
\n任务 A 当前是 10s 之后执行，因此它会被移动到第 1 层的第 10 个时间格子。
\n这里在层与层之间的移动也叫做时间轮的升降级。参考手表来理解就好！
\n时间轮比较适合任务数量比较多的定时任务场景，它的任务写入和执行的时间复杂度都是 0（1）。
\nRedis 是可以用来做延时任务的，基于 Redis 实现延时任务的功能无非就下面两种方案：
\n这部分内容的详细介绍我放在了《后端面试高频系统设计&场景题》中，有需要的同学可以进入星球后阅读学习。篇幅太多，这里就不重复分享了。
\n![\"《后端面试高频系统设计&场景题》\"](\"https://oss.javaguide.cn/xingqiu/back-end-interview-high-frequency-system-design-and-scenario-questions-fengmian.png\")
大部分消息队列，例如 RocketMQ、RabbitMQ，都支持定时/延时消息。定时消息和延时消息本质其实是相同的，都是服务端根据消息设置的定时时间在某一固定时刻将消息投递给消费者消费。
\n不过，在使用 MQ 定时消息之前一定要看清楚其使用限制，以免不适合项目需求，例如 RocketMQ 定时时长最大值默认为 24 小时且不支持自定义修改、只支持 18 个 Level 的延时并不支持任意时间。
\n优缺点总结：
\n如果我们需要一些高级特性比如支持任务在分布式场景下的分片和高可用的话，我们就需要用到分布式任务调度框架了。
\n通常情况下，一个分布式定时任务的执行往往涉及到下面这些角色：
\n一个很火的开源任务调度框架，完全由 Java 写成。Quartz 可以说是 Java 定时任务领域的老大哥或者说参考标准，其他的任务调度框架基本都是基于 Quartz 开发的，比如当当网的elastic-job就是基于 Quartz 二次开发之后的分布式调度解决方案。
使用 Quartz 可以很方便地与 Spring 集成，并且支持动态添加任务和集群。但是，Quartz 使用起来也比较麻烦，API 繁琐。
\n并且，Quartz 并没有内置 UI 管理控制台，不过你可以使用 quartzui 这个开源项目来解决这个问题。
\n另外，Quartz 虽然也支持分布式任务。但是，它是在数据库层面，通过数据库的锁机制做的，有非常多的弊端比如系统侵入性严重、节点负载不均衡。有点伪分布式的味道。
\n优缺点总结：
\nElasticJob 当当网开源的一个面向互联网生态和海量任务的分布式调度解决方案，由两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。
\nElasticJob-Lite 和 ElasticJob-Cloud 两者的对比如下：
\n| | ElasticJob-Lite | ElasticJob-Cloud |
\n| :
系统设计 相关的面试题为我的知识星球（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了《后端面试高频系统设计&场景题》中。
\n《后端面试高频系统设计&场景题》 包含了常见的系统设计案例比如短链系统、秒杀系统以及高频的场景题比如海量数据去重、第三方授权登录。
\n
近年来，随着国内的技术面试越来越卷，越来越多的公司开始在面试中考察系统设计和场景问题，以此来更全面的考察求职者，不论是校招还是社招。不过，正常面试全是场景题的情况还是极少的，面试官一般会在面试中穿插一两个系统设计和场景题来考察你。
\n于是，我总结了这份《后端面试高频系统设计&场景题》，包含了常见的系统设计案例比如短链系统、秒杀系统以及高频的场景题比如海量数据去重、第三方授权登录。
\n即使不是准备面试，我也强烈推荐你认真阅读这一系列文章，这对于提升自己系统设计思维和解决实际问题的能力还是非常有帮助的。并且，涉及到的很多案例都可以用到自己的项目上比如抽奖系统设计、第三方授权登录、Redis 实现延时任务的正确方式。
\n《后端面试高频系统设计&场景题》本身是属于《Java 面试指北》的一部分，后面由于内容篇幅较多，因此被单独提了出来。
\n", "image": "https://oss.javaguide.cn/xingqiu/back-end-interview-high-frequency-system-design-and-scenario-questions-fengmian.png", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "Java面试指北" ] }, { "title": "Web 实时消息推送详解", "url": "https://codingmap.strova.top/system-design/web-real-time-message-push.html", "id": "https://codingmap.strova.top/system-design/web-real-time-message-push.html", "summary": "消息推送通常是指网站的运营工作等人员，通过某种工具对用户当前网页或移动设备 APP 进行的主动消息推送。重点围绕 什么是消息推送？、消息推送常见方案、总结 等内容展开。结合 CodingMap 知识体系梳理 系统设计 / Web Real Time Message Push.Html 的核心概念、实践方法等核心内容。", "content_html": "\n\n原文地址：https://juejin.cn/post/7122014462181113887，JavaGuide 对本文进行了完善总结。
\n
我有一个朋友做了一个小破站，现在要实现一个站内信 Web 消息推送的功能，对，就是下图这个小红点，一个很常用的功能。
\n![\"站内信](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192380.png\")
不过他还没想好用什么方式做，这里我帮他整理了一下几种方案，并简单做了实现。
\n推送的场景比较多，比如有人关注我的公众号，这时我就会收到一条推送消息，以此来吸引我点击打开应用。
\n消息推送通常是指网站的运营工作等人员，通过某种工具对用户当前网页或移动设备 APP 进行的主动消息推送。
\n消息推送一般又分为 Web 端消息推送和移动端消息推送。
\n移动端消息推送示例：
\n![\"移动端消息推送示例\"](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/IKleJ9auR1Ojdicyr0bH.png\")
Web 端消息推送示例：
\n![\"Web](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/image-20220819100512941.png\")
在具体实现之前，咱们再来分析一下前边的需求，其实功能很简单，只要触发某个事件（主动分享了资源或者后台主动推送消息），Web 页面的通知小红点就会实时的 +1 就可以了。
通常在服务端会有若干张消息推送表，用来记录用户触发不同事件所推送不同类型的消息，前端主动查询（拉）或者被动接收（推）用户所有未读的消息数。
\n![\"消息推送表\"](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192384.png\")
消息推送无非是推（push）和拉（pull）两种形式，下边我们逐个了解下。
\n轮询(polling) 应该是实现消息推送方案中最简单的一种，这里我们暂且将轮询分为短轮询和长轮询。
\n短轮询很好理解，指定的时间间隔，由浏览器向服务器发出 HTTP 请求，服务器实时返回未读消息数据给客户端，浏览器再做渲染显示。
\n一个简单的 JS 定时器就可以搞定，每秒钟请求一次未读消息数接口，返回的数据展示即可。
\nsetInterval(() => {\n // 方法请求\n messageCount().then((res) => {\n if (res.code === 200) {\n this.messageCount = res.data;\n }\n });\n}, 1000);效果还是可以的，短轮询实现固然简单，缺点也是显而易见，由于推送数据并不会频繁变更，无论后端此时是否有新的消息产生，客户端都会进行请求，势必会对服务端造成很大压力，浪费带宽和服务器资源。
\n长轮询是对上边短轮询的一种改进版本，在尽可能减少对服务器资源浪费的同时，保证消息的相对实时性。长轮询在中间件中应用的很广泛，比如 Nacos 和 Apollo 配置中心，消息队列 Kafka、RocketMQ 中都有用到长轮询。
\nNacos 配置中心交互模型是 push 还是 pull？一文中我详细介绍过 Nacos 长轮询的实现原理，感兴趣的小伙伴可以瞅瞅。
\n长轮询其实原理跟轮询差不多，都是采用轮询的方式。不过，如果服务端的数据没有发生变更，会 一直 hold 住请求，直到服务端的数据发生变化，或者等待一定时间超时才会返回。返回后，客户端又会立即再次发起下一次长轮询。
\n这次我使用 Apollo 配置中心实现长轮询的方式，应用了一个类DeferredResult，它是在 Servlet3.0 后经过 Spring 封装提供的一种异步请求机制，直意就是延迟结果。
![\"长轮询示意图\"](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192386.png\")
DeferredResult可以允许容器线程快速释放占用的资源，不阻塞请求线程，以此接受更多的请求提升系统的吞吐量，然后启动异步工作线程处理真正的业务逻辑，处理完成调用DeferredResult.setResult(200)提交响应结果。
下边我们用长轮询来实现消息推送。
\n因为一个 ID 可能会被多个长轮询请求监听，所以我采用了 Guava 包提供的Multimap结构存放长轮询，一个 key 可以对应多个 value。一旦监听到 key 发生变化，对应的所有长轮询都会响应。前端得到非请求超时的状态码，知晓数据变更，主动查询未读消息数接口，更新页面数据。
@Controller\n@RequestMapping(\"/polling\")\npublic class PollingController {\n\n // 存放监听某个Id的长轮询集合\n // 线程同步结构\n public static Multimap<String, DeferredResult<String>> watchRequests = Multimaps.synchronizedMultimap(HashMultimap.create());\n\n /**\n * 设置监听\n */\n @GetMapping(path = \"watch/{id}\")\n @ResponseBody\n public DeferredResult<String> watch(@PathVariable String id) {\n // 延迟对象设置超时时间\n DeferredResult<String> deferredResult = new DeferredResult<>(TIME_OUT);\n // 异步请求完成时移除 key，防止内存溢出\n deferredResult.onCompletion(() -> {\n watchRequests.remove(id, deferredResult);\n });\n // 注册长轮询请求\n watchRequests.put(id, deferredResult);\n return deferredResult;\n }\n\n /**\n * 变更数据\n */\n @GetMapping(path = \"publish/{id}\")\n @ResponseBody\n public String publish(@PathVariable String id) {\n // 数据变更 取出监听ID的所有长轮询请求，并一一响应处理\n if (watchRequests.containsKey(id)) {\n Collection<DeferredResult<String>> deferredResults = watchRequests.get(id);\n for (DeferredResult<String> deferredResult : deferredResults) {\n deferredResult.setResult(\"我更新了\" + new Date());\n }\n }\n return \"success\";\n }当请求超过设置的超时时间，会抛出AsyncRequestTimeoutException异常，这里直接用@ControllerAdvice全局捕获统一返回即可，前端获取约定好的状态码后再次发起长轮询请求，如此往复调用。
@ControllerAdvice\npublic class AsyncRequestTimeoutHandler {\n\n @ResponseStatus(HttpStatus.NOT_MODIFIED)\n @ResponseBody\n @ExceptionHandler(AsyncRequestTimeoutException.class)\n public String asyncRequestTimeoutHandler(AsyncRequestTimeoutException e) {\n System.out.println(\"异步请求超时\");\n return \"304\";\n }\n}我们来测试一下，首先页面发起长轮询请求/polling/watch/10086监听消息更变，请求被挂起，不变更数据直至超时，再次发起了长轮询请求；紧接着手动变更数据/polling/publish/10086，长轮询得到响应，前端处理业务逻辑完成后再次发起请求，如此循环往复。
长轮询相比于短轮询在性能上提升了很多，但依然会产生较多的请求，这是它的一点不完美的地方。
\niframe 流就是在页面中插入一个隐藏的<iframe>标签，通过在src中请求消息数量 API 接口，由此在服务端和客户端之间创建一条长连接，服务端持续向iframe传输数据。
传输的数据通常是 HTML、或是内嵌的 JavaScript 脚本，来达到实时更新页面的效果。
\n![\"iframe](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192388.png\")
这种方式实现简单，前端只要一个<iframe>标签搞定了
<iframe src=\"/iframe/message\" style=\"display:none\"></iframe>服务端直接组装 HTML、JS 脚本数据向 response 写入就行了
\n@Controller\n@RequestMapping(\"/iframe\")\npublic class IframeController {\n @GetMapping(path = \"message\")\n public void message(HttpServletResponse response) throws IOException, InterruptedException {\n while (true) {\n response.setHeader(\"Pragma\", \"no-cache\");\n response.setDateHeader(\"Expires\", 0);\n response.setHeader(\"Cache-Control\", \"no-cache,no-store\");\n response.setStatus(HttpServletResponse.SC_OK);\n response.getWriter().print(\" <script type=\\\"text/javascript\\\">\\n\" +\n \"parent.document.getElementById('clock').innerHTML = \\\"\" + count.get() + \"\\\";\" +\n \"parent.document.getElementById('count').innerHTML = \\\"\" + count.get() + \"\\\";\" +\n \"</script>\");\n }\n }\n}iframe 流的服务器开销很大，而且 IE、Chrome 等浏览器一直会处于 loading 状态，图标会不停旋转，简直是强迫症杀手。
\n![\"iframe](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192389.png\")
iframe 流非常不友好，强烈不推荐。
\n很多人可能不知道，服务端向客户端推送消息，其实除了可以用WebSocket这种耳熟能详的机制外，还有一种服务器发送事件(Server-Sent Events)，简称 SSE。这是一种服务器端到客户端(浏览器)的单向消息推送。
大名鼎鼎的 ChatGPT 就是采用的 SSE。对于需要长时间等待响应的对话场景，ChatGPT 采用了一种巧妙的策略：它会将已经计算出的数据“推送”给用户，并利用 SSE 技术在计算过程中持续返回数据。这样做的好处是可以避免用户因等待时间过长而选择关闭页面。
\n![\"ChatGPT](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/chatgpt-sse.png\")
SSE 基于 HTTP 协议的，我们知道一般意义上的 HTTP 协议是无法做到服务端主动向客户端推送消息的，但 SSE 是个例外，它变换了一种思路。
\n![\"SSE](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192390.png\")
SSE 在服务器和客户端之间打开一个单向通道，服务端响应的不再是一次性的数据包而是text/event-stream类型的数据流信息，在有数据变更时从服务器流式传输到客户端。
整体的实现思路有点类似于在线视频播放，视频流会连续不断的推送到浏览器，你也可以理解成，客户端在完成一次用时很长（网络不畅）的下载。
\n![\"SSE](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192391.png\")
SSE 与 WebSocket 作用相似，都可以建立服务端与浏览器之间的通信，实现服务端向客户端推送消息，但还是有些许不同：
\nSSE 与 WebSocket 该如何选择？
\n\n\n技术并没有好坏之分，只有哪个更合适。
\n
SSE 好像一直不被大家所熟知，一部分原因是出现了 WebSocket，这个提供了更丰富的协议来执行双向、全双工通信。对于游戏、即时通信以及需要双向近乎实时更新的场景，拥有双向通道更具吸引力。
\n但是，在某些情况下，不需要从客户端发送数据。而你只需要一些服务器操作的更新。比如：站内信、未读消息数、状态更新、股票行情、监控数量等场景，SSE 不管是从实现的难易和成本上都更加有优势。此外，SSE 具有 WebSocket 在设计上缺乏的多种功能，例如：自动重新连接、事件 ID 和发送任意事件的能力。
\n前端只需进行一次 HTTP 请求，带上唯一 ID，打开事件流，监听服务端推送的事件就可以了
\n<script>\n let source = null;\n let userId = 7777\n if (window.EventSource) {\n // 建立连接\n source = new EventSource('http://localhost:7777/sse/sub/'+userId);\n setMessageInnerHTML(\"连接用户=\" + userId);\n /**\n * 连接一旦建立，就会触发open事件\n * 另一种写法：source.onopen = function (event) {}\n */\n source.addEventListener('open', function (e) {\n setMessageInnerHTML(\"建立连接。。。\");\n }, false);\n /**\n * 客户端收到服务器发来的数据\n * 另一种写法：source.onmessage = function (event) {}\n */\n source.addEventListener('message', function (e) {\n setMessageInnerHTML(e.data);\n });\n } else {\n setMessageInnerHTML(\"你的浏览器不支持SSE\");\n }\n</script>服务端的实现更简单，创建一个SseEmitter对象放入sseEmitterMap进行管理
private static Map<String, SseEmitter> sseEmitterMap = new ConcurrentHashMap<>();\n\n/**\n * 创建连接\n */\npublic static SseEmitter connect(String userId) {\n try {\n // 设置超时时间，0表示不过期。默认30秒\n SseEmitter sseEmitter = new SseEmitter(0L);\n // 注册回调\n sseEmitter.onCompletion(completionCallBack(userId));\n sseEmitter.onError(errorCallBack(userId));\n sseEmitter.onTimeout(timeoutCallBack(userId));\n sseEmitterMap.put(userId, sseEmitter);\n count.getAndIncrement();\n return sseEmitter;\n } catch (Exception e) {\n log.info(\"创建新的sse连接异常，当前用户：{}\", userId);\n }\n return null;\n}\n\n/**\n * 给指定用户发送消息\n */\npublic static void sendMessage(String userId, String message) {\n\n if (sseEmitterMap.containsKey(userId)) {\n try {\n sseEmitterMap.get(userId).send(message);\n } catch (IOException e) {\n log.error(\"用户[{}]推送异常:{}\", userId, e.getMessage());\n removeUser(userId);\n }\n }\n}注意： SSE 不支持 IE 浏览器，对其他主流浏览器兼容性做的还不错。
\n![\"SSE](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192393.png\")
Websocket 应该是大家都比较熟悉的一种实现消息推送的方式，上边我们在讲 SSE 的时候也和 Websocket 进行过比较。
\n这是一种在 TCP 连接上进行全双工通信的协议，建立客户端和服务器之间的通信渠道。浏览器和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。
\n![\"Websocket](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192394.png\")
WebSocket 的工作过程可以分为以下几个步骤：
\nUpgrade: websocket 和 Sec-WebSocket-Key 等字段，表示要求升级协议为 WebSocket；Connection: Upgrade和 Sec-WebSocket-Accept: xxx 等字段、表示成功升级到 WebSocket 协议。另外，建立 WebSocket 连接之后，通过心跳机制来保持 WebSocket 连接的稳定性和活跃性。
\nSpringBoot 整合 WebSocket，先引入 WebSocket 相关的工具包，和 SSE 相比有额外的开发成本。
\n<!-- 引入websocket -->\n<dependency>\n <groupId>org.springframework.boot</groupId>\n <artifactId>spring-boot-starter-websocket</artifactId>\n</dependency>服务端使用@ServerEndpoint注解标注当前类为一个 WebSocket 服务器，客户端可以通过ws://localhost:7777/webSocket/10086来连接到 WebSocket 服务器端。
@Component\n@Slf4j\n@ServerEndpoint(\"/websocket/{userId}\")\npublic class WebSocketServer {\n //与某个客户端的连接会话，需要通过它来给客户端发送数据\n private Session session;\n private static final CopyOnWriteArraySet<WebSocketServer> webSockets = new CopyOnWriteArraySet<>();\n // 用来存在线连接数\n private static final Map<String, Session> sessionPool = new HashMap<String, Session>();\n /**\n * 链接成功调用的方法\n */\n @OnOpen\n public void onOpen(Session session, @PathParam(value = \"userId\") String userId) {\n try {\n this.session = session;\n webSockets.add(this);\n sessionPool.put(userId, session);\n log.info(\"websocket消息: 有新的连接，总数为:\" + webSockets.size());\n } catch (Exception e) {\n }\n }\n /**\n * 收到客户端消息后调用的方法\n */\n @OnMessage\n public void onMessage(String message) {\n log.info(\"websocket消息: 收到客户端消息:\" + message);\n }\n /**\n * 此为单点消息\n */\n public void sendOneMessage(String userId, String message) {\n Session session = sessionPool.get(userId);\n if (session != null && session.isOpen()) {\n try {\n log.info(\"websocket消: 单点消息:\" + message);\n session.getAsyncRemote().sendText(message);\n } catch (Exception e) {\n e.printStackTrace();\n }\n }\n }\n}服务端还需要注入ServerEndpointerExporter，这个 Bean 就会自动注册使用了@ServerEndpoint注解的 WebSocket 服务器。
@Configuration\npublic class WebSocketConfiguration {\n\n /**\n * 用于注册使用了 @ServerEndpoint 注解的 WebSocket 服务器\n */\n @Bean\n public ServerEndpointExporter serverEndpointExporter() {\n return new ServerEndpointExporter();\n }\n}前端初始化打开 WebSocket 连接，并监听连接状态，接收服务端数据或向服务端发送数据。
\n<script>\n var ws = new WebSocket('ws://localhost:7777/webSocket/10086');\n // 获取连接状态\n console.log('ws连接状态：' + ws.readyState);\n //监听是否连接成功\n ws.onopen = function () {\n console.log('ws连接状态：' + ws.readyState);\n //连接成功则发送一个数据\n ws.send('test1');\n }\n // 接听服务器发回的信息并处理展示\n ws.onmessage = function (data) {\n console.log('接收到来自服务器的消息：');\n console.log(data);\n //完成通信后关闭WebSocket连接\n ws.close();\n }\n // 监听连接关闭事件\n ws.onclose = function () {\n // 监听整个过程中websocket的状态\n console.log('ws连接状态：' + ws.readyState);\n }\n // 监听并处理error事件\n ws.onerror = function (error) {\n console.log(error);\n }\n function sendMessage() {\n var content = $(\"#message\").val();\n $.ajax({\n url: '/socket/publish?userId=10086&message=' + content,\n type: 'GET',\n data: { \"id\": \"7777\", \"content\": content },\n success: function (data) {\n console.log(data)\n }\n })\n }\n</script>页面初始化建立 WebSocket 连接，之后就可以进行双向通信了，效果还不错。
\n![](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000042192395.png\")
什么是 MQTT 协议？
\nMQTT (Message Queue Telemetry Transport)是一种基于发布/订阅（publish/subscribe）模式的轻量级通讯协议，通过订阅相应的主题来获取消息，是物联网（Internet of Thing）中的一个标准传输协议。
\n该协议将消息的发布者（publisher）与订阅者（subscriber）进行分离，因此可以在不可靠的网络环境中，为远程连接的设备提供可靠的消息服务，使用方式与传统的 MQ 有点类似。
\n![\"MQTT](\"https://oss.javaguide.cn/github/javaguide/system-design/web-real-time-message-push/1460000022986325.png\")
TCP 协议位于传输层，MQTT 协议位于应用层，MQTT 协议构建于 TCP/IP 协议上，也就是说只要支持 TCP/IP 协议栈的地方，都可以使用 MQTT 协议。
\n为什么要用 MQTT 协议？
\nMQTT 协议为什么在物联网（IOT）中如此受偏爱？而不是其它协议，比如我们更为熟悉的 HTTP 协议呢？
\n具体的 MQTT 协议介绍和实践，这里我就不再赘述了，大家可以参考我之前的两篇文章，里边写的也都很详细了。
\n\n\n以下内容为 JavaGuide 补充
\n
| | 介绍 | 优点 | 缺点 |
\n|
这份 开发工具知识体系 面向后端学习和日常开发，围绕“项目构建 -> 依赖管理 -> 版本控制 -> 协作提效 -> 容器化交付”的顺序整理本站开发工具相关文章。
\n开发工具不只是会敲几个命令，更重要的是理解它们在团队协作、工程规范、环境一致性和交付效率中的作用。
\n大模型 API 看起来只是一段请求和一段返回，实际落地时问题都藏在细节里：Token 怎么花掉、上下文为什么塞不下、采样参数会不会让答案飘、结构化输出为什么偶发失败、上线前怎么证明效果真的变好了。
\n这份 大模型基础专题 面向 AI 应用开发入门和工程落地，先把这些基础问题讲清楚，再进入 Agent、RAG 和系统设计会顺很多。
\n很多 AI 应用的第一个版本都很“顺”：本地调通一个大模型 API，页面上能看到回答，Demo 就算跑起来了。
\n但一上生产，麻烦马上变得具体：
\n{"answer": "根因是。Guide 见过太多这样的事故。真正难的并非”怎么发一个 HTTP 请求给模型”，难点在于如何把大模型 API 当成一个不稳定、昂贵、受配额约束的外部依赖来治理。
\n本文覆盖：
\n上文默认你理解 Token、上下文窗口、Temperature、Top-p 等基础概念。如果还有疑问，建议先看《万字拆解 LLM 运行机制》和《大模型提示词工程实践指南》。
\n说明：OpenAI、Anthropic、Gemini 等供应商能力和参数变化较快，生产系统应从控制台、响应头或配置中心动态管理，而非依赖文档里的静态数字。
\n很多人排查大模型调用问题时，只盯着供应商返回了什么。这个视角太窄。
\n一次生产级 LLM 调用，本质上是一条跨业务系统、上下文系统、模型网关、外部供应商和前端展示层的链路。任何一段没有治理好，最后都会表现成“模型不稳定”。
\n拆开看，一次请求通常包含 8 个阶段：
\n很多团队栽的最多的一件事：把模型网关当成透明代理。它不是代理，它是 AI 应用的稳定性控制面。
\n如果没有网关，每个业务系统都会自己处理 API Key、超时、重试、限流、日志、供应商切换。短期看省事，长期一定变成事故放大器。Guide 的建议是：哪怕第一版很轻，也要把模型调用收口到一个统一的 LLMGateway。
默认的同步调用很好理解：后端发起请求，模型生成完全部内容后，一次性返回完整结果。
\n流式输出则是边生成边返回。模型每产生一段文本或一个事件，供应商就通过长连接把增量推给调用方。OpenAI 官方文档把 HTTP streaming 放在 SSE 场景下描述；Anthropic Messages API 也支持通过 SSE 增量返回事件；Gemini API 同样提供标准、流式和实时相关接口。具体字段和模型能力会变，以官方文档最新展示为准。
\n为什么 Streaming 能降低 TTFT？
\nTTFT（Time To First Token）指从请求发出到收到第一个可展示 Token 的时间。
\n同步返回时，用户要等模型生成完整答案。例如模型要生成 800 个 Token，后端必须等这 800 个 Token 都完成才把结果返回。
\n流式返回时，用户只要等模型开始生成第一个片段，就能看到内容逐步出现。
\n流式输出不是性能魔法。它没有让模型少算 Token，也不会天然省钱。它只是把等待过程拆成了可感知的进度，让用户觉得系统“活着”。
\n| 对比项 | 同步返回 | 流式返回 |
\n|
有个做智能客服的团队，花了三个月把 RAG 知识库从向量检索升级到混合检索，再加了一层 Reranker。上线前，工程师在本地测了几十条问题，感觉效果好了不少，于是就推了上线。
\n一周后，业务方反馈：“有些问题感觉还不如以前准。”
\n这句话最麻烦的地方，不是“效果变差了”，而是没人知道它到底有没有变差。旧版本质量是什么水平？新版本是哪类问题退步了？业务方说的“不如以前准”，是真退步，还是用户预期变高了？一查才发现，历史质量数据几乎没有。
\n很多 AI 应用早期都是这样：靠体感上线，靠体感判断好坏，靠体感决定改完之后是不是进步了。
\n这就像在黑盒里飞行。
\n这篇文章讲 AI 应用评测的完整闭环，主要包括：为什么公开 benchmark 替代不了自己的评测集；Golden Set 怎么构建；人工评测、规则评测、LLM-as-Judge 分别适合什么场景；LLM-as-Judge 的偏差和可靠用法；RAG、Agent、结构化输出、成本延迟、安全分别看哪些指标；以及离线评测、Trace 回放、线上灰度和 CI 自动回归怎么串起来。
\n说明一下：RAGAS、TruLens、LangSmith、Langfuse 等评测框架都在持续演进，生产系统要以官方文档最新说明为准。本文重点讲评测方法论和指标设计，不做工具横向测评，也不引用未经验证的 benchmark 数字。
\n很多团队选模型的方式很直接：打开某个评测榜单，找分数最高的，接进来用。
\n这个方法可以做粗筛，但用它判断“模型能不能做好我的业务”，经常靠不住。
\n公开 benchmark 优化的，不一定是你的数据分布。它通常使用固定数据集和固定任务类型，这些数据集上的排名，不一定能推断到真实用户行为。比如一个中文电商客服应用，用户问题高度集中在退换货流程、快递时效、促销规则、商品参数比较这些场景。选模型时只看英文推理榜，参考价值就很有限。
\n还有一个更隐蔽的问题：benchmark 数据通常比较干净，但生产数据不干净。真实用户输入里会有错别字、口语缩写、图文混排、多语言夹杂、前后矛盾的描述。模型在干净测试集上的表现，和它在真实脏数据里的表现，可能差很多。
\n业务里的失败模式也很特定。公开评测衡量的是平均能力，但业务真正敏感的往往不是平均分。
\n比如：
\n这类高权重失败，在通用 benchmark 里基本看不出来。
\n所以公开榜单可以用来排除明显不合适的模型，但决定一个模型能不能上你的业务，还是要靠自己的评测集。
\nGolden Set 是用来衡量 AI 应用质量的标准测试集。它的重点不是“样本很多”，而是每条样本都有明确输入，以及判断输出好坏的标准。
\n这个标准不一定是唯一正确答案。它可以是参考答案、评分维度、验证规则，也可以是一段人工判断说明。只要能让后续评测有一致标准，就有价值。
\n第一类来源是生产日志分层采样。
\n如果系统已经上线，生产日志通常是最有价值的数据源。采样时不要只取高频问题，因为高频问题往往是比较好处理的。真正容易出问题的，常常藏在低频、边缘和异常输入里。
\n建议重点看几类样本：用户点了“不满意”的，出现补充追问的，最后转人工的，以及那些看起来“差点失败”的边缘案例。
\n我遇到过一次，我们只从正常对话流里采样构建 Golden Set，结果漏掉了一类占生产流量 8% 的图文混排查询。这类查询的失败率比平均值高 3 倍，但在 Golden Set 里完全没有覆盖。后面连续两个版本所谓的“质量提升”，其实都是假提升。
\n第二类来源是人工构造。
\n新功能还没上线，或者某些高风险场景很少在日志里出现，就需要人工构造样本。
\n人工构造时至少覆盖三类：
\n第三类来源是失败案例回填。
\n上线后遇到的真实失败案例，是 Golden Set 最珍贵的补充来源。每次处理用户投诉时，都应该顺手问一句：这个案例能不能加进评测集？
\n失败案例回填能让 Golden Set 持续覆盖真实的模型软肋，而不是停留在最初构造时的主观想象里。
\n如果系统还没上线，也可以用合成数据做冷启动。比如先从知识库文档中生成一批问题、参考答案和难例，再由人工抽样审核后加入候选集。RAGAS 这类工具提供了测试集生成能力，适合帮你快速铺出第一版覆盖面。
\n但合成数据只能当辅助。它很容易继承生成模型自己的偏好，覆盖不到真实用户的脏输入和奇怪问法。真正用于发布门禁的 Golden Set，最终还是要被生产日志、失败案例和人工审核不断校准。
\n这个问题没有绝对答案，但可以有工程上的起点。
\n少于 50 条的 Golden Set，统计方差会很大。模型输出的一点随机波动，就可能让你误判质量变化方向。
\n50 到 200 条，通常可以作为很多场景的起点。它能覆盖主要功能路径，跑一次评测的成本也还可控，结论基本有参考价值。随着业务扩展，再逐步扩大到 500 条以上。
\n不过，比总量更重要的是分布。200 条全是同一类问题，不如 100 条覆盖 10 类场景。
\n| 分层 | 典型内容 | 建议占比 |
\n|
在探讨 RAG、Agent 工作流、MCP 协议这些高深概念之前，我想先聊聊一个让 Guide 踩过不少坑的基础问题：明明设置了温度为 0，结构化输出还是崩；往模型里塞了一堆文档，它好像直接失忆，关键指令全当空气。
\n说到底，还是底层原理没搞清楚。
\n万丈高楼平地起。这篇文章就是来填这个坑的。我们暂时把顶层架构放一放，回到 LLM 的基本面上来：Token 怎么算、上下文窗口怎么管、采样参数怎么调。
\n本文会沿着一条主线展开：先看模型为什么被 Token 和上下文窗口限制，再看采样参数如何影响输出稳定性，最后落到 Token 预算和参数配置建议。
\n具体会讲清楚：
\n当你在输入法里打“今天天气真”，它会自动建议“好”——大模型做的事情本质上一样。只不过它看的不是前面几个字，而是前面几千甚至几十万个字。每次只“补”一个 Token（文本碎片），然后把这个碎片加进上下文，再预测下一个，如此循环，直到生成完整回答。
\n这个过程叫做自回归生成（Autoregressive Generation）。
\n理解了自回归生成，后面所有概念都好办了：
\n你可以把 Token 理解为“模型的阅读单位”。我们人类读中文是一个字一个字地看，读英文是一个词一个词地看。但模型既不按字、也不按词——它用一套自己的“拆字规则”（叫 Tokenizer）把文本切成大小不等的碎片，每个碎片就是一个 Token。
\n为什么不直接按字或按词切？因为模型需要在“词表大小”和“序列长度”之间取平衡：
\n所以实际用的是折中方案——子词切分算法（如 BPE、Unigram），高频词保留为整体，低频词拆成更小片段。
\n你可以把 Token 想象成乐高积木。常用的“积木块”比较大（比如“你好”可能是一个 Token），不常用的词会被拆成更小的基础块拼起来。
\nToken 不是“一个字”或“一个词”的严格等价物：
\n工程上通常用经验估算做容量规划，用实际 API 返回的 usage做精确计费与监控。
\n经验估算（仅用于粗略规划）：
\nDeepSeek 官方数据：1 个英文字符约消耗 0.3 Token，1 个中文字符约消耗 0.6 Token。换算过来，1 个 Token 约等于 3.3 个英文字符或 1.7 个中文字符，与上述经验值吻合。
\n成本趋势提示：Token 成本与 Tokenizer 版本强相关。早期模型（如 GPT-3.5）中文压缩率较低（约 1 字 1.5~2 Token）。GPT-4o 使用 o200k_base Tokenizer（词表约 20 万），对中文压缩率有进一步提升；Qwen2.5 词表约 15 万，对中文常用词也有优化。实测数据因文本类型而异：新闻类约 1.5 字/Token，技术文档约 1.2 字/Token。
\n“趋近 1 字 1 Token”只适用于高频词汇，别拿它当成本估算基准。做预算前查一下当前模型版本的官方 Tokenizer 演示。
\nToken 划分直接影响模型理解能力。中文分词歧义和生僻字/低频专业术语的切分粒度，都会影响语义理解效果。
\nToken 化过程示例：
\n你好，我是 Guide。[你好] [，] [我是] [Guide] [。]![\"Token](\"https://oss.javaguide.cn/github/javaguide/ai/llm/llm-token-process.png\")
注意：实际 Token 切分由模型供应商的 Tokenizer 实现，不同供应商对相同文本可能产生不同的 Token 序列。
\nOpenAI 官方网页端 Tokenizer 工具：OpenAI Tokenizer
\n特殊 Token：除了文本内容对应的 Token，模型内部还会使用一些特殊标记，这些也会计入 Token 总数：
\n| 特殊 Token | 用途 | 示例 |
\n|
很多开发者第一次接大模型到业务系统里，都会经历一个很尴尬的阶段：本地 Demo 跑得挺顺，Prompt 里写一句“请返回 JSON”，模型也乖乖吐出一个对象；一到生产环境，问题就开始冒头。
\n有时它会在 JSON 前面加一句“好的，以下是结果”；有时少一个必填字段；有时本来应该是数字的 orderId 变成字符串；更麻烦的是，边界条件一复杂，模型会补出一个业务系统根本不认识的枚举值。解析器一报错，整条链路就断了。
问题不在于模型“不听话”，而在于我们把自然语言承诺错当成了工程契约。
\n结构化输出要解决的核心问题，是把“模型看起来像返回 JSON”升级成“后端可以稳定消费的结构化数据”。RAG 要靠它抽取证据，Agent 要靠它选择工具，客服系统要靠它分类工单，订单系统要靠它把自然语言请求变成可校验的参数。
\n本文会沿着一条主线展开：先看“只靠 Prompt 要 JSON”为什么不稳，再看怎么用 Schema 把输出变成契约，最后落到 Function Calling、MCP 和 Java 后端工具执行。
\n具体会讲清楚：
\n说明：OpenAI、Anthropic、Gemini、MCP 等产品和协议都在持续演进，生产系统应从官方文档最新展示获取能力描述。本文不引用未经验证的 benchmark，也不做绝对化性能结论。
\n先看一个非常常见的 Prompt：
\n请判断下面用户反馈属于哪类工单，返回 JSON。\n\n用户反馈：我付款成功了，但是订单一直显示待支付。模型可能返回：
\n{\n \"category\": \"payment\",\n \"priority\": \"high\",\n \"reason\": \"用户付款成功但订单状态未更新\"\n}看起来没问题。但这只是“看起来”。
\n当你把它接进后端系统，真正需要的是一份可以被程序稳定消费的契约。比如：
\ncategory 只能是 PAYMENT、LOGISTICS、AFTER_SALE、ACCOUNT。priority 只能是 LOW、MEDIUM、HIGH。confidence 必须是 0 到 1 之间的小数。reason 可以为空吗？最大长度是多少？NEED_MORE_INFO，还是继续猜？自然语言 Prompt 很难长期守住这些边界。常见翻车点主要有 5 类。
\n你要求模型返回 JSON，它大部分时候会返回 JSON，但不代表每次都只返回 JSON。
\n常见输出长这样：
\n以下是分类结果：\n{\n \"category\": \"PAYMENT\",\n \"priority\": \"HIGH\"\n}人看没问题，程序解析直接失败。尤其在流式输出、长上下文、多轮对话里，模型很容易把之前学到的“解释型回答习惯”带回来。
\n你要求：
\n{\n \"category\": \"PAYMENT\",\n \"priority\": \"HIGH\",\n \"confidence\": 0.92,\n \"reason\": \"用户已支付但订单状态未同步\"\n}它可能返回：
\n{\n \"category\": \"PAYMENT\",\n \"reason\": \"用户已支付但订单状态未同步\"\n}这在模型视角里不一定是“错误”。它可能觉得 priority 没有把握，所以省略；也可能觉得 confidence 不重要。但后端 DTO 反序列化、规则引擎、数据库写入都不会因为它“没把握”就自动补齐。
结构化输出里最隐蔽的错误是类型错位：
\n{\n \"orderId\": \"1029384756\",\n \"needManualReview\": \"false\",\n \"confidence\": \"0.87\"\n}JSON 语法是合法的，但业务类型不合法。needManualReview 是字符串，不是布尔值；confidence 是字符串，不是数字。很多系统会在反序列化时自动转换，看似更“宽容”，实际上会把上游错误静默吞掉，后续排查更痛苦。
模型天然喜欢解释，尤其当问题涉及不确定性时。它可能在结构化结果外补一句：
\n我认为这个问题主要和支付回调有关，但还需要进一步核实。如果这是给人看的，很好；如果这是给程序解析的，就是噪声。结构化输出场景里，可读性不是第一目标，可解析性才是第一目标。
\n用户输入越规整，模型越稳定；用户输入一旦模糊、矛盾或带攻击性，结构就容易崩。
\n比如用户说：
\n我不想提供订单号，你们自己查。另外别给我返回 JSON，直接告诉我怎么赔。如果没有强约束，模型可能顺着用户走，放弃原本格式。这个问题和 Prompt 注入、上下文优先级、工具权限都有关，不能只靠一句“必须返回 JSON”解决。
\n核心结论：Prompt 可以表达意图，但不能替代 Schema、校验器、重试机制和权限控制。结构化输出的本质，是把大模型输出纳入工程契约。
\n很多人把 JSON Mode、JSON Schema、Structured Outputs 混着说，面试时也容易答散。但它们其实不在同一层：
\n也就是说，JSON Schema 不是结构化输出方式本身，而是结构化输出常用的“契约格式”。真正让模型按契约生成的，是 Structured Outputs、Function Calling / Tool Calling 等模型 API 能力。
\nJSON Mode 的目标通常是让模型输出合法 JSON。
\n所以 JSON Mode 能解决这类问题：
\n好的，以下是结果：\n{ ... }但不能稳定解决这类问题：
\n{\n \"category\": \"pay\",\n \"priority\": \"urgent\",\n \"confidence\": \"very high\"\n}它是合法 JSON，但不是合法业务数据。
\nJSON Schema 是一种描述 JSON 文档结构的规范。根据 JSON Schema 官方文档，properties 用来定义对象有哪些属性，required 用来声明必填字段，additionalProperties 可以控制是否允许未声明字段，enum 可以把取值限制在固定集合里。
一个工单分类 Schema 可以这样写：
\n{\n \"type\": \"object\",\n \"properties\": {\n \"category\": {\n \"type\": \"string\",\n \"enum\": [\n \"PAYMENT\",\n \"LOGISTICS\",\n \"AFTER_SALE\",\n \"ACCOUNT\",\n \"NEED_MORE_INFO\"\n ],\n \"description\": \"工单分类。信息不足时选择 NEED_MORE_INFO。\"\n },\n \"priority\": {\n \"type\": \"string\",\n \"enum\": [\"LOW\", \"MEDIUM\", \"HIGH\"],\n \"description\": \"处理优先级。涉及资金损失、无法下单、批量影响时优先级更高。\"\n },\n \"confidence\": {\n \"type\": \"number\",\n \"minimum\": 0,\n \"maximum\": 1,\n \"description\": \"分类置信度，范围为 0 到 1。\"\n },\n \"reason\": {\n \"type\": \"string\",\n \"description\": \"分类依据，控制在 80 个中文字符以内。\"\n }\n },\n \"required\": [\"category\", \"priority\", \"confidence\", \"reason\"],\n \"additionalProperties\": false\n}这份 Schema 对后端很有价值，但它本身不会让模型“自动听话”。你需要把它传给支持结构化输出的 API，或者在服务端用校验器校验模型输出。
\nStructured Outputs 通常指供应商提供的结构化输出能力。它会把 JSON Schema 或类似 Schema 传入模型调用，让模型输出符合指定结构的数据。不同厂商对"符合 Schema"的保证强度不同：OpenAI strict 模式在解码阶段做约束，理论上语法层零违规；其他厂商更多依赖 prompting 加解码偏置，长文本和复杂工具组合场景下仍可能出现枚举越界或字段缺失。
\n这里要注意一个工程细节：不同供应商支持的 JSON Schema 子集并不完全一致。比如某些关键字（pattern、format）、递归 $ref、组合关键字（allOf / oneOf / anyOf）在不同 API 中支持程度不同。真正落地时，不要照搬完整 JSON Schema 规范的所有能力，先读对应供应商的"supported schemas"或工具定义文档。
| 对比维度 | JSON Mode | JSON Schema | Structured Outputs |
\n|
AI 应用开发面试很少只问“概念是什么”。更常见的是顺着一个项目往下追：为什么这样设计，出了问题怎么排查，上线后怎么评测，成本和安全怎么管。
\n这份 AI 应用开发面试题专题 面向 AI 工程师、AI 应用开发和后端转 AI 岗位复习，把“大模型基础、AI Agent、RAG、AI 系统设计”这些问题串成一条复习路线。
\nAI Agent 面试最容易出现两种极端：一种是把 Agent 讲得像“全自动数字员工”，什么都能自己规划、自己执行；另一种是把 Agent 讲得像“几个 Prompt 串起来”，完全看不出和普通工作流有什么区别。
\n真正好的回答要落到中间：Agent 的核心不是神秘的自主意识，而是一套围绕大模型构建的任务执行系统。它要有运行循环、上下文供给、记忆机制、工具调用、安全边界、失败恢复和评测闭环。
\n这份 AI Agent 面试题根据 AI 专栏现有文章整理，重点不是让你背“Agent 是什么”，而是帮你学会这样回答：
\n如果能沿着这条线回答，面试官通常会觉得你不是只看过概念，而是真的思考过工程落地。
\nAgent 题本质上在考“复杂 AI 应用怎么编排”。可以按下面几个层次准备。
\n| 考察方向 | 面试官想确认什么 | 常见扣分点 |
\n|
AI 应用开发面试和传统后端面试不太一样。
\n传统后端面试更多围绕 Java、JVM、并发、MySQL、Redis、消息队列、分布式和系统设计展开。AI 应用开发面试除了这些基础，还会继续追问：
\n这些题不是背几个术语就能过的。AI 应用开发面试更看重的是：你能不能把大模型、RAG、Agent、工具调用和系统设计放到真实工程里理解。
\n所以，这篇文章会作为 AI 面试题的总入口。你可以先通过这里建立知识地图，再进入具体模块刷题和回到原文补底层理解。
\n| 面试题模块 | 适合重点复习的人群 | 主要覆盖内容 |
\n|
AI 系统设计题和传统后端系统设计很像，但多了一个特别麻烦的变量：大模型。
\n传统服务通常遵循确定性的输入输出，出了问题可以按日志、链路、数据库状态逐步定位。AI 应用不一样，模型输出有随机性，Prompt 会影响行为，RAG 证据会影响答案，工具调用可能失败，供应商可能限流，评测还不能只靠单元测试。
\n所以，AI 系统设计面试真正考的是：你能不能把一个 Prompt Demo 设计成稳定、可观测、可评测、可回滚、可治理的生产系统。
\n这份 AI 系统设计面试题根据 AI 专栏现有文章整理，适合 2 年以上开发者复习。建议你按这条主线准备：
\nAI 系统设计题一般不会满足于“我用 LangChain 搭一个 RAG”。面试官更想看你是否有生产级架构意识。
\n| 考察方向 | 面试官想确认什么 | 常见扣分点 |
\n|
很多同学准备大模型面试时，第一反应是去背 Transformer、Attention、RLHF 这些词。不是说这些不重要，但对大部分后端转 AI 应用开发、AI 工程应用岗位来说，面试官更关心的是另一件事：
\n你是不是真的理解大模型调用链路里的工程约束。
\n比如 Token 为什么会影响成本和延迟？上下文窗口为什么不是越大越好？Temperature 为什么会影响结构化输出稳定性？Function Calling 为什么不能让模型直接执行真实业务操作？这些问题看起来基础，答不好就会暴露一个信号：你可能只是调过 API，还没有把大模型当作生产系统里的一个不稳定外部依赖来治理。
\n这份大模型基础面试题主要根据 AI 专栏现有文章整理。它不是让你机械背题，而是帮你建立一条复习主线：
\n大模型基础题表面上问概念，实际考的是工程判断。你可以按下面这张表来理解。
\n| 考察方向 | 面试官想确认什么 | 常见扣分点 |
\n|
RAG 是 AI 应用开发里最容易被低估的模块。
\n很多人以为 RAG 就是“文档切块 -> 转向量 -> 存向量库 -> 检索 -> 拼 Prompt”。Demo 阶段这么理解没问题，但一到真实业务，问题马上变复杂：文档解析不干净、Chunk 切碎了语义、Embedding 模型选错、召回结果不准、权限过滤漏了、知识库更新后旧版本还在、模型拿到证据却没有正确回答。
\n所以，RAG 面试真正考的不是“你会不会接向量数据库”，而是：你能不能把一个检索增强生成系统拆成可定位、可优化、可评测、可更新的工程链路。
\n这份 RAG 面试题根据 AI 专栏现有文章整理。建议你用下面这条主线复习：
\nRAG 题通常会从概念开始，但很快会追到排查和优化。你可以按下面几个层次准备。
\n| 考察方向 | 面试官想确认什么 | 常见扣分点 |
\n|
Prompt Demo 能跑起来，不代表系统能长期稳定地跑。生产环境还会追问模型怎么路由、失败怎么兜底、Token 成本怎么算、回答质量怎么回归、敏感工具怎么管。
\n这份 AI 系统设计专题 面向想把 Prompt Demo 做成生产级 AI 应用的开发者，重点关注架构分层、模型网关、RAG、Memory、Tool 调用、可观测、评测闭环、安全治理和实时语音链路。
\n大家好，我是 Guide。
\n很多团队做 AI 应用时，第一天都很兴奋：写一个 Prompt，调一下大模型 API，页面上很快就能跑出一个“智能客服”“知识库问答”或者“报告生成助手”。
\n然后进入第二周，问题开始冒出来：同一个问题今天答对、明天答偏；用户没有权限的资料被检索进上下文；Prompt 改了一行，线上效果突然变差却回滚不了；模型调用超时，前端一直转圈；Token 账单飙升，没人知道钱花在哪；出了事故，只能从一堆日志里猜当时模型到底看到了什么。
\n分水岭就在这里：Prompt Demo 证明的是模型能回答，生产系统要证明的是系统能长期、稳定、可控地回答。
\n本文接近 1.5w 字，建议收藏，通过本文你将搞懂：
\n先看一个最常见的 Demo：
\n前端输入问题 -> 后端拼 Prompt -> 调用模型 API -> 返回答案这条链路能演示产品想法，但它缺了生产系统最关键的 6 件事。
\n| 维度 | Prompt Demo | 生产级架构 |
\n|
大家好，我是 Guide。
\n很多开发者第一次做 AI 语音应用时，都会有一个很朴素的想法：用户说话，转成文字，丢给大模型，再把回答播出来。
\n听起来就是三段调用：ASR -> LLM -> TTS。
\n真推到生产环境，问题马上来了：用户还没说完，系统已经误判结束；用户想打断，AI 还在自顾自朗读；会议室里有空调声和键盘声，ASR 开始胡乱转写；网络稍微抖一下，下行音频就卡成一段一段；看起来模型很聪明，真正说话时却像慢半拍的电话客服。
\nAI 语音系统最折磨人的地方就在这里：它不是把文本 Agent 接上麦克风和扬声器这么简单，而是一套实时音频工程、语音模型、对话状态和端云协同共同组成的系统。
\n本文接近 2w 字，建议收藏，通过本文你将搞懂：
\n为避免阅读时产生困惑，本文涉及的核心术语做如下说明：
\n在说技术之前，先搞清楚我们到底在解决什么问题。
\n语音 Agent 的本质目标是让机器能像人一样自然地对话。这听起来简单，但和文字对话相比，语音多了几个维度：
\n市面上常见的语音交互有两类：
\n这两者的底层逻辑完全不同。本文主要讨论后者，也就是大模型语音 Agent 的工程化落地。
\nASR（Automatic Speech Recognition）看起来就是“音频进、文字出”，但背后至少包含三个判断：
\n比如用户说“帮我查一下 Java 21 的虚拟线程”，ASR 要同时识别中文、英文、数字和技术词。如果识别成“加瓦二十一的虚拟线程”，后面的 LLM 再强也得先猜半天。
\n| 类型 | 代表方案 | 优势 | 短板 | 适合场景 |
\n|
面试官看了一眼我的 AI 项目架构图，突然停住了。
\n“你这个 Agent，每次都是调用旗舰模型？”
\n我点点头：“对啊，肯定得用地表最强的啊，效果好。”
\n他沉默了两秒，然后开口：“那意图分类、标题生成、JSON 修复、简单摘要，也全走 Opus？”
\n我开始有点心虚：“主要是为了稳定……”
\n面试官没说话，等了几秒，又问：“那如果哪天旗舰模型限流了呢？意图分类这种小任务，每个月烧掉的钱你算过吗？”
\n很多朋友第一次做 AI 应用都会踩这个坑：以为模型越强，系统越稳。实际上，生产环境里真正难的不是“选一个最强模型”，而是根据任务类型、成本、延迟、风险，把不同请求送到合适的模型上。
\n这就是 LLM Gateway 要解决的问题。
\n本文接近 1.2w 字，建议收藏，通过本文你将搞懂：
\nLLM Gateway 可以简单理解成：API 网关 + 模型调用控制面。
\n传统 API 网关是位于客户端与后端服务之间的统一入口，所有客户端请求先经过网关，再由网关路由到具体的目标服务，主要管 HTTP 流量：鉴权、限流、转发、日志、熔断。
\n
LLM Gateway 则面对的是大模型调用，它除了处理普通 API 问题，还要处理模型特有的问题：模型选择、Token 预算、上下文长度、供应商差异、流式输出、工具调用、结构化响应、成本统计、Prompt 版本和输出质量。
\n更准确地说，LLM Gateway 是应用层和模型供应商之间的一层控制面。
\n![\"LLM](\"https://oss.javaguide.cn/github/javaguide/ai/llm/llm-gateway-overview.png\")
业务代码不直接关心 OpenAI、Anthropic、Gemini、Qwen、DeepSeek、私有化模型分别怎么调，而是统一向 Gateway 发一个标准请求。Gateway 根据场景、预算、延迟、模型可用性和业务策略，决定调用哪个模型、走哪个供应商、是否需要重试、是否需要降级、怎么记录日志。
\n一个最简易版的 Gateway 可能只有统一封装和日志；一个生产级 Gateway 往往还会管理模型路由、Token 预算、限流、成本归因、缓存、审计和安全策略。
\n所以，LLM Gateway 不是“把请求转发一下”。
\n它是 AI 应用的模型调用控制面。
\n很多团队第一次做 AI 应用时，会直接在业务服务里写模型调用：
\nController -> Service -> OpenAI SDK -> 返回答案这条链路很短，开发体验也好。但只要线上规模稍微起来，问题会集中暴露。
\n| 直连模型的典型问题 | 线上表现 | Gateway 对应能力 |
\n|
RAG 最容易被低估的地方，是它看起来像“文档切块 + 向量检索”，但真正影响效果的环节远不止这两个。
\n这份 RAG 专题 面向企业知识库问答、智能客服、文档助手和内部搜索等场景，按文档进入系统后的真实链路展开：解析、清洗、切分、向量化、索引、召回、重排、生成、更新和评测。
\n第一次做企业知识库问答时，通常会经历一个很相似的阶段：文档切块、Embedding、向量库、Top-K 检索、把片段塞给大模型。
\nDemo 很顺，领导问几个制度类问题也能回答。然后业务同事突然问：
\n\n\n“这几个部门过去半年反复提到的风险点是什么？它们之间有什么关联？”
\n
向量 RAG 就开始力不从心了。
\n它可能找到几个相似片段，却很难把“部门”“风险”“项目”“供应商”“时间线”这些对象串成一张关系网。更麻烦的是，答案往往来自多份文档的组合推理，而不是某一个 Chunk 里现成的一句话。
\n这就是 GraphRAG 要解决的问题。
\n下面 Guide 会把 GraphRAG 的核心概念和工程实践拆开讲清楚，重点放在它和传统向量 RAG 到底差在哪、什么时候该上、什么时候别碰。
\n全文接近 1w 字，建议先收藏。主要覆盖：
\n![\"什么是](\"https://oss.javaguide.cn/github/javaguide/ai/rag/rag-simplified-architecture-diagram.jpeg\")
RAG（Retrieval-Augmented Generation，检索增强生成）就是把信息检索和生成式大语言模型结合起来的框架。
\n它的核心思想是：在让 LLM 回答问题或生成文本之前，先从数据库、文档集合、企业知识库等外部知识源中检索相关上下文，再把“原始问题 + 检索上下文”一起交给 LLM。这样可以让模型回答得更准确、更及时，也更符合特定领域知识。
\n传统 RAG 的检索对象通常是 Chunk，也就是一个个文本片段。它很适合回答“答案就在某几个片段里”的问题，比如制度问答、API 文档问答、知识库局部事实查询。
\n![\"什么是](\"https://oss.javaguide.cn/github/javaguide/ai/rag/graphrag-simplified-architecture-diagram.png\")
GraphRAG（Graph-based Retrieval-Augmented Generation）可以理解为：在传统向量检索之外引入知识图谱，把文档中的实体、关系和结构化上下文显式建模。检索时除了召回相似片段，还会沿着图关系收集证据，再交给大模型生成答案。
\n注意，GraphRAG 的重点不是“用了图数据库”，而是检索对象变了。
\n传统向量 RAG 检索的是 Chunk，也就是一个个文本片段。GraphRAG 检索的是一张“知识关系网”里的节点、边、路径、社区摘要，再结合原始文本证据回答问题。
\n打个比方：
\n向量 RAG 擅长判断“这段话和我的问题像不像”，GraphRAG 更擅长理解“这些对象之间到底怎么连起来”。
\n![\"传统向量](\"https://oss.javaguide.cn/github/javaguide/ai/rag/graphrag-vector-rag-limitation.png\")
向量 RAG 的底层逻辑很直接：
\n这套方案在“局部事实问答”里很好用。比如：
\n因为答案大概率藏在某几个局部片段里，只要召回足够准，模型就能整理出结果。
\n但复杂知识问答的问题是：答案往往不在一个片段里，而在片段之间的关系里。
\n切块是向量 RAG 的必要工程手段，但它天然会打断上下文。
\n一份文档里，第一章定义了某个系统，第三章写了负责人，第五章提到它依赖的数据库，第七章记录了最近一次事故。切成 Chunk 之后，这些信息分散在不同文本块里。
\n向量检索只能判断“哪个文本块和问题最像”，却不知道这些文本块在业务上属于同一个对象。
\n这就是向量 RAG 的典型盲点：语义相似不等于关系完整。
\n假设用户问：
\n\n\n“A 系统的负责人最近参与过哪些和支付链路相关的故障复盘？”
\n
这个问题至少包含几层跳转：
\n向量 RAG 可能召回“A 系统说明”或“支付故障复盘”，但它不天然具备沿着“系统 -> 负责人 -> 复盘 -> 链路”这条关系链路扩展证据的能力。
\n还有一类问题更麻烦：
\n这类问题不是找“最相似的几段话”，而是要对整个语料做聚合、归纳和主题分析。Top-K 检索只能看到局部窗口，容易出现两种失败：
\n很多人这时会把 Top-K 从 5 调到 20，再加 rerank，再加查询改写。短期能缓解，但底层问题还在：你仍然在用片段相似度解决结构推理问题。
\n![\"GraphRAG](\"https://oss.javaguide.cn/github/javaguide/ai/rag/graphrag-vs-rag.png\")
| 维度 | 传统向量 RAG | GraphRAG |
\n|
做企业知识库问答时，很多团队的第一反应都是：把文档全塞给大模型，让它自己读。
\n文档少的时候，这招确实能跑。一旦知识库涨到几十万字，问题很快就出来了：每次请求都可能撞 Token 上限，刚更新的内容模型也不一定知道。更现实一点，企业文档还要考虑权限、溯源、成本和延迟，不能靠“全塞进去”硬扛。
\nRAG 要做的事其实很直接：在让大模型回答之前，先从知识库里找出相关内容，再把这些内容交给模型，让它基于证据生成答案。
\n这篇文章接近 6200 字，主要讲清楚几件事：
\nRAG（Retrieval-Augmented Generation，检索增强生成） 就是把信息检索和大语言模型绑在一起用。系统先从知识库里检索出和当前问题相关的片段，知识库可以是数据库、文档集合，也可以是企业内部系统。然后把这些片段和原始问题一起喂给 LLM，让模型基于检索内容回答，而不是只靠训练时记住的知识。
\n
![\"RAG（检索增强生成）如何解决](\"https://oss.javaguide.cn/github/javaguide/ai/rag/rag-llm-challenges.png\")
LLM 训练数据再大，也绕不开几个问题。RAG 正好可以在这些地方进行弥补。
\n第一是知识时效性。
\n预训练模型的知识会停在训练数据截止时间点。训练后发生的新事件、新政策、新产品文档，模型默认是不知道的，除非通过联网、工具调用或外部知识注入来补。RAG 的做法是动态检索外部知识源，把最新的相关内容直接送给 LLM，让它不用只依赖参数里的旧知识。
\n第二是私有数据访问。
\n企业内部的产品文档、知识库、客户数据，不可能让公开 LLM 随便访问。RAG 在用户提问时只提取和问题相关的片段给 LLM，不需要暴露全部数据，模型也能基于企业自己的知识回答。
\n第三是幻觉问题。
\nLLM 编造事实这件事大家都遇到过。RAG 通过提供明确参考文本，让模型尽量基于证据回答，确实能降低幻觉概率。但别指望它彻底消除幻觉。检索错误、上下文噪声、引用错配、模型不遵循指令，都可能导致错误答案。生产级 RAG 通常还要配引用校验、答案评估、拒答机制和人工反馈闭环。
\nRAG 最适合“答案依赖外部资料，并且资料会变化或很长”的场景。它先从知识库里检索相关内容，再让大模型基于检索结果生成回答，减少胡编，同时提高可追溯性。
\n常见场景包括这些：
\n不是所有问题都值得上 RAG。很多企业保留传统搜索，不是因为不知道 RAG 好用，而是用户需求本来就没到“生成答案”这一步。
\n如果用户只是想找一份制度原文、某个接口文档、一个合同模板，搜索框反而更直接。输入关键词，返回文档列表，用户自己点开确认，链路短、成本低、结果也更可控。RAG 则要先检索，再组织上下文，最后交给 LLM 生成答案。只要经过生成，就会多出延迟、Token 成本和总结偏差的风险。
\n所以选传统搜索还是 RAG，先看用户到底想要什么：是“帮我找到材料”，还是“帮我读完材料并给出结论”。
\n| 维度 | 传统搜索（搜索框） | RAG（检索 + 生成） |
\n|
\n\n术语约定：本文中 "Chunking" 与“切分”、"Embedding" 与“嵌入”、"Chunk" 与“块” 含义相同，统一使用中文表述以保持可读性。
\n
很多团队第一次搭 RAG 系统时，都会经历一个特别有意思的阶段：买最贵的向量数据库、调最牛的 embedding 模型、上线之后发现答案还是一塌糊涂。
\n根因往往不在检索环节，而在更上游——文档根本没有被正确解析，切分的时候把表格列拆散了，Chunk 把条件和结论切成两半，页眉页脚被当成正文入了索引。
\n换句话说：RAG 的瓶颈通常不在检索层，而在文档进入索引之前的那段管线。
\n这个问题在 PDF 多栏布局、Word 标题层级、Excel 字段关联、扫描件 OCR 等场景下尤其突出。很多团队以为换了更强的 embedding 模型就能解决，实际上只是让错误表达得更稳定而已。
\n这篇文章就把这条管线从头到尾拆开来看。接近 1w 字，建议收藏，主要覆盖这几块：
\n在说具体策略之前，先把链路画清楚。文档从上传到进入向量库，中间要经过至少六个环节：
\n![\"RAG](\"https://oss.javaguide.cn/github/javaguide/ai/rag/rag-document-processing-overall-link.png\")
这张图里有个容易忽略的点：质量校验不应该只发生在入库之后。在 Chunking 阶段做完采样校验，能提前发现问题，避免把低质量数据大批量写入向量库。
\n\n\n注：本图简化展示了 Chunking 阶段的校验，完整的分层校验策略见后文“如何设计分层校验策略”章节，涵盖格式校验、解析校验和 Chunking 校验三层。
\n
每个环节的核心风险：
\n| 环节 | 典型问题 | 最终影响 |
\n|
第一个企业知识库 RAG 系统上线后，很多团队都会碰到一个很真实的问题：文档明明更新了，回答还是老样子。
\n这时候先别急着怪 LLM。更常见的原因是知识库没有同步更新，或者更新链路只做了“写入新内容”，没有处理旧版本、权限、索引一致性这些细节。文档变更频繁之后，问题会更明显：每次都全量重建索引，成本和耗时扛不住；只更新变化部分，又怕漏掉旧块；只插入新向量，不清理旧版本，过期内容还会继续被召回；换了 Embedding 模型，历史数据到底要不要全部重索引，也绕不开。
\n这些问题背后，其实是 RAG 知识库的动态性、准确性、一致性、可回滚、可观测这几件事没有处理好。
\n这篇文章讲 RAG 知识库更新的工程实践，全文接近 8000 字。重点看几个问题：
\n在讲具体方案之前，先把目标说清楚。
\n知识库更新要解决的不是“怎么写一个同步任务”，而是更新之后，系统回答还能保持准、快、不越权，并且出了问题能定位、能恢复。
\n动态性指的是，文档变了，索引要能跟上。这个“及时”不一定都是秒级，可能是分钟级，也可能是天级，取决于业务对实时性的要求。内部制度库也许一天同步一次就够，客服知识库和合规条款就可能需要更快。
\n准确性指的是，更新后召回的内容要和当前文档一致，不能文档已经改了，模型还在引用旧版本。这个问题一旦发生，用户感知会很明显。
\n一致性更麻烦。同一个文档有不同版本，向量库、元数据库、全文检索又是不同系统，任何一端漏写或延迟，都可能导致结果不一致。
\n可回滚是为了出故障时能快速切回上一个健康状态，而不是靠人工临时修数据。可观测则要求更新过程能监控，更新结果能评估，失败原因能追到具体环节。
\n这些目标看起来像常识，但很多项目只做了第一步“更新”，后面几步全靠运气。结果就是文档改了十版，回答还停在第一版；删了一篇敏感文档，过了几个月还能被召回出来。
\n这一点要单独拎出来讲：索引时用的 Embedding 模型，必须和查询时用的模型一致。
\nEmbedding 模型会把文本转成向量，不同模型的向量空间并不通用。同一句话用 OpenAI 的 text-embedding-3-small 编码，和用 sentence-transformers 的 all-MiniLM-L6-v2 编码，得到的向量没有可比性。如果索引用模型 A，查询用模型 B，就等于在两个不同空间里算相似度。
具体表现还要看向量维度。如果维度不同，通常无法放进同一个索引，很多向量库会直接拒绝插入或查询。如果维度相同但模型不同，相似度分数也不具备可比性，召回结果不能信。它不是简单的“随机”，而是整个排序基础已经坏了。
\n生产里最容易忽视的有两个场景。
\n第一个是模型升级。 业务方觉得新模型效果更好，想从 text-embedding-3-small 切到 text-embedding-3-large。这意味着历史数据必须重新编码、重新入索引。工程上可以用双索引并行和灰度切流降低风险，但重建这一步绕不过去。
第二个是本地模型和 API 模型混用。 测试环境用本地 sentence-transformers，生产环境用 OpenAI API。这种差异在团队协作里特别常见，测试看起来正常，上线后召回率直接腰斩。
\n比较稳的做法是把 Embedding 模型信息写进元数据，每次查询时都校验模型版本。不匹配时，要么拒绝查询，要么打警告日志并降级到更保守的召回策略。
\n| 字段 | 说明 | 示例 |
\n|
第一次做 RAG 时，很多人的体验都差不多：文档切了，向量库建了，Top-K 也调大了，模型还是一本正经地胡说八道。
\n更难受的是，问题可能出在文档解析、Chunk 切分、上下文质量等多个环节，而不是单纯的 embedding 或 Top-K 参数。
\n调一个企业知识库问答时，很容易陷入一个误区：一开始疯狂换 embedding 模型，结果线上错误率没明显下降。把失败样本拆开看才发现，60% 的问题根本不是向量相似度不够，而是 PDF 表格被解析坏了、Chunk 把条件和结论切开了、重排前的候选池里没有正确片段。
\nRAG 优化的第一条经验是：它本质上是数据、切分、索引、召回、重排、上下文、生成、评估共同组成的系统工程，不是单点调参。
\n这篇文章就把这条链路上每个环节的优化方法拆开来讲。接近 1.5w 字，建议收藏。主要内容：
\n先把心智模型摆正。
\nRAG 更像一条证据加工流水线：原始资料先被解析、清洗、切块、打标签、建索引；用户问题进来后，再经过查询理解、召回、重排、上下文构建，最后才交给 LLM 生成答案。
\n这条链路里任何一环出问题，都会传染到下游。
\n| 环节 | 典型问题 | 最终表现 |
\n|
前段时间面某大厂的时候，面试官问我：“你们 RAG 系统的向量检索怎么做的？”
\n我当时回答：“用 MySQL 存 Embedding，查询时遍历计算相似度。”
\n面试官的表情已经说明问题了。我们当时知识库有 50 多万条 Chunk，每次查询都要全表扫描，平均响应时间 3 秒以上。对一个问答系统来说，这个延迟基本等于劝退用户。
\n后来才意识到，这就是典型的暴力搜索。Demo 阶段能跑，生产环境根本扛不住。真正上线时，至少要考虑向量数据库和 ANN 索引。
\n向量存储和向量索引是大多数 RAG 应用绕不开的基础设施。数据规模、延迟要求、召回要求一上来，靠遍历计算相似度很快就会出问题。
\n这篇文章围绕几个面试高频问题展开：
\n向量数据库并不是直接理解文本。它存储和检索的是 Embedding。
\nEmbedding 的过程是：把一段文本交给 Embedding 模型，模型输出一个固定维度的稠密向量。可以粗略理解成“文本语义坐标”。两段文本语义越接近，它们在向量空间里的距离通常也越近。
\n![\"Embedding](\"https://oss.javaguide.cn/github/javaguide/ai/rag/rag-embedding-vector-retrieval.png\")
RAG 的向量检索链路可以简化成这样：
\n文档 Chunk -> Embedding 模型 -> 文档向量 -> 写入向量数据库\n用户问题 -> Embedding 模型 -> 查询向量 -> 检索最相似的 Top-K 文档向量基础概念可以看 RAG 基础篇。本文重点放在后半段：这些向量怎么高效存储、索引和检索。
\nRAG（Retrieval-Augmented Generation）的核心是语义检索。系统把文档和用户问题都转成高维向量，再找出最相似的 Top-K 片段，作为 LLM 的上下文。
\n所以 RAG 场景里真正要解决的，不只是“能不能存 Embedding”，而是能不能在大规模高维向量里，低延迟找出最相关的 Top-K。
\n传统关系型数据库可以存向量，也可以通过函数或 SQL 表达式计算相似度。但如果没有专门的向量索引，通常只能全表扫描，很难支撑生产级低延迟检索。当 Chunk 数量达到几十万、百万甚至更高时，就需要引入向量数据库、向量搜索引擎，或者 PostgreSQL + pgvector 这类带向量索引能力的数据库扩展。
\n![\"RAG](\"https://oss.javaguide.cn/github/javaguide/ai/rag/rag-why-need-vector-store.png\")
Embedding 通常是 768 到 3072 维的稠密向量。没有向量索引时，即使数据库能计算余弦相似度、内积或欧氏距离，也很难在大规模数据上快速完成 Top-K 检索。
\n暴力搜索就是遍历全表计算距离，复杂度是 O(n)。以 100 万条 1024 维向量为例，单次查询大约要做：
\n1,000,000 × 1,024 次乘法运算实际延迟很容易到秒级，具体取决于硬件和实现。对实时问答系统来说，秒级延迟基本不可接受。
\nANN（Approximate Nearest Neighbor，近似最近邻）检索就是为了解这个问题。向量数据库通过图导航、空间划分、量化等方式减少距离计算次数，不再每次都把所有向量算一遍。
\nANN 的价值不在于永远返回 100% 精确的最近邻，而是在召回率、延迟和资源消耗之间做工程取舍。在合适的索引参数和硬件条件下，ANN 通常能把百万级向量检索从秒级暴力扫描优化到几十毫秒甚至更低。不过具体效果必须拿业务数据、Top-K、过滤条件、并发和召回率目标来测，不能只看理论复杂度。
\n| 指标 | 暴力搜索 | ANN 索引检索 |
\n|
\n\n\n本文转自：http://www.guoyaohua.com/sorting.html，JavaGuide 对其做了补充完善。
\n
所谓排序，就是使一串记录，按照其中的某个或某些关键字的大小，递增或递减的排列起来的操作。排序算法，就是如何使得记录按照要求排列的方法。排序算法在很多领域得到相当地重视，尤其是在大量数据的处理方面。一个优秀的算法可以节省大量的资源。在各个领域中考虑到数据的各种限制和规范，要得到一个符合实际的优秀算法，得经过大量的推理和分析。
\n常见的内部排序算法有：插入排序、希尔排序、选择排序、冒泡排序、归并排序、快速排序、堆排序、基数排序等，本文只讲解内部排序算法。用一张表格概括：
\n| 排序算法 | 时间复杂度（平均） | 时间复杂度（最差） | 时间复杂度（最好） | 空间复杂度 | 排序方式 | 稳定性 |
\n|
这份 算法专题 面向算法面试和基础能力训练，整理经典算法思想、常见数据结构 LeetCode 题目、字符串、链表、剑指 Offer 和排序算法。
\n贪心的本质是选择每一阶段的局部最优，从而达到全局最优。
\n455.分发饼干：https://leetcode.cn/problems/assign-cookies/
\n121.买卖股票的最佳时机：https://leetcode.cn/problems/best-time-to-buy-and-sell-stock/
\n122.买卖股票的最佳时机 II：https://leetcode.cn/problems/best-time-to-buy-and-sell-stock-ii/
\n55.跳跃游戏：https://leetcode.cn/problems/jump-game/
\n45.跳跃游戏 II：https://leetcode.cn/problems/jump-game-ii/
\n动态规划中每一个状态一定是由上一个状态推导出来的，这一点就区分于贪心，贪心没有状态推导，而是从局部直接选最优的。
\n经典题目：01 背包、完全背包
\n509.斐波那契数：https://leetcode.cn/problems/fibonacci-number/
\n746.使用最小花费爬楼梯：https://leetcode.cn/problems/min-cost-climbing-stairs/
\n416.分割等和子集：https://leetcode.cn/problems/partition-equal-subset-sum/
\n518.零钱兑换：https://leetcode.cn/problems/coin-change-ii/
\n647.回文子串：https://leetcode.cn/problems/palindromic-substrings/
\n516.最长回文子序列：https://leetcode.cn/problems/longest-palindromic-subsequence/
\n回溯算法实际上一个类似枚举的搜索尝试过程，主要是在搜索尝试过程中寻找问题的解，当发现已不满足求解条件时，就 “回溯” 返回，尝试别的路径。其本质就是穷举。
\n经典题目：8 皇后
\n77.组合：https://leetcode.cn/problems/combinations/
\n39.组合总和：https://leetcode.cn/problems/combination-sum/
\n40.组合总和 II：https://leetcode.cn/problems/combination-sum-ii/
\n78.子集：https://leetcode.cn/problems/subsets/
\n90.子集 II：https://leetcode.cn/problems/subsets-ii/
\n51.N 皇后：https://leetcode.cn/problems/n-queens/
\n将一个规模为 N 的问题分解为 K 个规模较小的子问题，这些子问题相互独立且与原问题性质相同。求出子问题的解，就可得到原问题的解。
\n经典题目：二分查找、汉诺塔问题
\n108.将有序数组转换成二叉搜索数：https://leetcode.cn/problems/convert-sorted-array-to-binary-search-tree/
\n148.排序列表：https://leetcode.cn/problems/sort-list/
\n23.合并 k 个升序链表：https://leetcode.cn/problems/merge-k-sorted-lists/
\n", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "计算机基础" ] }, { "title": "常见数据结构经典LeetCode题目推荐", "url": "https://codingmap.strova.top/cs-basics/algorithms/common-data-structures-leetcode-recommendations.html", "id": "https://codingmap.strova.top/cs-basics/algorithms/common-data-structures-leetcode-recommendations.html", "summary": "按数据结构类别整理经典 LeetCode 题目清单，聚焦高频与核心考点，助力系统化刷题与巩固。重点围绕 数组、链表、栈与队列、二叉树、算法 等内容展开。结合 CodingMap 知识体系梳理 计算机基础 / 算法 / Common Data Structures Leetcode Recommendations.Ht。", "content_html": "704.二分查找：https://leetcode.cn/problems/binary-search/
\n80.删除有序数组中的重复项 II：https://leetcode.cn/problems/remove-duplicates-from-sorted-array-ii
\n977.有序数组的平方：https://leetcode.cn/problems/squares-of-a-sorted-array/
\n707.设计链表：https://leetcode.cn/problems/design-linked-list/
\n206.反转链表：https://leetcode.cn/problems/reverse-linked-list/
\n92.反转链表 II：https://leetcode.cn/problems/reverse-linked-list-ii/
\n61.旋转链表：https://leetcode.cn/problems/rotate-list/
\n232.用栈实现队列：https://leetcode.cn/problems/implement-queue-using-stacks/
\n225.用队列实现栈：https://leetcode.cn/problems/implement-stack-using-queues/
\n347.前 K 个高频元素：https://leetcode.cn/problems/top-k-frequent-elements/
\n239.滑动窗口最大值：https://leetcode.cn/problems/sliding-window-maximum/
\n105.从前序与中序遍历构造二叉树：https://leetcode.cn/problems/construct-binary-tree-from-preorder-and-inorder-traversal/
\n117.填充每个节点的下一个右侧节点指针 II：https://leetcode.cn/problems/populating-next-right-pointers-in-each-node-ii
\n236.二叉树的最近公共祖先：https://leetcode.cn/problems/lowest-common-ancestor-of-a-binary-tree/
\n129.求根节点到叶节点数字之和：https://leetcode.cn/problems/sum-root-to-leaf-numbers/
\n102.二叉树的层序遍历：https://leetcode.cn/problems/binary-tree-level-order-traversal/
\n530.二叉搜索树的最小绝对差：https://leetcode.cn/problems/minimum-absolute-difference-in-bst/
\n200.岛屿数量：https://leetcode.cn/problems/number-of-islands/
\n207.课程表：https://leetcode.cn/problems/course-schedule/
\n210.课程表 II：https://leetcode.cn/problems/course-schedule-ii/
\n215.数组中的第 K 个最大元素：https://leetcode.cn/problems/kth-largest-element-in-an-array/
\n216.数据流的中位数：https://leetcode.cn/problems/find-median-from-data-stream/
\n217.前 K 个高频元素：https://leetcode.cn/problems/top-k-frequent-elements/
\n", "date_published": "2026-06-05T13:49:21.000Z", "date_modified": "2026-06-05T13:49:21.000Z", "authors": [], "tags": [ "计算机基础" ] }, { "title": "几道常见的链表算法题", "url": "https://codingmap.strova.top/cs-basics/algorithms/linkedlist-algorithm-problems.html", "id": "https://codingmap.strova.top/cs-basics/algorithms/linkedlist-algorithm-problems.html", "summary": "精选链表高频题的思路与实现，覆盖两数相加、反转、环检测等场景，强调边界处理与复杂度分析。重点围绕 1. 两数相加、2. 翻转链表、3. 链表中倒数第 k 个节点、4. 删除链表的倒数第 N 个节点、算法 等内容展开。结合 CodingMap 知识体系梳理 计算机基础 / 算法 / Linkedlist Algorit。", "content_html": "\n\n\nLeetcode:给定两个非空链表来表示两个非负整数。位数按照逆序方式存储，它们的每个节点只存储单个数字。将两数相加返回一个新的链表。
\n你可以假设除了数字 0 之外，这两个数字都不会以零开头。
\n
示例：
\n输入：(2 -> 4 -> 3) + (5 -> 6 -> 4)\n输出：7 -> 0 -> 8\n原因：342 + 465 = 807Leetcode 官方详细解答地址：
\nhttps://leetcode-cn.com/problems/add-two-numbers/solution/
\n\n\n要对头结点进行操作时，考虑创建哑节点 dummy，使用 dummy->next 表示真正的头节点。这样可以避免处理头节点为空的边界问题。
\n
我们使用变量来跟踪进位，并从包含最低有效位的表头开始模拟逐位相加的过程。
\n![\"图1，对两数相加方法的可视化:](\"https://oss.javaguide.cn/github/javaguide/cs-basics/algorithms/34910956.jpg\")
我们首先从最低有效位也就是列表 l1 和 l2 的表头开始相加。注意需要考虑到进位的情况！
\n/**\n * Definition for singly-linked list.\n * public class ListNode {\n * int val;\n * ListNode next;\n * ListNode(int x) { val = x; }\n * }\n */\n //https://leetcode-cn.com/problems/add-two-numbers/description/\nclass Solution {\npublic ListNode addTwoNumbers(ListNode l1, ListNode l2) {\n ListNode dummyHead = new ListNode(0);\n ListNode p = l1, q = l2, curr = dummyHead;\n //carry 表示进位数\n int carry = 0;\n while (p != null || q != null) {\n int x = (p != null) ? p.val : 0;\n int y = (q != null) ? q.val : 0;\n int sum = carry + x + y;\n //进位数\n carry = sum / 10;\n //新节点的数值为sum % 10\n curr.next = new ListNode(sum % 10);\n curr = curr.next;\n if (p != null) p = p.next;\n if (q != null) q = q.next;\n }\n if (carry > 0) {\n curr.next = new ListNode(carry);\n }\n return dummyHead.next;\n}\n}\n\n剑指 offer:输入一个链表，反转链表后，输出链表的所有元素。
\n
![\"翻转链表\"](\"https://oss.javaguide.cn/github/javaguide/cs-basics/algorithms/81431871.jpg\")
这道算法题，说直白点就是：如何让后一个节点指向前一个节点！在下面的代码中定义了一个 next 节点，该节点主要是保存要反转到头的那个节点，防止链表 “断裂”。
\npublic class ListNode {\n int val;\n ListNode next = null;\n\n ListNode(int val) {\n this.val = val;\n }\n}/**\n *\n * @author Snailclimb\n * @date 2018年9月19日\n * @Description: TODO\n */\npublic class Solution {\n\n public ListNode ReverseList(ListNode head) {\n\n ListNode next = null;\n ListNode pre = null;\n\n while (head != null) {\n // 保存要反转到头的那个节点\n next = head.next;\n // 要反转的那个节点指向已经反转的上一个节点(备注:第一次反转的时候会指向null)\n head.next = pre;\n // 上一个已经反转到头部的节点\n pre = head;\n // 一直向链表尾走\n head = next;\n }\n return pre;\n }\n\n}测试方法：
\n public static void main(String[] args) {\n\n ListNode a = new ListNode(1);\n ListNode b = new ListNode(2);\n ListNode c = new ListNode(3);\n ListNode d = new ListNode(4);\n ListNode e = new ListNode(5);\n a.next = b;\n b.next = c;\n c.next = d;\n d.next = e;\n new Solution().ReverseList(a);\n while (e != null) {\n System.out.println(e.val);\n e = e.next;\n }\n }输出：
\n5\n4\n3\n2\n1\n\n剑指 offer: 输入一个链表，输出该链表中倒数第 k 个结点。
\n
\n\n链表中倒数第 k 个节点也就是正数第(L-K+1)个节点，知道了这一点，这一题基本就没问题！
\n
首先两个节点/指针，一个节点 node1 先开始跑，指针 node1 跑到 k-1 个节点后，另一个节点 node2 开始跑，当 node1 跑到最后时，node2 所指的节点就是倒数第 k 个节点也就是正数第(L-K+1)个节点。
\n/*\npublic class ListNode {\n int val;\n ListNode next = null;\n\n ListNode(int val) {\n this.val = val;\n }\n}*/\n\n// 时间复杂度O(n),一次遍历即可\n// https://www.nowcoder.com/practice/529d3ae5a407492994ad2a246518148a?tpId=13&tqId=11167&tPage=1&rp=1&ru=/ta/coding-interviews&qru=/ta/coding-interviews/question-ranking\npublic class Solution {\n public ListNode FindKthToTail(ListNode head, int k) {\n // 如果链表为空或者k小于等于0\n if (head == null || k <= 0) {\n return null;\n }\n // 声明两个指向头结点的节点\n ListNode node1 = head, node2 = head;\n // 记录节点的个数\n int count = 0;\n // 记录k值，后面要使用\n int index = k;\n // p指针先跑，并且记录节点数，当node1节点跑了k-1个节点后，node2节点开始跑，\n // 当node1节点跑到最后时，node2节点所指的节点就是倒数第k个节点\n while (node1 != null) {\n node1 = node1.next;\n count++;\n if (k < 1) {\n node2 = node2.next;\n }\n k--;\n }\n // 如果节点个数小于所求的倒数第k个节点，则返回空\n if (count < index)\n return null;\n return node2;\n\n }\n}\n\nLeetcode:给定一个链表，删除链表的倒数第 n 个节点，并且返回链表的头结点。
\n
示例：
\n给定一个链表: 1->2->3->4->5, 和 n = 2.\n\n当删除了倒数第二个节点后，链表变为 1->2->3->5.说明：
\n给定的 n 保证是有效的。
\n进阶：
\n你能尝试使用一趟扫描实现吗？
\n该题在 LeetCode 上有详细解答，具体可参考 LeetCode。
\n我们注意到这个问题可以容易地简化成另一个问题：删除从列表开头数起的第 (L - n + 1)个结点，其中 L 是列表的长度。只要我们找到列表的长度 L，这个问题就很容易解决。
\n![\"图](\"https://oss.javaguide.cn/github/javaguide/cs-basics/algorithms/94354387.jpg\")
两次遍历法
\n首先我们将添加一个 哑结点 作为辅助，该结点位于列表头部。哑结点用来简化某些极端情况，例如列表中只含有一个结点，或需要删除列表的头部。在第一次遍历中，我们找出列表的长度 L。然后设置一个指向哑结点的指针，并移动它遍历列表，直至它到达第 (L - n) 个结点那里。我们把第 (L - n)个结点的 next 指针重新链接至第 (L - n + 2)个结点，完成这个算法。
\n/**\n * Definition for singly-linked list.\n * public class ListNode {\n * int val;\n * ListNode next;\n * ListNode(int x) { val = x; }\n * }\n */\n// https://leetcode-cn.com/problems/remove-nth-node-from-end-of-list/description/\npublic class Solution {\n public ListNode removeNthFromEnd(ListNode head, int n) {\n // 哑结点，哑结点用来简化某些极端情况，例如列表中只含有一个结点，或需要删除列表的头部\n ListNode dummy = new ListNode(0);\n // 哑结点指向头结点\n dummy.next = head;\n // 保存链表长度\n int length = 0;\n ListNode len = head;\n while (len != null) {\n length++;\n len = len.next;\n }\n length = length - n;\n ListNode target = dummy;\n // 找到 L-n 位置的节点\n while (length > 0) {\n target = target.next;\n length--;\n }\n // 把第 (L - n)个结点的 next 指针重新链接至第 (L - n + 2)个结点\n target.next = target.next.next;\n return dummy.next;\n }\n}进阶——一次遍历法：
\n\n\n链表中倒数第 N 个节点也就是正数第(L - n + 1)个节点。
\n
其实这种方法就和我们上面第四题找“链表中倒数第 k 个节点”所用的思想是一样的。基本思路就是： 定义两个节点 node1、node2；node1 节点先跑，node1 节点跑到第 n+1 个节点的时候，node2 节点开始跑。当 node1 节点跑到最后一个节点时，node2 节点所在的位置就是第（L - n）个节点（L 代表总链表长度，也就是倒数第 n + 1 个节点）。
\n/**\n * Definition for singly-linked list.\n * public class ListNode {\n * int val;\n * ListNode next;\n * ListNode(int x) { val = x; }\n * }\n */\npublic class Solution {\n public ListNode removeNthFromEnd(ListNode head, int n) {\n\n ListNode dummy = new ListNode(0);\n dummy.next = head;\n // 声明两个指向头结点的节点\n ListNode node1 = dummy, node2 = dummy;\n\n // node1 节点先跑，node1节点 跑到第 n 个节点的时候,node2 节点开始跑\n // 当node1 节点跑到最后一个节点时，node2 节点所在的位置就是第 （L-n ） 个节点，也就是倒数第 n+1（L代表总链表长度）\n while (node1 != null) {\n node1 = node1.next;\n if (n < 1 && node1 != null) {\n node2 = node2.next;\n }\n n--;\n }\n\n node2.next = node2.next.next;\n\n return dummy.next;\n\n }\n}\n\n剑指 offer:输入两个单调递增的链表，输出两个链表合成后的链表，当然我们需要合成后的链表满足单调不减规则。
\n
我们可以这样分析：
\n考虑通过递归的方式实现！
\n递归版本：
\n/*\npublic class ListNode {\n int val;\n ListNode next = null;\n\n ListNode(int val) {\n this.val = val;\n }\n}*/\n//https://www.nowcoder.com/practice/d8b6b4358f774294a89de2a6ac4d9337?tpId=13&tqId=11169&tPage=1&rp=1&ru=/ta/coding-interviews&qru=/ta/coding-interviews/question-ranking\npublic class Solution {\n public ListNode Merge(ListNode list1, ListNode list2) {\n if (list1 == null) {\n return list2;\n }\n if (list2 == null) {\n return list1;\n }\n if (list1.val <= list2.val) {\n list1.next = Merge(list1.next, list2);\n return list1;\n } else {\n list2.next = Merge(list1, list2.next);\n return list2;\n }\n }\n}\n\n作者：wwwxmu
\n\n
谈到字符串问题，不得不提的就是 KMP 算法，它是用来解决字符串查找的问题，可以在一个字符串（S）中查找一个子串（W）出现的位置。KMP 算法把字符匹配的时间复杂度缩小到 O(m+n)，而空间复杂度也只有 O(m)。因为 “暴力搜索” 的方法会反复回溯主串，导致效率低下，而 KMP 算法可以利用已经部分匹配这个有效信息，保持主串上的指针不回溯，通过修改子串的指针，让模式串尽量地移动到有效的位置。
\n具体算法细节请参考：
\n除此之外，再来了解一下 BM 算法！
\n\n\nBM 算法也是一种精确字符串匹配算法，它采用从右向左比较的方法，同时应用到了两种启发式规则，即坏字符规则和好后缀规则，来决定向右跳跃的距离。基本思路就是从右往左进行字符匹配，遇到不匹配的字符后从坏字符表和好后缀表找一个最大的右移值，将模式串右移继续匹配。
\n
\n《字符串匹配的 KMP 算法》：http://www.ruanyifeng.com/blog/2013/05/Knuth–Morris–Pratt_algorithm.html
\n\n剑指 offer：请实现一个函数，将一个字符串中的每个空格替换成 "%20"。例如，当字符串为 We Are Happy.则经过替换之后的字符串为 We%20Are%20Happy。
\n
这里我提供了两种方法：① 常规方法；② 利用 API 解决。
\n//https://www.weiweiblog.cn/replacespace/\npublic class Solution {\n\n /**\n * 第一种方法：常规方法。利用String.charAt(i)以及String.valueOf(char).equals(\" \"\n * )遍历字符串并判断元素是否为空格。是则替换为\"%20\",否则不替换\n */\n public static String replaceSpace(StringBuffer str) {\n\n int length = str.length();\n // System.out.println(\"length=\" + length);\n StringBuffer result = new StringBuffer();\n for (int i = 0; i < length; i++) {\n char b = str.charAt(i);\n if (String.valueOf(b).equals(\" \")) {\n result.append(\"%20\");\n } else {\n result.append(b);\n }\n }\n return result.toString();\n\n }\n\n /**\n * 第二种方法：利用API替换掉所用空格，一行代码解决问题\n */\n public static String replaceSpace2(StringBuffer str) {\n\n return str.toString().replaceAll(\"\\\\s\", \"%20\");\n }\n}对于替换固定字符（比如空格）的情况，第二种方法其实可以使用 replace 方法替换，性能更好！
str.toString().replace(\" \",\"%20\");\n\nLeetcode: 编写一个函数来查找字符串数组中的最长公共前缀。如果不存在公共前缀，返回空字符串 ""。
\n
示例 1：
\n输入: [\"flower\",\"flow\",\"flight\"]\n输出: \"fl\"示例 2：
\n输入: [\"dog\",\"racecar\",\"car\"]\n输出: \"\"\n解释: 输入不存在公共前缀。思路很简单！先利用 Arrays.sort(strs) 为数组排序，再将数组第一个元素和最后一个元素的字符从前往后对比即可！
public class Main {\n public static String replaceSpace(String[] strs) {\n\n // 如果检查值不合法及就返回空串\n if (!checkStrs(strs)) {\n return \"\";\n }\n // 数组长度\n int len = strs.length;\n // 用于保存结果\n StringBuilder res = new StringBuilder();\n // 给字符串数组的元素按照升序排序(包含数字的话，数字会排在前面)\n Arrays.sort(strs);\n int m = strs[0].length();\n int n = strs[len - 1].length();\n int num = Math.min(m, n);\n for (int i = 0; i < num; i++) {\n if (strs[0].charAt(i) == strs[len - 1].charAt(i)) {\n res.append(strs[0].charAt(i));\n } else\n break;\n\n }\n return res.toString();\n\n }\n\n private static boolean checkStrs(String[] strs) {\n boolean flag = false;\n if (strs != null) {\n // 遍历strs检查元素值\n for (int i = 0; i < strs.length; i++) {\n if (strs[i] != null && strs[i].length() != 0) {\n flag = true;\n } else {\n flag = false;\n break;\n }\n }\n }\n return flag;\n }\n\n // 测试\n public static void main(String[] args) {\n String[] strs = { \"customer\", \"car\", \"cat\" };\n // String[] strs = { \"customer\", \"car\", null };//空串\n // String[] strs = {};//空串\n // String[] strs = null;//空串\n System.out.println(Main.replaceSpace(strs));// c\n }\n}\n\nLeetCode: 给定一个包含大写字母和小写字母的字符串，找到通过这些字母构造成的最长的回文串。在构造过程中，请注意区分大小写。比如
\n"Aa"不能当做一个回文字符串。注意：假设字符串的长度不会超过 1010。回文串：“回文串” 是一个正读和反读都一样的字符串，比如 "level" 或者 "noon" 等等就是回文串。——百度百科 地址：https://baike.baidu.com/item/回文串/1274921?fr=aladdin
\n
示例 1：
\n输入:\n\"abccccdd\"\n\n输出:\n7\n\n解释:\n我们可以构造的最长的回文串是\"dccaccd\", 它的长度是 7。我们上面已经知道了什么是回文串？现在我们考虑一下可以构成回文串的两种情况：
\n统计字符出现的次数即可，双数才能构成回文。因为允许中间一个数单独出现，比如 "abcba"，所以如果最后有字母落单，总长度可以加 1。首先将字符串转变为字符数组。然后遍历该数组，判断对应字符是否在 hashset 中，如果不在就加进去，如果在就让 count++，然后移除该字符！这样就能找到出现次数为双数的字符个数。
\n//https://leetcode-cn.com/problems/longest-palindrome/description/\nclass Solution {\n public int longestPalindrome(String s) {\n if (s.length() == 0)\n return 0;\n // 用于存放字符\n HashSet<Character> hashset = new HashSet<Character>();\n char[] chars = s.toCharArray();\n int count = 0;\n for (int i = 0; i < chars.length; i++) {\n if (!hashset.contains(chars[i])) {// 如果hashset没有该字符就保存进去\n hashset.add(chars[i]);\n } else {// 如果有,就让count++（说明找到了一个成对的字符），然后把该字符移除\n hashset.remove(chars[i]);\n count++;\n }\n }\n return hashset.isEmpty() ? count * 2 : count * 2 + 1;\n }\n}\n\nLeetCode: 给定一个字符串，验证它是否是回文串，只考虑字母和数字字符，可以忽略字母的大小写。说明：本题中，我们将空字符串定义为有效的回文串。
\n
示例 1：
\n输入: \"A man, a plan, a canal: Panama\"\n输出: true示例 2：
\n输入: \"race a car\"\n输出: false//https://leetcode-cn.com/problems/valid-palindrome/description/\nclass Solution {\n public boolean isPalindrome(String s) {\n if (s.length() == 0)\n return true;\n int l = 0, r = s.length() - 1;\n while (l < r) {\n // 从头和尾开始向中间遍历\n if (!Character.isLetterOrDigit(s.charAt(l))) {// 字符不是字母和数字的情况\n l++;\n } else if (!Character.isLetterOrDigit(s.charAt(r))) {// 字符不是字母和数字的情况\n r--;\n } else {\n // 判断二者是否相等\n if (Character.toLowerCase(s.charAt(l)) != Character.toLowerCase(s.charAt(r)))\n return false;\n l++;\n r--;\n }\n }\n return true;\n }\n}\n\nLeetCode: 最长回文子串 给定一个字符串 s，找到 s 中最长的回文子串。你可以假设 s 的最大长度为 1000。
\n
示例 1：
\n输入: \"babad\"\n输出: \"bab\"\n注意: \"aba\"也是一个有效答案。示例 2：
\n输入: \"cbbd\"\n输出: \"bb\"以某个元素为中心，分别计算偶数长度的回文最大长度和奇数长度的回文最大长度。
\n//https://leetcode-cn.com/problems/longest-palindromic-substring/description/\nclass Solution {\n private int index, len;\n\n public String longestPalindrome(String s) {\n if (s.length() < 2)\n return s;\n for (int i = 0; i < s.length() - 1; i++) {\n PalindromeHelper(s, i, i);\n PalindromeHelper(s, i, i + 1);\n }\n return s.substring(index, index + len);\n }\n\n public void PalindromeHelper(String s, int l, int r) {\n while (l >= 0 && r < s.length() && s.charAt(l) == s.charAt(r)) {\n l--;\n r++;\n }\n if (len < r - l - 1) {\n index = l + 1;\n len = r - l - 1;\n }\n }\n}\n\nLeetCode: 最长回文子序列
\n
\n给定一个字符串 s，找到其中最长的回文子序列。可以假设 s 的最大长度为 1000。
\n最长回文子序列和上一题最长回文子串的区别是，子串是字符串中连续的一个序列，而子序列是字符串中保持相对位置的字符序列，例如，"bbbb" 可以是字符串 "bbbab" 的子序列但不是子串。
给定一个字符串 s，找到其中最长的回文子序列。可以假设 s 的最大长度为 1000。
\n示例 1：
\n输入:\n\"bbbab\"\n输出:\n4一个可能的最长回文子序列为 "bbbb"。
\n示例 2：
\n输入:\n\"cbbd\"\n输出:\n2一个可能的最长回文子序列为 "bb"。
\n动态规划： dp[i][j] = dp[i+1][j-1] + 2 if s.charAt(i) == s.charAt(j) otherwise, dp[i][j] = Math.max(dp[i+1][j], dp[i][j-1])
class Solution {\n public int longestPalindromeSubseq(String s) {\n int len = s.length();\n int [][] dp = new int[len][len];\n for(int i = len - 1; i>=0; i--){\n dp[i][i] = 1;\n for(int j = i+1; j < len; j++){\n if(s.charAt(i) == s.charAt(j))\n dp[i][j] = dp[i+1][j-1] + 2;\n else\n dp[i][j] = Math.max(dp[i+1][j], dp[i][j-1]);\n }\n }\n return dp[0][len-1];\n }\n}\n\n爱奇艺 2018 秋招 Java：
\n
\n一个合法的括号匹配序列有以下定义：\n
\n- 空串 "" 是一个合法的括号匹配序列
\n- 如果 "X" 和 "Y" 都是合法的括号匹配序列，"XY" 也是一个合法的括号匹配序列
\n- 如果 "X" 是一个合法的括号匹配序列，那么 "(X)" 也是一个合法的括号匹配序列
\n- 每个合法的括号序列都可以由以上规则生成。
\n例如：""，"()"，"()()"，"((()))" 都是合法的括号序列。
\n
\n对于一个合法的括号序列我们又有以下定义它的深度：\n
\n- 空串 "" 的深度是 0
\n- 如果字符串 "X" 的深度是 x，字符串 "Y" 的深度是 y，那么字符串 "XY" 的深度为 max(x, y)
\n- 如果 "X" 的深度是 x，那么字符串 "(X)" 的深度是 x+1
\n例如："()()()" 的深度是 1，"((()))" 的深度是 3。牛牛现在给你一个合法的括号序列，需要你计算出其深度。
\n
输入描述:\n输入包括一个合法的括号序列s,s长度length(2 ≤ length ≤ 50),序列中只包含'('和')'。\n\n输出描述:\n输出一个正整数,即这个序列的深度。示例：
\n输入:\n(())\n输出:\n2代码如下：
\nimport java.util.Scanner;\n\n/**\n * https://www.nowcoder.com/test/8246651/summary\n *\n * @author Snailclimb\n * @date 2018年9月6日\n * @Description: TODO 求给定合法括号序列的深度\n */\npublic class Main {\n public static void main(String[] args) {\n Scanner sc = new Scanner(System.in);\n String s = sc.nextLine();\n int cnt = 0, max = 0, i;\n for (i = 0; i < s.length(); ++i) {\n if (s.charAt(i) == '(')\n cnt++;\n else\n cnt--;\n max = Math.max(max, cnt);\n }\n sc.close();\n System.out.println(max);\n }\n}\n\n剑指 offer: 将一个字符串转换成一个整数（实现
\nInteger.valueOf(string)的功能，但是 string 不符合数字要求时返回 0），要求不能使用字符串转换整数的库函数。数值为 0 或者字符串不是一个合法的数值则返回 0。
//https://www.weiweiblog.cn/strtoint/\npublic class Main {\n\n public static int StrToInt(String str) {\n if (str.length() == 0)\n return 0;\n char[] chars = str.toCharArray();\n // 判断是否存在符号位\n int flag = 0;\n if (chars[0] == '+')\n flag = 1;\n else if (chars[0] == '-')\n flag = 2;\n int start = flag > 0 ? 1 : 0;\n int res = 0;// 保存结果\n for (int i = start; i < chars.length; i++) {\n if (Character.isDigit(chars[i])) {// 调用Character.isDigit(char)方法判断是否是数字，是返回True，否则False\n int temp = chars[i] - '0';\n res = res * 10 + temp;\n } else {\n return 0;\n }\n }\n return flag != 2 ? res : -res;\n\n }\n\n public static void main(String[] args) {\n // TODO Auto-generated method stub\n String s = \"-12312312\";\n System.out.println(\"使用库函数转换：\" + Integer.valueOf(s));\n int res = Main.StrToInt(s);\n System.out.println(\"使用自己写的方法转换：\" + res);\n\n }\n\n}