在算法中，数据结构的选择直接影响程序的效率，其核心是匹配具体场景的操作需求（如频繁查找、插入、排序等）。常见数据结构可分为线性结构、树形结构、图形结构等，每种结构因存储方式和操作特性的不同，适用于特定场景。 一、线性结构：一对一的数据关系 线性结构是最基础的数据结构，元素间呈线性排列，核心差异在于内存存储方式（连续或离散）和操作效率。 数据结构 核心特点 优点 缺点 典型使用场景 数组（Array） 元素连续存储，通过索引访问，长度固定（静态）或动态扩容 随机访问快（O(1)），内存连续利用率高 插入/删除效率低（需移动元素，O(n)）；动态扩容有性能损耗 需频繁随机访问场景：如存储用户列表、矩阵运算、滑动窗口算法 链表（Linked List） 元素离散存储，通过指针/引用连接（单链表、双链表、循环链表） 插入/删除快（O(1)，只需改指针）；长度灵活 随机访问慢（O(n)，需从头遍历）；额外存储指针，内存开销大 频繁插入/删除场景：如链表式队列、LRU缓存（双链表）、邻接表（图的存储） 栈（Stack） 遵循后进先出（LIFO），仅允许在栈顶操作（push/pop） 操作简单，时间复杂度O(1) 功能单一，仅支持栈顶操作 表达式求值（如括号匹配）、递归调用栈、深度优先搜索（DFS） 队列（Queue） 遵循先进先出（FIFO），允许在队尾插入、队头删除 顺序处理数据，操作效率O(1) 中间元素操作困难 任务调度（如线程池任务队列）、广度优先搜索（BFS）、消息队列 双端队列（Deque） 队列两端均可插入/删除，结合栈和队列特性 操作灵活，两端操作O(1) 实现较复杂（如基于链表或循环数组） 滑动窗口问题、缓存实现（如Java中的ArrayDeque） 二、树形结构：一对多的层级关系 树形结构通过“父节点-子节点”形成层级，适用于具有层级关系的数据，核心是优化查找和排序效率。 数据结构 核心特点 优点 缺点 典型使用场景 二叉树（Binary Tree） 每个节点最多2个子节点（左、右），无平衡要求 结构简单，适合递归操作 极端情况下退化为链表（如有序插入成单链），查找效率低（O(n)） 基础树形结构学习，表达式树（如编译器语法解析） 二叉搜索树（BST） 左子树节点值 < 根节点值 < 右子树节点值，支持快速查找 查找、插入、删除平均效率O(logn) 不平衡时退化为链表（如顺序插入） 动态数据的查找（如字典查询），但实际中多被平衡树替代 红黑树（Red-Black Tree） 自平衡二叉搜索树，通过颜色规则（红/黑）维持平衡，最长路径不超过最短路径2倍 查找、插入、删除稳定O(logn)，平衡性好 实现复杂，旋转操作耗时 TreeMap（Java）、C++ STL中的map/set，数据库索引（小型索引） B树/B+树 多路平衡查找树，B树节点存储数据，B+树数据仅在叶子节点，且叶子节点连成链表 减少IO次数（适合磁盘存储），支持范围查询 B+树非叶子节点不存数据，空间利用率更高 数据库索引（如MySQL InnoDB的聚簇索引）、文件系统（大量数据的磁盘存储） 堆（Heap） 完全二叉树，分为大顶堆（父>子）和小顶堆（父<子），支持优先操作 插入/删除O(logn)，获取最值O(1) 不支持随机访问，查找效率低（O(n)） 优先队列（如任务调度按优先级执行）、堆排序、Top K问题（如取最大的10个数） 三、哈希结构：通过哈希函数快速映射 哈希结构（Hash）的核心是键值对（Key-Value）映射，通过哈希函数将键转换为存储地址，实现快速查找。 ...

