MQTT Broker的负载均衡策略及高并发场景下的性能优化

Cao Ze 2026-09-18 01:22

MQTT协议在IoT和实时通信领域被广泛采用，但面对海量设备接入和高吞吐消息场景，单节点Broker很快就会成为瓶颈。要真正解决高并发问题，负载均衡策略的选择和性能优化的实施缺一不可。本文围绕这两个核心话题展开，结合实际案例和配置示例，帮助开发者从原理到落地系统性地掌握MQTT Broker的调优方法。

技术栈说明：以下所有示例均基于EMQX 5.x开源MQTT Broker，配合Shell脚本、YAML配置文件和JSON数据格式，不混合使用其他技术栈。

一、MQTT Broker的角色与高并发挑战

1.1 MQTT架构中的Broker定位

MQTT协议采用发布/订阅模型，Broker（消息代理）是整个架构的中枢。所有Publisher（发布者）和Subscriber（订阅者）都不直接通信，消息的流转完全依赖Broker来中转和分发。Broker的核心职责包括四个方面：连接管理，负责接收和维持客户端的TCP长连接；消息路由，根据客户端订阅的主题将消息分发到对应的目标；会话管理，处理QoS（服务质量）相关的确认、重传和离线消息逻辑；协议编解码，解析和封装MQTT协议的字节流。

在高并发场景下，Broker的性能直接决定了整个系统的上限。一个单节点的MQTT Broker通常能支撑几万到几十万级别的并发连接，一旦超过这个阈值，消息延迟会急剧上升，甚至出现连接断开和消息丢失。理解Broker的工作机制，是进行负载均衡和性能优化的前提。

1.2 高并发的典型业务场景

理解高并发的具体场景，才能有针对性地选择优化方案。

IoT设备大规模接入：一个智慧工厂可能部署数万个传感器，每个传感器每秒上报一次温湿度、振动等数据。这意味着Broker每秒需要处理数万条消息的发布和分发，同时还要维持所有设备的长连接。

车联网实时通信：一辆车的ECU（电子控制单元）可能有几十个上报点，对应几十到上百个MQTT连接。如果车厂有百万级车辆在线，那就是上亿级别的并发连接，这对Broker的横向扩展能力提出了极高要求。

直播弹幕与消息推送：直播平台的弹幕系统和即时通讯的消息推送本质上也是高并发消息分发场景。虽然同时在线的客户端数量通常少于IoT设备，但突发流量非常集中，比如主播开播瞬间可能有几十万用户同时涌入发布消息。

1.3 为什么需要负载均衡

在单Broker节点无法满足性能需求时，自然想到的是加机器。但简单地增加节点并不等于解决了问题，因为客户端连接哪个节点、消息在节点之间如何路由，都需要一套合理的策略来协调。如果没有负载均衡机制，可能出现某个节点连接数暴增而其他节点空闲的情况，资源利用率极低；或者消息在节点之间来回转发，增加了不必要的网络开销和延迟。

负载均衡的目标很简单：让每个Broker节点都能高效地处理自己负责的那部分流量，而不是一个节点忙死、其他节点闲着。但实现这个目标的具体策略有很多种，每种策略有不同的适用场景和权衡取舍。

二、三种主流负载均衡策略详解

2.1 基于连接数的负载均衡（最简单方案）

这是最基础的负载均衡方式，原理就是统计每个Broker节点的当前活跃连接数，然后把新连接分配给连接数最少的节点。实现上通常借助反向代理服务器，比如HAProxy或Nginx，在它们前面挂一层，由它们来决定新连接发到哪个后端节点。

这种方案的优点是实现简单，HAProxy和Nginx都原生支持leastconn（最少连接数）策略，配置几行就能搞定。缺点也很明显：它只关心连接数，完全不知道消息的流向。如果客户端A连接到节点1，但客户端A订阅的主题对应的发布者全部连接到节点2，那消息就需要从节点2转发到节点1再发给客户端A，多了一次网络跳转，增加了延迟。

2.2 基于会话亲和性的负载均衡（推荐方案）

会话亲和性（Session Affinity）的思路是：同一个客户端的多次连接，尽量分配到同一个Broker节点。这样Broker节点可以缓存该客户端的订阅关系和会话状态，减少跨节点通信。

