既然要考虑为什么使用，那么我们应该从这么几点来去分析这个问题。
1、原始需求是什么？
2、现有框架/产品。
3、对比匹配一个。

原始需求是什么？

功能方面:

一、需要存储6种格式的数据
    1、client_session_subscriptions
        包含clientid、订阅主题、订阅主题质量、更新时间
    2、client_sessions(客户端连接信息)
        包含是clientid、否在线、在线node、持久化session选项
    3、outgoing_message_flow(服务端发送给客户端信息流水)
        包含clientid、message(即所有从服务端到客户端的mqtt消息)、时间戳
    4、incomming_message_flow（客户端发送给服务端信息流水）
        包含clientid、message(即所有从客户端到服务端的mqtt消息)、时间戳
    5、queued_messages(服务端向客户端发送消息的队列)           
        包含clientid、publish、时间戳
三、支持Transaction
四、因为HiveMQ自己做的Cluster Replicate,所以embedded数据库更佳。

性能方面:

1、在完成高性能的同时需要满足占用很少的消耗，尤其是内存。

---

现有框架/产品

redis

功能

1、Key-Value内存数据库
2、不支持Transaction
3、非embedded

性能

1、连接占用tcp连接
2、占内存
3、并发读写性能很好

---

MapDB

功能

1、embedded
2、纯java编写，适合HiveMQ调用
3、支持Transaction
4、B-Tree

性能

该处性能由于有Xodus做的性能对比，此处不做赘述。

---

H2 MVStore Map

功能

1、Key-Value数据库
2、支持Transaction
3、R-Tree
4、非embedded

性能

该处性能由于有Xodus做的性能对比，此处不做赘述。

---

Xodus

功能

1、支持Transaction
2、embedded
3、MVCC

性能

该处性能由于有Xodus做的性能对比，此处不做赘述。

对比匹配一个

功能

由于HiveMQ存储结构较简单、单一；不需要太丰富的查询、插入；支持事物；并最好是embedded型数据库即可，所以由上即可选出使用MapDB和Xodus。

题外话：在3.x.x版本之前，hivemq就是采用MapDB做为持久化框架。
之后hivemq在性能、并发性做了非常大的调优。

性能

下图为xodus官网给出的性能对比:

xodus源码地址:https://github.com/JetBrains/xodus

总结

由上分析，我们就可以得出今天最终的答案。

---

HiveMQ的性能测试如下:
链接: https://pan.baidu.com/s/1gfHsKkN 密码: 9fhk

---

MQTT交流群:221405150

---