一 java基础 Java的跨平台性 Java可在不同操作系统上运行，原理是通过JVM（Java虚拟机）实现——Java代码编译为字节码（.class），由不同系统的JVM解释执行，即“一次编写，到处运行”。 抽象类 vs 接口比较 抽象类可包含具体方法和成员变量，接口仅定义方法签名（Java 8后支持默认方法）。 选择依据：若需共享代码或状态，用抽象类；若定义规范或回调机制，用接口。 volatile 关键字详解 一句话：Java中的volatile关键字通过内存屏障强制保证变量的可见性（修改后立即刷新主存）和禁止指令重排序，适用于状态标志、单例初始化等场景，但无法保证复合操作的原子性（如i++需配合锁或原子类）。 1. 核心特性 可见性 保证变量修改后立即刷新到主内存，其他线程读取时直接从主内存获取最新值，避免线程本地缓存导致的脏数据问题。 示例： volatile boolean flag = false; // 线程A修改flag后，线程B立即可见 禁止指令重排序 阻止编译器和处理器对指令进行重排序优化，确保代码执行顺序与编写顺序一致。 典型场景： volatile int a = 0; int b = 1; // 写操作不会被重排序到a的读操作之前 2. 底层实现原理 内存屏障（Memory Barrier） JVM通过插入内存屏障指令（如 StoreStore、StoreLoad）实现可见性和禁止重排序： 写操作：在写入 volatile 变量后插入 StoreLoad 屏障，强制刷写主存。 读操作：读取前插入 LoadLoad 屏障，确保后续操作基于最新值。 Happens-Before 关系 volatile 写操作先行发生于后续的读操作，形成线程间的同步约束。 3. 典型应用场景 场景 作用 示例代码片段 状态标志 线程协作终止条件（如中断信号） java volatile boolean running = true; 单例模式（DCL） 防止指令重排序导致半初始化对象泄漏 java volatile static Singleton instance; 配置参数 多线程共享的动态配置值（需配合锁或CAS保证原子性） java volatile int refreshInterval = 5000; 硬件寄存器操作 嵌入式开发中直接访问内存映射的硬件寄存器（确保每次操作直接访问物理内存） c volatile uint32_t *reg = (uint32_t*)0x1234; 4. 局限性 不保证原子性 ...