实现会话亲和性有几种常见方式：第一种是基于客户端IP的哈希，同一个IP的请求总是分配到同一个节点；第二种是基于客户端ID的哈希，同一个客户端ID的请求总是分配到同一个节点；第三种是在负载均衡器中维护一个会话表，记录客户端ID和节点的映射关系。

会话亲和性的好处是消息路由效率高，因为订阅关系和会话状态都在同一个节点上。坏处是节点故障时恢复成本高——故障节点上的所有会话都需要迁移到其他节点，客户端需要重新连接，恢复时间取决于会话数量和重建连接的速度。

2.3 基于主题路由的负载均衡（最优雅但最复杂）

主题路由的思想是：根据消息的主题（Topic）来决定消息应该路由到哪个Broker节点。比如，所有factory/1/开头的主题都路由到节点A，所有factory/2/开头的主题都路由到节点B。

这种方案的优点是消息路由效率最高，消息几乎不需要跨节点转发。缺点也非常明显：灵活性差。如果某个节点故障了，它负责的所有Topic下的客户端都会受到影响。而且Topic结构一旦变化，路由规则就需要跟着调整，运维成本高。

在实际生产中，最常用的做法是混合策略：用HAProxy做第一层基于连接数的分发，确保连接均匀分布；然后在Broker集群内部通过会话亲和性或主题路由来优化消息转发效率。这样既保证了连接的均匀分布，又减少了不必要的跨节点消息传递。

2.4 HAProxy实现连接数+IP亲和的混合策略

下面是一个完整的HAProxy配置示例，通过IP Hash和最少连接数的组合来实现混合负载均衡：

# ============================================
# HAProxy 配置示例 - MQTT Broker 集群负载均衡
# 文件路径：/etc/haproxy/haproxy.cfg
# 场景：3节点EMQX集群，通过IP Hash保证会话亲和
# ============================================

global
    daemon                        # 以后台守护进程模式运行
    maxconn 500000                # 全局最大连接数，根据机器性能调整
    log /dev/log local0           # 日志输出到 syslog

defaults
    mode    tcp                   # MQTT 是 TCP 协议，必须用 tcp 模式而非 http
    timeout connect 5s            # 与后端节点建立连接的超时时间
    timeout client 3600s          # 客户端空闲超时时间，MQTT长连接设大一些
    timeout server 3600s          # 服务端空闲超时时间，与 client 保持一致
    timeout check 10s             # 健康检查的超时时间

# ========== MQTT 前端监听 ==========
frontend mqtt_tcp_front
    bind *:1883                   # 监听 MQTT 标准端口 1883
    bind *:8883                   # 监听 MQTT over TLS 端口 8883
    default_backend mqtt_tcp_backends

# ========== 后端节点池 ==========
backend mqtt_tcp_backends
    # 策略说明：source 表示基于源 IP 的哈希分发
    # 效果：同一客户端 IP 总是分配到同一后端节点，实现会话亲和
    # 其他可选策略：
    #   leastconn    - 最少连接数（纯连接数负载均衡）
    #   roundrobin   - 轮询
    #   static-rr    - 加权轮询
    balance source

    # 健康检查配置
    option tcp-check              # 使用 TCP 层健康检查
    tcp-check connect timeout 5s  # 健康检查连接超时
    tcp-check send "PING\r\n"     # 发送 PING 命令探测 EMQX 状态
    tcp-check expect string "PONG"  # 期望收到 PONG 响应

    # 定义3个EMQX后端节点（IP和端口根据实际环境修改）
    server emqx1 192.168.1.101:1883 check inter 5s fall 3 rise 2
    server emqx2 192.168.1.102:1883 check inter 5s fall 3 rise 2
    server emqx3 192.168.1.103:1883 check inter 5s fall 3 rise 2

    # 统计页面，可通过 http://<HAProxy_IP>:8404 访问
    stats enable
    stats uri /stats
    stats refresh 10s
    stats auth admin:admin123

三、高并发场景下的性能优化策略

3.1 系统级参数调优

Broker性能优化不能只盯着应用层，操作系统的内核参数往往是隐藏的瓶颈。

TCP缓冲区调优：默认的TCP接收和发送缓冲区太小，在高并发场景下容易成为瓶颈。缓冲区太小会导致频繁的系统调用和网络等待，增加延迟。

