HiveMQ是什么

小編給大家分享一下HiveMQ是什么，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

簡單介紹

HiveMQ是企業級MQTT Broker，提供高性能、高可用、高擴展、高安全性的企業級服務。

它是純Java實現的。

官網地址:http://www.hivemq.com

基于它如上的描述，所以后續我們就是基于它的高性能、高可用、高擴展、高安全性這幾個特點來分析它的源碼。

注意：本篇源碼都是基于HiveMQ 3.1.2版本源碼講解。

拓撲圖

Single

多個客戶端直接與Broker連接。 Cluster

多個客戶端與Load Balancer連接,由Load Balancer做負載均衡,將連接分發到各個Broker。 多個Broker組成Cluster,由JGroup進行集群通訊。 多個Broker由一致性hash環虛節點，進行集群中數據的主主備份，以達到高可用。 HiveMQ提供多種集群Discovery來達到不同組網場景中的集群發現。

架構圖

• Handlers由實現Netty ChannelHandlerAdapter。處理SSL;處理MQTT協議的codec；處理監控數據收集;處理流量限制;擴展點回調觸發等客戶端長鏈接。

• SPI是HiveMQ擴展出來為做HiveMQ Broker端二次開發,提供各種- - - Callback、 Cache、Scheduler、Authentication、Authorization、- Configuration等等擴展點;還提供了各種異步/同步的接口Service。以便開發人員基于HiveMQ開發屬于自己的業務；

• Plugins是基于SPI提供出來的擴展點，按照HiveMQ的Plugin開發要求，注冊屬于客戶自己的Plugin，HiveMQ官方也給我們提供出來了一些基礎插件及各種插件的示例。

• ClusterServices是處理集群連接、數據備份、數據交換、節點狀態、一致性has虛擬節點等處理的一堆Service

• Persistences是處理消息的存儲、Cluster節點間的數據存儲／同步。

• LocalPersistences是處理消息在當前節點的信息存儲。

開源框架使用

• 使用Guice做DI

• 使用Netty 4做網絡框架

• 使用JGroups做Cluster Node之間的集群通訊

• 使用Exodus做Broker信息文件持久化存儲

• 使用Dropwizard Metrics做Broker的統計、監控

• 使用Kryo做序列化/反序列化

• 使用Jetty做Broker端servlet容器

• 使用Resteasy做Broker端restfull框架

• 使用Quartz/做Broker端任務的調度

• 其他還有一些使用的框架不一一列舉

官方工具: https://www.hivemq.com/developers/community/

身份認證：https://www.hivemq.com/docs/4.2/extensions/introduction.html（貌似可以為每個網格提供一個身份認證器?）

硬件配置及性能優化:https://www.hivemq.com/docs/4.2/hivemq/system-requirements.html(包含文件句柄數調整及TCP緩沖器大小調整)

hivemq擴展開發庫:https://github.com/hivemq?q=extension&type=&language=java(提供各種各樣的api,感覺可以做很多東西)

擴展開發庫api：https://www.hivemq.com/docs/4.2/extensions-javadoc/index.html

hivemq擴展程序HTTP提供了就緒檢查，這意味著服務能夠檢測HiveMQ實例是否脫機：https://github.com/hivemq/hivemq-heartbeat-extension

hivemq基準測試

基準1000W連接/40個節點=25W/node

Message Rate for Publisher

?詳細性能測試報告可到官網下載PDF文檔

機器:

結論:

hivemq client話費8分47秒連接1000W個連接到hivemq，平均每秒500個連接

CPU:38%→25%

內存:6.97-7.6

Quick Results: Connect & Subscribe Test - 10,000,000 MQTT clients

HiveMQ 3.3.0

40 node Cluster

Connect Duration: Connect Speed (avg):

CPU Memory

Subscribe Duration: Subscribe Speed (avg):

CPU Memory

8 min 47 sec 19,011 connects/sec 30 % 5.07 GB

4 min 31 sec 36,765 subscribes/sec 38 % 6.97 GB

測試表明，HiveMQ每秒平均可處理174萬條消息（每秒1,739,876毫秒/秒）出，而每秒可處理16.7萬條消息（166,925毫秒/秒）入。 在30分鐘的測試時間內，總共有31.3億條消息（3,131,776,800 msg）傳出消息和3億msg（300,465,888 msg）傳入消息。

查看系統帶寬時，HiveMQ平均每秒處理389.78兆字節（408,711,565字節/秒）出，并處理327.84 MB /秒（343,762,614字節/秒））入。

