Apollo原理--概览

•  apollo是怎么实现快速实时通知的？
  • 答：使用pollNotification接口来进行实现长连接，当有变更立即响应客户端namespace的名字，然后客户端在调queryConfig接口查配置
• 长连接是怎么实现的？
  • 答：是使用轮询(循环)实现，客户端每个1秒发送一个调用
• 每秒调用，当没有配置发生变化时不是出现资源浪费吗？
  • 答：不会，因为没有配置变化时，服务端会阻塞60秒，只要60内有发布变更，就会立即响应，服务端使用Spring DeferredResult实现异步化，可以做到“有变更立即响应，无变更不浪费资源”
• 服务端阻塞60秒，那db链接不是也会被hold住60秒吗？不会有问题吗？
  • 答：所以在长连接接口中读完db之后就需要手动断开连接，否则就会出现上述的问题
• 如果长连接挂了，或者服务端没有及时响应变更怎么办？
  • 答：客户端会有兜底方案，就是每5分钟会按namespace去调queryConfig接口拉去最新的配置。
• 服务端是怎么识别到配置的变化的？
  • 答：消息通知，apollo自己实现了一个内部的消息通知机制，使用数据库来实现的，当发布和回滚的时候会往消息表中插入消息，每个apollo服务器都会开启一个消息扫描的定时任务，时间间隔是1秒。使用观察者模式去通知关注这些消息的Listener
• 消息会删除吗？什么时候删除？
  • 答：会，每个服务都会去定期删除消息表中的消息，但是会保留最新的一条，不会删光，按namespace级别，内存中会去保存最新的maxId
• 如果服务端挂了怎么办？业务应用还能读到配置吗？
  • 答：会，客户端会保存配置副本到本地文件，只是配置是旧的，不能实时更新
• 为什么apollo现在要这样设计，而不直接在长连接中推送变更的配置？
  • 答：官方的回答是不能保证幂等性，然后就没了。我想了一下大概是这样的一个场景，为了保证数据不丢失，兜底定时拉取的方案肯定是需要的，那如果使用直接推变更的配置的方案，如果说推送变更1预期先到客户端，定时拉取2预期后操作，但是由于网络问题导致1后到，就会因为顺序问题导致数据不一致。而现在的实现方式就不会出现这个问题