分布式 ID / 序列号生成方案技术选型 1. 方案概述 1.1 UUID 128 位随机数（V4）或基于时间+MAC（V1）。无需中心节点，生成即唯一。 完全无序、不连续，无法用于排序或范围查询 36 字节字符串存储开销大，随机值导致 B+Tree 页分裂，写入性能差 1.2 数据库自增 ID MySQL AUTO_INCREMENT 主键，单表内严格递增且连续。 每次发号伴随磁盘写（INSERT/UPDATE），单机上限约 1000-3000 TPS 强依赖单点数据库，宕机即停；分库后各库独立递增，全局不连续 1.3 Snowflake（雪花算法） 64 位 = 1 bit 符号 + 41 bit 时间戳 + 10 bit 机器 ID + 12 bit 序列号。纯内存计算，单机 400 万+/秒。 趋势递增但不连续，两个 ID 的差值无业务含义 依赖机器时钟，时钟回拨可能导致 ID 重复 1.4 Leaf-Segment（美团 Leaf 号段模式） 从数据库批量预取号段（如 1000 个），应用内存中顺序分发。当前号段消耗到阈值时异步预加载下一号段，避免切换时阻塞。 号段内连续，但进程重启时未消费的号段被浪费，产生空洞 多实例部署时各进程持有不同号段，同一业务维度内 ID 交叉，无法保证连续 1.5 Leaf-Snowflake Snowflake 变体，用 ZooKeeper 管理 workerID 并解决时钟回拨。本质仍是 Snowflake，不连续的缺陷不变。 ...

draft need to be improved Slice GOtype slice struct { array unsafe.Pointer len int cap int } // 扩容 func nextslicecap(newLen, oldCap int) int { newcap := oldCap doublecap := newcap + newcap if newLen > doublecap { return newLen } const threshold = 256 if oldCap < threshold { return doublecap } for { // 1.25x newcap += (newcap + 3*threshold) >> 2 if uint(newcap) >= uint(newLen) { break } } // overflowed if newcap <= 0 { return newLen } return newcap } Map GOtype Map struct { used uint64 // The number of filled slots seed uintptr // the hash seed, computed as a unique random number per map. // The directory of tables. // Normally dirPtr points to an array of table pointers // dirPtr *[dirLen]*table dirPtr unsafe.Pointer dirLen int // 1 << globalDepth globalDepth uint8 // The number of bits to use in table directory lookups. globalShift uint8 // The number of bits to shift out, 64 - globalDepth writing uint8 // detect the race. tombstonePossible bool // whether a table in this map contains a tombstone. clearSeq uint64 // version number, used to detect map clears during iteration. } Swiss Table refer: Faster Go maps with Swiss Tables ...

Spring 容器启动流程

编译过程 计算机硬件结构 虚拟内存 地址翻译 文件 网络 并发 进程 资源分配的基本单位。每个进程拥有独立的地址空间、文件描述符表、信号处理器等资源，进程之间彼此隔离。 进程的状态包括：创建、就绪、运行、阻塞、终止。 上下文切换 进程上下文切换需要保存和恢复的内容： CPU 寄存器（程序计数器 PC、栈指针 SP、通用寄存器等） 虚拟内存映射（页表基址寄存器，需刷新 TLB） 内核栈 进程控制块（PCB）中的状态信息 由于涉及页表切换和 TLB 刷新，进程切换的开销较大（通常在微秒级）。 进程间通信 进程拥有独立的地址空间，因此需要通过操作系统提供的 IPC 机制来通信： 方式 特点 适用场景 管道（Pipe） 半双工，父子进程间使用 简单的单向数据流 命名管道（FIFO） 半双工，无亲缘关系限制 不相关进程间通信 消息队列 有格式的消息，可按类型读取 结构化数据传递 共享内存 最快的 IPC 方式，需配合同步机制 大量数据交换 信号量（Semaphore） 用于同步，控制对共享资源的访问 互斥与同步 信号（Signal） 异步通知机制 事件通知（如 SIGKILL） Socket 支持不同主机间通信 网络通信 线程 ...

