追风笔记

Dubbo 总体架构与核心概念

Tue, 25 Aug 2026 00:00:00 +0000

Dubbo 的核心竞争力在于清晰的职责分层与高度可插拔的扩展机制。理解分层与 Invoker 抽象，是读懂 Dubbo 源码与排查线上问题的基础。

分层架构

Dubbo 自顶向下可分为若干逻辑层，每一层只依赖其下层的接口而非实现：

service / config 层：面向用户的 API 与配置层，@DubboService、@DubboReference 以及 ReferenceConfig、ServiceConfig 在此落地。
proxy 层：生成服务接口的动态代理，让远程调用对业务代码透明。
registry 层：封装服务注册与订阅，感知 provider/consumer 的上线下线。
cluster 层：将多个 Invoker 封装为「集群 Invoker」，负责负载均衡、容错与路由。
protocol 层：封装 RPC 调用，是 Invoker 暴露与引用的核心。
filter 链：贯穿调用的拦截器，可用于日志、鉴权、限流等横切逻辑。

Invoker 与 SPI

Invoker 是 Dubbo 的通用领域模型，代表「一个可执行且可描述的调用」，抽象了本地、远程、集群等不同类型的调用。URL 则作为贯穿各层的配置总线，几乎所有扩展点都通过 URL 传递参数。

Dubbo 的扩展机制基于改进版的 JDK SPI，通过 @SPI 注解声明扩展接口，@Adaptive 生成自适应实现，META-INF/dubbo/ 下以接口全限定名命名的文件登记实现类：

@SPI("dubbo")
public interface Protocol {
 @Adaptive
 <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;
 @Adaptive
 <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;
}

一次同步调用的链路

当 consumer 发起一次同步调用时，请求大致经历以下步骤：

Kafka 存储与消费模型

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的高性能依赖于「分区日志 + 顺序写 + 批量拉取」的设计。理解存储与消费模型，才能合理配置并行度与避免重复消费。

Topic 与 Partition

topic 是逻辑主题，partition 是物理并行单位，消息只追加写入分区末尾。
每个分区是一个有序、不可变的日志，由多个 segment 文件组成，并维护 offset（分区内唯一递增）。
分区数决定了消费的并行上限：一个分区同一时刻只被 group 内一个消费者消费。

Offset 与消费位移

消费者处理完消息后提交的位移称为 offset，Kafka 将其保存在内部 topic __consumer_offsets 中：

Producer -> [partition-0: 0,1,2,3 ...]
 ^
 | committed offset (group A)
Consumer group A 从 offset=4 继续拉取

位移提交方式影响可靠性：

自动提交：间隔提交，可能丢失（提交后未处理崩溃）或重复（处理中崩溃未提交）。
手动提交：处理成功后再提交，配合幂等可实现至少一次/精确一次。

Consumer Group 与 Rebalance

同一 group 内的消费者共同消费 topic 的全部分区，分区在成员间均衡分配。当成员加入/退出时触发 rebalance，重新分配分区。频繁 rebalance 会暂停消费，应控制 session.timeout 与 heartbeat.interval 并避免消费耗时过长。

MySQL 索引原理与最佳实践

Tue, 25 Aug 2026 00:00:00 +0000

索引是 MySQL 查询性能的决定性因素。理解 InnoDB 的 B+Tree 索引结构，才能写出真正命中索引的 SQL。

B+Tree 与聚簇索引

InnoDB 使用 B+Tree 组织索引，其特点是非叶子节点只存索引键用于导航，所有数据都落在叶子节点，且叶子节点通过双向链表串联，非常适合范围扫描。

InnoDB 的主键索引是聚簇索引，叶子节点直接存放整行数据；二级索引的叶子节点存放「索引键 + 主键值」。因此通过二级索引查询非索引列时，需要再用主键回表查聚簇索引。

回表与覆盖索引

当查询的列都在二级索引中时，无需回表，称为覆盖索引，性能更好：

