特征读写模型定义：读写特征、数据一致性要求、性能指标
特征读写模型是分布式系统或并发模块中，对同一份数据（特征）进行并发读取与写入时所遵循的访问协议与约束集合。本章作为讲义的第一章，明确“读写特征”的类型、“数据一致性要求”的范围以及“性能指标”的衡量维度，为后续章节的模块边界划分与控制流设计奠定基础。
本章定位：所有后续章节的选型标准、风险分析和落地步骤都基于本章定义的模型要素。理解本章后，才能有效界定模块边界并设计并发控制策略。
模块边界
特征读写的模块边界由以下三个维度界定：
- 数据域边界：特征集合的归属范围（如用户画像特征、设备特征、业务特征），不同域之间不允许直接读写交叉，必须通过中介层交互。
- 并发边界：同一特征在同一时刻允许的最大读者数与写者数，以及写者是否阻塞读者。
- 生命周期边界：特征的创建、更新、过期、删除操作必须归属同一模块或经过明确仲裁。
组件职责
| 组件 | 职责 |
|---|---|
| 特征写入器（Writer） | 提交特征更新，触发版本号递增；必须持有写锁或通过无锁CAS（Compare-And-Swap）写入 |
| 特征读取器（Reader） | 读取特定版本的特征快照；可接受过期读（Tolerate Stale Read）或强一致读取 |
| 一致性仲裁器（Consensus Arbiter） | 在写写冲突（Write Conflict）时判定最终版本；仅在强一致模式下生效 |
| 版本管理器（Version Manager） | 存储特征版本号、时间戳、快照指针，支持多版本并发控制（MVCC） |
| 性能监控器（Perf Monitor） | 采集读延迟、写延迟、吞吐量、冲突率等指标，上报决策单元 |
核心概念
读写特征
- 读偏重（Read Heavy）：读操作远多于写操作，适合引入缓存与快照读，降低写锁开销。
- 写偏重（Write Heavy）：写操作频繁，需优先解决写冲突与版本膨胀，可采用写时拷贝（COW）或批量合并。
- 读写混合（Mixed）：读写比例接近，同时要求低延迟与高吞吐，需要读写分离或乐观并发控制。
数据一致性要求
| 一致性级别 | 说明 | 典型场景 |
|---|---|---|
| 强一致性（Linearizability） | 读操作总能返回最近一次写入的值，所有操作顺序全局一致 | 支付特征、库存特征 |
| 最终一致性（Eventual Consistency） | 如果没有新写入，最终所有读操作返回相同值 | 用户昵称、推荐特征 |
| 因果一致性（Causal Consistency） | 有因果关系的写事件必须被所有观察者按相同顺序看到 | 会话特征、风控特征 |
| 单调读一致性（Monotonic Read） | 同一客户端不会读到过时的值 | 个性化配置特征 |
性能指标
- P99 读延迟：99%的读操作在给定时间范围内完成。
- P99 写延迟：写入操作从发起至确认的最大延时。
- 吞吐量（QPS/TPS）：每秒完成的读/写事务数。
- 冲突率（Conflict Rate）：写写冲突或ABA问题出现的频率。
- 版本链深度（Version Chain Depth）：每个特征保留的版本快照数量，影响内存与GC负担。
常见误区：在特征读写的初始设计阶段，容易忽略“读偏重”与“写偏重”对模块边界的影响。例如，将写偏重特征与读偏重特征放在同一模块内共享写锁，会导致读操作被频繁阻塞，P99延迟飙升。
数据流与控制流
典型特征读写的数据流路径：
- 写请求到达特征写入器，申请写锁（或CAS尝试）。
- 写入器更新版本管理器，生成新版本号及快照。
- 特征数据写入底层存储（内存/磁盘）。
- 读请求到达特征读取器：若允许过期读，直接返回最近快照；若要求强一致读，等待所有未提交写入生效，或通过仲裁器获得最终版本。
- 性能监控器采集所有阶段的延迟与吞吐量，并反馈给负载调节器。
控制流由一致性仲裁器与版本管理器协同决定：写冲突时触发重试或分布式锁，读锁与写锁的粒度（行级/表级）通过配置下发。
选型权衡
- 强一致 vs 性能：强一致需要仲裁器参与每笔写操作，写延迟增加 2~5ms，P99读延迟在小并发测试下增加不明显，但冲突率>5%时延迟会恶化。
- MVCC 版本深度：保留更多版本可以支持快照读和回滚，但会增大内存占用和GC压力。建议写偏重场景版本深度≤3，读偏重场景≤10。
- 读锁粒度：行级读锁在高并发场景下能提升并发度，但锁管理开销较表级锁高 30% 左右。模块边界应尽量将热数据限定在小行集上。
风险点
- 写写冲突死锁：当两个写入器同时修改同一特征的行与列时，若锁顺序不一致，可能产生死锁。解决方案：全局锁顺序编号或使用乐观锁+重试。
- 版本链长导致读取慢：超过10个未读版本时，读操作需要遍历版本链，P99延迟可能超过100ms。需设置版本淘汰策略。
- 一致性模型暴露给调用方：如果不明确限定模块边界内的一致性级别，下游调用方容易误用，造成业务逻辑错误。
落地步骤
- 识别特征域：将业务特征按“读偏重”、“写偏重”、“混合型”分类，并标记一致性需求。
- 选择一致性模型：根据业务容忍度，从强一致、最终一致、因果一致中选定；为每个特征域配置独立的一致性仲裁策略。
- 确定版本管理机制：接入MVCC或时间戳向量，设置最大版本深度与快照淘汰周期。
- 定义性能基线：在仿真环境中测量 P99读延迟、写延迟、冲突率，与目标指标对比。
- 划定模块边界：将不同特征域拆分为独立模块，模块间通过轻量级消息总线通信，避免锁扩散。
验收标准
| 验收项 | 通过标准 |
|---|---|
| 读延迟 P99 | ≤ 2ms（强一致场景）或 ≤ 1ms（最终一致场景） |
| 写延迟 P99 | ≤ 5ms（强一致场景）或 ≤ 1ms（最终一致场景） |
| 冲突率 | 写写冲突率 ≤ 2%，且重试次数均值 ≤ 1.2 |
| 一致性验证 | 在并发写入测试中，随机读取1000次，强一致场景下100%返回最新版本；最终一致场景下5秒内收敛。 |
| 模块边界隔离 | 一个特征域的写storm不会导致其他特征域的读延迟超过基线值的20% |
关键产出物：本章定义了特征读写模型的元数据库，包含每个特征域的一致性级别、版本管理方式、性能目标。其余章节将在此基础上展开模块边界设计、控制流编排与选型验证。