4. 消息缓存机制：Friend Queue与Message Cache调优
高密度节点网络里，最头疼的问题是什么？我个人觉得，不是配网慢，也不是路由跳数多，而是——消息风暴。你想想看，一个节点收到一条消息，转发给邻居，邻居再转发，整个网络瞬间被撑爆。这时候，Friend Queue 和 Message Cache 就是你的救命稻草。
说白了，这两个机制就是蓝牙Mesh的“内存缓冲池”。用得好，网络稳如老狗；用不好，节点分分钟挂掉。我早期做智能照明项目时，就吃过这个亏——节点一多，消息全堵在队列里，灯死活关不掉。嗯，今天咱们就把这两个机制彻底讲透。
4.1 Friend Queue：低功耗节点的“消息信箱”
低功耗节点（LPN）为了省电，大部分时间都在睡觉。它醒来时，会问它的Friend节点：“有没有我的消息？”Friend节点就把缓存的消息一股脑丢给它。这个缓存区，就是Friend Queue。
我在项目中遇到过一个问题：LPN节点每隔5秒醒来一次，但Friend Queue只配了3个槽位。结果呢？消息一多，队列溢出，LPN永远收不到某些关键指令。后来我把队列深度调到10，问题才解决。
4.1.1 队列深度怎么定？
队列深度不是越大越好。太大了，Friend节点内存吃紧；太小了，LPN丢消息。我一般按这个公式估算：
队列深度 = (LPN睡眠间隔 / 消息平均到达间隔) × 安全系数(1.5~2.0)举个例子：LPN每5秒醒一次，网络里平均每2秒产生一条发给它的消息。那队列深度至少是 (5/2)×1.5 ≈ 4，我建议直接配到6或8，留点余量。
| 场景 | LPN睡眠间隔 | 推荐队列深度 | 备注 |
|---|---|---|---|
| 智能灯控 | 3~5秒 | 6~10 | 开关指令密集 |
| 传感器上报 | 10~30秒 | 3~6 | 数据量小，频率低 |
| 门锁/安防 | 1~2秒 | 10~15 | 实时性要求高 |
4.1.2 超时与重传策略
Friend Queue里的消息不是无限期保留的。每条消息都有个TTL（生存时间）。超时了还没被LPN取走，Friend节点就会把它丢掉。
我曾经踩过一个坑：TTL设得太短（比如2秒），LPN睡眠间隔是5秒。结果LPN每次醒来，消息早就过期了。后来我把TTL设为睡眠间隔的2倍，才稳定下来。
// 伪代码示例：Friend Queue消息管理
typedef struct {
uint8_t data[384]; // 消息内容
uint32_t timestamp; // 入队时间戳
uint16_t ttl_ms; // 生存时间(毫秒)
uint8_t retry_cnt; // 重试次数
} friend_queue_entry_t;
// 建议TTL设置
#define FRIEND_QUEUE_TTL_MS (LPN_SLEEP_MS * 2) // 2倍睡眠间隔4.2 Message Cache：中继节点的“消息滤网”
Message Cache 的作用很简单：防止同一条消息在网络里反复转发。每个中继节点收到消息后，先查一下Cache里有没有。如果有，直接扔掉；如果没有，存进去再转发。
你想想看，没有Cache会怎样？一条消息从A传到B，B传给C，C又传回A……无限循环，网络直接瘫痪。所以，Message Cache 是中继节点的必备机制。
4.2.1 Cache大小怎么配？
Cache太小，消息很快被覆盖，起不到去重效果；Cache太大，浪费内存。我一般按这个原则：
- 低密度网络（<50节点）： Cache配32~64条就够了
- 中密度网络（50~200节点）： 建议128~256条
- 高密度网络（>200节点）： 至少512条，甚至1024条
我记得有个项目，客户非要用32条Cache去跑300个节点的网络。结果呢？消息重复率高达40%，网络延迟从50ms飙升到2秒。后来改成512条，一切恢复正常。
4.2.2 Cache淘汰策略
Cache满了怎么办？得把旧消息踢出去。常见的策略有两种：
| 策略 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| FIFO（先进先出） | 最早进来的消息先被淘汰 | 实现简单，开销小 | 可能淘汰掉仍在转发的消息 |
| LRU（最近最少使用） | 最久没被命中的消息先淘汰 | 命中率高，去重效果好 | 实现复杂，需要维护访问时间 |
我个人习惯用FIFO。为什么？因为蓝牙Mesh的消息生命周期很短，通常几秒内就传完了。FIFO足够用，而且省CPU。LRU虽然理论更好，但在高密度场景下，维护LRU链表本身就会增加开销，得不偿失。
4.3 两者协同：Friend Queue + Message Cache 的配合
Friend Queue 和 Message Cache 不是孤立的。它们之间有个关键交互：Friend节点收到消息后，既要存入自己的Message Cache（防止重复转发），又要存入Friend Queue（等待LPN来取）。
我画了张图，帮你理清这个流程：
4.4 调优实战：从踩坑到稳定
说了这么多理论，来点实际的。我分享一个真实案例：
项目背景： 某智能楼宇项目，500个传感器节点，每个节点都是LPN，通过Friend节点接入网络。Friend节点用的是Cortex-M4芯片，64KB RAM。
初期配置：
- Friend Queue深度：4
- Message Cache大小：64条
- LPN睡眠间隔：5秒
- TTL：3秒
问题现象： 上线后，大量LPN收不到控制指令，丢包率高达30%。Friend节点CPU占用率飙到90%。
排查过程：
- 先看Friend Queue——队列经常满，消息被丢弃。深度4太小了。
- 再看Message Cache——64条Cache，在高密度网络下，消息很快被覆盖，重复转发严重。
- 最后看TTL——3秒比LPN睡眠间隔5秒还短，LPN永远取不到过期消息。
优化后配置：
| 参数 | 优化前 | 优化后 | 原因 |
|---|---|---|---|
| Friend Queue深度 | 4 | 12 | 匹配消息到达率 |
| Message Cache大小 | 64 | 256 | 减少重复转发 |
| TTL | 3秒 | 10秒 | 覆盖LPN睡眠周期 |
结果： 丢包率从30%降到0.5%，CPU占用率从90%降到40%。
4.5 总结：记住这三条
嗯，聊了这么多，最后给你三个最实用的建议：
- Friend Queue深度 = LPN睡眠间隔 × 消息速率 × 1.5，别抠门，留余量
- Message Cache大小 = 网络节点数 × 0.5~1，高密度场景往大了配
- TTL一定要大于LPN睡眠间隔，至少2倍，否则LPN永远收不到消息
记住这三条，你的高密度节点网络至少能跑稳80%。剩下的20%，就得靠实际调试和你的经验了。