在软件开发管理中，提升团队绩效并非简单的“加压催工”，而是需要从目标对齐、流程优化、能力赋能、激励机制、团队氛围等多维度系统设计，结合软件开发的创造性、协作性、迭代性特点，激发团队的主动性和战斗力，同时减少内耗与重复劳动。 一、明确目标：让“做什么”和“为什么做”清晰可触 模糊的目标会导致团队精力分散，精准的目标能聚焦资源。软件开发团队的目标设定需兼顾业务价值与技术质量。 目标拆解：从“模糊任务”到“可落地指标” 用OKR（目标与关键成果） 或SMART原则定义目标：例如“Q3完成支付系统重构”可拆解为“关键成果1：9月前完成核心模块迁移（覆盖80%交易场景）；关键成果2：重构后接口响应时间降低50%”。 关联业务价值：让团队理解“代码优化”“需求交付”如何影响用户体验或业务指标（如“这次性能优化能减少30%客诉”），避免“为开发而开发”。 优先级管理：拒绝“多头并行” 用MoSCoW方法（Must have/Should have/Could have/Won’t have）明确任务优先级，避免同时推进多个高复杂度需求导致资源分散。 定期（如每周）同步优先级变更：业务方临时加需求时，需同步“挤压了哪些原有任务”，让团队感知到决策的权衡，而非被动接受。 选择合适的目标管理工具 方法 核心特点 适用场景 优势 劣势 OKR（目标与关键成果） 目标（O）需有挑战性，关键成果（KR）可量化，强调对齐 创新型项目、需求多变的团队 激发创造力，灵活适应变化，聚焦价值 短期难衡量，需团队成熟度 KPI（关键绩效指标） 基于具体指标（如迭代完成率、bug率），侧重可量化结果 流程稳定的重复性工作（如运维、标准化开发） 易考核，数据驱动 可能导致“为指标而工作”（如忽视技术债务） 用户故事点 以用户需求为单位（如“用户登录功能”），估算工作量（故事点） 敏捷开发团队，迭代周期短 贴合业务价值，便于拆分任务 估算依赖经验，新手易偏差 目标设定的3个关键原则 对齐业务优先级：开发目标需直接支撑产品核心价值（如“Q3完成支付流程优化，降低30%支付失败率”），避免“为开发而开发”。 拆分至可执行粒度：大目标拆解为迭代级任务（如将“重构用户系统”拆分为“用户数据迁移”“接口适配”等子任务），每个任务明确负责人与交付标准。 预留缓冲空间：软件开发中需求变更、技术难题频发，目标需预留20%-30%的弹性时间（如迭代周期4周，实际规划3周工作量）。 二、优化流程：减少内耗，让“做事效率”提升 低效的流程是绩效的隐形杀手，需通过标准化与自动化减少非增值活动。 标准化开发流程，减少“重复踩坑” 明确迭代节奏：例如2周一个迭代，固定“需求评审→开发→测试→上线”节点，避免“无限期拖延”或“频繁变更范围”。 沉淀技术规范：如代码提交规范（Conventional Commits）、分支管理策略（Git Flow）、测试用例标准，减少跨成员协作的沟通成本。 自动化工具提效：用CI/CD工具（Jenkins、GitLab CI）自动完成构建、测试、部署；用代码审查工具（SonarQube）自动检测低级bug，让开发者聚焦核心逻辑。 每日站会“三问”：每人用1-2分钟回答“昨天做了什么”“今天计划做什么”“遇到什么阻塞”，快速暴露问题（如依赖其他团队的接口未到位）。 迭代复盘会：迭代结束后，用“帆船模型”复盘——哪些做得好（继续保持）、哪些待改进（如测试环境不稳定导致联调延迟），并明确下次迭代的优化动作（如提前1天准备测试环境）。 精简沟通，避免“会议过载” 区分沟通场景： 日常同步用15分钟站会（只说“昨天做了什么/今天计划/阻塞问题”）； 复杂方案讨论用专题会（提前发文档，明确讨论目标）； 非紧急问题用异步工具（如Confluence、飞书文档）沉淀。 可视化进度：用看板工具（Jira、Trello）实时展示任务状态（待办/进行中/阻塞/已完成），阻塞问题标红并指定负责人，避免“信息黑箱”。 简化审批环节：开发相关审批（如代码合并、测试环境申请）通过工具自动化（如GitLab的Merge Request审批流程），避免线下流转。 三、赋能成长：让团队“有能力做”，而非“被迫做” 软件开发是协作密集型工作，信息孤岛会导致重复开发、理解偏差等问题。 针对性补短板，避免“能力断层” 识别团队能力缺口：例如新人多则加强基础培训（如框架使用、业务知识）；资深成员多则引入新技术分享（如微服务架构、AI工具应用）。 建立“传帮带”机制：让资深开发者担任“技术导师”，结对辅导新人；定期组织“代码复盘会”，分析线上bug或性能问题的根因，转化为团队经验。 允许“试错空间”，鼓励创新 预留20%“创新时间”：让团队尝试优化现有工具（如写个脚本简化测试流程）或探索新技术（如用低代码平台加速开发），提升工作成就感。 区分“不可接受的错”和“可复盘的错”：例如线上故障未走灰度发布流程是“不可接受的错”（需完善流程）；而新技术选型导致初期效率低是“可复盘的错”（总结经验即可），避免因怕犯错而保守不前。 推动知识共享与传承 建立团队知识库：沉淀高频问题解决方案（如“接口超时排查步骤”）、核心模块设计文档、历史项目经验（如“某项目踩过的坑”），用Wiki或语雀维护。 定期技术分享：每周1次内部分享会（30分钟），轮流讲解技术难点、新工具使用（如“如何用Jenkins实现自动部署”），提升团队整体能力。 必备工具清单 ...