-- idx_user_age 为 (name, age) 的联合索引
-- 仅取索引列，命中覆盖索引
SELECT name, age FROM user WHERE name = 'tom';

若 SELECT * 还需要 phone 等额外列，则会触发回表。高频查询应优先设计为覆盖索引。

最左前缀原则

联合索引 (a, b, c) 能生效的条件是查询从最左列开始连续匹配：

WHERE a = ? 可用
WHERE a = ? AND b = ? 可用
WHERE b = ? 无法使用该联合索引（断开了最左前缀）

避免索引失效

常见导致索引失效的写法：

Redis 数据结构与底层实现

Tue, 25 Aug 2026 00:00:00 +0000

Redis 对外暴露五种常用类型，但底层有多种编码（encoding）。根据数据规模自动在不同编码间转换，是它兼顾内存与性能的关键。

核心底层结构

SDS（简单动态字符串）：相比 C 字符串记录长度、预分配空间，避免缓冲区溢出并支持二进制安全。
ziplist / listpack：连续内存的紧凑列表，节省空间，适合小数据量。
linkedlist：双向链表，元素多时替代 ziplist。
dict（字典）：哈希表，使用链地址法解决冲突，渐进式 rehash 避免阻塞。
skiplist（跳表）：多层有序链表，结合 dict 实现 zset，范围查询高效。

各类型的编码与转换

类型	小数据编码	大数据编码	转换阈值（示意）
string	int / embstr	raw	长度 > 44 字节转 raw
hash	ziplist/listpack	hashtable	元素数或单个值超阈值
list	quicklist（ziplist 片段）	quicklist	—
set	intset	hashtable	含非整数或元素过多
zset	ziplist	skiplist+dict	元素数或值长度超阈值

以 zset 为例，小数据使用 ziplist 紧凑存储（member 与 score 相邻），当元素数量或单个 member 长度超过阈值时转为 skiplist + dict，保证有序遍历与按 member 查找都为 O(1)/O(log n)。

zset 小: [member1, score1, member2, score2, ...] (ziplist)
zset 大: dict(member->score) + skiplist(score->member)

理解这些阈值有助于解释「为什么小哈希比单独 key 省内存」，也提醒我们避免让单个 key 堆积过多元素，否则编码升级或操作耗时都会陡增。

ZooKeeper 数据模型与 ZAB 协议

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper 的可靠性来源于其简洁的数据模型与强一致的 ZAB 协议。理解二者是正确使用 ZK 的前提。

数据模型 znode

ZK 维护一棵类似文件系统的层级树，每个节点称为 znode，可同时承载数据与子节点。其类型决定了生命周期与并发语义：

持久节点 / 临时节点：临时节点随 session 断开自动删除，是分布式锁、选主的基础。
普通节点 / 顺序节点：顺序节点创建时自动追加单调递增序号。
每个 znode 带有 version、cversion、aversion，修改时版本自增，提供乐观锁语义。

Session 与 Watcher

客户端与服务器建立 session，通过心跳保活，session 超时则服务器清理其临时节点。客户端可对节点注册 Watcher，节点发生变化（数据写、子节点变）时收到一次性通知，需重新注册才能继续监听。

ZAB 协议

ZAB（ZooKeeper Atomic Broadcast）是为 ZK 设计的崩溃恢复原子广播协议，保证所有事务以相同顺序被所有副本应用。

崩溃恢复与选主

集群启动时或 Leader 宕机进入恢复阶段：选举产生新 Leader，并让各 Follower 补齐到与 Leader 相同的状态。选主依赖 zxid（事务 id）与 myid，zxid 越大代表数据越新，优先当选。

消息广播

正常阶段采用类似 2PC 的广播：Leader 为每个写请求分配递增 zxid 并发起提议，Follower 写本地日志后 ACK，Leader 收到多数派 ACK 即提交并通知应用。

PageFly

Mon, 01 Jan 0001 00:00:00 +0000

