1）MQTT协议和其它协议的区别
MQTT 是OSI的 第7层，应用层协议，和Http(s)/FTP/POP3/DNS/Telnet等处于同一级别(楼最高)。
Socket是第5层，会话session层
TCP/UDP是OSI第4层的传输层协议。
2）弊端
2.1) 更多的调试
所以，当你选择在 应用层mqtt 建立自己的产品开发路线时，这个可能会带来更多的调试。虽然有很多现成的基于mqtt的开源产品( 后台管理界面看上去，也比较吸引人，看上去实现了很多期待的功能 ），但是更高的协议，意味着更多的封装，所以，在这些产品上实施项目，并不一定比你选择 socket 从头写代码，更容易。一旦遇到丢包、性能问题，不好调试。
2.2) 不太重要的特性“订阅Sub”
mqtt提供订阅(sub)功能。但是如果你的商业逻辑上，并不是那么必要把辛苦收集来的信息推送给别人，最多也就是公司内部共享，那为什么需要开放出专门的sub机制呢？别人大量订阅、持久订阅（就算是一个知道来源的username/clientID)，恐怕还会对你的服务器，带来跟mqtt相关的特定端口的 tcp/ip连接过多、释放不掉的副作用、给整个服务器带来压力。
3）麻烦的统计
统计功能似乎是所有 mqtt server的弱项，至少在著名的emqx 社区版里，我只能看到 “当前收了多少消息” 这个最基本的统计。那如果我想分时间段 统计下呢？它没有。要么购买花钱去企业版，那么你就知道开源软件的赚钱之道呢 。
可以在message到达时，像emqx那样写入到menisa库，或者写入sqlite/关系数据库mysql/或者mongoDB，然后想怎么统计就怎么统计。就现有的emqx/mosquitto等来讲，统计只能很简单的统计，一复杂，要自己做。做的方式有3种：
3.1）修改总体的源码
比如对emqx，要增加那个menisa库的写入内容，这个要求较高，要懂erLang。
3.2）利用官方的插件来做
可能官方插件需要钱的；同时，又涉及性能调优，因为找的插件，不透明、不知道源码。容易陷入麻烦。
3.3）自己订阅某一个topic，只针对一个topic做统计
然后存数据库、写sql/hsql统计，那么这个也很费事。首先你要写单独的订阅代码这个就慢了一手呢！因为消息已经来了,你还要去写一个独立于系统的订阅代码。
当然，对物联网消息来讲，不统计，或者统计的不好，也许也无所谓，它们不是什么银行交易记录的那种业务信息，是物联网信息，也谈不上什么 transaction事务、统计。。。
4) 转发到其它消息队列的难题
比如转发到 Kafka,RocketMQ 等，这个涉及企业级特性，往往对于开源 mqtt server来讲：
是需要使用者 额外付钱的 ！！！
5）socket方式实现类似功能的一般思路
其实，如果在性能上，要求不是很严，那么可以通过任意语言，通过socket 来实现此目的，比如用java：
1）在服务端初始化 Socket Server。
建立HashMap，key为topic，value为针对每个topic建立的队列Queue变量。
2) 为每一个client连接建立，应答子线程。
pub是往队列Queue里push message ;sub时，从queue里pull。
3）如果要pub后，期望返回服务器的应答，那么则用socket的双向通信机制，这个机制很简单、很完善、很好用。
6) 物联网终端的发展现状
1）往往是有线电源供电：车上，车子供电；船上，船供电；地下管道，管道附近拉电源线。最好不要谈什么低功耗。低功耗的，搞什么带移动电池的项目，有什么利润？谁去做？
2）具备一定的内存和硬盘（比如ARM机），并非以前的无内存无硬盘的弱单片机。对于发不出去的消息，把它保存成离线文件，等有网了，再发出去，就可以了。不需要搞什么：至多一次、至少一次 。。。
3) 4g网络很常见，带宽很充沛，不需要节省什么流量；物联卡办理很容易，马上5g也要普及呢！就连卫星网络，也不是想象的那么贵，在将来会和5g联通。
所以，一切都很好办。IBM的历史遗留，毕竟充满着一些学术的味道！要谨慎对待。IBM自己也几乎从IT的历史长河中退出呢！
7)基于java的mqtt项目
说了那么多，如果你仍然想打造自己的mqtt，但是对 erLang(emqx的开发语言)，C(mosquitto的开发语言) 语言不熟悉，也可以改造基于java的mqtt项目：https://github.com/moquette-io
618
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