通过豆包APP，先询问：“从北京出发，去大同旅游，出一份四天三晚的游玩计划” 再询问：“推荐大同的美食和饭店” 根据以上内容即可整理一份大同旅游攻略 最后我们就可以去欣赏下大同的美食、美景 大同攻略如下 行程 第一天（半天）：大同博物馆，古城墙夜游（古城墙，东南邑历史文化街区） 第二天：云冈石窟、大同古城墙（华严寺、九龙壁、代王府、法华寺等） 第三天：北岳恒山、悬空寺、应县木塔 第四天：回程～ 大同古城 善化寺–>华严寺–>钟楼–>四牌楼–>九龙壁–>代王府–>法华寺 关帝庙–>鼓楼–>净土寺–>文庙 大同介绍 大同位于山西北部，晋冀蒙交界处，是北魏都城、辽金陪都，有 “三代京华” 之称。云冈石窟为世界文化遗产，悬空寺是罕见三教合一古建，应县木塔为现存最高木构建筑。恒山为北岳，大同博物馆展地方历史。刀削面、羊杂等美食独具风味。曾以煤炭为支柱产业，现正转型发展新能源、文旅等新兴产业。 大同市是山西省省域副中心城市，以下将从其地理环境、历史文化、旅游景点、特色美食、经济发展这几个维度展开详细介绍： 地理环境 地理位置：位于山西北部，地处晋冀蒙交界处，北以外长城为界，与内蒙古自治区乌兰察布市相邻，西、南与本省朔州市、忻州市相连，东与河北省张家口市、保定市相接。 地形地貌：地处黄土高原东部边缘和太行山脉交接地带，地势高亢，地貌类型复杂多样，山地、丘陵、盆地、平川兼备，自西北向东南呈“T”字形。 气候特征：属温带大陆性季风气候，主要气候特点是降水偏多但时空分布不均，气温略偏高，日照偏多，无霜期偏长，大风天气偏多。 历史文化 历史沿革：大同历史悠久，古称平城、云州、云中，辽代改称大同。曾是北魏京都，辽金陪都，明清重镇。战国时初为代国，后并入赵地；北周时复置恒安镇；民国废府留县；1949年和平解放，成立大同市。 文化交融：处在内外长城之间，是北方的边陲重地，是胡汉文化交融的地方，形成了独特的多民族交融文化。赵武灵王曾在此推广胡服骑射，北魏时期鲜卑族在此建都，进一步促进了民族文化的交流与融合。 非遗文化：拥有市级以上非物质文化遗产保护项目103项，其中国家级保护项目有雁北耍孩儿、灵丘罗罗腔、恒山道乐、晋北鼓吹、广灵染色剪纸、左云楞严寺寺庙音乐、北路梆子、大同铜器制作技艺等8项。 旅游景点 云冈石窟：中国三大石窟之一，位于大同市云冈区云冈镇1号，依山开凿，东西绵延1000米，现存洞窟53个，石雕造像5万余尊，其艺术价值和历史价值极高，是世界文化遗产。 悬空寺：位于大同市浑源县东南郊恒山脚下，是中国唯一的高空绝壁建筑，也是罕见的佛、道、儒三教合一的寺庙，建筑悬挂在悬崖峭壁之上，十分壮观。 大同古城墙：是古代军事建筑史上的重镇，位于大同市平城区，城墙高大坚固，城楼、角楼等建筑气势恢宏，登上城墙可俯瞰古城风光。 九龙壁：位于大同市平城区大同古城大东街18号，是明初代王朱桂府的照壁，由426块特制的五彩琉璃构件拼砌而成，长45.5米，高8米，厚2.02米，是国内建筑最早、规模最大、保存最好的龙壁。 华严寺：位于大同市平城区大同古城下寺坡街459号，始建于辽重熙七年，依据佛教经典《华严经》而命名，其大雄宝殿建筑面积宏伟，殿顶鸱吻高大，天宫楼雕塑艺术堪称辽金时期“海内孤品”。 特色美食 大同刀削面：大同特色面食，面条中间厚两边薄，形似柳叶，入口外滑内筋，软而不粘，越嚼越香。 羊杂：以羊头、羊蹄、羊心、羊肝、羊肺等羊内脏为主料，加入粉条等食材，再配以辣椒、花椒等调料，味道浓郁，口感丰富。 大同兔头：有麻辣、五香等多种口味，肉质鲜嫩，骨头入味，是大同人喜爱的小吃之一。 黄糕：由黄米面蒸制而成，可油炸或油煎，外酥里嫩，香甜可口，通常搭配豆馅、糖等食用。 经济发展 传统产业：以煤炭为主的矿产资源采掘业是全市的支柱产业，大同煤炭资源丰富，在全国煤炭产业中占据重要地位。 新兴产业：近年来，大同也在积极推动产业转型，发展新能源、文化旅游、装备制造、大数据等新兴产业，努力实现经济的多元化发展。 云冈石窟 基本介绍 地理位置：位于中国山西省大同市城西约 16 公里的武州（周）山南麓、武州川的北岸，地理位置为东经 113º20’，北纬 40º04’。 规模：石窟依山开凿，东西绵延约 1 公里，窟区自东而西依自然山势分为东、中、西三区。现存主要洞窟 45 个，附属洞窟 209 个，雕刻面积达 18000 余平方米，佛龛约计 1100 多个，大小造像 59000 余尊。 历史地位：云冈石窟距今已有 1500 年的历史，是佛教艺术东传中国后，第一次由一个民族用一个朝代雕作而成皇家风范的佛教艺术宝库，是公元 5 世纪中西文化融合的历史丰碑。1961 年 3 月被国务院公布为首批全国重点文物保护单位；2001 年 12 月被联合国教科文组织批准列入 “世界文化遗产” 名录；2007 年 5 月成为国家首批 5A 级旅游景区。 ...

