总结下本周源码阅读的心得：

一. 数据同步的目的

网关是流量请求的入口，是微服务架构中前排的角色，网关高可用即意味着服务的高可用。在使用网关的过程中，为了满足业务诉求，经常需要变更配置，比如流控规则、路由规则等等。因此，网关动态配置是保障网关高可用的重要因素，单纯的通过数据库来同步数据的话，是一个很慢的过程，网关如果通过内存读取配置的话就会很快了，那么数据同步的目的就是，通过内存读取流量转发的配置，策略等，热插拔，随时可在页面进行动态调整。

二. 数据同步的设计

Soul 网关在启动时，会从从配置服务同步配置数据，并且支持推拉模式获取配置变更信息，并且更新本地缓存。而管理员在管理后台，变更用户、规则、插件、流量配置，通过推拉模式将变更信息同步给 Soul 网关，具体是 push 模式，还是 pull 模式取决于配置

三. 数据同步的方式

soul-admin 在用户发生配置变更之后，会通过 EventPublisher 发出配置变更通知，由 EventDispatcher 处理该变更通知，然后根据配置的同步策略(http、weboscket、zookeeper)，将配置发送给对应的事件处理器

    1. 如果是 websocket 同步策略，则将变更后的数据主动推送给 soul-web，并且在网关层，会有对应的 WebsocketCacheHandler 处理器处理来处 admin 的数据推送

    2. 如果是 websocket 同步策略，则将变更后的数据主动推送给 soul-web，并且在网关层，会有对应的 WebsocketCacheHandler 处理器处理来处 admin 的数据推送

    3. 如果是 zookeeper 同步策略，将变更数据更新到 zookeeper，而 ZookeeperSyncCache 会监听到 zookeeper 的数据变更，并予以处理

    4. 如果是 http 同步策略，soul-web 主动发起长轮询请求，默认有 90s 超时时间，如果 soul-admin 没有数据变更，则会阻塞 http 请求，如果有数据发生变更则响应变更的数据信息，如果超过 60s 仍然没有数据变更则响应空数据，网关层接到响应后，继续发起 http 请求，反复同样的请求

具体的实现细节参照：

soul源码解析（八） - zookeeper 长轮询数据同步过程

soul源码解析（七） - http 长轮询数据同步过程

soul源码解析（六） - websocket 数据同步过程

四. 数据同步的分析

1）. websocket同步方式

    为默认推荐方式，依赖websocket进行消息推送，当建立连接时会进行一次全量数据同步，后续的数据都是增量的方式进行更新，增加，对比来说性能更好，且支持断线重连，默认30s。

2）. zookeeper同步方式

    zk的方式性能可很好，也是首次连接全量的数据同步，后续增量同步，但是相对于websocket来说，需要多引进一个中间件，维护成本高了，需要考虑zk的稳定性，以及脑裂等问题。

3）. http长轮询同步

    http的实现过程较为复杂，比较轻量，但是时效性低，其根据分组key来拉取，如果数据量过大，过多，会有一定的影响。 也就是一个组下面的一个小地方更改，会拉取整个的组数据。而且在soul-admin 集群时候，可能会有bug。

4）. nacos同步方式

    该方式中规中矩，我也没细研究，推荐websocket和zk的数据同步方式。