前 9 篇，系统是跑在单机上的：一个 TDengine 容器，REPLICA 1，数据只有一份。节点挂了，数据还在盘上，但服务没了。这一篇把部署换成三节点集群，REPLICA 3，然后真的停掉一个节点做故障演练——看看查询还能不能继续。这也是本系列最后一篇：从部署到高可用，一条遥测数据的旅程完整闭环。

第 7 篇的模拟器里，电机设备的振动超过 0.18 就报状态码 2、超过 0.35 报 3——但这两个阈值是写死在模拟器里的。真实系统不能这样：阈值得能配、能停用、能按设备类型区分。这篇讲告警引擎：规则存 PostgreSQL，遥测在 TDengine，evaluate 实时跨库求值，一条规则从创建到触发的完整旅程。

档案放 PostgreSQL，时序放 TDengine——这是很多 IoT 系统的标准姿势。但真要把两个数据源塞进同一个 Spring Boot 应用，配置、注入、防注入、分页、健康检查，每一步都有坑。本文用实战源码，讲透双数据源查询层的完整实现。

第 4 篇我们搭好了写入管线，背压、攒批、并发 worker 都就位了。可管线再高效，也得有数据往里喂。今天回到源头：数据从哪来？两条路——模拟器直接造，采集器从三源收，最终都汇入同一条 pipeline。这篇就讲四件事：物理模型、确定性 seed、归一化漏斗、坏数据去向。读完你能回答：模拟器的物理模型为什么这么设计？三源各适合什么场景？坏数据去哪了？

同一个数据库，三种进门方式：WebSocket 走 6041、REST 也走 6041、Native 独占 6030。端口背后藏着协议实现的本质差异。读懂这里，你才能写出公平的基准测试，也才知道日常开发该走哪扇门。

**导读：** 上一篇我们拆解了 Agent Loop，但循环里的 `run_tool()` 还是个黑盒。- **`dispatch(name, args, **kwargs)`**：按名字查表执行，查不到返回 `{"error": f"Unknown tool: {name}"}`。- **`get_definitions(enabled_toolsets=None)`**：返回 OpenAI

高频时序写入的朴素写法是：来一条数据，INSERT 一次。每秒上千条时，网络往返、内存堆积、连接池全部亮红灯。本文拆解一个生产级 asyncio 写入管线：有界队列背压、双触发攒批、多 worker 并发，外加转义、重试与优雅停机，一套可照抄的写入模式。

窗口聚合、每设备最新值、离线检测，是时序查询三个高频场景。本文用 TDengine 实战代码讲 INTERVAL + _wstart、LAST_ROW()、HAVING LAST(ts) 三种写法，解释为什么聚合列敢拼 SQL、条件却必须参数绑定，以及 31 天/5000 行边界背后的资源保护逻辑。

为什么你的子表名是一串看不懂的字符？建库语句里每个数字到底在管什么？哪些字段该当 TAG、哪些该当列？本文用真实可运行的 TDengine 建模代码，把这三个决策点一次讲透，读完你就能独立设计一张不踩坑的超级表。

导读： 物联网数据一天产生上亿行，MySQL 扛得住吗？本文从一个可运行的工业 IoT 参考项目出发，讲清楚时序数据库为什么适合物联网、系统分哪五层、怎么用 Docker Compose 五分钟拉起完整环境，再跟随一条遥测数据走完从模拟器到 Grafana 面板的完整旅程。