RocketMQ是阿里巴巴开源的分布式消息中间件，基于Java开发，专为高吞吐、高可靠的分布式系统设计。 核心特点 ①高吞吐量（支持千万级TPS）； ②低延迟（毫秒级响应）； ③支持多种消息模式（普通消息、顺序消息、事务消息等）； ④完善的重试和死信机制； ⑤分布式架构，支持水平扩展； ⑥提供丰富的监控和运维工具。 消息队列优势 系统解耦：解决不同重要程度、不同能力级别系统之间依赖导致一死全死；大多数MQ支撑多语言客户端，可兼容多语言发开发； 削峰填谷：主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题 异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 提升性能：当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统 蓄流压测：线上有些链路不好压测，可以通过堆积一定量消息再放开来压测 数据冗余：有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。MQ把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多MQ所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 核心组件 **生产者（Producer）：**Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调用链路的上游。生产者是轻量级匿名无身份的。 消息存储 主题（Topic）：Apache RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。 队列（MessageQueue）：Apache RocketMQ 消息传输和存储的实际单元容器，类比于其他消息队列中的分区。 Apache RocketMQ 通过流式特性的无限队列结构来存储消息，消息在队列内具备顺序性存储特征。 消息（Message）：Apache RocketMQ 的最小传输单元。消息具备不可变性，在初始化发送和完成存储后即不可变。 消息消费 消费者分组（ConsumerGroup）：Apache RocketMQ 发布订阅模型中定义的独立的消费身份分组，用于统一管理底层运行的多个消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展。 消费者（Consumer）：Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须被指定到某一个消费组中。 订阅关系（Subscription）： Apache RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。 Apache RocketMQ 的订阅关系除过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留。 Broker：消息服务器，存储消息并处理收发请求，由多个节点组成集群，分为Master和Slave（Master负责读写，Slave同步数据并提供读服务）。 NameServer：轻量级注册中心，存储Broker的路由信息（如Topic与Broker的映射关系），支持动态扩容，无状态且节点间互不通信。 NameServer是RocketMQ的“路由中枢”，核心作用是存储和更新集群的路由信息，为生产者和消费者提供Broker的地址发现服务。 与Broker的交互机制： ①Broker启动时向所有NameServer注册自身信息（如IP、端口、Topic配置等）； ②Broker定期（默认30秒）向NameServer发送心跳包，维持在线状态； ③NameServer在120秒内未收到Broker心跳，则将其从路由信息中移除，保证路由的实时性。 保证消息的可靠性 RocketMQ的消息可靠性保证贯穿于消息生产、Broker存储、消息消费全链路，通过多层次机制确保消息不丢失、不重复，具体如下： 一、生产端：确保消息成功发送到Broker 生产者（Producer）发送消息时，通过“重试机制+确认机制”避免因网络波动、Broker临时故障导致的消息丢失。 发送确认机制 RocketMQ支持三种发送方式，均通过Broker的响应确认消息是否成功送达： 同步发送：Producer发送消息后，等待Broker返回“发送成功”确认（包含消息ID和存储位置），才视为发送完成；若超时未收到确认，触发重试。 异步发送：Producer发送消息后立即返回，通过回调函数接收Broker的确认结果；若失败，在回调中处理重试。 单向发送：仅发送消息不等待确认（适用于日志等非核心场景），但核心业务一般不使用，避免丢失。 失败重试机制 当发送失败（如网络超时、Broker繁忙）时，Producer会自动重试，可通过参数配置： retryTimesWhenSendFailed：同步发送失败重试次数（默认2次）。 retryTimesWhenSendAsyncFailed：异步发送失败重试次数（默认2次）。 重试时会选择其他Broker节点（通过NameServer获取路由信息），避免单节点故障影响。 二、Broker端：确保消息持久化与集群可靠性 Broker作为消息存储核心，通过“持久化存储+主从复制+故障转移”保证消息不丢失。 ...