#!/bin/bash
# ============================================
# Linux 系统 TCP 参数调优脚本
# 用途：为 MQTT Broker 优化 TCP 网络栈参数
# 注意：修改前请备份 /etc/sysctl.conf
# ============================================

# 备份原配置文件
cp /etc/sysctl.conf /etc/sysctl.conf.bak

# 追加 MQTT 优化参数到 sysctl.conf
cat >> /etc/sysctl.conf << 'EOF'

# ========== MQTT Broker TCP 网络优化参数 ==========

# TCP 接收缓冲区最大值设为 16MB
# 范围：最小值 最小值 最大值（单位字节）
net.core.rmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216

# TCP 发送缓冲区最大值设为 16MB
net.core.wmem_max = 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216

# TCP 最大连接跟踪表大小，默认值在高并发下不够用
net.netfilter.nf_conntrack_max = 1000000

# 允许重用处于 TIME_WAIT 状态的端口，加速连接释放
net.ipv4.tcp_tw_reuse = 1

# 启用 TCP 快启动和慢启动优化
net.ipv4.tcp_slow_start_after_idle = 0

# 增加文件描述符上限，默认1024太小
fs.file-max = 1000000

# 增加本地端口范围，应对大量连接
net.ipv4.ip_local_port_range = 1024 65535

# 允许内核自动调整路由参数
net.ipv4.conf.all.rp_filter = 0

# 提高系统最大打开文件数
fs.nr_open = 1000000
EOF

# 加载配置，立即生效（不需要重启）
sysctl -p

# 验证关键参数是否生效
echo "===== 验证 TCP 缓冲区 ====="
cat /proc/sys/net/core/rmem_max
echo "===== 验证文件描述符上限 ====="
cat /proc/sys/fs/file-max
echo "===== 验证 TIME_WAIT 重用 ====="
cat /proc/sys/net/ipv4/tcp_tw_reuse

文件描述符限制：每个MQTT连接都会占用一个文件描述符，默认1024的限制意味着Broker最多只能处理1024个连接（还要减去系统进程占用的部分）。必须大幅增加这个限制：

# 修改 /etc/security/limits.conf
# 给运行 EMQX 的用户（通常是 root 或 emqx）更大的文件描述符限制
# 格式：用户名 类型 资源 限制值
# 添加以下行：

echo "root soft nofile 1000000" >> /etc/security/limits.conf
echo "root hard nofile 1000000" >> /etc/security/limits.conf
echo "emqx soft nofile 1000000" >> /etc/security/limits.conf
echo "emqx hard nofile 1000000" >> /etc/security/limits.conf

# 如果使用 systemd 管理 EMQX 服务，还需要在 service 文件中设置
# 编辑 /etc/systemd/system/emqx.service 或在 [Service] 段添加：
cat >> /etc/systemd/system/emqx.service.d/override.conf << 'EOF'
[Service]
LimitNOFILE=1000000
LimitNPROC=1000000
EOF

# 重新加载 systemd 配置并重启 EMQX
systemctl daemon-reload
systemctl restart emqx

3.2 Broker配置层优化

系统参数调好之后，还需要在Broker层面做针对性优化。

监听器调优：监听器的acceptors（接收器进程数）直接影响同时建立连接的速度。默认值通常太小，需要根据CPU核心数调整。

# ============================================
# EMQX 监听器与连接层优化配置
# 文件路径：/opt/emqx/etc/emqx.yaml
# 说明：配置监听器参数以优化高并发连接性能
# ============================================

# TCP 监听器配置（MQTT 默认端口）
listener:
  tcp:
    bind: "0.0.0.0:1883"          # 绑定所有网卡的1883端口
    acceptors: 64                  # 同时接收连接的进程数
                                      # 建议值 = CPU核心数 × 4~8
                                      # 例如8核CPU设为 32~64
    max_connections: 100000        # 单个监听器最大连接数
    keepalive_interval: 60s        # 空闲连接检查间隔，0表示不检查
    keepalive_timeout: 120s        # 空闲连接超时断开时间
    receive_timeout: 300s          # 接收数据超时时间

  # TLS 监听器配置（MQTT over TLS）
  ssl:
    bind: "0.0.0.0:8883"
    acceptors: 64
    max_connections: 100000
    # TLS 证书路径
    certfile: "/opt/emqx/etc/certs/server.crt"
    keyfile: "/opt/emqx/etc/certs/server.key"
    cacertfile: "/opt/emqx/etc/certs/ca.crt"
    # TLS 协议版本限制，提高安全性
    versions:
      - tlsv1.2
      - tlsv1.3
    # 优先使用服务器端加密套件
    prefer_server_cipher_suites: true

