Step 1 - 明确需求

一些可供参考的需求讨论点：

1. 哪种类型的聊天系统，一对一还是群聊？=>都支持
2. 移动端 or 网页端 or both？=> both
3. 用户规模多大？适用于初创公司还是大公司？=> 日活按5000万计算
4. 群聊人数有限制吗？=> 最多100人
5. 需要支持哪些特性？支持附件吗？=>一对一，群聊，上线提示，只支持文本。
6. 消息大小有限制吗？=>单条不超过1万字
7. 需要端对端加密吗？=>当前不需要，后续可能需要
8. 聊天记录需要保持多久？=>永久保存

接下来以下面的需求作为系统设计的目标：

• 一对一低延时聊天系统
• 支持最多100人的群聊
• 上线提示
• 多平台同时线支持。
• 消息通知推送。
• 日活5000万。

Step 2 - 高阶设计

客户端与客户端不直接通信，而是通过聊天服务进行通信，聊天服务需要支持以下特性：

• 从客户端接收消息
• 将消息发送给接收者
• 如果接收者不在线，则将消息暂存起来，直到接收者上线

客户端上线时需要与聊天服务建立连接，这里涉及到连接协议的问题。对于客户端来说，使用HTTP协议是一个常见的选择，客户端使用HTTP协议向服务端发起请求，并且将聊天内容和接收者附加在HTTP消息中，聊天服务器收到HTTP请求后会将消息转发给接收者。客户端和服务器之间使用保活维持聊天连接，减少TCP握手次数。

使用HTTP协议对于客户端来说很方便，但是对于服务端来说就比较复杂了，因为HTTP请求只能由客户端发起，这就导致服务端无法主动发起会话。有很多针对服务端主动发起会话的技术，包括轮询，长轮询，WebSocket。

轮询

指客户端循环检测服务器是否有新消息。根据循环的间隔，轮询可能非常占用资源，导致系统效率低。

长轮询

针对轮询系统效率低的问题，发展出了长轮询。长轮询是指客户端向查询服务器端是否有新消息时，不立即返回，而是等服务器有消息，或是超时之后再返回，这种方式有以下缺点：

• 发送者和接收者可能不在同一个聊天服务器上。HTTP协议通常是无状态的，如果使用轮转的方式做负载均衡，则有可能发送者和接收者不在同一个聊天服务器上。
• 服务器无法判断客户端是否下线。
• 效率不高。如果用户发送聊天信息不频繁，那么维护长轮询也会导致周期性的重连。