PageFly 是一个面向 AI 工作流的轻量页面托管方案：写好 HTML/Markdown 后直接发布，适合把分析页、工具页或实验性内容快速上线。

状态：已上线
地址：https://fly.882680.xyz
技术栈：Cloudflare Pages + Functions + KV（免费层）
用途：个人工作流落地页、轻量产品原型、AI 输出展示

Kafka 可靠性与精确一次

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的可靠性需要在 producer、broker、consumer 三端协同配置。下面从「不丢、不重、有序」三个目标展开。

Producer 端的可靠性

通过 acks 控制写入持久化级别：

acks=0：发完即认为成功，可能丢消息，吞吐最高。
acks=1：leader 写入即成功，leader 宕机可能丢。
acks=all：ISR 全部同步才成功，最安全，配合 min.insync.replicas 防单点。

开启重试（retries）可应对瞬时失败，但会带来重复：网络抖动导致 producer 未收到 ack 而重试，同一条消息被写两次。

幂等 Producer 与事务

Kafka 提供 幂等 producer（enable.idempotence=true），broker 用 producerId + 序列号 去重，保证单分区内不重不漏。需要跨分区、跨系统的原子写入时，使用事务（transactional.id）将多次 produce 与 offset 提交纳入一个事务：

producer.initTransactions();
producer.beginTransaction();
producer.send(record1);
producer.send(record2);
producer.commitTransaction(); // 要么都成功，要么都不可见

消费端去重与幂等

即使 producer 幂等，consumer 在 rebalance 或位移提交时机不当时仍可能重复消费。消费端应保证业务幂等：

用唯一键（订单号等）做去重表/唯一索引。
将「处理 + 提交位移」放在同一事务（如消费写 DB 同时记录 offset）。

分区顺序性

Kafka 只保证单分区内有序。需要全局顺序只能单分区（牺牲并行）；需要业务顺序则按 key（如用户 id）分区，使同一 key 落到同一分区，从而在该 key 维度保持顺序。精确一次（EOS）正是幂等 + 事务 + 消费幂等三者叠加的结果。

MySQL 事务与锁机制

Tue, 25 Aug 2026 00:00:00 +0000

并发场景下，事务与锁共同保证了数据的一致性。InnoDB 通过 MVCC 与锁的协同，在性能与隔离性之间取得平衡。

ACID 与隔离级别

事务的 ACID 由不同机制保障：原子性靠 undo log，持久性靠 redo log，隔离性靠 MVCC 与锁，一致性是最终目标。

SQL 标准定义四种隔离级别，InnoDB 默认 REPEATABLE READ：

READ UNCOMMITTED：可能脏读
READ COMMITTED：避免脏读，可能不可重复读
REPEATABLE READ：避免不可重复读（InnoDB 额外避免幻读）
SERIALIZABLE：完全串行，性能最低

MVCC 与日志

MVCC（多版本并发控制）让读不加锁、读写不阻塞。每行记录隐含 trx_id 与 roll_pointer，通过 undo log 构建历史版本，配合 ReadView 判断某版本对当前事务是否可见。

undo log：记录数据修改前的镜像，用于回滚与构建旧版本。
redo log：记录物理页修改，保证崩溃后已提交事务不丢失（WAL 机制）。

行锁、间隙锁与 Next-Key Lock

InnoDB 默认使用行锁，但「锁的是索引记录」而非行本身。在 REPEATABLE READ 下，为解决幻读引入：

行锁（Record Lock）：锁住具体索引记录。
间隙锁（Gap Lock）：锁住索引记录之间的间隙，阻止插入。
Next-Key Lock：行锁 + 间隙锁，锁定左开右闭的区间。

-- 在 (10, 20] 区间加 Next-Key Lock，阻止其他事务插入 id=15
SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE;

死锁成因与排查

死锁通常由两个事务以相反顺序获取锁引起。排查手段：

Redis 缓存设计

Tue, 25 Aug 2026 00:00:00 +0000

