架构师面试（三）：订阅模型

对【注册中心】【配置中心】【消息队列】和【IM】进行分析和抽象，可归纳出一个完整的业务模型单元，即【订阅系统】，下面关于实现订阅系统的几种模型的相关描述中，说法正确的有哪几项？

A. 信箱模型，即客户端定时对服务端进行轮询，实现简单，但实时性不高；信箱模型可基于 HTTP 或 TCP 协议实现；注册中心一般采用信箱模型做可靠性兜底策略；

B. 电话模型，即服务端主动推送数据到客户端，实时性很高，但实现复杂；电话模型可基于 TCP 协议或 http long pull 实现；IM 系统一般采用该实现模型达到高实时性的目的；

C. BP机模型，即服务端主动推送通知到客户端，从而触发信箱模型，实时性高，同时实现也简单；Zookeeper 和 Apollo 采用了该实现模型；

D. 扩展的信箱模型，即客户端实时对服务端轮询，只不过服务端有数据或超时后再返回；RocketMQ 采用了该实现模型。

A：信箱模型，由客户端触发，服务端被动响应，容易落地；客户端无法及时感知服务端是否产生了消息，所以通过轮询方式获取，实时性不高；

      信箱模型通常基于 HTTP 或 TCP 实现，如果轮询周期比较长，可以采用短连接协议，轮询周期比较短时，可以采用长连接协议；

      注册中心客户端，一般通过启动时拉取 和 被服务端通知的方式获取服务方变更信息，为了提高可靠性，可通过信箱模型来兜底。

信箱模型见下图。

B：电话模型，由服务端触发，客户端被动响应，消息实时性比较高，但是落地相对复杂很多；（服务端只有一个，客户端有很多，服务端怎么存储客户端的连接信息？推送给客户端后，怎么确保客户端接收到了？各种异常信息怎么处理？......这些事情都需要服务端处理，相对复杂很多。）

      电话模型，通常基于长连接或短连接的长轮询方式，即 TCP 协议或 http long pull 实现；

      IM 系统一般会采用电话模型实现消息的推送。

电话模型见下图。

C：BP 机模型，包括三次交互，首先是服务端主动推送 “通知” 到客户端，然后触发客户端的【信箱模型】动作；

      BP 机模型同时具备了信箱模型和电话模型的优点，即实时性高，落地容易（服务端业务逻辑是被动响应方式实现的）；

      Zookeeper 的 watcher 机制 基于 TCP 协议实现了通知的推送和数据的拉取；

      Apollo 基于 http long pull 实现了通知的推送 和 配置项的拉取。

BP 机模型见下图。

D：扩展的信箱模型，由客户端触发，服务端在产生消息或超时后返回，典型的开源案例就是 RocketMQ 的 pull 模型。 

ABCD