配置中心最基础的场景：
客户端和服务端保持一个长链，当在后台操作配置时，会把这个配置以 K/V 形式存储，然后通知 Procesor，后者拿到 K/V 之后把它推给客户端，整个过程就完成了
保存K/V时，额外存一个flag字段，表示是否已经成功发送给客户端
多份配置的处理
- 存储
一个设备的 K/V 对通常不会超过 100 项，每对 Size 不超过 1K，也就是一台设备对应的大小上限为 100K 左右，假如设备数为 100 万，就需要 100G 的磁盘空间
采用索引加上组合的方式，
参考一下 Go 语言里 Slice 的设计，Slice 内部使用了一个数组，但可以指定使用该数组的哪一部分，其实就是索引。
这样某个 Key 如果有新的 Value 了，只需在对应的 Key 后面 append 即可。此时需要同步更新设备的索引，这块可能花一点时间，如果数据都在内存的话其实也还好（由于只是存索引，因此这些数据量内存 hold 得住），持久化可以异步进行。
流量
对数据进行压缩
例如使用lz4,lzma等
使用diff
Diff 的话一种处理方式是把 K/V 的索引放到客户端，然后比对两个索引的 Diff，再把真正的 Value Diff 下发到客户端进行合并。这样就会有一个问题，客户端需要上报它当前的配置中心的索引值，这就涉及到上报时机。服务端在得知更新后，主动向客户端要当前保存在客户端的 Config Indexes，对比之后再发送 Diff
同步策略
多设备
简单的处理可以用令牌桶算法：桶里的令牌数代表服务器当前的承载能力，每次请求进来消耗一个令牌，如果令牌消耗完了，请求直接拒绝，等服务器缓过来了，再往桶里加令牌。
多维度
维度的更新
上面可以看出，该配置针对每个duid都会有一些配置，而不是我们传统意义上的针对app_key部分，这样，可以确保每个用户都能收到