事件服务又如何保证可靠性呢？

既然已经幂等了那为何不直接对失败消息直接重试，另外这个事件表的加入感觉会严重影响性能和实效性，没看出引入的必要性

可靠事件模式和可靠消息应该是两种模式，可靠事件模式通过消息中间件加本地事务消息表两个来实现事务的最终一致性。可靠消息比如Rocketmq的事务消息来保证消息最终一致性，需要从三个方面。一、发送方可靠，保证本地事务处理成功后，消息一定能被投递到服务方。事务消息帮我们解决了这个问题。老师讲的发送方投递消息超时，服务方处理消息成功，这种数据不一致性也可以得到解决。不然需要我们消费端做幂等，发送方重试来保证最终一致性 二、服务方可靠，需要服务方高可用，比如采用主从多副本机制，同步刷盘。 三、消费方可靠，根据消费方的ack机制，处理成功后才提交消费进度，利用消息重试功能，超过最大重试次数比如rocketmq的16次，加入到死信队列，告警打印日志，人工介入处理。 没有用过可靠事件方式，但我觉得实现起来比可靠消息更加复杂，实现了数据最终一致性也同时给系统带来了一定的复杂度。

事件服务作为一个外部服务，跟生产者之间又会出现事件状态一致性的问题，这个该怎么考虑？

生产者调用事件服务是在本地事务提交前吗？如果是的话，那事务不是会变得很长，影响业务吗？如果不是，那调用事件服务失败了，怎么回滚呢，业务自己补偿还是本地数据库也有一个事件表？

还可以用 binlog 这样的数据库日志，就可以不用事务了。