如何基于日志，同步实现数据的一致性和实时抽取?

消息中schema部分,定义了namespace 是由 类型+数据源名+schema名+表名+版本号+分库号+分表号?能够描述整个公司的所有表,通过一个namespace就能唯一定位.

payload是指具体的数据,一个json包里面可以包含1条至多条数据,提高数据的有效载荷.

UMS中支持的数据类型,参考了Hive类型并进行简化,基本上包含了所有数据类型.

全量和增量的一致性

在整个数据传输中,为了尽量的保证日志消息的顺序性,kafka我们使用的是1个partition的方式.在一般情况下,基本上是顺序的和唯一的.

但是我们知道写kafka会失败,有可能重写,Storm也用重做机制,因此,我们并不严格保证exactly once和完全的顺序性,但保证的是at least once.

因此_ums_id_变得尤为重要.

对于全量抽取,_ums_id_是唯一的,从zk中每个并发度分别取不同的id片区,保证了唯一性和性能,填写负数,不会与增量数据冲突,也保证他们是早于增量消息的.

对于增量抽取,我们使用的是MySQL的日志文件号 + 日志偏移量作为唯一id.Id作为64位的long整数,高7位用于日志文件号,低12位作为日志偏移量.

例如：000103000012345678. 103 是日志文件号,12345678 是日志偏移量.

这样,从日志层面保证了物理唯一性(即便重做也这个id号也不变),同时也保证了顺序性(还能定位日志).通过比较_ums_id_ 消费日志就能通过比较_ums_id_知道哪条消息更新.

其实_ums_ts_与_ums_id_意图是类似的,只不过有时候_ums_ts_可能会重复,即在1毫秒中发生了多个操作,这样就得靠比较_ums_id_了.

心跳监控和预警

整个系统涉及到数据库的主备同步,Canal Server,多个并发度Storm进程等各个环节.

因此对流程的监控和预警就尤为重要.

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!