QoS等级选择策略：QoS（服务质量）有三个等级，每个等级的开销差异很大。QoS 0是"最多一次"投递，不保证消息一定到达，开销最小；QoS 1是"至少一次"投递，需要Broker回复确认，可能重复投递但不会丢失；QoS 2是"恰好一次"投递，需要四次握手确认，开销最大。

在实际业务中，大部分IoT场景用QoS 0或QoS 1就够了。比如温度传感器上报数据，偶尔丢一条不影响整体分析。只有金融交易、支付扣款这类场景才需要QoS 2。盲目使用QoS 2会白白增加Broker的计算和存储开销。

{
    "comment": "QoS 等级选择建议 - 根据业务场景选择合适的QoS等级",
    "scenarios": [
        {
            "场景": "传感器数据上报",
            "推荐QoS": 0,
            "理由": "数据偶尔丢失可接受，QoS 0 性能开销最小",
            "吞吐量提升": "相比 QoS 2 可提升 3~5 倍消息处理速度"
        },
        {
            "场景": "设备指令下发",
            "推荐QoS": 1,
            "理由": "指令不能丢失，QoS 1 保证至少送达一次",
            "吞吐量提升": "相比 QoS 2 可提升 2~3 倍消息处理速度"
        },
        {
            "场景": "金融交易/支付",
            "推荐QoS": 2,
            "理由": "不能丢失也不能重复，必须用 QoS 2 保证恰好一次",
            "吞吐量提升": "无优化空间，这是正确性的要求"
        }
    ]
}

3.3 消息处理层优化

主题过滤器优化：当订阅的主题数量很多时（比如一个客户端订阅了几百个Topic），Broker在每条消息到达时需要遍历所有订阅关系来匹配主题，匹配开销和订阅数量成正比。

EMQX提供了基于前缀树（Trie）的主题过滤器优化，可以将匹配复杂度从O(n)降低到接近O(1)。下面展示相关配置：

# ============================================
# EMQX 主题过滤器优化配置
# 文件路径：/opt/emqx/etc/emqx.yaml
# 说明：优化主题匹配算法，提升大量订阅场景下的消息路由效率
# ============================================

topic_filter:
  # 主题前缀树的最大深度
  # 值越大支持越深层级的主题，但内存占用也越大
  max_depth: 128

  # 是否启用通配符（+ 和 #）优化
  # 开启后 Broker 会使用专门的算法处理通配符匹配
  wildcard_optimize: true

  # 是否启用正则表达式加速
  # 正则匹配比通配符慢很多，开启加速后 Broker 会预编译正则
  regex_accel: true

  # 主题匹配缓存大小
  # 缓存最近匹配过的主题，避免重复计算
  match_cache_size: 10000

消息队列配置：当订阅者的消费速度跟不上发布速度时，Broker会在内存中排队等待发送。排队队列的大小直接影响Broker能承受的突发流量。

# ============================================
# EMQX 消息队列与持久化配置
# 文件路径：/opt/emqx/etc/emqx.yaml
# 说明：优化消息排队和持久化存储性能
# ============================================

# 消息队列配置
queue:
  # 每个会话的最大排队消息数
  # 超过此数量后新消息会被丢弃（取决于溢出策略）
  max_queue_size: 10000

  # 排队溢出策略：drop（丢弃新消息）或 drop_overflow（丢弃队列溢出部分）
  overflow: drop

# 消息持久化配置
persistence:
  # 是否启用消息持久化
  # 仅 QoS 1 和 QoS 2 消息需要持久化
  enabled: true

  # 消息过期时间（秒）
  # 设置为 0 表示消息永不过期，需要手动清理
  # 建议根据业务需求设置合理值，避免磁盘爆满
  message_ttl: 3600

  # 持久化存储目录
  # 强烈建议放在 SSD 上，机械硬盘会成为严重瓶颈
  persistence_dir: /data/emqx/persistence

  # 批量写入大小
  # 值越大，写性能越好，但故障恢复时可能丢失更多未刷盘的数据
  bulk_write_size: 256

  # 是否启用 WAL（Write-Ahead Log）
  # WAL 可以提高写入性能，但会增加磁盘占用
  wal_enabled: true

