QingLong/Doc/策略与办法/增量数据同步策略.txt

原则上，要求所有汇集系统必须提供增量数据变更办法，采用伪删除+时间戳策略，原则上不允许对表格进行delete操作！

但就是怕坚持不下来，导致出现有的业务系统存在delete操作的问题。

# ds_id 为guid类型，为唯一主键，原来的业务主键不使用
# 每张字段都有一列 is_del,描述此条数据是否已被删除掉，需业务系统进行维护，不得真的执行 delete 操作。
如果实在说服不了业务系统，就需要对于存在delete操作的业务系统表，由我司研发人员，手动写delete trigger,向原表中插入一个带有删除标识的数据记录,来完成对原有逻辑的维护。

---------------------------
可以考虑如下的备用方案：

增量数据通过Kafka的单Topic向业务系统发布，可以避免Kafka的时序不正确问题，性能下降不是最主要的矛盾问题。

# debezium同步postgresql数据至kafka 
https://www.cnblogs.com/virtualzzf/p/17574740.html


# 业务系统数据库，如果共享数据增量获取异常，该如何重置？
答：kafka中json数据格式：ts_ms记录了写入时间戳，可以用Java转化为 Date类型，同理，一旦用户的增量数量获取异常，可以采用如下方法重置：

1、向数据仓库管理员申请最新的完全备份，比如2023-10-31 00：00：00
2、采用Postgresql 16还原此数据库，再通过自行编码等办法，完成自己业务数据库中对共享数据的重建。
3、向 Kafka中获取时间戳大于2023-10-31 00：00：00的数据即可。


对于未来可能出现的多租户多级模式，可以考虑debezium->kafka,然后用Java写代码，将kafka的Topic中数据读取出来，再根据划分的粒度，比如到区县、到校的办法，创建新的Topic,再进行写入即可。

# kafka topic和topic权限操作
https://blog.csdn.net/qq_17328759/article/details/129804571