@pisc
感谢老哥指正
---
1: 不是 2pc，更多是 TCC （如果有预冻结操作） 或 Saga
2：分布式事务分为强一致性，顺序一致性，弱一致性等，理论上延时依次递减，需根据实际业务选择不同实现方式。

1: 不是 2pc，更多是 TCC 。2pc 是第一步：A 服务，B 服务 都进行 preapre ； 第二步 A 和 B 都 prepare 成功，则 commit，如果其中一个失败，则全部回滚。

2：分布式事务严格意义上，没有强一致性，只有最终一致性。

3：优点：不用重复造轮子（高可用，高性能），缺点：运维

------
分布式事务，如果是 java 系，可以看一下阿里的 seata

CI （编译）：可在 A 或 B 执行，如果 B 是 A 的 slave 节点，而且被分配。如果仅仅是配置了 ssh，只会在 A 执行。
CD （部署）：B 需要拉取 CI 阶段的产物来运行，这个产物可能在 A，或者 B 。
---
生产流程，一般 B 不能作为 jenkins slave 节点。

假定数据在后端有序自增且去重，系统只需记录，该用户上一次获取资讯的最大 id （往往是最新），就可以保证用户每一次获取的数据都不一样了。

拉的方式：加时间戳字段，查询时过滤。适用于下单量不大，或非热门产品。
推的方式：定时轮询，或者 mq 。如果分钟级轮询太长，可以通过 while(true){sleep}来减少间隔，如果一次性 update 时间太长，做完压测后，加上 limit 。适用于热门产品。

正则查询

怎么同步，应该不是问题，关键是你什么时候切，切完是否要强一致。