Skip to content

延时消息提前或延后投递(时钟偏差)

更新时间:2026/8/23 17:04:45

现象

延时消息设置 10 秒,约 6 秒就被消费;或设置 5 秒,过了 8 秒才收到。

原因

Artemis 延时消息按绝对时间戳投递 —— 发送端用本机时钟计算「当前时间 + 延时」写入消息属性,broker 等到自己的时钟到达该时间戳才投递。当应用与 broker 跨机器部署且两机时钟不一致时,实际延时会平移两机时钟差:

  • 应用机器时钟于 broker → 消息提前投递(如本例慢约 4 秒,10 秒延时约 6 秒即送达)
  • 应用机器时钟于 broker → 消息延后投递

排查

对比两机时钟。可借 broker 主机上任意 HTTP 服务(如 Artemis 控制台 8161 端口)的响应 Date 头与本机时间比对:

bash
curl -sI http://<broker主>:8161/ | grep -i '^date'   # broker 侧时间(秒级精度)
date                                                    # 本机时间

修复

两台机器均开启 NTP 对时。

Linux 服务器(broker 所在主机):

bash
timedatectl                          # 查看 "System clock synchronized" 与 "NTP service" 状态
sudo timedatectl set-ntp true        # 未开启时先开启 timesyncd
# 系统未装 timesyncd 时,安装 chrony 接管(RHEL 系用 dnf,服务名为 chronyd):
sudo apt install chrony && sudo systemctl enable --now chrony
chronyc tracking                     # 验证:Leap status 为 Normal 即已同步

Windows 开发机(本地跑后端连远程 broker 的场景):

powershell
w32tm /query /status                 # 查看时间服务状态与上次成功同步时间
# 以下两条需管理员终端执行:
w32tm /resync                        # 立即校时(机器休眠唤醒后时钟漂移,可手动执行)
w32tm /config /syncfromflags:manual /manualpeerlist:"ntp.aliyun.com time.windows.com" /update
                                     # time.windows.com 通路不稳时切换国内 NTP 源

TIP

官方安装器部署中,应用与 Artemis 为同一宿主机上的容器,共享内核时钟,天然不存在此问题。该问题常见于「本地跑后端 + 远程 broker」的开发拓扑,以及自行跨机部署 broker 的场景 —— 跨机部署时 NTP 对齐是延时消息精度的硬前提。


返回 FAQ

基于 GNU LGPL v3.0 协议开源