本文定义 Naming 领域中临时服务的 AP 一致性规则。本文细化共享的 AP 一致性规范和 Naming 一致性与客户端状态规范。
本文负责：
- 临时 client 运行时状态的 ownership；
- Distro data type、change、delete、verify、snapshot 和 repair 语义；
- Distro apply 后的 client change 如何对 Naming 索引、service storage 和 push 可见；
- 服务端 Distro repair 与客户端 redo 的边界。
本文不定义持久服务、CP metadata group 或客户端 SDK 本地缓存行为。
临时状态由负责该临时 client 的服务节点拥有：
| Client 类别 | Owner 规则 |
|---|---|
| Connection-based client | 持有存活 gRPC connection 的节点拥有 native client。 |
| HTTP connection-based client | Distro responsibility 根据 HTTP_CLIENT@@<externalClientId> 内部 id 选择责任节点。 |
| Ephemeral IP-port client | 由 Distro responsibility 根据 client responsible id 选出的节点拥有 native client。 |
| Synced client | 从其他 owner 节点同步来的远端副本，是服务状态，不代表本地 ownership。 |
只有合法、native、responsible、ephemeral 的 client 才应作为 Distro 源数据同步。Persistent client 不得通过该路径同步。
Naming ephemeral Distro data 使用 resource type Nacos:Naming:v2:ClientData。Resource key 为
client id。
同步 payload 是 client 级数据，包含 client identity、已发布 service identity、instance publish information、可选的 batch instance data，以及 verify flow 使用的 client revision。Distro 不以 service 级记录作为权威来源；service view 由 client state 和索引派生。
HTTP connection-based Client 继续使用同一个 resource type 和
DistroClientDataProcessor。它通过 Client attributes 同步 namespace、鉴权主体标识、Client
活性和 Publisher 活性，不增加领域专用 Distro payload。普通续约只更新时间戳，不要求每次产生
CHANGE；publication 或其语义健康投影变化时仍使用标准 Client revision 和 CHANGE。
源节点必须从 client event 发布 Distro 变更：
- client changed ->
CHANGE； - client disconnected ->
DELETE； - 目标节点 verify failed -> 对该目标立即发送
ADD。
节点收到 ADD 或 CHANGE 时，必须创建或更新 synced client，并 apply 同步来的实例数据。Apply
同步数据必须发布重建 publisher index、service storage 和 push view 所需的本地 Naming event。
节点收到 DELETE 时，必须 disconnect 并 release 对应 source client id 的 synced client。派生索引和
service storage 必须通过普通 client release 使用的同一本地事件路径更新。
Distro verify 使用 source client revision 与目标节点状态进行比较。如果目标节点无法 verify 该 client，必须返回 verify failure，使源节点向该目标发送完整 client data。
Revision 0 可以被视为兼容数据。对于当前协议数据，revision 匹配会刷新目标侧 liveness 观察；
revision 不匹配必须触发 repair。
Snapshot transfer 是针对整个 Naming ephemeral Distro data type 的 anti-entropy。Snapshot 包含源
节点除 connection-based client 外的全部 ephemeral clients。Connection-based client 由持有存活
gRPC 连接的节点独占写入，不得进入 snapshot；接收节点上缺失的 connection-based client 通过
verify 失败触发的 repair 补偿。加载 snapshot 时，必须对每个 client 使用与普通 ADD 或 CHANGE
相同的 sync-data apply 规则。
Connection-based client 在远程 connection 断开，或 connection manager 移除过期连接时过期。释放 native client 必须产生 disconnect 和 release event，使 Distro 删除远端副本，并清理本地索引。
Ephemeral IP-port client 通过心跳和 cache-time cleanup 过期。Owner 节点必须移除过期 native client， 并发布 Distro deletion 使用的同类 disconnect event。
HTTP connection-based Client 由责任节点分别检查 Client 和 Publisher 活性。Publisher 过期只删除 该 Client 的 publication；Client 仍有 subscriber state 时可以继续存在。Client 自身过期时沿用 Client release 事件清理全部 publisher 和 subscriber state。Replica 清理以及后续责任转移复用最近一次 成功 Distro verify 的观测时间作为本地超时下界；Client 不维护并行的 responsibility 标记。
Remote synced client 是 Distro path 的清理对象，不得在接收节点续约 native ownership。
Ephemeral Naming visibility 在集群中最终一致：
- owner 节点更新 client state；
- 本地 event 更新 publisher index 和 service storage；
- owner 节点调度 Distro sync 到 peer 节点；
- peer 节点 apply synced client data，并重建派生服务状态；
- service change event 调度 subscriber push。
Subscriber push 携带派生的 ServiceInfo view，不会使临时状态变成持久状态。Push retry 和 reconnect
恢复由运行时推送与重连规范定义。
- Ephemeral Distro 不把 instance state 持久化到数据库。
- Ephemeral Distro 不拥有 service metadata 或 instance metadata；这些状态存在时遵循 metadata CP 规则。
- 某个节点上的注册成功，可能需要等到 Distro sync 或 anti-entropy repair 后，才对其他节点可见。
- 面向 ephemeral service state 的范围查询，在 AP 收敛完成前可能观察到节点本地服务状态。