环信支持千万并发即使通讯的技术要点--来自一名Qcon会议听众的分享

IM协议和IM Server

XMPP确实很传统，WhatsApp选用了，同时经过压缩、精简（比如说user字符串使用u字符替代）处理，让XMPP轻量不少。

MQTT，如何实现群组、好友呢，这个是业务层面上事情，大家都订阅某一个主题Topic好了，属于业务拓展。

SIP，接触少。

针对XMPP协议的改进，很有参考价值。

心跳单向四个字节，在XMPP协议下，估计应该是极限了吧。在私有协议协议下，一来一往两个字节足够。

文件传输方式，这是业界通用方式。

移动互联网环境下，用户永远在线，大家的共识。可是取决于手机有没有连接到服务器端，这是无法逾越的障碍。

Muc聊天室，业务层面改进。

这个针对使用OpenFire的同学，很有参考意义。

二。移动网络环境下的网络、电量等客户端优化

IM或推送，建立长连接是必须的，可以节省TCP来回创建的开销，但断线之后，是否需要即刻重连，尤其是处于地铁、WIFI边缘地带，可能会造成重连风暴，需要添加稍加延迟连接机制。

针对发送的消息的回执，客户端一定要发送回执反馈，否则不知道是否发送成功与否。

流量跑马测速，心跳智能，压缩传输。

Android手机端优化措施，干货、细节很实用，可以直接拿来用，分享很给力，呵呵！

批量、合并数据请求/发送，增量更新，这是一个大家都应该使用的常规节省流量手段，应牢记！

难得的是，分享了：

2G 文件上传最佳buffer size 1024个字节，3G/4G下直接设置为10K

2G 文件下载最佳buffer size 2048个字节，3G/4G下 30K

绝对经验的总结，赞！

心很细，给出了频繁的属性访问直接声明protected/publish了，不创建新的Java对象只能static类型了。记得很久以前写J2ME程序时，就用过这样的方式。

实践中走过多少弯路才总结出来的同步、绘图、渲染页面惊艳，尤其是支持离线方式的数据同步机制，很受用。

三。百万级架构经验分享

虽然很简单，熟悉TCP/IP协议，这是毫无疑问。

无状态协议交互，才能够很容易水平横向扩展，也是当今共识。

让所有操作都要尽可能的异步

典型的按照机房进行完整部署，若不能够在DNS层面做到按照用户ID进行指派（HTTP DNS进行接入IP分配），那么就必须处理用户乱入机房的问题，必然要做到一些数据的跨机房的同步，大家都会采用增量式同步方式，跨机房一般常见30毫秒的延迟，批量形式增量同步，那都不叫事。

可以看到业务垂直切分，各个业务之间水平扩展。

貌似可以看到单元化CELL/SET架构的影子，但这只是自己的瞎猜而已。

PPT上架构图文字细节不甚清晰，再加上自己近视，分辨不太老好的，可以看到消息存储使用了Kafka（和数据库集群之间存定时拉取关系），分布式锁基于Zookeeper，前端LVS做负载均衡，业务非常垂直。

在PPT上只看到了两个机房，若用户量级上亿，可能需要扩展到第三个、第三机房，可能跨机房同步的压力就就凸显出来了。