🎯 核心思想
借鉴 Rust 语言的所有权（Ownership）、借用（Borrowing）和生命周期（Lifetime）概念，构建分布式系统的数据管理模型。
“数据有其主，创建即拥有，默认只读，修改需流程，移交要审批，同步靠缓冲。”*
📦 三大核心概念
| 所有权（Owner） 数据所有者有者 | 每条数据有且仅有一个拥有者，创建者默认为拥有者 | |
| 借用（Borrow） | 读取权限 | 数据默认只借用者读者可查看但不可修改 |
| 可变借用（&mut） 流程化修改修改非所有者通过流程申请获得所有者审批后的临时修改权限权限 | ||
| 移动（Move） | 所有权转移 通过流程将所有权转移给他人，通常对应工作交接流程流程 | |
| 生命周期（Lifetime） | 数据有效期 | 数据从创建到销毁的完整时间线 |
🏗️ 服务端分布式所有者模型者模型
核心定位
-拥有者（Owner）即服务端服务端**：每条数据的拥有者节点就是该数据的“服务端”
-创世节点即第二服务端服务端**：作为系统初始节点，负责新节点加入引导、全局消息缓冲，同时也是其他拥有者的备份服务器
- 服务端数量不固定：每个数据拥有者都是一个逻辑服拥有者越多，服务端越多，从而构成分布式服务网络务网络
~分布式拥有者-服务端模型端模型
数据A（企业通讯录）
└── 拥有者 = HR节点（服务端A）
数据B（项目文档）
└── 拥有者 = 项目经理节点（服务端B）
数据C（设计图纸）
└── 拥有者 = 设计师节点（服务端C）
创世节点（第二服务端）
├── 引导新节点加入
├── 全局消息缓冲（离线缓存）
├── 其他拥有者的备份服务器
│ └当拥有者离线时，可暂代其提供数据同步服务步服务
└── 无数据所有权，仅同步中转
### 代码演进策略
| 阶段 | 策略 | 说明 |
|—|—|—|
| **当前** | 服务端代码完全融入 `core` 库每个节点都是潜在的服务端，逻辑集中在 `core` 中` 中 |
| **稳定后** | 从 `core` 分离为独立 `server` 模块 | 模型稳定后，将服务端逻辑独立为可选模块 |
| **未来** | 支持纯客户端模式 | 不承担服务端职责的节点可精简部署 |
## 🔄 数据操作模型
### 操作类型与权限
| 操作 | Rust 对应 | 权限要求 | 执行方式 |
|—|—|—|—|
| **创建** | `T::new()` | 任意节创建者默认为拥有者，并成为该数据的服务端的服务端 |
| **读取** | `&T` | 读取权（群成员） | 直接读取本地缓存 |
| **修改（拥有者）** | `&mut T` | 拥有者 | 直接修改 → 广播 → 作为服务端发布新版本 |
| **修改（读者）** | `&mut T`（申请） | 读者发起 → 拥有者确认 | 申请 → 审批 → 执行 → 广播 |
| **删除** | `drop(T)` | 拥有由拥有者删除或归档除或归档 |
| **所有权转移** | `move` | 拥有者发起 → 接收者确发起流程 → 转移所有权 → 广播→ 广播 |
| **同步** | `Clone` | 读者 | 接收广播，更新本地缓存### 拥有者直接修改流程需流程）
拥有者（服务端├── 1. 直接修改数据（基于拥有者权限）者信任├── 2. 生成新版本号（基于时间戳）时间戳）
│
├── 3. 本地存储更新
│
└── 4. 广播变更 → 创世节点 → 所有读者
读者发起修改流程（触发拥有者审批）拥有者）
读者发起申请 → 拥有者（服务端）接收 → 审批→├── 同意 → 拥有者执行修改 → 广播通知→└── 驳回 → 返回驳回原因返回原因
所有权转移流程（Move）
当前所有者发起转移申请转移申请
├── 选择目标接收者
├── 填写转移原因
└── 提交申请
│
▼
目标接收者收到通知
├── 查看转移详情
└── 确认接受 / 拒绝
│
▼
系统执行转移
├── 更新数据所有权记录
├── 记录转移日志
广播所有权变更通知有权变更
~## 📡 更新频率与同步策略与同步策略
三种同步模式
| 按需拉取 | 低频访问数据、专业文档草稿专业内草稿 | 用户主动请求 | 极低 |
| 实时推送 | 高频交互、已关注的文件已关注文件 | 拥有者修改后自动广播 | 中等 |
| 定时同步 | 每日更新的文件、计划性定稿文件计划性定稿 | 定时器触发 | 可控 |
文件在所有权模型中的定文件所有者 = 创建者，拥有文件的唯一写入权限唯一写文件修改遵循版本号机制（基于时间戳）（时间文件同步遵循三种模式：按需拉取、实时推送与定时同步定时同文件所有权转移遵循 Move 流程ve 流程
同步策略矩阵
| 聊天消息 | 推送 | — | — | — | — |
| 审批通知 | 推送 | — | — | — | — |
| 企业通讯录 | 推送 | — | — | — | — |
| 专业内设计文件 | 组内推送 | — | 定稿时发布 | — | 计划节点触发 |
| 跨专业设计文件 | 按需拉取 | 推送 | 发布时通知 | — | 计划节点触发 |
| 流程单附件 | 按需拉取 | 推送 | — | — | 审查节点触发 |
| 日报周报 | — | — | — | 每日/每周 | — |
| 初步定稿 | — | — | ✅ 一次性事件 | — | 里程碑触发 |
说明：“—” 表示该模式不适用于此数据类型该数据类型“计划驱动”指计划节点到达时自动触发的同步事件的同步事件
🕐 版本号设计
时间戳作为版本号
版本号 = 时间戳（毫秒级）
示例：
v1700000000000 → 2023-11-14 22:13:20.000
v1700000001000 → 2023-11-14 22:13:21.000
为什么不需要序列号？
在类Rust同一时刻只有一个写入者（所有者）者（拥有者），修改是顺序执行的，不会产生同一毫秒内的并发冲突，因此时间戳天然唯一且有序。
🕐 生命周期管理
数据状态流数据状态流转】
无状态（空）
│ 创建
▼
活跃（Active）
│ 修改/更新（拥有者或流变更中（Borrowed）── 完成 ──▶ 活跃（Active） ──▶ 活跃
│
│ 归档
▼
只读（Archived）
│ 销毁
▼
已销毁（Dropped）
### 生命周期各阶段说明
| 阶段 | 状态 | 权限 | 说明 |
|—|—|—|—|
| **活跃** | Ac拥有者可读写，读者可读可写，读者可读 | 数据正常使用中 |
| **归档** | Archived | 只读（长数据已冻结，仅支持查询，但仍处于生命周期内属于生命周期内 |
| **已销毁** | Dropped |数据已被彻底删除，此为生命周期终点，生命周期终点 |
## 📬 消**“邮箱”是一个比喻，其本质是创世节点的消息队列/存储区，用于缓存和转发离线期间的数据变更。**的数据变更。**
### 缓冲区工数据拥有者修改数据
拥有者修创世节点（缓冲区）
创世节点缓冲1. 追加变更记录，分配版本号消息，分配版本2. 检查各目标节点的同步游标有目标节点的游3. 在线节点：实时推送变更点 → 实时推送
│
└── 4. 离线节点 → 保留在缓冲区
│
▼
节点上线
│
├── 1. 请求所有待处理变更
│
├── 2. 缓冲区返回增量变更
│
├── 3. 节点应用变更，更新本地数据
│
└── 4. 更新游标，确认同步
🧩 设计原则
| 原则 | 说明 |
|–创建即拥有 | 数据的创建者默认为拥有者，并成为该数据的服务端成为该数据的服务端 |
| 唯一拥有者 | 每条数据有且仅有一个拥有者，杜绝默认只读 | 数据默认只读（&T），读者无法直接修改，读者无法直接修改 |
| 拥有者信任 | 拥有者直接修改，无需流程审批 |
| 流程即申请 | 读者的修改请求通过流程触发拥Move 需双方确认 | 所有权转移需由拥有者发起，并经接收者确认起 + 接收者确认 |
| 群定边界 | 群（Group）是读取权缓冲同步 | 创世节点的缓冲区缓存所有变更，按需同步所有变更，生命周期完整 | 数据从创建、归档到销毁有完整的状态管理毁有完整的状态管理 |
| 服务端融入核心 | 稳定前服务端代码融入 core，稳定后分离 |
| 分布式服务 | 每个拥有者都是服务端，形成分布式服务网络 |
✅ 模型价值总结
| **所有者/读者角色明确，权限边界清晰明确，权限边界清晰 | |
| 操作可审计 | 所有修改可服务端弹性扩展 |
| **分每个所有者都是服务端，形成去中心化的服务网络去中心化的服务网络 | |
| **高创世节点作为备用服务端，提供引导和备份能力提供引导和备份能力 | |
| 离线友好 | 缓冲区机制保证离线节点上线后自动同步 |
| 架构统一 | 消息、文件、流程都遵循同一套规则 |
| 代码演进 | 服务端代码先融入核心库，稳定后分离 |
“数据有其主，创建即拥有，默认是只读，修改走流程，移交需审批，同步靠缓冲，归档仍可查，销毁方终结。”
一句话总结：类Rust变量模式将Rust的所有权、借用和生命周期概念映射到分布式数据管理，每个拥有者都是服务端，形成清晰、可审计、去中心化的数据治理网络。