引入缓存能显著降低数据库压力，但设计不当会引入穿透、击穿、雪崩等经典问题。下面逐一拆解成因与对策。

三大经典问题

缓存穿透：查询不存在的数据，缓存与数据库都查不到，请求每次都打到 DB。应对：缓存空值（短过期）、布隆过滤器拦截非法 key。
缓存击穿：某个热点 key 过期瞬间，大量并发同时回源 DB。应对：互斥锁（只放一个线程重建）、逻辑过期（异步刷新）、热点 key 不过期。
缓存雪崩：大量 key 同一时刻集中失效，或 Redis 整体不可用，DB 被冲垮。应对：过期时间加随机抖动、多级缓存、Redis 高可用（哨兵/集群）。

Cache-Aside 与一致性

最常用的是 Cache-Aside（旁路缓存）：

读: 先读缓存 -> 命中返回; 未命中读 DB -> 写入缓存
写: 先更新 DB -> 再删除缓存 (而非更新缓存)

「先更新 DB 再删缓存」可降低并发下读到旧值的概率；极端不一致可通过延迟双删或订阅 binlog（如 Canal）补偿。注意：不要盲目「更新缓存」，否则并发写可能产生脏数据。

大 key 与热 key

大 key：如包含百万元素的 hash/list，删除或序列化会阻塞主线程。应对：拆分、分批删除（unlink）、定期清理。
热 key：单个 key 访问极高，单节点成为瓶颈。应对：本地缓存副本、key 打散到多个副本、Redis 集群分片。

过期与淘汰策略

Redis 提供主动 + 惰性两种过期删除，内存不足时按 maxmemory-policy 淘汰：

ZooKeeper 分布式协调实战

Tue, 25 Aug 2026 00:00:00 +0000

ZooKeeper 提供原语级的协调能力，几乎所有分布式协调需求都可基于「临时节点 + 顺序节点 + Watcher」组合实现。

选主（Master Election）

每个候选者在 /election 下创建临时顺序节点，序号最小的即成为 Master。非最小节点监听其前一个节点，前驱消失时重新判断自己是否最小，从而实现故障自动转移：

/election
 ├── /n_0000000001 (master)
 ├── /n_0000000002 (watch 001)
 └── /n_0000000003 (watch 002)

配置中心

将配置写入持久节点，客户端读取并注册 Watcher，配置变更时收到通知后热更新，无需重启应用。注意配置节点应控制体积，避免单次推送过大。

分布式锁

基于「临时顺序节点 + 监听前驱」实现公平排他锁，比简单 create 抢锁更健壮、可避免惊群。

羊群效应（Herd Effect）

若所有客户端都监听同一个锁节点，释放时会被同时唤醒并争抢，产生大量无效请求。正确做法是只监听比自己序号小的前一个节点，形成链式唤醒，将 O(N) 通知降为 O(1)。

临时节点的坑

客户端 GC 停顿或网络抖动可能导致 session 超时，临时节点被误删而锁提前释放。需结合合理的 sessionTimeout 与心跳。
持锁方崩溃后锁自动释放，但业务未提交，需保证操作幂等。

与 etcd 的取舍

etcd 基于 Raft，提供更强一致与租约（lease）、Watch 增量推送，API 更简单，云原生场景（Kubernetes）更主流；ZK 生态成熟、客户端丰富，但在超大规模 Watch 下存在性能瓶颈。新项目可优先考虑 etcd，存量 Dubbo/Hadoop 体系仍常用 ZK。

服务注册与发现实战

Tue, 25 Aug 2026 00:00:00 +0000

服务注册与发现是微服务架构的基石。Dubbo 将注册中心抽象为 Registry 接口，因此可以在 ZooKeeper、Nacos、Consul 等实现之间平滑切换，业务代码无需改动。

注册中心接入

以 Nacos 为例，只需在配置中声明注册中心地址与协议即可。Dubbo 在启动时自动完成服务导出（export）与订阅（subscribe）：

