零。前言
一天早上起来，偶然机会看到《环信支持千万并发即使通讯的技术要点》演示文档，简单翻阅之后，感觉干货很多，于是快速记下以下笔记。
一。IM协议和IM Server
XMPP确实很传统，WhatsApp选用了，同时经过压缩、精简（比如说user字符串使用u字符替代）处理，让XMPP轻量不少。
MQTT，如何实现群组、好友呢，这个是业务层面上事情，大家都订阅某一个主题Topic好了，属于业务拓展。
SIP，接触少。
微信私有协议ActivitySync，以前在博客上分享过。
正确拼写是WhatsApp，呵呵。
针对XMPP协议的改进，很有参考价值。
心跳单向四个字节，在XMPP协议下，估计应该是极限了吧。在私有协议协议下，一来一往两个字节足够。
文件传输方式，这是业界通用方式。
移动互联网环境下，用户永远在线，大家的共识。可是取决于手机有没有连接到服务器端，这是无法逾越的障碍。
Muc聊天室，业务层面改进。
这个针对使用OpenFire的同学，很有参考意义。
话说，我以前也安装过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上只看到了两个机房，若用户量级上亿，可能需要扩展到第三个、第三机房，可能跨机房同步的压力就就凸显出来了。
四。小结
总之，干货不少，很给力，再次对刘少壮大牛表示感谢！
原PPT下载地址：http://vdisk.weibo.com/s/A0GI9rXObFMd
PS: 若有侵权，请及时告知。