你好，我是陈现麟。

现在我们已经学完“分布式计算篇”了，一直坚持到现在不容易，恭喜你做到了，这是一件值得鼓励和高兴的事情。

在“分布式计算篇”的学习过程中，我们一起讨论了非常多的分布式计算相关的技术原理，并且在讨论技术原理的时候，同时也一起讨论了技术出现的原因、解决问题的思路和架构设计中的 trade-off 。我认为它们和技术原理是一样重要的，是我们进行系统设计的软素质，相信你已经具备了分布式在线业务系统的架构能力，还有足够的信心去做一些相关的系统设计了。

所以，今天我们就来个期中测试，实际考察一下你对分布式计算系统的理解，以及对所学知识的应用情况。

你可以用一周的时间，去做一个 IM 系统的架构设计，对于这个 IM 系统，从业务上和架构上有如下的需求。

业务上的需求：

• 支持单聊。
• 100 个人以内的群聊。
• 峰值同时在线 1000 w。
• 峰值发送消息 10 w QPS。

架构上的需求：

• 开发模式简单，新功能支持快速迭代。
• 长连接支持就近接入和负载均衡。
• 分层设计。
• 在功能迭代上线的时候，不要影响到用户已经建立好的长连接。
• 发送消息的接口是幂等的。

根据上面描述的业务上和架构上的需求，请你分别回答下面几个问题：

1.IM 系统一般都会涉及基于 TCP 的长连接通道和基于 HTTP(S) 的短连接通道，你认为长连接通道和短连接通道的职责分别是什么？

2.长连接的就近接入和负载均衡应该怎么来做？（可以考虑通过设计一个路由服务来解决。）

3.整个 IM 系统应该怎么分层？每一层的职责是什么？（可以考虑从长连接接入、Push 和 IM 等方面来进行分层。）

4.在系统设计中，如何让功能在迭代上线的时候，不要影响到用户已经建立好的长连接呢？

5.对于业务需求， IM 系统的消息扩散模式，采用读扩散还是写扩散？为什么？

6.如何保障消息的发送接口是幂等的？

7.如果要对 IM 系统进行限流，你认为应该在哪几个地方来实施？为什么？

8.如何提高长连接和短连接通道的连接成功率？

9.整个 IM 系统满足业务需求的指标，大约需要多少机器资源？是怎么计算的？

加油，期待你的回答，我们将在 3 月 14 日更新架构作业的讲解。

预祝你取得好成绩！