皖月清风的个人博客

我已经有 EFK（Elasticsearch + Fluentd + Kibana）/ELK 看日志了，查问题也挺方便，为啥还要多搞一套链路追踪？ 为什么需要链路追踪？EFK 是“看文字记录”，链路追踪是“看地图+路线+耗时”。日志能告诉你“发生了什么”，链路追踪能告诉你“请求怎么走的、谁慢了、谁挂了”。 1. EFK 只能看到“点”，链路追踪能看到“整条线”假设用户下单失败，你去 EFK 搜日志： 用 EFK 查问题你只能看到： 订单服务报错了 支付服务也报错了 用户服务好像也有问题 但你完全不知道： 谁先调用谁？ 是谁导致谁挂了？ 是调用链断在哪一步？ 日志是分散的，像一堆散落的纸条。 用链路追踪查问题直接给你一张完整调用路线图：网关 → 订单服务 → 库存服务 → 支付服务 → DB并且标红：支付服务调用超时 瞬间定位根因。 2. EFK 没有“请求串联”能力微服务里，一个请求会穿过：5 个服务 + 3 个数据库 + 2 个缓存 + MQ EFK 里： 订单服务日志：request-id=abc123 支付服务日志：traceId...

EFK速通ELK 是 Elasticsearch + Logstash + Kibana 的缩写，现在主流搭配是 Elasticsearch + Filebeat + Kibana（EFK），Filebeat 更轻量、资源占用更低。 一、3个组件干什么？ Elasticsearch（ES）：核心数据库+搜索引擎，存日志、快速查日志，端口 9200。 Filebeat：轻量日志采集器，装在服务器上读日志文件、发给 ES，端口 5044。 Kibana：可视化面板，网页看日志、做图表、搜数据，端口 5601。 极简流程：Filebeat 采集日志 → Elasticsearch 存储 → Kibana 查看/分析 二、环境准备（Linux/CentOS 7）1. 基础要求 系统：CentOS 7 / Ubuntu（新手推荐 CentOS 7） 内存：至少 2GB（ES 很吃内存） Java：Elasticsearch 8.x 自带 JDK，不用额外装 Java 2. 关闭防火墙/开放端口123456789# 临时关闭防火墙systemctl...

MCPMCP是定义在上下文当中的MCP 把上下文拆成 5 大标准模块（全部在协议里明确定义）： 1. System Context（系统上下文）定义：Agent 的身份、行为规则、Skills 范围MCP 定义：系统提示（System Instruction）可用 Skills 列表（Agent 会什么）约束、权限、安全规则 2. User Context（用户上下文）定义：用户信息、目标、历史、偏好MCP 定义：当前用户请求对话历史（短期记忆）用户长期偏好 / 配置会话状态 3. Tool Context（工具上下文）定义：所有可用 Tools 的元数据 + 调用规范MCP 定义（最核心）：工具名、描述、参数 schema工具权限、可用范围调用格式、返回格式工具状态、执行结果 4. Resource Context（资源上下文）定义：静态数据 / 文档 / 知识MCP 定义：文件、数据库、API 数据RAG 检索结果知识库、配置 5. Session Context（会话上下文）定义：多轮状态、执行流MCP 定义：任务进度中间结果多步骤执行状态 融...

重定向和请求转发重定向是服务器返回 3xx 让浏览器重新访问新 URL（地址栏会改变，需二次请求），而请求转发只在同一服务器内部把同一 request 转给其他资源处理（一次请求，地址栏不变）。 Elasticsearch相关Elasticsearch：擅长“模糊”和“相关性”搜索。例如：搜索“苹果手机”，它不仅能找到包含“苹果”和“手机”的商品，还能通过算法智能地判断出“iPhone”、“iOS设备”的相关性，并按照相关度高低返回结果。这是因为它底层使用了倒排索引 这种神奇的数据结构。 倒排索引（Inverted Index）一句话：把“文档→关键词”反过来，变成“关键词→文档”，用来做快速搜索。 1. 它是什么？正常存储是： 文档1：我喜欢苹果 文档2：苹果很好吃 倒排索引就是反过来： 苹果 → 文档1、文档2 喜欢 → 文档1 好吃 → 文档2 这样搜“苹果”，直接就能拿到所有包含它的文档，不用全文扫一遍。 2. 核心结构一般包含两部分： 词典（Term Dictionary）所有关键词的集合：苹果、喜欢、好吃…… 倒排表（Posting List）每个词对应...

