使用GroupEventSink时，数据变更不频繁同步卡住的解决方案

当使用GroupEventSink时，如果有一个或者多个分库一直没有binlog，那么所有paser线程都会卡在doSink方法上，导致有binlog产生的分库数据也无法消费。从代码注释上看，这么设计的原因，是为了相互协同，防止某个分库出现问题时，被落下，这样可以避免instance重启时丢数据。但同时也增大了Group模式的局限性，我们现在就有类似的场景，项目预期会有很大的数据量，提前进行了分库（8个库），但是还没有大批量推广，每天的数据量只有几千条，某些分库会长时间没有数据。

为了解决这个问题，我想到的方案有两个：

1、一个是利用心跳Sql，类似“insert into retl.xdual values(1,now()) on duplicate key update x=now()“，保证分库源源不断的有binlog产生，这样就不会卡住了。缺点是对业务系统有侵入，必须在业务库上创建一个辅助表

2、另外想到的一个方案是，改造MysqlEventParser，在内部类MysqlDetectingTimeTask的run方法中，当没有出现异常时，构造一个Heartbeat类型的Event，然后调用consumeTheEventAndProfilingIfNecessary方法，类似AbstractEventParser的buildHeartBeatTimeTask方法

你看还有没有更好的方案？

原提问者GitHub用户lulu2panpan