在測試執行期間，CPU使用率平均為64.72％，內存為11.33 GB（12,164,655,331字節）。

QoS 0測試表明

HiveMQ在大型群集中具有強大的吞吐能力，可以充分發揮其在水平擴展方面的優勢。 具有1000萬個并發連接的客戶端的HiveMQ實現了每秒170萬條外發消息的恒定吞吐量，平均CPU負載不超過64％。 為了使數字更易于掌握，讓我們將它們與一些龐大的Internet應用程序進行比較，其中一個很好的例子是WhatsApp。 2014年，WhatsApp發推文稱，一天之內，它們已收到640億條消息（傳入200億條消息，傳出440億條消息）。 將總計640億條消息與我們在測試中獲得的數量進行比較，每30分鐘添加傳入和傳出流量時，我們有3,432,242,688條消息。每天總共增加了1647.5億條消息（164,747,649,024條消息）。 HiveMQ群集每天可以輕松處理通過整個WhatsApp基礎架構發送的消息量的2.5倍！ 在查看性能以及負載指標時，很明顯，HiveMQ不僅提供高吞吐量，而且以64％的CPU和73％的內存使用率保持受控和穩定的狀態。

QoS 1測試表明，

HiveMQ每秒平均可處理78萬條消息（779,576 msg / sec），每秒可處理78萬條消息（779.577 msg / sec）。 在30分鐘的測試期間內，總共有14億條消息（1,403,237,449 msg）傳出消息和14億消息（1,403,237,882 msg）傳入。

查看系統帶寬時，HiveMQ平均每秒處理279.44兆字節（293,010,785字節/秒），并處理220.24 MB /秒（230,935,379字節/秒）。

HiveMQ可以處理硬件上的10.000.000個連接，并具有出色的，穩定的吞吐量，同時在傳入和傳出兩個方向（QoS 1測試）上具有170萬個傳出消息（QoS 0測試）和780 msg / sec。 HiveMQ能夠輕松地水平擴展到群集節點的中間兩位數 HiveMQ能夠處理具有高放大倍數的大型扇出情況。在測試時間范圍內，吞吐量保持恒定且穩定，消息速率隨群集大小和CPU數量而變化 HiveMQ具有水平擴展的能力，因此非常適合小型和大型部署。 它是最具擴展性的MQTT代理，即使提供QoS 1保證，也具有出色的性能。

hivemq配置項

操作系統

生產：Linux是生產環境當前支持的唯一操作系統。建議使用CentOS7或其他基于RHEL的發行版。

最低硬件要求

• 至少4GB RAM

• 4個或更多CPU

• 100GB或更多可用磁盤空間。

環境

生產：需要OpenJDK JRE 11或更高版本。

Linux配置優化

您可以通過幾種方式優化Linux配置：

增加打開文件限制

如果在Linux操作系統上運行HiveMQ，請確保允許HiveMQ進程打開足夠數量的文件。要調整限制，請在/etc/security/limits.conf文件中添加以下幾行：

• hivemq hard nofile 1000000

• hivemq soft nofile 1000000

• root hard nofile 1000000

• root soft nofile 1000000

調整TCP設置

在具有許多連接的系統上，可能有必要調整TCP配置并使系統打開更多套接字。要進行這些調整，請在/etc/sysctl.conf文件中添加以下行：

＃這會使內核在服務過載時主動發送RST數據包。

net.ipv4.tcp_fin_timeout = 30

＃可分配的最大文件句柄。

fs.file-MAX = 5097152

＃啟用等待插座的快速回收。

net.ipv4.tcp_tw_recycle = 1

• ＃從協議的角度來看，在安全的情況下，允許將等待套接字重新用于新連接。

net.ipv4.tcp_tw_reuse = 1

• ＃的默認大小接收緩沖區的套接字使用。

net.core.rmem_default = 524288

• ＃該套接字使用的發送緩沖區的默認大小。

net.core.wmem_default = 524288

• ＃套接字使用的已接收緩沖區的最大大小。

net.core.rmem_max = 67108864

• ＃套接字使用的已發送緩沖區的最大大小。

net.core.wmem_max = 67108864

• ＃每個TCP連接的接收緩沖區的大小。（最小值，默認值，最大值）

net.ipv4.tcp_rmem = 4096 87380 16777216

• ＃每個TCP連接發送的緩沖區的大小。（最小值，默認值，最大值）

net.ipv4.tcp_wmem = 4096 65536 16777216

要應用更改，請鍵入sysctl -p或重新啟動系統。

以上是“HiveMQ是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！