多表同步 ES 的问题
原始需求
对跨业务域数据提供联查搜索能力。
- 比如：对退款单提供根据退款单、退款状态、发货状态的联查，其中退款状态和发货状态是跨业务域。
- 比如：对订单提供根据订单号、订单状态、退款状态的联查，其中订单状态和退款状态是跨业务域。
为什么要上溯需求层面 ？要优化现有方案，容易局限在现有方案的框架里。上溯到需求层面，能够跳出现有方案框架，在更大的范围内搜索解决方案，亦可对现有方案的部分设计与实现的前提和约束有更为清晰的认识。
目标
将多源数据存储 (S1,S2,...,Sn) 的数据同步到具备联查能力的目标数据存储 T，且必须满足：
- T 中的不变数据与 Si 中对应的不变数据应当在指定计算关系下保持一致；
- 对于每一次同步，T 中的可变数据与 Si 中对应的可变数据在最新状态下保持一致。
在现实场景下，源数据存储 Si 通常是数据库 DB ， 而 T 则有不同选择。 比如，有赞选择了 ES 。选择不同的存储，对解决方案的影响也是非常大的。
注意：需求和目标是存在差异的。目标是原始需求在当前环境约束下所能转化的第二层需求。如果跨业务域数据都存储在一张源数据存储中，也就是 源数据存储-目标数据存储 是 1:1 的关系，那么目标就是单数据存储的同步了，解决方案也会简单得多。
但是，在规范的设计理念的指引下，不同业务域的数据通常存储在不同的数据表里，因此才会有多表同步的需求。
制定目标时，需要考虑当前环境约束的影响。如果当前环境约束过强，则应适当考虑能否改造环境约束，使得设计方案有更灵活的空间可供选择。环境约束改变了，同样需求的目标也会发生变化。
设计关键
数据状态变更的每一次最新状态同步必须保持强一致性。
这里的难点在于可变状态的同步。因为不可变状态只需要原样同步即可，且在任何时刻进行均可。
可变状态的同步怎么弄呢 ？ 假设状态是不可逆的，且数值是递增的，比如订单状态的数值只能从 99 -> 100 ，不可能从 100 -> 99, 这样，通过数值的比较（而不是时间戳），就可以过滤掉那些过时的状态。解决方案也会相对简单。
现实场景中，状态的逆转往往不可避免，状态数值的递增关系也不一定满足，因此，通用的方案不能以状态数字的递增关系为前提（否则就会削弱方案的通用性），而要以状态变更的原始时间戳为准。
ES 的前提
ES 存储的数据是一个大的 JSON 串，没有字段级别的版本控制，只有针对整个 JSON 串的一个版本控制。 在多表情形下，同步 ES 需要考虑全局版本控制问题。
ES 数据存储： https://elasticsearch.cn/article/6178
ES 版本乐观控制：https://es.xiaoleilu.com/030_Data/40_Version_control.html
多表同步的现有方案： https://tech.youzan.com/you-zan-ding-dan-tong-bu-de-tan-suo-yu-shi-jian-2/
同步ES的基本逻辑
情形一
假设有一个 索引 E 含有 (refund_id, order_no, rp_status, version)
有一个 DB 表 r (refund_id, order_no, rp_status, version)
同步方案：
只要按照 version 字段，同步到 ES 即可。对于 T1 M1, T2 M2 ，如果 T1.version < T2.verison ，将 T2 时刻的记录同步写入。 此时，使用非顺序队列即可。
结论：
理想的情形下， 一个 ES 表完全仅对应一个 DB ， DB 含有 version 字段，可以作为 ES 表的 version 版本控制，使用非顺序队列。 做搜索索引，应尽可能符合这种情形。
情形二
现在假设有 t (order_no, shop_name) ，要把 shop_name 同步到 E 中。 shop_name 是不变的。
这时，只要在同步处理消息的时候， 关联 t 表，将 shop_name 读取，写入到 E 即可。 只是增加了一次 DB 访问，仍然可以使用非顺序队列。
结论：
将 DB1 ， DB2 同步到 E 中， 以 DB1 为主， 获取 DB2 的不变字段，依然可以使用非顺序队列。DB1 的 version 字段作为版本控制。
需要注意的是，对于分库分表来说， 这里的 version 必须是全局递增的 version ，而不是某个分表的 version 。因为某个分表的 version 是不能满足递增特性的。
情形三
现在假设有 t (order_no, order_status) , 需要把 order_status 同步到索引 E 中。这时候，如果用 version 是不够的。
存在这样的情形：
假设退款单 R001 (T1 M1)→ (T2,M2) 发生了 rp_status = 1 → 3 ; 订单状态 order_status (T1', M1') → (T2', M2') 发生了 order_status = 1 → 5。
现在 T2 时刻的退款单消息 M2 先于 M1 抵达，实时获取了 T1' 的订单状态 1 ；得到了 T2R = (R001, E001, rp_status=3, order_status=1, version =3)
然后 T1 时刻的退款单消息 M1 抵达，实时获取了 T2' 的订单状态 5， 得到了 T1R =（R001, E001, rp_status=1, order_status=5, version=1）
由于 T2R.version > T1R.verison， 因此 T2R 写入。 然而，此时，order_status 的同步是错误的。
结论：
当 DB1 （主），DB2 （辅） 均要同步到索引 E 时，如果 DB1 和 DB2 所需同步的字段都存在变化，那么，使用 DB1 的 version 字段控制版本号是不可行的。这将导致 DB2 的字段同步变更存在错误。
此时，就同步 ES 来说，应当尽量避免这种情形。在设计方案的时候：
-
避免将两个表的可变状态同时同步到一个索引里。
-
在业务层就能做到把 DB2 的可变字段冗余到 DB1 里。不过，这样会增加 DB1 设计和业务更新的复杂度，且事先也不会想到这种冗余方法。
现有解决方案
要解决多表同步的问题，有两种现有方案：
使用顺序队列
上述的问题引发的原因是， DB1 的后更新的消息先抵达先处理。 使用顺序队列，使得 DB1 的先更新的消息始终先处理，这样，就不会导致 后更新的消息获取到过时的 DB2 的字段状态了。 使用顺序队列的原理是，设置 DB1 的主键 ID 作为顺序队列的排序 key 。 顺序队列的优势，是让业务方处理容易了；但顺序队列的并发吞吐量取决于队列分区数，且容易因为一条消息处理出错而阻塞后续的处理。
使用非顺序队列
使用非顺序队列，需要中间存储，自定义的全局版本号 G 和 一个全局的 存储 S
理想情况下，无论谁先到达，都应该写入 最新的数据。那么，这个全局存储 S 和 全局版本号 应该具备什么特征呢 ？
-
全局存储 S，应当含有同步 ES 所需的所有字段；
-
每次通过全局存储 S 和 全局版本号 G 的处理 GlobalHandler， 总能拿到所有字段的最新值 FVnew；
-
每次通过全局存储 S 和 全局版本号 G 的处理 GlobalHandler， 总能拿到递增的全局版本号 G；
-
以 G 为 ES 的版本号控制，总能将递增的 G 和 最新值 FVnew 写入。
实现思路：
-
第一点相对容易，梳理一下所需要同步的字段即可。举上为例：<refund_id, order_no, rp_status, order_status, G>
-
第二点：全局存储 S，具备字段级别的过滤能力，能够根据时间戳过滤掉状态过时的字段值；也就是说，对于要同步的字段 Fi （i= 1,2,..., N）, 如果 Fi.timestamp_t1 > Fi.timestamp_t2 ，则 Fi_value_timestamp_t2 被丢弃。每次写入 S 之后，再取出 S 的最新值。 这正是 HBaseFilter 的功能。
比如说， M2 先抵达，T2 rp_status = 3 被同步到 S ，然后取出最新的值写入 E； 接着， M1 抵达，由于 rp_status = 1 的时间戳 T1 < T2 ，因此， rp_status = 1 会被 S 过滤掉，不起作用，然后取出最新的 S 写入 ES ； 接着 M3 抵达，将 order_status = 5 写入 S，再取出 S 的最新值写入 E。
-
第三点： 全局版本号 G 的计算，保证消息写入的递增性。 同一个表 比如 DB1 的时间戳是有先后的，比如 T2 > T1 , 但是 不同表的时间戳是没有先后的，比如 DB1 T2 与 T3 是无法确定谁大虽小的。
假设 Gf 是消息所带时间戳 T 的函数，Gf = G(T,Ginit) ，Ginit 是全局版本号 G 的初始值，那么 Gf 应当满足什么条件呢 ？
首先 G1 = Gf(T1, Ginit) , G2 = Gf(T2,G1) ，此时 应始终满足： G1 > Ginit , G2 > G1。
即：Gm = Gf(T1, Ginit) > Ginit, Gf(T2, Gm) > Gm 。
也就是说，对于任意的 t 及 Gm, 都有 Gf(t, Gm) > Gm。一个简单的实现是，Gf(t, Gm) = a * t + Gm + b, a 和 b 为常数。
考虑 t = 0 , 则 b > 0 。 取 b = 1. Gf(t, Gm) = a * t + Gm + 1
方案对比：
-
顺序队列方案更简单，只需要一个任务，所有同步逻辑都在这个任务里，且流程更符合自然思维；但顺序队列方案容易阻塞，吞吐量有瓶颈。适合中小型业务量。
-
非顺序队列方案，吞吐量更优，不会因为某个消息消费阻塞；不过方案也更复杂一点，需要多个任务，额外全局存储，且同步逻辑较为分散，不容易直接理解。适合大型业务量。
【未完待续】
