综合考虑,使用http和tcp。
xmpp
协议开源,可拓展性强,在各个端(包括服务器)有各种语言的实现,开发者接入方便。但是缺点也是不少:XML表现力弱,有太多冗余信息,流量大,实际使用时,有大量天坑。
MQTT
协议简单,流量少,但是它设计之初并不是一个专门为IM设计的协议,多使用于物联网、推送。IM需要自己在业务上实现。(近几年有很多公司使用MQTT实现通用IM框架),服务端实现相比其他协议会复杂一些。
私有协议
自己实现协议,一个被良好设计的私有协议一般有如下优点:高效,节约流量(一般使用二进制协议),安全性高,难以破解。 缺点就是自己设计的协议考虑不能很全面,协议不通用,以后切换其他框架不方便。自己设计协议需要花费一些时间。
综合考虑,MQTT协议更适合我们。
指使用MQTT的程序或设备。客户端总是去连接服务端。它可以:
发布其他客户端可能会感兴趣的应用消息订阅自己感兴趣的的应用消息退订应用消息从服务端断开连接扮演订阅或发布应用消息的客户端之间的中间人。一个服务端:
接受客户端的网络连接接受客户端发布的应用消息处理客户端订阅和退订的请求转发匹配客户端订阅的应用消息
从以上协议定义中我们知道,MQTT将客户端和服务端限制了4种功能。假如我们要实现IM业务都需要按照它规定的要求来实现。
场景:客户端A要给客户端B发送一条消息,按照MQTT协议是如何实现的。
最简单的流程,B向服务器订阅话题test,A向服务器test话题发布消息,B收到消息。
流程图如下:
MQTT协议比较特别的方式就是它的发布与订阅,相比传统的收发消息,它要多一步订阅,只有订阅了你才能收到消息,也只能通过订阅的方式来收消息没有别的途径。
在说实现方式前,先说一下技术的难点。
难点1:客户端与服务器保持稳定的长连接,比如心跳策略,断线重连。
难点2:如何保证消息可达(不丢)/唯一(不重复)/保序(不乱序)。
难点3:维护mqtt协议要求的发布、订阅等协议逻辑。
自主开发,服务器通过netty与客户端保持长连接,netty基于java技术栈,网上还有erlang或nodejs的实现方式,但综合考虑还是建议使用netty。订阅发布可以使用kafka或rabbitmq等中间件来实现。
方案的优点:自己开发不受框架限制,可以实现各种业务,开发顺利上线后,运营成本低。
方案的缺点:开发成本高,稳定性相比其他方式较差,需要考虑的因素非常多,容易出问题。
基于ActiveMq
直接使用开源的activieMQ来实现客户和服务器端。
方案的优点:不用操心长连接稳定性问题,不用操心消息的送达率、顺序等问题。
方案的缺点:基于activeMq可能会受到一些业务限制。
使用第三方IM服务,比较出名的提供商:容联、网易云信,环信、融云等。
对比文章参考:
https://blog.csdn.net/caoyan0829/article/details/83504739?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.add_param_isCf&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.add_param_isCf
方案的优点:相比之下开发工作量最小,服务稳定。
方案的缺点:收费。
答:实用。
答:如果自己开发,会先判断用户是否在线,假如在线会通过长链给用户发布消息,客户端回复收到推送消息确保推送成功。
假如用户不在线,会调用内部推送系统使用极光推送消息给用户。
答:服务器引入google jar包即可编码和解码protobuf内容。Protobuf的内容定义参考MQTT协议规范。
答:服务器通过雪花算法来生成唯一且有序的唯一消息id。保证消息的有序唯一。