菜鸡碰到一个消息发送的需求，想不到啥好的解决方法，想请教一下大家

[lbprivateacc]

各位大佬们，碰到一个消息发送的需求，想请教一下： 消息体里面的字段是主表+关联表的属性字段，当这些属性字段发生变更时，要把变更的字段内容发出去。 目前的情形是：主表，关联表的字段修改，后端有差不多 10 个接口，我的方案是使用 AOP 去拦截这些接口在 before 和 after 做处理就好了。 但我上司觉得不好，后面如果其他人开发其他接口时也有修改这些属性的可能，可能会漏掉。我上司希望这个东西不会影响后面人的开发，但我比较菜，想不出来其他方法了，希望大家能指点一二

统一回复一下：
属性修改有业务逻辑，设计到属性状态这些的，有些属性修改要审批通过后才发消息。cannal 我看了下是支持带业务逻辑的处理，但目前时间比较紧，应该来不及去研究了，准备穷举接口先把需求完成吧。
刚入职一个月，对项目还不是很熟悉，真是鸭梨山大啊，谢谢大家的回复😘

[k9990009]

canal

[xuanbg]

binlog

[cloud107202]

debezium

[96XL]

拦截这些表的 update sql ？

[4lieS]

canal

[bugprovider]

binlog

[chenPiMeiHaoChi]

发哪去啊？发给其他平台的话就用 mq ，记好日志，留好证据吵架用。

[siweipancc]

最近写了个类似的东西，如果是 java 跟 Hibernate 有几个类给你关注一下
`org.hibernate.integrator.spi.Integrator`,`org.hibernate.event.spi.PostUpdateEventListener`

然后可以参照一下官方的缓存实现 `org.hibernate.cache.internal.CollectionCacheInvalidator`

其他的实现 JPA 标准的提供商都应该都有这一块的逻辑，非 service 驱动的话 hook 进去即可。如果不是 JPA 标准，那么你只能自己实现了，注意`脏值`这个语义, 拦截 sql 大部分是无意义的🤣

[jiakme]

flink-cdc

[yinaqu]

兄弟，你拦截接口层，那必然会导致后续有新接口也要加拦截，甚至不是接口去修改，就是个定时任务或者其他 service 修改了字段，你或者其他开发人员忘记了有这么个更新字段业务的情况（没忘每次都要额外处理也烦）。反正你这种实现方式确实不合适。binlog 的方案我感觉相对也麻烦，思路切换到在表格映射 java 实体这一层做钩子我觉得会好很多。如果你们用的是 jpa hibernate 之类的，可以尝试直接在 entity 这一层使用 @PreUpdate 和 @PrePersist 。

[yinaqu]

@yinaqu 如果你们用的是其它 orm 框架，比如 mybatis 之类的，就去查它有没有类似的功能，感觉这是个相当基础的功能，一般来说都有

[cnoder]

canal

[fengpan567]

canal

[Gobling]

你担心 deadline ，可以和上级商量。花时间去研究 canal ，这对项目来说是好事。好过你去写一个未来肯定会废弃的东西，浪费时间。

[KimAndBella]

可以考虑字节码编程，在驱动层拦截 sql ，并且抛出来，项目实现接口自定义处理方法，这样不管哪里来的 sql 都可以抓到。 以上可能描述不是很准确，不过我觉得应该可以满足你的需求。

[ycvk]

flink cdc

[andrew2558]

你这个字段变更时，是要时实的发出去吗？如果不需要实时的话。可以用触发器呀，有更新时将修改内容插入到一个特定表内，再用程序去定时观察这张表不就可以了？

[SANJI59]

用的什么 orm 框架，拦截 sql 就可以啊。

[urnoob]

拦 sql 会有可靠性问题。
flink debezium 之类的可以。而且实现起来也简单

[lbprivateacc]

@yinaqu 用的是 mybaties ，想过在 dao 层做，但这些字段更新，消息发送存在着业务逻辑。处理起来感觉要😇就放弃了

[lbprivateacc]

@Gobling 要和其他项目，没办法往后推了

[lbprivateacc]

联调，漏打了

[totoro52]

canal 无脑上啊 ，简简单单， 搞个 client 就行了

[nanjingwuyanzu]

直接 canal ，你用其他的方式出了问题研究的时间肯定大于等于你研究 canal 的时间了、

[chachae]

debezium cdc ，有用 flink 的可以直接上 flink-cdc