L1 日常排错篇 适用场景：服务连不上、启动报错、明显卡顿。L1 不追求命令全，只保留日常最常用、能马上定方向的几组操作；指标解释和深入定位放到 L2。 1. 服务是不是还活着 使用场景：服务启动后访问不了、发布后怀疑没起来、进程异常退出、systemd 服务状态不对。 BASHsystemctl status <service> --no-pager journalctl -u <service> -n 100 --no-pager journalctl -u <service> -f pgrep -af <name> 先看服务状态是不是 active (running)，最近 100 行日志里有没有启动失败、配置错误、端口占用、权限错误。pgrep -af 用来确认进程是否真的存在，以及启动参数是不是预期的。 2. 端口有没有开 使用场景：服务进程存在，但客户端连不上；启动时报 Address already in use；不确定服务监听的是本机、内网还是所有网卡。 BASHss -lntp ss -lntp | grep ':8080' lsof -i :8080 重点看有没有 LISTEN，监听地址是 0.0.0.0、127.0.0.1 还是具体内网 IP。服务只监听 127.0.0.1 时，本机能访问，外部机器通常访问不到。 3. 从外部能不能访问 使用场景：本机服务看起来正常，但浏览器、调用方、其他机器访问失败；需要区分是 DNS、网络、端口、HTTP 还是服务端处理慢。 BASHnc -zv <ip> <port> curl -Iv http://<host>:<port>/ dig <domain> ping -c 4 <ip> nc 看 TCP 端口能不能连上，curl -Iv 看 HTTP 状态码、重定向和握手过程，dig 看域名是否解析到预期 IP。ping 只作为辅助参考，很多云服务器会禁 ICMP，ping 不通不代表 TCP 一定不通。 ...

Redis 数据结构 本文按 Redis 8.x/unstable 源码写，重点看内存编码和自动转换。老版本里 ziplist、linkedlist 等编码已经不适合作为当前主线。 逻辑类型 (Type) 底层数据结构 (Internal Encoding) String int, embstr, raw (SDS) List listpack, quicklist Hash listpack, listpackEx, hashtable Set intset, listpack, hashtable ZSet listpack, skiplist + hashtable Stream rax + listpack graph TD A[redisObject] --> B{type} B -->|STRING| C[int / embstr / raw] B -->|LIST| D{size?} B -->|HASH| E{size?} B -->|SET| F{all int?} B -->|ZSET| G{size?} B -->|STREAM| S[rax + listpack] D -->|小| DL[listpack] D -->|大| DQ[quicklist] E -->|小| H[listpack] E -->|field TTL| HX[listpackEx / hashtable metadata] E -->|大| I[hashtable] F -->|yes & 少| J[intset] F -->|no & 小| K[listpack] F -->|大| FH[hashtable] G -->|小| L[listpack] G -->|大| M[skiplist + hashtable]每种类型根据数据量自动切换编码：小数据用紧凑结构省内存，大数据切高效结构保性能。 ...

前言 Java 作为一门历史悠久的编程语言，一直在不断演进。本文按照 LTS（长期支持）版本 组织，介绍 Java 8 到 Java 25 的重要新特性，帮助开发者快速了解每个版本可以用哪些功能。 💡 每个特性后标注的版本号表示该特性正式可用的最低版本。 Java 8 LTS (2014) - 里程碑式更新 Java 8 是 Java 历史上最重要的版本，引入了函数式编程的核心概念。 Lambda 表达式 是什么？ 一种简洁的匿名函数写法，把"行为"像数据一样传递。 JAVA// ❌ 传统写法 Collections.sort(list, new Comparator<String>() { @Override public int compare(String s1, String s2) { return s1.compareTo(s2); } }); // ✅ Lambda 写法 Collections.sort(list, (s1, s2) -> s1.compareTo(s2)); // ✅ 方法引用 Collections.sort(list, String::compareTo); Lambda 语法： ...

MySQL 技术要点 一、MySQL 架构 MySQL 采用分层架构设计，主要分为 Server 层 和 存储引擎层。 1.1 Server 层 组件 职责 连接器 管理客户端连接、身份认证、权限校验 分析器 词法分析（识别关键字、表名、列名）、语法分析（构建语法树） 优化器 生成执行计划、选择最优索引、决定 JOIN 顺序 执行器 调用存储引擎 API 执行查询，返回结果集 1.2 存储引擎层 MySQL 支持插件式存储引擎，常用引擎对比： 引擎 事务支持 锁粒度 适用场景 InnoDB ✓ 行锁 OLTP、高并发读写 MyISAM ✗ 表锁 只读或读多写少 Memory ✗ 表锁 临时表、缓存 InnoDB architecture 二、索引机制 2.1 索引数据结构 类型 特点 适用场景 B+ Tree 有序、支持范围查询、树高稳定 主键索引、普通索引 Hash O(1) 查找、不支持范围查询 等值查询（Memory 引擎） Full-Text 倒排索引、支持自然语言搜索 全文检索 2.2 索引分类 按物理存储： ...

