关于消息驱动架构在实际项目的应用

来源：6-7 实例3-JMS-DB.最大努力一次提交

木星鸽_手机

2018-07-02

老师你好，看了消息驱动的架构方式，感觉获益匪浅
有几个问题和需要确认的点想和你请教下
1、在此架构模式下解决分布式事务问题的关键就是jms事务与spring事务的同步
2、「最大努力一次提交」这种方式在实际应用中能解决复杂的问题吗？一个方法中如果包含jms与数据库两种数据源，并且如果不可避免的出现2个数据库事务提交的场景，如何解决呢？
3、实际应用中最大努力一次提交用的普遍吗？还有一种在每个业务数据库建事件表的可靠消息方案，也是用来解决分布式事务的，这两种方案哪种更好用点?

写回答

1回答

大漠风

2018-07-02

已采纳

其实，在一个事务中操作消息队列和数据库，在分布式系统当中非常常见，在这种情况下，我们是简化了事物管理，也就是避免为了让2个数据源的事务出现问题，而编写过多的相关错误处理代码。而是使用更简单粗暴的方式，就是用同步的方式一次提交。spring的事务同步大都是通过spring 的事件，还有listener等实现的。
那么在出错的时候，就简单的通过重试解决那些可恢复的问题，如网络、IO、数据暂时被锁等。
但是，在这种情况下，我们需要通过合理的设计我们的业务和代码的流程，提前做好条件的判断，资源预留等，从而避免出现不可恢复问题。比如我要买一个商品，你在最后再判断商品的库存，那么这时候出错了，我就需要回滚之前的操作。这就不是能通过重试就能解决的问题了。

你说的是否需要把事件写到表里，这个应该是为了解决某些情况下的错误。事件保存到数据库后，在系统恢复以后，可以重新获取事件重新处理。但是，我觉得这样保存在数据库中，跟在MQ服务器上持久化保存消息直到成功处理，是类似的。这个麻烦的地方是怎么恢复，如果用表，那这个恢复的部分需要你自己处理，如果是mq，那么我可以让他一直重复处理直到这个消息被正常消费。（这也是很多消息中间件的所谓的事务特性，他们保证消息至少被处理一次）

而且，你把事件保存下来，这其实是在往event sourcing模式靠近了，这样的话，也可以考虑完全以事件为中心的event sourcing模式。这个我们在后面的课程里面会详细介绍。