内容参考：https://www.toutiao.com/a6643383570985386509/
摘要: 原创出处
http://www.iocoder.cn/Apollo/admin-server-send-release-message/ 「芋道源码」欢迎转载，保留摘要，谢谢！
- 1. 概述
- 2. ReleaseMessage
- 2.1 ReleaseMessageKeyGenerator
- 2.2 ReleaseMessageRepository
- 3. MessageSender
- 3.1 发布配置
- 3.2 Topics
- 3.3 DatabaseMessageSender
- 4. ReleaseMessageListener
- 4.1 ReleaseMessageScanner
- 666. 彩蛋
本文接 《Apollo 源码解析 —— Portal 发布配置》 一文，分享配置发布的第三步，Admin Service 发布配置后，发送 ReleaseMessage 给各个Config Service 。
FROM 《Apollo配置中心设计》 的 2.1.1 发送ReleaseMessage的实现方式
Admin Service 在配置发布后，需要通知所有的 Config Service 有配置发布，从而 Config Service 可以通知对应的客户端来拉取最新的配置。
从概念上来看，这是一个典型的消息使用场景，Admin Service 作为 producer 发出消息，各个Config Service 作为 consumer 消费消息。通过一个消息组件（Message Queue）就能很好的实现 Admin Service 和 Config Service 的解耦。
在实现上，考虑到 Apollo 的实际使用场景，以及为了尽可能减少外部依赖，我们没有采用外部的消息中间件，而是通过数据库实现了一个简单的消息队列。
实现方式如下：
- Admin Service 在配置发布后会往 ReleaseMessage 表插入一条消息记录，消息内容就是配置发布的 AppId+Cluster+Namespace ，参见 DatabaseMessageSender 。
- Config Service 有一个线程会每秒扫描一次 ReleaseMessage 表，看看是否有新的消息记录，参见 ReleaseMessageScanner 。
- Config Service 如果发现有新的消息记录，那么就会通知到所有的消息监听器（ReleaseMessageListener），如 NotificationControllerV2 ，消息监听器的注册过程参见 ConfigServiceAutoConfiguration 。
- NotificationControllerV2 得到配置发布的 AppId+Cluster+Namespace 后，会通知对应的客户端。
因此，对于同一个 Namespace ，生成的消息内容是相同的。通过这样的方式，我们可以使用最新的 ReleaseMessage 的 id 属性，作为 Namespace 是否发生变更的标识。而 Apollo 确实是通过这样的方式实现，Client 通过不断使用获得到 ReleaseMessage 的 id 属性作为版本号，请求 Config Service 判断是否配置发生了变化。 这里胖友先留有一个印象，后面我们会再详细介绍这个流程。
正因为，ReleaseMessage 设计的意图是作为配置发生变化的通知，所以对于同一个 Namespace ，仅需要保留其最新的 ReleaseMessage 记录即可。所以，在 「3.3 DatabaseMessageSender」 中，我们会看到，有后台任务不断清理旧的 ReleaseMessage 记录。