dubbo:
 application:
 name: order-service
 registry:
 address: nacos://127.0.0.1:8848
 protocol:
 name: dubbo
 port: 20880

Provider 启动后会在注册中心写入自身元数据（接口、IP、端口、权重等）；Consumer 启动后订阅接口节点，拿到可用 Provider 列表并缓存到本地，后续调用直接走本地缓存，降低注册中心压力。

健康检查与上下线

注册中心侧健康：基于临时节点（ZooKeeper）或心跳（Nacos）感知进程存活，进程宕机时节点被摘除，Consumer 收到 unregister 通知后剔除实例。
应用侧优雅下线：收到 SIGTERM 时先取消注册、拒绝新请求、等待在途请求处理完毕再退出，避免调用方打到已下线的实例。

不停机发布

滚动发布时常见问题是「刚下线就又有流量」。推荐组合拳：

下线前通过注册中心将实例权重置 0，使其不再接收新流量。
等待预热期与在途请求排空（如 10s）。
再执行实际进程关闭。

配合 Consumer 端的失败重试与 Cluster 容错（如 Failover），可基本实现调用方无感知的版本迭代。需要注意：注册中心通知存在网络延迟，Consumer 本地缓存与重试机制是兜底关键。

投资顾问系统

Mon, 01 Jan 0001 00:00:00 +0000

一个偏向个人投资研究的原型系统：用 AKShare 获取 A 股/基金数据，Supabase 做后端存储，All-Weather 策略做资产配置参考。

状态：进行中
技术栈：Python / AKShare / Supabase / All-Weather
目标：把「数据获取 → 策略回测 → 组合跟踪」串成可复用的工作流
适用：个人投资研究，非投资建议

认知匹配 / AI 认知画像

Mon, 01 Jan 0001 00:00:00 +0000

一个轻资产创业方向的探索：通过 AI 认知画像，把人的知识结构、偏好与能力结构化，再与机会（项目、人、内容）做匹配。

状态：规划中
形态：React + Claude API 的轻量原型
投入：每周约 18–27 小时，优先免费/低成本方案
核心问题：如何把「认知相似性」变成可计算、可解释的匹配信号

中文 AI 人味化 skill

Mon, 01 Jan 0001 00:00:00 +0000

一个 WorkBuddy skill（v3.0.0-zh），用于把 AI 生成的中文内容去「AI 味」，覆盖 18 类常见痕迹：夸张象征、宣传腔、-ing 分析、模糊归因、破折号滥用、三段式、AI 词汇等。

版本：v3.0.0-zh
形态：WorkBuddy skill
用途：公众号、技术文档、邮件、报告等需要「像人写的」中文场景
思路：先检测痕迹模式，再按类别做针对性改写

银行业本体论

Mon, 01 Jan 0001 00:00:00 +0000

把银行科技中反复出现的概念（组织、产品、账户、交易、客户、渠道、风险、监管报送等）结构化成本体，形成可复用的知识框架。

状态：研究中
输出：PPT、概念图、领域词汇表
目标：让业务→技术→数据的映射有统一语言
关联方向：ECIF、MDM、监管报送、数据资产

开博第一篇：为什么写「追风笔记」

Sat, 15 Aug 2026 00:00:00 +0000

做银行系统架构这些年，踩过的坑、想明白的事，大多散落在笔记本和聊天记录里。开这个站点，是想把它们系统地沉淀下来。

我会写什么

架构专栏：客户信息系统（ECIF）、核心系统、分布式架构，以及领域驱动设计（DDD）在银行场景下的落地。
银行业务专栏：支付清算、计息与限额、账户/卡、反洗钱（AML）/KYC/CRS 等核心业务梳理。
数据专栏：数据治理、加密与安全、分库分表、消息与流处理。

写给谁

同行、想转行做金融科技的工程师，以及任何对「银行系统为什么这么设计」感到好奇的人。

这个站点是示例内容，框架搭好后，真实文章会逐步替换进来。

在银行客户信息系统（ECIF）里落地 DDD 聚合