3.4 网络层与压缩优化

在跨节点通信量大的集群部署中，网络带宽可能成为瓶颈。启用消息压缩可以在不损失信息的前提下显著减少网络传输量。

# ============================================
# EMQX 网络与压缩优化配置
# 文件路径：/opt/emqx/etc/emqx.yaml
# 说明：优化节点间通信和消息压缩以降低网络带宽占用
# ============================================

# 节点间通信配置
cluster:
  # 集群发现策略
  discovery:
    strategy: static              # 静态发现（手动配置节点列表）
    # 其他可选策略：
    # dns - 通过 DNS 自动发现
    # etcd - 通过 etcd 服务发现
    # k8s - 通过 Kubernetes API 发现
    static:
      seeds:                      # 种子节点列表
        - "emqx1@192.168.1.101"
        - "emqx2@192.168.1.102"
        - "emqx3@192.168.1.103"

  # 集群间通信超时
  connection_timeout: 10s

# 消息压缩配置
# 当消息体较大时，压缩可以显著减少网络传输量
compression:
  # 是否启用消息压缩
  enabled: true

  # 压缩算法选择
  # gzip - 压缩率高但CPU开销大
  # zstd - 压缩率和速度兼顾，推荐
  # lz4  - 速度最快但压缩率低
  algorithm: zstd

  # 压缩阈值（字节）
  # 只有大于此大小的消息才会压缩，小消息压缩反而可能变大
  threshold: 512

  # 压缩级别（1~22，数值越大压缩率越高但CPU开销越大）
  level: 3

四、实战：搭建高可用MQTT集群

4.1 环境准备与一键部署

在讲完策略和优化方法之后，我们需要一个实际的环境来验证效果。下面使用Docker Compose来部署一个3节点的EMQX集群：

#!/bin/bash
# ============================================
# EMQX 高可用集群一键部署脚本
# 用途：在每台节点上执行，部署3节点EMQX集群
# 前提：已安装 Docker 和 Docker Compose
# 用法：修改下方变量后在每台节点执行一次
# ============================================

set -e  # 遇到错误立即退出

# ====== 修改以下变量为实际值 ======
NODE_NAME="emqx1"                                # 当前节点名称（每台不同）
NODE_IP="192.168.1.101"                          # 当前节点IP（每台不同）
DATA_DIR="/data/emqx"                             # 数据持久化目录
# ==================================

# 创建数据目录
mkdir -p ${DATA_DIR}/data
mkdir -p ${DATA_DIR}/log

# 生成 docker-compose.yml
cat > /opt/emqx/docker-compose.yml << 'EOF'
version: '3.8'

