客户端配置同步增量更新

[jackie-coming]

你的特性请求和某个问题有关吗？请描述

清晰简洁地描述这个问题是什么。即，当碰到xxx时，总是感觉很麻烦
当前的客户端配置是把namespace下的所有item同步到客户端更新。
对于db的io而言，如果一个namespace有2000个key,每个key 1k,则一个namespace有2M左右，若有100台客户端，每次配置更新会有200MB的db带宽访问，非常容易把db的带宽打满

清晰简洁地描述一下你希望的解决方案
1、是否可以只同步变更的key?

清晰简洁地描述一下这个特性的备选方案

其它背景
如果可以的话，我很愿意实现它

在这里添加和这个特性请求有关的背景说明、截图

[nobodyiam]

可以探讨下增量如何实现

[jackie-coming]

好的，我这几天写一个详细的方案，一起交流下

[jackie-coming]

可以一起看看有没有更好的方案，按照现有的release表设计（所有item在一个字段里面），貌似只能在查询侧缓存多个版本的change结果

[nobodyiam]

• 在客户端侧可以从某个版本开始支持增量更新能力，例如请求服务端时传入一个参数
• 服务端侧可以增加配置开关决定是否启用增量更新能力，在返回的结果中也需要让客户端感知是全量配置还是增量配置
• 从逻辑上来看是否启用增量配置和 config service 是否启用 cache 是独立的能力，是否直接延用 ConfigServiceWithCache 目前针对 notification id 的缓存能力即可，例如计算增量配置时先根据 notificationid 加载配置再计算增量配置？

[jackie-coming]

• 在客户端侧可以从某个版本开始支持增量更新能力，例如请求服务端时传入一个参数
• 服务端侧可以增加配置开关决定是否启用增量更新能力，在返回的结果中也需要让客户端感知是全量配置还是增量配置
• 从逻辑上来看是否启用增量配置和 config service 是否启用 cache 是独立的能力，是否直接延用 ConfigServiceWithCache 目前针对 notification id 的缓存能力即可，例如计算增量配置时先根据 notificationid 加载配置再计算增量配置？

好的，那我就按照是否启用增量配置和 config service 是否启用 cache 是独立的能力 为两个独立的能力进行代码编写

[jackie-coming]

实现的过程中，发现一个小问题需要一起讨论一下

[nobodyiam]

1. 增量更新是一个优化的 feature，具备 fallback 能力（全量更新）
2. 一般情况下配置发布后短时间内（如 2 秒内）基本上所有客户端都会更新到最新版本

基于上述信息，在内存中只需要保留最近 1~2 个版本的 delta，时间也不需要太长（例如 5 秒？），所以采取缓存的方式会更具可行性？

[jackie-coming]

1. 增量更新是一个优化的 feature，具备 fallback 能力（全量更新）

2. 一般情况下配置发布后短时间内（如 2 秒内）基本上所有客户端都会更新到最新版本

基于上述信息，在内存中只需要保留最近 1~2 个版本的 delta，时间也不需要太长（例如 5 秒？），所以采取缓存的方式会更具可行性？

好的 我也认为缓存可以解决大部分问题同时对用户感知最小

[jackie-coming]

实现的过程中，还有两个问题，需要帮忙一起看看

[nobodyiam]

1. releaseKey 能够唯一确定一个版本，notificationId 相同不一定 releaseKey 相同
2. 可以在本地 install apollo-client/apollo-core 后测试 apollo-configservice，mvn clean install
3. 待测试通过后提交 PR 到远端仓库，有 github action 可以打包