备份转载金总的Note
概述
本文描述了在 Linux 服务器上部署 example broker 上的相关过程及步骤, 为运维及开发人员提供参考。
example broker
example broker 是一款使用 Java 编写的 Mqtt 服务器。能够为符合 Mqtt 规范的客户端提供基于 Mqtt 的消息订阅, 发送服务。example broker 对于 Java 版本有着严格的要求，只能运行在 Java 8 或是以上版本, 不提供向下兼容。
操作系统
example broker 并未在 Windows 平台上进行过测试，因此建议生产环境部署在 Linux。以下相关的命令都是基于 Cent OS X86_64 版本, 部分命令可能需要 root 权限。
内核参数
为了保证 example broker 能够达到要求的连接数, 因此需要对内核参数进行如下的修改, 来支撑大量的 tcp/ip 连接(大于等于 500,000)。
系统文件数
运行 cat /etc/security/limits.conf 查看操作系统当前允许打开的最大文件数，确认运行 example broker 的用户能够打开 500,000 以上的文件, (建议修改为 1,000,000) 以下的配置示例是允许所有用户修改文件数的值为 1,048,576:
* soft nofile 1048576
* hard nofile 1048576
其中的 * 代表影响系统所有用户, 可以根据实际需要修改为运行 example broker 的用户。soft 对应的为警告值, 而 hard 则是真正起作用的限制值。
运行 sysctl -a | grep file 查看 fs.file-max 的值应符合 1,000,000 左右的数值, 并小于上面提及的允许修改数, 这个数字将会影响整个操作系统能够打开的最大文件数。
启动 example broker 之前, 在当前 shell 中执行 ulimit -n 1000000 使当前会话中允许打开的最大文件数设置生效。具体会在启动 example broker 部分进行介绍。
TCP/IP 及网络相关参数
执行 lsmod | grep nf_conntrack_ipv4 查看系统是否启用 firewalld service。
由于 tcp/ip 连接数上升后会造成 防火墙的相关功能及日志写入的工作量上升, 从而影响 tcp/ip 请求的正常连接, 因此现阶段的临时解决方案使关闭防火墙 服务。在实际生产环境的解决措施仍待考虑。执行 systemctl stop firewalld, 然后再次执行 lsmod | grep nf_conntrack_ipv4 查看服务是否已经关闭。
tcp/ip 的 backlog 参数也会影响 tcp/ip 的连接速度及稳定性, 因此可以执行以下命令, 将参数设置为 4096(参考值)。
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
所需软件
在部署和使用 example broker 前，请按照如下步骤安装所需的软件，并确认软件安装正确。
Java
请执行 java -version 确认服务器上是否安装 Java, 或是已经安装的 Java 版本。如前文所述, example broker 依赖 Java 8 或是以上版本, 如果服务器现有 Java 的版本较低，请更新至所需的高版本。
在同一个操作系统上存在多个版本 Java 时容易引起一些不必要的麻烦，或是由于环境变量等因素额外增加不必要的工作, 因此我们推荐安装 jEnv 来管理不同版本的 Java。具体的安装过程请参考官方网站, 本文不再赘述。
Kafka
example broker 依赖 Kafka 消息中间件来完成 mqtt 消息的订阅-发布功能, 因此请确认 kafka 服务器的联通性和可用性正常。
Redis
Redis 负责 mqtt 相关消息的存储功能, 因此在运行 example broker 时确认连接的 redis 能够正常工作。
安装 example broker
example broker 本身为 jar 包, 且包含了运行所需的所有依赖类库。因此只需要上传至用户安装所需的目录即可，无需额外的特殊操作。
运行
使用原生的 java 命令即可运行 example broker 服务。但是为了便捷, 我们建议编写一个独立的 shell 脚本来完成该项工作。以下是一个运行 example broker 的示例脚本。
#!/bin/bash
ulimit -n 1000000
JAVA_OPTS="-server -Xms4048M -Xmx4048M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote.port=9988 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=192.168.1.1"
nohup java $JAVA_OPTS -jar example-broker-0.0.1-SNAPSHOT-uber.jar server config.yaml&
首先脚本使用 ulimit -n 1000000 来设置本次 shell session 运行的进程允许最多打开 1,000,000 个文件句柄。
脚本中的 JAVA_OPTS 参数定义了启动 Java 虚拟机所需的相关参数。在示例中我们定义了以 server 模式启动 JVM, 同时定义了Java Heap 部分的最大, 最小内存都为 4048MB, 且最小内存为 400MB。其余的 JVM 参数请参考对应的用户手册, 并根据实际要求要添加或是修改。
其中需要特别指出的是 JMX 相关的参数设置, 启用了 JMX 的监测服务, 允许用户在系统运行阶段使用 JMX 客户端进行连接, 从而实时监控系统的运行参数。
脚本中的剩余部分即为使用后台运行模式来运行 example broker 程序。
验证
在运行 example broker 后, 请使用以下的方式来验证 example broker 是否正常运行。
使用 tail 命令查看 example broker 的日志输出, 查看是否正常启动, 或在启动过程中是否出现异常信息。
使用 jps 命令查看是否存在 example broker 对应的进程。
在条件允许的情况下, 可以使用第三方的 mqtt 客户端对 example broker 进行简单的功能性测试。
Trouble Shooting
按照本文的上述配置, 在内网环境的同一个网段上, 部署单个 example broker 在双核 8G 内存的服务器, 可以轻松的达到 500,000 的长连接数。如果在部署过程中遇到问题, 或是无法达到预期的性能请参考以下的流程进行排查。
- 确认操作系统的文件句柄数已经调整, 且大于需要承载的连接数。
- 确认 Linux 的 iptables 服务已经关闭。
- example broker 依赖的 Kafka 和 Redis 服务能够正常工作。
- Linux 上安装的 Java 版本正确。
- 启动 example broker 的命令正确。