Kafka基础架构介绍 Kafka 是一个分布式、高吞吐量、低延迟的流处理平台，核心用于消息传递、日志收集、实时数据管道等场景。其架构设计和底层原理围绕“高吞吐”“高可用”“持久化”三大目标展开，以下从核心架构和底层机制两方面解析。 主要应用场景： ①日志收集（如ELK架构中收集应用日志）； ②消息系统（解耦生产者和消费者）； ③流式数据处理（与Spark Streaming、Flink等结合）； ④事件溯源（记录系统状态变化的事件序列）； ⑤数据同步（跨系统数据实时同步）。 一、Kafka 核心架构 Kafka 的架构由四大核心组件和关键概念构成，整体呈现分布式集群形态： 1. 核心组件 Producer（生产者）：向 Kafka 集群发送消息的客户端（如应用程序、日志采集器等）。 Consumer（消费者）：从 Kafka 集群读取消息的客户端（如数据分析程序、下游服务等）。 Broker（ broker 节点）：Kafka 服务器实例，负责存储消息、处理生产/消费请求，多个 broker 组成集群。 ZooKeeper（协调服务）：早期版本（2.8 前）用于管理集群元数据（如 broker 注册、分区 leader 选举、配置存储等）；新版本（2.8+）引入 Self-Managed Metadata Quorum，逐步弱化对 ZooKeeper 的依赖。 2. 关键概念 Topic（主题）：消息的逻辑分类，生产者按 Topic 发送消息，消费者按 Topic 订阅消息（类似“消息队列名称”）。 Partition（分区）：每个 Topic 被拆分为多个分区（Partition），分区是 Kafka 并行处理的基本单位。 每个分区是有序、不可变的消息日志（仅支持追加写入），消息按发送顺序编号（Offset，从 0 开始递增）。 分区分布在不同 broker 上，实现数据分片存储和并行读写（吞吐量随分区数增加而提升）。 Replica（副本）：为保证数据高可用，每个分区可配置多个副本（Replica），其中一个为Leader 副本（处理读写请求），其余为Follower 副本（同步 Leader 数据，Leader 故障时替代）。 三者是描述Partition副本状态的术语： AR（Assigned Replicas）：Partition的所有副本集合（包括Leader和Follower）。 ISR（In-Sync Replicas，同步副本集）：与Leader副本保持同步的副本集合（包括Leader本身），满足两个条件：①与Leader保持网络连接；②同步滞后不超过replica.lag.time.max.ms（默认30秒）。 若 Follower 长时间未同步，会被踢出 ISR，仅 ISR 中的副本可参与 Leader 选举。 ...

