1.推送式系统口
与常见的请求响应式的系统不同，例如搜索系统，系统，b系统，这些都属于请求响应式系统。 推送式系统最大的特点就是，你不需要去主动请求就可以接收到响应结果，从而触发一些业务操作。
2.逻辑复杂性难点口
举个简单的添加好友流程： 。用户A添加用户B为好友，并且添加到分组G 。判断A是否存在 。判断B是否存在 。判断分组G是否存在 。拉取A的好友列表，判断B是否存在A的好友列表中 。判断A的好友是否达到上限 。判断A是否将B拉黑 。判断B是否将A拉黑 。检查用户A是否频繁添加其他人为好友 。检查用户A添加好友描述是否涉黄，敏感词 。拉取用户B的添加好友策路，查看是否允许添加好友 。再根据B的添加好友策路走不通的添加流程，如开启好友验证，则走好友申请流程，如按身份添加则走身份判断流 程.…
账号，群组，消息等服务的复杂度并不低于好友服务口
3.消息可达性→口
既消息的可靠传输，其实这个问题不光是即时通讯的难点，所有的分布式系统可能都有这个难点，只是这一点在即时通 讯的场景中尤为突出与重要，如果一个聊天软件，频繁丢消息还有用户会使用吗？ 分布式领域有一个非常重要的定理，内容是：任何端到端的消息传递协议，不可能做到既不丢失也不重复。那么是不是 即时通讯系统就被判了死刑了呢？并不是，我们在设计即时通讯架构系统的时候需要做一定的折中取舍。后面会详细介 绍。
4.状态同步
5.海量数据存储
系统中存在的用户数据，用户与用户之间的好友数据，用户与用户的群组数据，群组中的群成员数据.… 如果一个日活10小w的即时通讯应用，那么每天群聊，单聊所产生的聊天消息会有多少条呢？
6.即时&&通讯
即时：顾名思义要快，当一条消息发送出去之后，要让用户非常快的收到消息，那么多久算快呢？快递送货两三天才能到，下裁文件几个小时我们都能等，为什么一条消息延迟几秒钟，就会让人感觉体验很差？因为凡是都需要一个预期，快递我们提前能够知道就是需要两三天时间，下载文件，我们也能够有预期有个进度条在。那么即时通讯需要有多快才 能称得上即时？A输入完文字秒级以内可以发送给B,不影响双方的聊天，这是我们衡量是否即时的标准，所以要做到即时一定是毫秒级别为单位的。
通讯：双方按照既定的协议进行信息的传递。
什么是协议呢？双方共同遵守的一个东西叫协议。如：离婚协议，夫妻双方就婚烟的终止达成的一个约定。如停战协 议，战事双方就战争停止达成一定的协议。 什么事信息？信息是可以传播的内容。比如A跟B说，”你好”，那么这个“你好”是信息。 而即时通讯是什么？是双方按照共同遵守的协议进行快速传递信息的技术。