duckula3/run/consumer

发布 : 2020-12-21 浏览 :

kafka消费任务

  duckula3的kafka消费任务,是延续duckula2的功能,如果binlog监听任务的数据确定只有一个使用者时,可以不配置这个任务,因为,binlog监听任务有足够的能力直达想要去的中间件(见”监听任务”一节),如果想用kafka来做缓存,用于缓冲binlog解析器与存储中间件的接收速度,如果只有一个数据使用者时,这种缓存并不需要,第一,接收中间件速度慢了,数据肯定延迟,加不加缓存不能解决问题。第二,由于只有一个使用者,由于接收中间件接收速度慢并不会影响别人,慢点解析有什么关系呢?使用kafka还有一个作用就是利用kafka的consumer的消费offset来做HA,但是binlog在5.6以后可以支持gtid了,它可以精准定位binlog位置,也就是说mysql本身就具有HA的机制。

  综合来说在数据使用者只有一个时,可以使用直接推送到存储中间件的方案,少一次消息发送和消费的过程,减少失败,如果具有多个使用者同时使用相同的数据时,那必须考虑使用kafka等消息中间件缓存一下,利用消息中间件的广播模式可以很好地做到消息复用。

主界面

  入口:运行管理->kafka消费任务

image-20201222110634795

支持“消费者名”条件查询。上面的小框是它的编辑界面:

字段说明

  • kafka消费任务:用于标识这个消费者的,需要能一看就懂的消费者

  • 版本:执行器对应的程序版本,如果是host/docker发布模式,只能使用发布管理上的版本,所以在此不能进行配置。只有k8s可以配置版本

  • 反查实例: 反查是指通过数据库表的id来查到此记录的全部字段的行为。在以下两种情况下需要反查,当数据由于某种原因丢了部分数据,那么可以采用离线解析的方案把这部分数据补到kafka中,那么这部分数据是旧数据,不应该覆盖目标中间件的现有数据,所以在duckula有一个字段:isError标识为true,对于这部分数据,consumer需要做一次反查db的动作,拿到最新的数据再去覆盖。第二种情况是kafka采用全幂等模式,binlog监听只传一个数据库的id(这样不用考虑顺序性,大大提高发送kafka性能),那么consumer想要添加到存储中间件前必须做一个反查。一般来说这个字段选择的数据库与binlog监听数据库实例相同。

  • 布署环境:消费者执行器将在哪个环境进行布署。

  • kafka实例:将要监听的kafka实例,它会在“存储中间件管理”页面进行配置

  • 目的中间件:将要把监听的kafka消息同步到哪个目标中间件,它会在“存储中间件管理”页面进行配置

  • topic:监听哪个kafka主题,为了减小架构难度,一个kafka消费任务只处理一个topic的数据。

  • 附加配置:要同步到目的中间件需要的其它配置,由插件来使用这些配置。

  • 编辑规则 :见。。。。

本文作者 : andy.zhou
原文链接 : https://rjzjh.gitee.io/2020/12/21/duckula3/duckula3-run-consumer/
版权声明 : 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处!

知识 & 情怀 | 二者兼得

微信扫一扫, 向我投食

微信扫一扫, 向我投食

支付宝扫一扫, 向我投食

支付宝扫一扫, 向我投食

留下足迹