MySQL是一个开放源代码的数据库管理系统（DBMS），是由MySQL AB公司开发、发布并支持的。MySQL是一个跨平台的开源关系型数据库管理系统，广泛地应用在Internet上的中小型网站开发中。 概念 SQL语句分类 数据定义语言DDL（Data Ddefinition Language）：CREATE，DROP，ALTER 主要为以上操作 即对逻辑结构等有操作的，其中包括表结构，视图和索引。 数据查询语言DQL（Data Query Language）：SELECT 这个较为好理解 即查询操作，以select关键字。各种简单查询，连接查询等 都属于DQL。 数据操纵语言DML（Data Manipulation Language）：INSERT，UPDATE，DELETE 主要为以上操作 即对数据进行操作的，对应上面所说的查询操作 DQL与DML共同构建了多数初级程序员常用的增删改查操作。而查询是较为特殊的一种 被划分到DQL中。 数据控制功能DCL（Data Control Language）：GRANT，REVOKE，COMMIT，ROLLBACK 主要为以上操作 即对数据库安全性完整性等有操作的，可以简单的理解为权限控制等。 数据库三大范式是什么 第一范式：每个列都不可以再拆分。 第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。 第三范式：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。 在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理由。比如性能。事实上我们经常会为了性能而妥协数据库的设计。 一 存储引擎 1.1 存储引擎 MySQL 8.0支持的存储引擎有InnoDB、MyISAM、Memory、Merge、Archive、Federated、CSV、BLACKHOLE等。 MySQL常用存储引擎包括： InnoDB（默认）：支持事务、外键、行级锁，适合高并发场景。 MyISAM：不支持事务和外键，表级锁，读写性能较高（适合读多写少）。 Memory：数据存储在内存中，速度极快，适合临时表。 Archive：只支持INSERT和SELECT，压缩存储，适合历史数据归档。 核心区别： 特性 InnoDB MyISAM 事务支持 ✅ ❌ 外键 ✅ ❌ 锁机制 行级锁 表级锁 索引与数据 聚簇索引（索引和数据存储在一起） 非聚簇索引 崩溃恢复 支持 不支持 InnoDB与MyISAM对比： InnoDB主键索引直接存储数据，MyISAM索引只存储数据地址。 InnoDB的二级索引叶子节点存储主键值，MyISAM存储数据地址。 MyISAM：不支持事务和外键，支持表级锁，查询速度快，适合读多写少场景（如日志表），崩溃后恢复困难。 InnoDB：支持事务（ACID）、外键和行级锁，有崩溃恢复能力（依赖redo日志），适合写操作频繁的场景（如订单表），性能略低于MyISAM但安全性更高。 1.2 日志文件 常用的日志文件包括错误日志、二进制日志、查询日志、慢查询日志和InnoDB引擎在线Redo日志等。 ...

TCP三次握手&四次挥手 TCP 三次握手 客户端发送 SYN 包请求连接，服务端返回 SYN+ACK 确认并请求连接，客户端再返回 ACK 确认，双方进入 ESTABLISHED 状态。 graph LR A[客户端] -->|1、SYN=1, Seq=x| B[服务端] B -->|2、SYN=1, ACK=1, Seq=y, Ack=x+1| A A -->|3、ACK=1, Seq=x+1, Ack=y+1| B A -->|4、ESTABLISHED| C[连接建立完成] B -->|4、ESTABLISHED| C 作用：建立可靠的双向连接，确保通信双方确认彼此的接收和发送能力。 过程： 第一次握手（客户端 → 服务端）： 客户端发送带有 SYN=1，Seq=x 的报文，进入 SYN_SENT 状态，请求建立连接。 第二次握手（服务端 → 客户端）： 服务端收到后，发送 SYN=1，ACK=1，Seq=y，Ack=x+1 的报文，进入 SYN_RCVD 状态，确认客户端请求并发起自身连接请求。 第三次握手（客户端 → 服务端）： 客户端发送 ACK=1，Seq=x+1，Ack=y+1 的报文，进入 ESTABLISHED 状态。服务端收到后也进入 ESTABLISHED 状态，连接建立完成。 TCP 四次挥手 主动关闭方先发送 FIN 包请求关闭，被动关闭方返回 ACK 确认（此时仍可发送剩余数据）。 被动关闭方数据发送完毕后，再发送 FIN 包请求关闭，主动关闭方返回 ACK 确认，并进入 TIME_WAIT 状态（等待 2MSL 确保最后一个 ACK 到达），被动关闭方收到后立即关闭。 graph LR D[主动关闭方] -->|1、FIN=1, Seq=m| E[被动关闭方] E -->|2、ACK=1, Seq=n, Ack=m+1| D E -->|3、FIN=1, ACK=1, Seq=p, Ack=m+1| D D -->|4、ACK=1, Seq=m+1, Ack=p+1| E D -->|5、TIME_WAIT| F[等待超时后关闭] E -->|5、CLOSED| G[立即关闭] 作用：终止连接，确保双向数据传输都已完成，资源可安全释放。 过程： ...