Wed, 12 Aug 2026 00:00:00 +0000

ECIF 里「客户」的概念极其庞大：个人、对公、同业，各自的属性、关系、生命周期都不同。如果用一个巨大的 Customer 实体硬扛，代码会迅速腐化。

用界限上下文切分

把客户拆成几个界限上下文：

客户主数据（Party）：统一的自然人/机构标识与基础属性。
客户画像（Profile）：风险偏好、营销标签，读写频率高、变化快。
客户关系（Relationship）：持股、担保、集团关系。

聚合根怎么定

每个上下文内部再定聚合根。例如 Party 上下文里，Party 是聚合根，Address、Contact 是其值对象，保证一致性边界内不跨聚合调用。

经验：聚合的边界应以「事务一致性」而非「业务概念大小」来划。ECIF 里最容易犯的错，就是把所有客户信息塞进一个聚合。

这样设计后，主数据服务稳定，画像服务可以独立迭代，互不影响。

一文理清 ECIF：客户信息为什么要「集中」

Mon, 10 Aug 2026 00:00:00 +0000

在没有 ECIF 的年代，网点、网银、信用卡中心各自维护一份客户信息。同一个客户，在不同系统里姓名、证件、联系方式都不一样，营销和风控都无从谈起。

ECIF 解决什么

ECIF（企业客户信息整合）把分散在各业务系统的客户主数据收敛到一处，对外提供唯一客户视图。

唯一标识：用客户号（Party ID）统一自然人/机构，而非证件号。
主次关系：支持一人多户、一户多卡，但主数据唯一。
服务化：其他系统通过接口查询，不再各自落库。

技术上的关键取舍

读写分离：主数据写入强一致，查询可走缓存/只读副本。
变更可溯源：客户信息变更需要留痕，满足监管审计。

ECIF 不是「又一个数据库」，而是银行数字化的最底层地基。

银行数据治理：先治「元数据」再治「质量」

Sat, 08 Aug 2026 00:00:00 +0000

很多银行的数据治理项目最后沦为「补元数据、填责任表」。要见效，得把治理内建到数据生产的流水线里。

两件事优先做

元数据与血缘：字段从哪个系统来、被哪些任务加工、流向哪里，必须可自动追踪。
质量规则内建：非空、唯一、口径一致等校验，在 ETL/湖仓任务里当「门禁」，不过不入库。

安全与加密

静态加密：落盘即对敏感字段加密（如证件号、卡号）。
动态脱敏：查询侧按角色脱敏，开发环境拿不到明文。

治理的目标不是「漂亮的报告」，而是让 downstream 系统敢用这份数据。

关于

Mon, 01 Jan 0001 00:00:00 +0000

简介

王鹏，数学学士 + 软件工程硕士（跨专业），现就职于某银行总部（北京），从事核心系统后端研发。主要关注分布式架构、单元化部署、银行核心业务建模，以及 AI 在银行业务中的工程化落地。

证书：PMP
技术主线：Java 后端、分布式系统、DDD / CQRS / Saga、企业架构与数据资产
当前重点：对客 AI Agent 平台建设；企业级 Java AI 框架选型（Spring AI 2.0 / LangChain4j / SAA / Embabel）

经历

阶段	内容
教育	数学本科 → 软件工程硕士（跨专业转型）
现任	银行总部核心系统研发工程师
备考	软考高级「系统架构设计师」

技术栈

Java · Spring Cloud · 分布式事务 · 单元化 · DDD · 数据库（MySQL / 分库分表）· 消息与流（Kafka）· 缓存（Redis）· 协调服务（ZooKeeper）· 微服务治理 · 企业架构

项目与研究

详见项目与技术笔记。近期方向包括：投资顾问系统（AKShare + Supabase + All-Weather）、认知匹配 / AI 认知画像、PageFly 轻量页面托管、中文 AI 人味化、银行业本体论，并计划重启「银行科技 + AI」主题公众号。