本工程是按照https://www.cnblogs.com/520playboy/p/6715438.html (使用事件和消息队列实现分布式事务)这个文章实现的。目前实现了注册用户成功，保存用户表和消息表EventPublish，然后轮询根据消息表发送kafka消息，然后消费者订阅消息并消费消息，把消息入库到EventProcess表。至于后面定时器定时处理EventProcess表中的数据的业务逻辑就没有写了（为了快速消费可以开启多线程，用springboot的异步@Async来并发处理数据）
1.启动Application，这里会自动启动定时器去扫描相关表，也会启动一个线程作为消费者去连接到kafka接收消息。 2.执行DistributedTranTest的addUser()可以模拟注册用户的逻辑。
1.上面文章中的第2个图的EventPublish应该是EventProcess，至于为什么要把EventPublish和EventProcess分开，明明字段都是一样的。因为用户注册端和代金券端是2个微服务，很可能用的是2个库，所以这里用的2个表，如果2个微服务用的同一个库，能不能不分开（待考虑）？ 2.Q:文章中的消费者消费消息，接收到kafka消息后，就根据消息进行实际的业务处理，直到一次接收到的消息全部处理成功，再给kafka手动返回消息偏移量。如果处理过程中失败，只需要下次再重新从kafka接收上次没有处理成功的偏移量开始算起的消息，为什么需要EventProcess表来存一次消息，然后在后面处理？ A：主要是消息可能接受到了一批多个，在业务处理过程中（假设比较复杂），比如大部分都处理成功了，但是有几个就是处理不成功要报异常，那么这批数据的偏移量就都不能提交，因为一旦提交，这几条消息就没机会处理了，但是直接插入EventProcess表，由于业务简单的insert，一般都会成功，然后提交偏移量。后面再依据EventProcess表的数据来进行处理，处理失败也没有关系，下次轮询继续处理那几条处理失败的数据即可。
1.新增用户成功后，如果有那种时效性要求比较高的业务，需要马上知道有用户注册成功了，怎么设计