1. 特征并发读写的数据流边界问题
1.1 业务场景
现代大型系统普遍采用特征分支开发模式：同一份数据（如用户画像、商品库存、配置策略）被多个特征团队并行读写。典型场景包括：
- 推荐特征实时计算：多个推荐策略同时读取用户点击序列，并写入新的行为特征。
- 风控规则热更新：风控团队在线调整规则特征权重，同时线上请求持续读取并比较。
- AB实验分流：实验平台并行写入多个实验版本的特征值，服务网关根据用户ID读取对应版本。
这些场景的共同特征是：写入方来自不同团队/不同微服务，读取方为高并发请求处理链，且对数据一致性与可用性都有严格约束。
1.2 核心矛盾
直接让多个特征写入方并发修改同一份数据，会引发三个层次矛盾：
| 矛盾层 | 表现 | 典型后果 |
|---|---|---|
| 互斥锁争抢 | 写入与读取竞争同一行记录上的锁 | 读请求大量超时，服务雪崩 |
| 语义冲突 | 两个特征写入同时修改同一字段的不同部分 | 数据覆盖、逻辑混乱 |
| 时效性失配 | 写入方期望立即生效，读取方要求最终一致性 | 脏读或版本断裂 |
核心矛盾：如何在不阻塞高频读取的前提下，支持多个特征安全、独立地写入，保证数据最终正确？
1.3 边界定义
我们将特征读写并发数据流边界定义为：
- 物理边界：数据通道的入口/出口，例如缓存层、持久化存储层之间的网络接口。
- 逻辑边界：特征数据的所属域与版本域，例如
feature_namespace:feature_key:version形成的隔离单位。 - 协议边界：写入方的提交规范与读取方的获取规范（如批量读、版本号声明、冲突解决策略）。
边界的价值在于将并发的复杂度局限在边界内部，外部调用方只需遵守简易接口，无需感知锁粒度、版本合并、冲突检测等机制。
1.4 边界封装的价值
| 价值维度 | 解释 |
|---|---|
| 读请求无锁化 | 读取方仅从边界公开的快照视图获取数据，无需等待写入完成 |
| 写方独立演进 | 每个特征写入模块只需关心自身写入协议，不依赖其他模块的实时状态 |
| 冲突降级可审计 | 所有冲突事件在边界层被记录，可回放、可重算 |
| 整体吞吐提升 | 读写分离、缓冲批量写入，减少临界区占用 |
1.5 问题抽象与分层
从系统架构视角，我们将问题拆解为四层：
- 识别层：明确哪些数据属于“特征数据”，哪些操作为“并发读写”。
- 边界层：定义数据流入口/出口、版本控制策略、冲突判定规则。
- 调度层：安排写入顺序、批量合并、缓存刷新时机。
- 治理层：监控边界压力、冲突频次、数据延迟，动态调整参数。
课程定位：本章为后续所有章节打下概念基础。后续章节将分别深入边界识别原则、分层职责分配、数据流/控制流设计、并发冲突处理模式、封装策略及落地步骤。
1.6 边界问题图谱
下图给出特征并发读写数据流边界的典型结构，标识出主要矛盾点与封装边界的位置。
注意：本图仅展示单实例边界结构。分布式场景下边界可能分裂为多个本地边界 + 全局协调节点，我们将在第8章“分布式边界设计”中深入。
1.7 风险点清单（本章范围）
- 边界识别遗漏：未将隐藏的并发写入口纳入边界管控，导致绕过封装的原始写操作。
- 版本管理缺失：未定义版本号规范，导致冲突时无法确定覆盖顺序。
- 读延迟被写阻塞：如果边界的快照视图更新锁过大，可能与高并发读形成隐性竞争。
- 边界退化：紧急降级时直接暴露底层存储，导致未封装的原始并发问题回归。