线程池一、什么是线程池？线程池 = 提前创建好的一堆线程 + 任务队列 + 调度器 你可以把它理解成： 一个固定人数的“工人小组”，专门等着处理你丢过来的“任务”。 不用每次来任务都新招工人（创建线程） 任务做完工人不辞退（不销毁线程） 工人闲着就等着，来任务马上干活 任务太多排排队，不会一下子把系统压垮 这就是线程池。 二、为什么要用线程池？（核心作用）如果不用线程池，你每次处理任务都 new Thread()，会有 3 个致命问题： 1. 频繁创建/销毁线程 → 非常耗性能创建线程、销毁线程是重量级操作，比执行普通代码慢得多。线程池让线程复用，避免反复创建销毁。 2. 无限制创建线程 → 系统崩溃如果你来了 1000 个任务，就开 1000 个线程： CPU 疯狂切换 内存爆掉 程序直接卡死 线程池可以限制最大线程数量，保证系统稳定。 3. 线程管理混乱手动创建线程很难统一管理： 怎么控制并发数？ 怎么拒绝过载任务？ 怎么监控任务状态？ 线程池自带管理、监控、拒绝策略、定时任务等功能。 三、线程池的核心好处（总结版） 降低资源消耗：复用...

Mysql存储引擎 主索引（聚簇索引）将数据存储在叶子节点，辅助索引存储指向主键的指针 # 什么是存储过程？ **存储过程（Stored Procedure）** 是**数据库中预先编译好、存储在服务器上的一组 SQL 语句集合**，你可以把它理解成**数据库里的“自定义函数/小程序”**。 它提前把复杂的 SQL 逻辑（增删改查、循环、判断、事务等）写好并保存，需要使用时，直接调用名字就能执行，不用重复写代码。 一、用最简单的比喻理解你要做一道菜： 普通 SQL：每次都把所有食材、步骤写一遍，一步步操作； 存储过程：把完整菜谱提前存在厨房，想吃的时候喊一声菜名，厨师直接按菜谱做好。 二、核心特点 存储在数据库服务器不是写在你的代码里，而是保存在 MySQL、Oracle、SQL Server 等数据库中。 预先编译第一次执行后就编译好了，后续调用速度更快。 可重复调用一次编写，无数次使用，程序、报表、脚本都能直接调用。 支持参数、逻辑判断、循环能实现复杂业务逻辑，不只是简单查询。 减少网络传输不用把一大段 SQL 发给服务器，只发一个调用指令。 三、...

MySQL 锁分类MySQL 锁按锁粒度、锁模式、实现机制、并发思想四大维度划分，主流 InnoDB 引擎下核心锁类型如下： 一、按锁粒度（作用范围）1. 全局锁（Global Lock） 锁定整个数据库实例，所有表只读、不可写 命令：FLUSH TABLES WITH READ LOCK（FTWRL） 场景：全库逻辑备份、主从切换 2. 表级锁（Table Lock） 锁定整张表，粒度大、开销小、并发低 子类型： 表读锁（共享）：LOCK TABLES ... READ 表写锁（排他）：LOCK TABLES ... WRITE 元数据锁（MDL）：保护表结构，DDL/DML 自动加 意向锁（IS/IX）：InnoDB 表级意向，兼容行锁 引擎：MyISAM、InnoDB（无索引时退化为表锁） 3. 行级锁（Row Lock） 锁定单行，粒度最小、并发最高，InnoDB 核心 依赖索引实现，无索引会全表加锁 4. 页级锁（Page Lock） 锁定 16KB 数据页，仅 BDB 引擎（已淘汰） 二、按锁模式（读写兼容性）1. 共享锁（S 锁 ...