领域驱动设计(DDD) 领域驱动设计（Domain-Driven Design, DDD）是一种以领域模型为核心的软件开发方法论，旨在应对复杂业务系统的设计与演进。DDD 分为战略设计和战术设计两个层面：战略设计关注系统整体的边界划分与团队协作模式，战术设计则聚焦于领域模型的具体实现模式。 1. 战略设计 战略设计的目标是从整体上划分系统的限界上下文（Bounded Context），并在每个上下文中发展出清晰一致的通用语言（Ubiquitous Language）。 1.1 领域与子域 领域（Domain）：系统所关注的问题范围，代表业务活动和规则的集合。 子域（Subdomain）：领域的组成部分，将复杂业务划分为更小、更聚焦的单元。 子域通常分为三类： 类型 说明 核心域（Core Domain） 业务的核心竞争力所在，需要重点投入 支撑域（Supporting Subdomain） 支撑核心业务运作，但非核心竞争力 通用域（Generic Subdomain） 通用功能，可采用现成方案 领域分析发生在问题空间（Problem Space），而领域模型的设计与实现属于解决方案空间（Solution Space）： 问题空间：识别业务目标和边界，关注"做什么"。 解决方案空间：将需求转化为可实现的设计和模型，关注"怎么做"。 1.2 限界上下文（Bounded Context） 限界上下文是领域模型的语义边界。在该边界内，所有的概念、对象和规则都有明确且一致的含义。 同一个术语在不同上下文中可能代表不同含义，而在同一上下文中则保持语义一致。 例如，“账户"在用户上下文中可能指用户登录凭证，而在财务上下文中则指资金账户。限界上下文的划分有助于避免模型的混淆和污染。 1.3 通用语言（Ubiquitous Language） 通用语言是限界上下文内部领域专家与开发人员共享的统一语言。它通过领域模型来表达业务规则、行为和约束。 每个限界上下文都有自己独立的通用语言 通用语言不能跨上下文混用 代码、文档、沟通都应使用通用语言 1.4 上下文映射（Context Mapping） 当不同的限界上下文需要交互时，必须通过上下文映射来完成语言的"翻译"和语义对齐。上下文映射定义了上下文之间的关系、通信模式以及模型转换方式。 常见的上下文映射模式包括： 模式 说明 合作关系（Partnership） 两个团队共同协调开发，相互依赖 共享内核（Shared Kernel） 共享部分模型代码，需谨慎管理 客户-供应商（Customer-Supplier） 上游供应、下游消费，下游可提需求 遵奉者（Conformist） 下游完全遵从上游模型 防腐层（ACL） 下游建立转换层隔离上游模型 开放主机服务（OHS） 上游提供标准化协议供多方使用 发布语言（Published Language） 使用标准化的数据交换格式 1.5 防腐层（Anti-Corruption Layer） 下游上下文在使用上游上下文的数据或服务时，应建立一个防腐层（ACL）。防腐层负责： ...

IM 消息拉取接口的 SQL 优化记录 1. 背景与问题 在开发 IM 系统的“拉取历史消息”功能时，我发现当单张消息表（messages）的数据量达到百万级，且某个热点会话（conversation_id）拥有超过 10 万条消息时，接口响应出现明显卡顿。 环境信息： 数据库：MySQL 8.0+ (InnoDB) 数据量：单表 100 万行，大会话 10 万条信息 场景：用户查看最新的 20 条消息（Top-N 查询） 慢查询 SQL： SQLSELECT * FROM messages WHERE conversation_id = 'chat_hot' ORDER BY seq DESC LIMIT 20; 2. 排查过程 2.1 慢日志抓取 开启 MySQL 慢查询日志（log_output=FILE, long_query_time=0.1），捕获到该语句的执行情况： TEXT# Query_time: 0.148528 Lock_time: 0.000003 Rows_sent: 20 Rows_examined: 151676 异常点：为了返回 20 条数据，MySQL 实际扫描了 15 万行数据。扫描/返回比极低，说明索引效率存在严重问题。 2.2 执行计划分析 (EXPLAIN) 执行 EXPLAIN 查看当前索引使用情况： ...