基于Kafka监听DB数据变更并同步副表与ES的办法 有更新！ 2024-03-09 今天分享一个最近在业务开发中涉及使用到的很巧妙的小tip。 业务背景是有一张记录后台的DB主表，数据量达到百万级别。后台会涉及到一些字段筛选等，所以如果每次查询直接走DB的话会效率较慢。于是该业务采用的是当有用户或者后台运营进行数据变更时通过消息队列及时将DB变化及时同步至ES。此刻有一个新的业务后台开发，数据是从该百万级别数据量的DB中获取，某个字段符合一定条件时同步至该表，且主表信息变更需要同步至副表。 对于这样的需求，最简单暴力的解决方式就是可以通过定时脚本去进行数据同步，但是这样的方法有点太low啦。因为需要脚本启动之后才会进行数据更新，实时性很差。而且数据库数据量较大，每次全量查询影响性能。 那如果在所有涉及主表记录变更业务触发时，进行副表数据同步呢？当然，这也不是最优解。首先，对于这样庞大数据量的表，其字段和涉及业务也是众多的，你需要去穷尽所有对该表有影响的业务，并且去在每个业务中，增加同步新后台，很容易遗漏；其次，如果过了一段时间，又有新的业务后台也需要同步这张主表数据呢？并且随着后续该表相关业务的累加，很难保证后续的业务开发人员，在触及到主表字段修改的相关业务，或者同步....
Kafka 消费者使用 有更新！ 2023-08-12 consumer 消息消费者，从kafka broker中取消息的客户端。 最近手上的项目需要通过新建kafka订阅，来对消息进行处理，这是我第一次实战使用kafka，以前都只是纸上谈兵。经过本次需求的摸索，在一个服务中，开启多个kafka消费者来提高消费速度，对kafka consumer的使用也有了一定的理解，故记录下。 在实际项目中，主要流程分如下几个步骤，对kafka进行消费。 在业务代码中，定期创建任务并携带需要的参数去订阅kafka消息。 创建kafka消费组，实时监听kafka订阅主题中的消息，由于kafka接收到的消息数据结构是一致的，所以定义一个统一的结构体kafkaMessage去解析接收到的kafka消息，而消息中需要的具体参数，则会存放在kafkaMessage中的Data字段内。不过，要注意的是，由于同一topic的kafka中的消息可能是来自多方的，所以在消息调度前，要对解析后的kafka消息进行筛选，在本项目中，通过的是kafkaMessage中的ProjectName字段进行初步筛选，命中目标参数后再进行消息的调度。 项目背景： 在笔记后台管理平台中，原....
