4. 终端生命周期与注册流程

LwM2M 终端从出厂到退网，并不是“上线—离线”这么简单。它在 LwM2M Server 眼中是一个有明确状态机的对象：先通过 Bootstrap 获得服务器信息与安全凭据，再 Register 建立注册关系，随后用 Update 维持注册有效期，最终以 Deregister 主动退出或等待注册过期被清理。理解这条链路，是设计大规模接入平台的基础。

一、四个阶段各自解决什么问题

Bootstrap（引导）解决“终端该连谁、用什么凭据连”。终端出厂时通常只知道一个 Bootstrap Server 地址（或通过工厂预置的 PSK/证书）。Bootstrap Server 向终端下发两类内容：一是 LwM2M Server 的 URI、短服务器 ID（Short Server ID）；二是安全对象（Security Object，Object ID 0）中的密钥或证书、以及 Server Object（Object ID 1）中的绑定模式、生命周期参数。完成后终端会断开 Bootstrap Server，转向正式服务器。

Register（注册）解决“我是谁、我有哪些对象”。终端向 LwM2M Server 发送 POST /rd?ep={Endpoint Client Name}<={lifetime}&b=U，携带 Object 列表（如 /1/0、/3/0、/3303/0）。服务器返回 2.01 Created 与 Location 路径（如 /rd/5f3a），这个 Location 就是后续 Update、Deregister 的操作句柄。

Update（更新）解决“我还活着”。终端必须在 lifetime 到期前发送 POST {location}，否则服务器会将其标记为过期并删除注册。Update 也可携带参数变化（如新增对象实例、lt 调整）。

Deregister（注销）解决“我主动离开”。终端发送 DELETE {location}，服务器返回 2.02 Deleted 并释放注册资源。若终端异常掉电，则不会发送 Deregister，只能靠 lifetime 超时清理。

二、大规模并发下的状态管理要点

当终端规模从几百上升到十万级，注册状态管理会暴露三个瓶颈：注册表写入热点、lifetime 定时器数量爆炸、以及 Bootstrap 与 Register 的流量叠加。

注册表分片。不要把所有注册记录放在单个 Redis 实例或单张 MySQL 表。可按 Endpoint Client Name 的哈希值分片，例如 64 个分片，每个分片独立维护 location→注册信息的映射。Location 本身由服务器生成，建议编码分片号，如 /rd/{shard}-{seq}，这样 Update 和 Deregister 能直接路由到对应分片，避免全局扫描。

定时器合并。为每个终端单独创建一个定时器，在 10 万终端下会产生 10 万个定时任务。更经济的做法是采用时间轮或分层时间轮：把 lifetime 按秒级精度放入不同槽位，每秒钟只扫描当前槽位中的到期终端。示例参数：lifetime 统一设为 300 秒，时间轮 512 槽，每槽覆盖 1 秒，则只需一个每秒触发的扫描任务即可管理全部终端。

Update 抖动抑制。若大量终端在同一时刻注册（例如批量上电），它们的 Update 也会在同一时刻到达。可在服务器下发的 lifetime 中引入随机化，或在终端侧将 Update 触发点设置为 lifetime 的 0.7～0.9 倍之间的随机值。例如 lifetime=300s，终端在 210～270 秒之间随机选择发送时刻，从而把 Update 峰值摊平。

三、一个可参考的注册状态表结构

下面给出注册状态存储中一条记录的关键字段示例，用于说明服务器侧需要维护哪些信息才能正确驱动生命周期。

{
  "endpoint": "dev-0001",
  "location": "/rd/17-0042",
  "lifetime": 300,
  "binding": "U",
  "objects": ["/1/0", "/3/0", "/3303/0"],
  "sms": "13000000000",
  "register_time": 1710000000,
  "last_update": 1710000240,
  "expire_at": 1710000540,
  "shard": 17,
  "state": "REGISTERED"
}

其中 expire_at = last_update + lifetime，是判断过期的唯一依据；state 可取 BOOTSTRAPPING、REGISTERED、UPDATE_PENDING、DEREGISTERED、EXPIRED。服务器后台任务只需扫描 expire_at 小于当前时间的记录，将其置为 EXPIRED 并释放资源，无需依赖终端是否发送 Deregister。

四、异常路径与判断依据

实际运行中，终端可能注册成功但 Update 丢失。此时服务器在 expire_at 到达后删除注册，终端若仍在线，下一次 Update 会收到 4.04 Not Found，终端应重新执行 Register，而不是继续重试 Update。另一种情况是终端更换了对象实例（例如新增了一个温度传感器实例 /3303/1），应在 Update 中携带新的 Object 列表，服务器据此刷新注册信息。

判断注册是否健康，可以观察三个指标：注册成功率（2.01 Created / Register 请求数）、Update 准时率（在 expire_at 前到达的 Update 比例）、以及过期清理量（EXPIRED 状态转移次数）。若过期清理量持续偏高，说明终端侧 Update 定时器或网络链路存在问题，需要结合终端日志与服务器侧 last_update 时间戳定位。