背景与动机
kvspace 现状是纯 dispatch 前端库 （见 README）：消费者只链 libkvspace，运行期按 DSN scheme 选后端——
DSN scheme
后端
装载
shm://…kvspace-c（file-backed mmap + ART）
dlopen libkvspace-c.so.1（RTLD_LOCAL）
redis:// fs:// s3://kvspace-durable（Rust）
dlopen libkvspace_durable.so.1
即：一个连接 = 一个 DSN = 一个后端，进程本地装载，无跨节点概念、无常驻管理服务 。
这套纯库模型的边界在 kvspace-c 侧逐渐显现：#15（shm 运行期扩缩容：容量创建时锁死、缺 mremap/回收/多进程重映射握手）、#14（tensor.data 由扩展存储后端管理）等，都指向一个「主动管理」的角色——但单为某个库的一个局部问题起一个常驻服务，不划算 。
若把视角抬到「分布式 kvspace 系统」，这个常驻服务才有充分理由：统一纳管各节点的 kvspace-c shm 路径与 kvspace-durable 实例，顺带承接扩缩容、缓存、路径级后端选择。本 issue 记录这个长期方向，作为把上述局部问题收进同一框架讨论的锚点。这是方向性 issue，非近期承诺。
目标（三件事）
1. 集群模式：常驻协调服务纳管拓扑
一个 coordinator（+ 每节点 agent），维护集群拓扑：每个节点上有哪些 shm 文件（路径、容量、健康、生命周期）、哪些 durable 后端实例（redis/fs/s3 端点）。节点注册、发现、掉线降级。kvspace-c 的 #15 扩缩容、#14 存储分离在集群里由该服务承接主动管理，而非塞进库内。
2. 路径级后端选择（mount 式）
把当前「整连接一个 scheme」升级为命名空间内按路径前缀挂载后端 ，例如：
/hot/* → 本地节点 shm（低延迟热数据）
/cold/* → durable s3（冷数据）
/shared/* → 远端节点 shm（跨节点共享）
前端的路由从「scheme → 本地 so」扩展为「路径 → (本地后端 | 远端节点)」。消费者仍只链 libkvspace、用同一套 kvspace* C ABI，路由对上层透明。
实现载体已现成——vtable ：前端 handle 现在就是 {vtable, dl, backend}，所有 kvspace* 调用都过一层函数指针 vtable（get/set/list/…）。当前是 1 handle → 1 vtable → 1 backend 。路径级选择只需升级为 1 handle → 路由表 → 多个 (mount 前缀 → vtable + backend) ：kvspaceGet(h, key) 先按 key 前缀查路由表选中挂载点的 vtable，再派发。集群「远端节点」不过是另一个 vtable 实现 （RPC / RDMA 后端），与本地 dlopen 的 so vtable 并列——对上层 ABI 完全透明，前端抽象无需为分布式改形状，只是多了一类 vtable 实现和一层前缀路由。
3. 缓存
多级 / 透明缓存：本地 shm 作为 durable 后端的读缓存，或热点路径缓存到本地节点。需与失效 / 版本 / 租约的一致性协议一并设计——缓存正确性是难点，不是加个 LRU 就完事。
与现有的关系
待设计（分档，先出文档再落子 issue）
拓扑与发现 ：节点/shm/durable 实例的注册模型；与 /networld 的边界。路由表 ：路径前缀 → 后端实例映射，谁维护、如何热更、路由变更时的一致性。一致性模型 ：本地 shm 多进程当前无锁 （slotsboxmalloc rw_lock 未启用，见 slotsboxmalloc 路线图），跨节点只会更弱；须先定档——读多写少 / 最终一致 vs 强一致。缓存一致性 ：失效、版本号、租约、写穿 vs 写回。传输 = 一类新 vtable ：本地 dlopen so vtable vs 远端 vtable（gRPC / RDMA / 自定义），二者实现同一函数指针表；远端 vtable 的读返回值天然是拷贝，与 统一读值视图 kvspaceGetView：shm 零拷贝借用 / durable 拷贝，owned 标记统一释放 #8 故障域 ：节点掉线、shm 文件损坏、durable 不可达时的降级与恢复。
交付
先出设计文档（分布式 kvspace 架构：协调服务 + 路由 + 缓存 + 一致性），再拆子 issue 落地。近期不实现，仅作为把 #15/#14 等局部问题收进统一框架讨论的锚点，避免为单点问题起服务。
背景与动机
kvspace 现状是纯 dispatch 前端库（见 README）：消费者只链
libkvspace，运行期按 DSN scheme 选后端——shm://…dlopen libkvspace-c.so.1（RTLD_LOCAL）redis://fs://s3://dlopen libkvspace_durable.so.1即：一个连接 = 一个 DSN = 一个后端，进程本地装载，无跨节点概念、无常驻管理服务。
这套纯库模型的边界在 kvspace-c 侧逐渐显现：#15（shm 运行期扩缩容：容量创建时锁死、缺 mremap/回收/多进程重映射握手）、#14（tensor.data 由扩展存储后端管理）等，都指向一个「主动管理」的角色——但单为某个库的一个局部问题起一个常驻服务，不划算。
若把视角抬到「分布式 kvspace 系统」，这个常驻服务才有充分理由：统一纳管各节点的 kvspace-c shm 路径与 kvspace-durable 实例，顺带承接扩缩容、缓存、路径级后端选择。本 issue 记录这个长期方向，作为把上述局部问题收进同一框架讨论的锚点。这是方向性 issue，非近期承诺。
目标（三件事）
1. 集群模式：常驻协调服务纳管拓扑
一个 coordinator（+ 每节点 agent），维护集群拓扑：每个节点上有哪些 shm 文件（路径、容量、健康、生命周期）、哪些 durable 后端实例（redis/fs/s3 端点）。节点注册、发现、掉线降级。kvspace-c 的 #15 扩缩容、#14 存储分离在集群里由该服务承接主动管理，而非塞进库内。
2. 路径级后端选择（mount 式）
把当前「整连接一个 scheme」升级为命名空间内按路径前缀挂载后端，例如：
前端的路由从「scheme → 本地 so」扩展为「路径 → (本地后端 | 远端节点)」。消费者仍只链
libkvspace、用同一套kvspace*C ABI，路由对上层透明。实现载体已现成——vtable：前端 handle 现在就是
{vtable, dl, backend}，所有kvspace*调用都过一层函数指针 vtable（get/set/list/…）。当前是 1 handle → 1 vtable → 1 backend。路径级选择只需升级为 1 handle → 路由表 → 多个 (mount 前缀 → vtable + backend)：kvspaceGet(h, key)先按 key 前缀查路由表选中挂载点的 vtable，再派发。集群「远端节点」不过是另一个 vtable 实现（RPC / RDMA 后端），与本地dlopen的 so vtable 并列——对上层 ABI 完全透明，前端抽象无需为分布式改形状，只是多了一类 vtable 实现和一层前缀路由。3. 缓存
多级 / 透明缓存：本地 shm 作为 durable 后端的读缓存，或热点路径缓存到本地节点。需与失效 / 版本 / 租约的一致性协议一并设计——缓存正确性是难点，不是加个 LRU 就完事。
与现有的关系
kvspace*C ABI 契约：消费者与两后端共用的那套 head byte-identical 契约不动；变化集中在前端路由层与新增的协调服务。/networld名册（登记参与 kvspace 的 proc / 文件，/networld/{ip}/proc/{pid}已有节点注册雏形）：与「纳管各节点 shm 路径」高度重叠，需澄清二者关系——集群拓扑是复用/networld、还是各司其职（/networld管进程/vthread，cluster 管存储后端）。待设计（分档，先出文档再落子 issue）
/networld的边界。rw_lock未启用，见 slotsboxmalloc 路线图），跨节点只会更弱；须先定档——读多写少 / 最终一致 vs 强一致。dlopenso vtable vs 远端 vtable（gRPC / RDMA / 自定义），二者实现同一函数指针表；远端 vtable 的读返回值天然是拷贝，与 统一读值视图 kvspaceGetView：shm 零拷贝借用 / durable 拷贝，owned 标记统一释放 #8 的 owned/borrowed 语义对齐。交付
先出设计文档（分布式 kvspace 架构：协调服务 + 路由 + 缓存 + 一致性），再拆子 issue 落地。近期不实现，仅作为把 #15/#14 等局部问题收进统一框架讨论的锚点，避免为单点问题起服务。