虚拟地址页表用大白话精准说：这个对照表叫「页表」 1. 基础存放位置✅ 页表本身，存在【物理内存（内存条）】里 操作系统给每个进程都单独造一张页表，老老实实放在内存条。 2. 加速小缓存（TLB）CPU 嫌每次查内存页表太慢，自己内部带了个高速小缓存： ✅ TLB（页表高速缓存）存在【CPU 内部】 常用的「虚拟地址→物理地址」映射，先存在 TLB 里，秒查。 3. 完整流程举例 程序访问虚拟地址 CPU 先看自己内部 TLB 有没有对照表 没有就去 物理内存 里找这个进程的页表 翻译成真实物理地址，再拿数据 极简总结 完整大对照表（页表）👉 内存条 加速临时对照表（TLB）👉 CPU 里面 硬盘中的虚拟内存先拆大白话，再讲原理一、先懂：平时的「内存不够」痛点电脑 物理内存（内存条 RAM） 容量有限（比如 8G/16G），开太多软件、大程序时，物理内存会塞满，不够用了。 二、什么是「把硬盘一部分设为虚拟内存」？操作系统从 硬盘 划出一块专属空间（Windows 叫页面文件 pagefile.sys，Linux 叫 Swap 分区），冒充”临时内存”，和物理内...

这歌好听：【毒吐】☾+.uoow【佐藤乃子】推荐博客 小林coding应用层只需要专注于为用户提供应用功能，比如 HTTP、FTP、Telnet、DNS、SMTP等FTP（文件传输协议）和 Telnet（远程终端协议）都是互联网早期的基础协议，但都已因安全问题（明文传输）而被更现代的替代方案取代。 FTP (File Transfer Protocol)核心功能用于在网络上进行文件传输（上传/下载），基于客户端-服务器架构。 工作模式 控制连接（端口 21）：传输命令和响应 数据连接（端口 20 或动态端口）：实际传输文件数据 主动模式 vs 被动模式：解决客户端防火墙/NAT 问题 主要缺陷 问题 说明 明文传输 用户名、密码、文件内容全部明文传输 多重连接 控制与数据分离，增加防火墙配置复杂度 无加密 易被中间人攻击窃听或篡改 现代替代方案 SFTP（SSH File Transfer Protocol）：基于 SSH 加密，最常用 FTPS（FTP over SSL/TLS）：FTP 的 SSL 加密版本 SCP（Se...

Go 入门：消息队列与 Kafka 4.x 实战指南专为 Go 语言学习者编写，从零理解消息队列，聚焦 Kafka 4.x 最新稳定版本（基于 KRaft 模式，无 ZooKeeper 依赖），包含完整部署、启动及 Go 实战流程，轻松跑通全流程。 一、什么是消息队列？（通俗版）1. 核心定义消息队列（Message Queue，简称 MQ），就像生活中的快递柜： 生产者：寄快递的人（发送数据的服务/代码） 消费者：取快递的人（接收处理数据的服务/代码） 消息队列：快递柜（临时存储数据，解耦发送方和接收方） 发送方不用等接收方立刻处理，把数据放进队列就可以继续做自己的事；接收方有空了再从队列里取数据处理，互不阻塞。 2. 为什么要用消息队列？ 解耦：两个服务不直接依赖，修改一个不影响另一个 异步处理：耗时操作丢进队列，主线程不用等待，提升响应速度 削峰填谷：高并发时先把请求存进队列，避免服务被压垮 流量缓冲：保护后端服务，平稳处理请求 3. 常见消息队列对比（只记重点） 消息队列 优点 缺点 适用场景 Kafka 4.x 高吞吐、低延迟、分布式...