release message只是一个无状态的通知，重复收到release message也没关系，因为处理逻辑是幂等的。

就算客户端没有收到推送通知，过30秒后重连的时候，服务端也会识别出该客户端漏了消息，会重新推送的。

清理过时的release message只是不希望release message表持续增长。

谢谢，看到了，对于 release message 还有一个缓存，对于所有发布的配置最新的缓存。在重连的时候就能将客户端因为网络问题导致的丢失解决了。之前没有注意，感谢你的回答。

还有个问题，看代码时候没看太明白。

    List<ReleaseMessage> latestReleaseMessages =
        releaseMessageService.findLatestReleaseMessagesGroupByMessages(watchedKeys);

ReleaseMessageServiceWithCache中是不是所有更新过的配置。

通过他获取配置好像是直接获取，没有做什么判断，这样client端每一次发起http会不会就直接获取到结果了，不需要经过异步处理了。还是我看漏了什么地方？

这段代码用到了Spring DeferredResult，所以看上去可能有些费劲。

如果客户端的notification不是最新的，就会执行154行，直接返回。
如果客户端的notification是最新的，就会执行157行，异步处理。

ReleaseMessageServiceWithCache中存放的是ReleaseMessage（对应表ReleaseMessage），不是真正的配置（对应表release）。

这个关于 Spring DeferredResult 的能看明白。ReleaseMessageServiceWithCache中存放了ReleaseMessage，当client端发起 http long polling 后，服务端先从ReleaseMessageServiceWithCache获取相关的ReleaseMessage，然后通过一定的方法比较出client端的缓存是不是最新的。如果不是，就返回新的，是的话就挂起，等待发布事件。这个比较的方法没太看明白( ╯□╰ )。能麻烦讲个大概吗？

NotificationController不负责判断客户端的配置是不是最新的，它只负责判断客户端是不是收到了最新的推送消息。

判断的逻辑就是
https://github.com/ctripcorp/apollo/blob/master/apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/controller/NotificationControllerV2.java#L149

嗷嗷，我想我应该明白了，之前看走偏了。NotificationController发布的更新的消息，消息中会告诉client端那个配置变了，但不会携带变化的配置，当client端收到变化的提醒，然后再请求config server获取最新的配置。是这样理解吗？

对的~

非常感谢。为什么不在 long polling 的返回结果中直接返回更新的结果呢？

这样推送消息就是有状态了，做不到幂等了，会带来很多问题。

嗯。好的，非常感谢您的耐心解答。

这样推送消息就是有状态了，做不到幂等了，会带来很多问题。

麻烦请教下。

能否详细举些例子说下如果推送的时候携带数据都会带来哪些问题呢？

因为个人觉得在推送时携带数据也有它的好处：

1. 减少一次后续client与server的交互.

2. push的时候可以引入一些计算，比如灰度什么的，如果当前机器不在灰度列表内也不需要返回任何信息。

谢谢