services:
  emqx:
    image: emqx/emqx:5.7
    container_name: emqx
    restart: always
    network_mode: host          # 使用宿主机网络，避免端口映射开销
    environment:
      # 节点名称，集群内必须唯一
      - EMQX_NODE_NAME=${NODE_NAME}
      - EMQX_NODE_HOST=${NODE_IP}

      # 集群静态发现配置
      - EMQX_CLUSTER__DISCOVERY__STRATEGY=static
      - EMQX_CLUSTER__STATIC__SEEDS=emqx1@192.168.1.101,emqx2@192.168.1.102,emqx3@192.168.1.103

      # 单节点最大连接数
      - EMQX_ACCEPTORS__TCP__MAX_CONNECTIONS=100000

      # Dashboard 管理密码（生产环境请修改）
      - EMQX_DASHBOARD__DEFAULT_PASSWORD=emqx_secure_pass_2024

      # 启用 Prometheus 指标导出
      - EMQX_PROMETHEUS__ENABLE=true
      - EMQX_PROMETHEUS__COLLECT=true
    volumes:
      - /data/emqx/data:/opt/emqx/data    # 持久化数据
      - /data/emqx/log:/opt/emqx/log      # 持久化日志
    deploy:
      resources:
        limits:
          cpus: '4'           # 限制CPU核心数
          memory: 8G          # 限制内存使用量
    # 健康检查：每10秒检查一次EMQX状态
    healthcheck:
      test: ["CMD", "emqxctl", "status"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 30s
EOF

# 启动容器
cd /opt/emqx
docker-compose up -d

# 等待EMQX启动完成
echo "等待 EMQX 启动..."
sleep 15

# 验证集群状态
echo "===== 检查集群状态 ====="
docker exec -it emqx emqxctl cluster status

# 验证节点列表
echo "===== 集群节点列表 ====="
docker exec -it emqx emqxctl cluster list_peers

echo ""
echo "部署完成！节点 ${NODE_NAME} (${NODE_IP}) 已加入集群"
echo "请在所有3个节点上执行此脚本后，集群会自动组建完成"

4.2 性能压测验证

集群部署完成后，需要用压测工具来验证性能指标是否达到预期。下面使用EMQX官方提供的emq_bench工具进行两个场景的压测：

#!/bin/bash
# ============================================
# EMQX 集群性能压测脚本
# 使用 emq_bench 工具模拟高并发连接和消息发布
# 前提：压测工具已拉取到本地
# ============================================

# 拉取压测镜像
docker pull emqx/emq_bench:5.7.0

echo "========== 场景1：验证最大连接数能力 =========="
echo "目标：模拟 100,000 个客户端同时连接"
echo ""

docker run --rm --net=host emqx/emq_bench:5.7.0 \
  emq_bench \
  -i 0.5 \                                  # 每0.5秒建立一个新的连接
  -n 100000 \                                # 总共建立100000个连接
  -t tcp://192.168.1.200:1883 \              # HAProxy 负载均衡地址
  -p 1200 \                                  # Keep-Alive 间隔1200秒（20分钟）
  -S 1200 \                                  # Session 过期时间1200秒
  -P "emqx" \                                # 客户端密码（需提前配置认证）
  -l info                                    # 日志级别
  -D 180                                     # 压测持续180秒

echo ""
echo "========== 场景2：验证消息吞吐量 =========="
echo "目标：10000个发布者，每个每秒发布10条消息"
echo ""

docker run --rm --net=host emqx/emq_bench:5.7.0 \
  emq_bench \
  -n 10000 \                                 # 10000个客户端同时发布
  -i 0.1 \                                   # 每0.1秒建立一个连接
  -t tcp://192.168.1.200:1883 \              # HAProxy 负载均衡地址
  -d "factory/sensor/+/data" \               # 发布目标主题（+/为通配符，压测时随机填充）
  -M json \                                   # 消息格式为JSON
  -s 256 \                                   # 每条消息大小256字节
  -R 10 \                                    # 每个客户端每秒发布10条消息
  -l debug                                   # 日志级别
  -D 60                                      # 压测持续60秒

echo ""
echo "========== 场景3：验证订阅者消费能力 =========="
echo "目标：10000个订阅者同时消费消息"
echo ""

docker run --rm --net=host emqx/emq_bench:5.7.0 \
  emq_bench \
  -n 10000 \                                 # 10000个订阅者
  -i 0.1 \                                   # 每0.1秒建立一个连接
  -t tcp://192.168.1.200:1883 \              # HAProxy 负载均衡地址
  -s "factory/sensor/+/data" \               # 订阅的主题模式（+匹配一级通配符）
  -M json \                                   # 期望收到的消息格式
  -l info                                    # 日志级别
  -D 60                                      # 压测持续60秒

echo ""
echo "所有压测场景完成，请查看终端输出的详细报告"
echo "关键指标：消息吞吐率(msgs/s)、延迟(P99)、连接成功率"

4.3 监控指标采集与告警

压测过程中需要实时观察各项指标，确保系统运行在预期范围内。EMQX原生支持Prometheus指标导出，配合Grafana可以实现可视化监控和告警：

# ============================================
# EMQX Prometheus 监控配置
# 文件路径：/opt/emqx/etc/emqx.yaml
# 说明：配置 Prometheus 指标导出，供 Grafana 采集展示
# ============================================

prometheus:
  enable: true                    # 开启 Prometheus 指标导出
  collect: true                   # 自动收集所有可用指标
  # 导出端口
  listen: "0.0.0.0:18091"

# 自定义监控告警规则示例
# 将此文件放入 Prometheus 的告警规则目录
# 文件路径：/etc/prometheus/rules/emqx_alerts.yml
rules:
  - alert: EMQXConnectionDropHigh
    expr: rate(emqx_dropped[5m]) > 10
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "EMQX 连接断开率过高"
      description: "过去5分钟内断开的连接数速率超过10个/秒，已持续2分钟"

  - alert: EMQXMessageQueueFull
    expr: emqx_msgs_queued / emqx_sessions > 0.8
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "EMQX 消息队列接近满"
      description: "消息队列使用率超过80%，可能影响消息投递延迟"

  - alert: EMQXNodeDown
    expr: emqx_node_state == 0
    for: 30s
    labels:
      severity: critical
    annotations:
      summary: "EMQX 节点离线"
      description: "节点 {{ $labels.instance }} 已离线超过30秒"

五、技术优缺点综合分析

5.1 负载均衡策略的优缺点对比

三种策略各有利弊，选择哪种取决于具体的业务场景和运维能力。

连接数负载均衡：优势是实现最简单，HAProxy和Nginx都原生支持，配置几行代码就能上线。适合快速搭建原型和中小规模部署。劣势是在高吞吐场景下会产生大量跨节点消息转发，增加网络带宽占用和消息延迟。

会话亲和性负载均衡：优势是消息路由效率更高，同一客户端的消息不需要跨节点转发。适合客户端数量稳定、通信模式可预测的场景。劣势是节点故障时恢复成本高，故障节点上的会话需要全部重建，恢复时间取决于会话数量和网络状况。

主题路由负载均衡：优势是消息路由效率最高，延迟最小。适合Topic结构稳定且可预测的场景，比如按工厂、按设备类型分Topic。劣势是灵活性差，Topic结构变更时需要修改路由规则，且某个节点故障会影响其负责的所有Topic。

5.2 性能优化手段的优缺点对比

性能优化的手段也有很多种，不同的手段解决的问题和副作用也不同。

系统级参数调优：优点是效果立竿见影，通常能提升20%-50%的连接能力和吞吐量。缺点是具有一定的系统侵入性，改错了可能导致系统不稳定甚至无法启动，需要运维人员具备一定的Linux内核知识。

Broker配置优化：优点是相对安全，影响范围可控，回滚简单。缺点是优化幅度有限，通常只能提升10%-30%的性能。

存储引擎优化：优点是对涉及大量QoS 1/2消息的场景效果显著，可以减少磁盘IO瓶颈。缺点是没有持久化需求的场景做了也白做，增加了架构复杂度。

网络与压缩优化：优点是可以显著减少跨节点网络带宽占用，在集群规模大时效果明显。缺点是对CPU有一定开销，如果CPU本身就是瓶颈则可能适得其反。

六、注意事项与避坑指南

6.1 集群部署中容易踩的坑

时钟同步问题：MQTT集群的节点之间必须时间同步。如果节点之间的时间偏差超过几秒，消息过期判断、会话超时、日志关联等功能都会出问题。强烈建议使用Chrony或NTP来同步集群内所有节点的时间，并定期检查时间偏差。

网络分区处理：分布式系统的CAP定理告诉我们，在网络分区发生时必须在一致性和可用性之间做出选择。EMQX默认采用AP模式（优先可用性），但某些需要强一致性的业务场景可能需要调整策略。网络分区时，少数派的节点会进入只读模式，拒绝新的写入操作，这是正常的自我保护机制。

版本一致性：集群内所有节点必须使用完全相同的EMQX版本。混合版本可能导致协议不兼容、集群无法组建等问题。升级时要采用滚动升级策略：先升级一个节点验证无误，确认集群稳定后再升级其余节点，每次只升级一个。

资源隔离：如果Broker和其他服务部署在同一台机器上，必须做好资源隔离。Broker需要充足的文件描述符和稳定的网络带宽，如果同机器的其他服务抢占了这些资源，Broker的性能会不可预测地下降。生产环境建议Broker独占物理机或使用容器做资源限制。

6.2 性能调优的边界认知

性能调优是有上限的，不能盲目加机器、加参数就以为能解决所有问题。首先要定位瓶颈到底在哪一层，不同的瓶颈需要不同的优化方向：

CPU瓶颈：CPU占用率持续超过80%，优化方向是减少不必要的计算，比如关闭不需要的功能、减少Topic匹配复杂度、降低QoS等级。
内存瓶颈：内存占用持续超过80%，优化方向是减少内存占用，比如缩短Session过期时间、减少排队队列大小、降低消息持久化比例。
磁盘IO瓶颈：磁盘IOPS或吞吐量打满，优化方向是换SSD、调大批量写入、减少持久化消息数量。
网络瓶颈：网络带宽打满，优化方向是启用消息压缩、增加节点分摊流量、优化消息大小。

定位瓶颈的常用工具包括top/htop（CPU）、free（内存）、iostat（磁盘）、iftop/nload（网络），以及EMQX自带的Dashboard监控面板。

七、文章总结

MQTT Broker的负载均衡和高并发优化是一个系统工程，需要从协议理解、架构设计、系统调优、监控告警等多个维度综合入手。以下是核心要点：

选择正确的负载均衡策略。没有最好的策略，只有最适合的策略。连接数负载均衡适合快速搭建，会话亲和性适合长期运行的稳定系统，主题路由适合Topic结构固定的场景。生产中通常采用混合策略。

从底层往上优化。先调系统参数（TCP缓冲区、文件描述符），再调Broker配置（监听器、队列、持久化），最后才考虑架构变更（加节点、换存储引擎）。这样既安全又能快速见效。

建立完善的监控体系。Prometheus + Grafana是业界标配，关键指标包括消息吞吐量、活跃连接数、消息延迟P99、Broker的CPU和内存使用率。配置好告警规则，确保问题在影响业务之前被发现。

定期做压测。不是上线前测一次就完了，而是每次版本更新、配置变更后都要重新压测，确保没有性能退化。压测数据是优化决策的依据，没有数据的优化就是瞎猜。

不要过度优化。过早优化是万恶之源。先用默认的架构跑起来，有了真实的数据再针对性地优化，才能做到有的放矢。记住：先让它工作，再让它快，最后让它好。

MQTT协议之所以在IoT和实时通信领域如此流行，很大程度上是因为它足够轻量、足够可靠。但在高并发场景下要充分发挥它的优势，需要在Broker层面做大量的工程工作。希望这篇文章能帮你少走一些弯路，把精力集中在真正重要的优化上。

围绕“MQTT Broker的负载均衡策略及高并发场景下的性能优化”参与讨论

0 条

MQTT Broker的负载均衡策略及高并发场景下的性能优化

一、MQTT Broker的角色与高并发挑战

1.1 MQTT架构中的Broker定位

1.2 高并发的典型业务场景

1.3 为什么需要负载均衡

二、三种主流负载均衡策略详解

2.1 基于连接数的负载均衡（最简单方案）

2.2 基于会话亲和性的负载均衡（推荐方案）

2.3 基于主题路由的负载均衡（最优雅但最复杂）

2.4 HAProxy实现连接数+IP亲和的混合策略

三、高并发场景下的性能优化策略

3.1 系统级参数调优

3.2 Broker配置层优化

3.3 消息处理层优化

3.4 网络层与压缩优化

四、实战：搭建高可用MQTT集群

4.1 环境准备与一键部署

4.2 性能压测验证

4.3 监控指标采集与告警

五、技术优缺点综合分析

5.1 负载均衡策略的优缺点对比

5.2 性能优化手段的优缺点对比

六、注意事项与避坑指南

6.1 集群部署中容易踩的坑

6.2 性能调优的边界认知

七、文章总结

评论

关联文章

AI助手

一、MQTT Broker的角色与高并发挑战

1.1 MQTT架构中的Broker定位

1.2 高并发的典型业务场景

1.3 为什么需要负载均衡

二、三种主流负载均衡策略详解

2.1 基于连接数的负载均衡（最简单方案）

2.2 基于会话亲和性的负载均衡（推荐方案）

2.3 基于主题路由的负载均衡（最优雅但最复杂）

2.4 HAProxy实现连接数+IP亲和的混合策略

三、高并发场景下的性能优化策略

3.1 系统级参数调优

3.2 Broker配置层优化

3.3 消息处理层优化

3.4 网络层与压缩优化

四、实战：搭建高可用MQTT集群

4.1 环境准备与一键部署

4.2 性能压测验证

4.3 监控指标采集与告警

五、技术优缺点综合分析

5.1 负载均衡策略的优缺点对比

5.2 性能优化手段的优缺点对比

六、注意事项与避坑指南

6.1 集群部署中容易踩的坑

6.2 性能调优的边界认知

七、文章总结

同分类面试题

关联文章

AI助手