Spring Cloud 最新架构概览 截至 2025 年，Spring Cloud 的架构已全面拥抱云原生技术，主要包括以下核心组件： 服务发现：Nacos 2.0 成为首选，支持动态服务发现、配置管理和服务元数据管理 API 网关：Spring Cloud Gateway 4.0 全面支持 WebFlux 和响应式编程 负载均衡：Spring Cloud LoadBalancer 替代 Ribbon，提供更轻量的客户端负载均衡 断路器：Sentinel 取代 Hystrix，提供更强大的流量控制和熔断降级能力 配置中心：Nacos Config 或 Apollo 成为主流选择，支持实时配置刷新 分布式链路追踪：Micrometer Tracing + Zipkin/Skywalking 组合，兼容 OpenTelemetry 标准 服务间通信：OpenFeign 支持响应式编程，与 WebClient 协同工作 Spring Cloud Gateway架构设计与核心原理详解 Spring Cloud Gateway 基于响应式编程模型（WebFlux + Reactor），通过 动态路由匹配（Predicate 断言）和 过滤器链（GlobalFilter/GatewayFilter） 实现请求转发，集成服务发现（如 Nacos）、负载均衡（Ribbon）及熔断限流（Hystrix/Sentinel），以非阻塞 I/O 模型支撑高并发，保障微服务网关的高性能与可扩展性。 一、架构设计 1. 分层模型 Spring Cloud Gateway 采用 四层分层架构，支持高并发与动态扩展： 网络层（Netty Server） 基于 Netty 实现异步非阻塞 I/O，单线程处理万级并发连接。 支持 HTTP/2、WebSocket 协议，通过 ReactorNettyServer 封装请求为 ServerWebExchange 对象。 路由层（Route Matching） ...

Spring Boot 是基于 Spring 框架的开源开发框架，由 Pivotal 团队于 2014 年推出，旨在简化 Spring 应用的初始搭建和开发流程。以下是其核心特性、应用场景及技术价值的全面解析： 一、核心特性与技术优势 1. 约定优于配置（Convention Over Configuration） 自动配置机制：通过 @EnableAutoConfiguration 注解，根据类路径依赖自动配置组件（如数据库连接池、Web 服务器） 默认配置优化：提供合理的默认值（如内嵌 Tomcat 服务器），开发者仅需关注业务逻辑，减少 XML 配置 2. 起步依赖（Starter Dependencies） 场景化依赖管理：通过 spring-boot-starter-* 模块快速集成常用功能（如 spring-boot-starter-web 整合 Web 开发所需依赖） 版本统一控制：BOM（Bill of Materials）确保依赖版本兼容性，避免冲突 3. 嵌入式服务器与独立运行 内嵌容器：支持 Tomcat、Jetty、Undertow，无需部署 WAR 包，直接运行 JAR 文件 生产级监控：集成 Actuator 模块，提供健康检查、指标采集、审计日志等运维功能 4. 开发效率增强 热部署：通过 Spring DevTools 实现代码修改自动重启，提升调试效率 命令行工具：支持快速生成项目骨架、执行数据库迁移等操作 二、典型应用场景 1. 微服务架构 服务快速启动：每个微服务独立打包，通过 Spring Cloud 实现服务注册、负载均衡 云原生支持：与 Docker、Kubernetes 深度集成，适应容器化部署需求 2. RESTful API 开发 简化 Web 开发：通过 @RestController 和 @RequestMapping 快速定义接口 JSON 处理：默认集成 Jackson 库，实现对象与 JSON 的自动转换 3. 数据访问与持久化 ORM 整合：支持 JPA、MyBatis，通过 spring-boot-starter-data-jpa 简化数据库操作 连接池管理：内置 HikariCP（默认）或 Druid，优化数据库连接性能 4. 批处理与异步任务 Spring Batch：处理大规模数据导入/导出，支持事务管理和错误重试 @Async 注解：实现异步方法调用，提升系统吞吐量 三、版本演进与技术升级 版本系列 关键特性 适用场景 1.x 初始版本，支持 Java 8，集成 Tomcat 8 传统企业级应用 2.x 支持响应式编程（WebFlux）、Java 11+ 高并发、云原生应用 3.x 默认使用 Jakarta EE 9+，移除 Java 8 兼容 现代化微服务架构 升级建议：从 2.x 到 3.x 需注意包名变更（如 javax → jakarta）和废弃 API 的替换 ...