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

Question

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

Answer 1

大漠风 2018-07-02 12:33:16

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


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


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

• 提问者 木星鸽_手机 #1

  多谢老师长文解答
  原来事件表的思路接近事件溯源，可靠消息这种实现方式，是为了在异常情况下去重新读取处理失败的消息
  但是这种方案会定期清除历史事件；
  
  因为事件溯源还是挺少见的，实践起来会不会很困难
  如果说最大努力一次提交是简化的方式，那么在实际项目中这种方式用的多吗，老师你的推荐是？
  

• 大漠风 #2

  事件溯源跟消息驱动本质上还是不一样的，我个人觉得消息驱动没有必要把事件写到数据库中，因为从表中读事件恢复当前的流程比从队列中操作会麻烦一点，而且，你增加了复杂度，多了一步操作。
  但是，消息保存到表中也有好处，这样一有消息就转存到数据库，然后，自己自己控制消息的消费，以及失败的流程。这样的好处就是消息的消费跟业务处理都操作一个数据库，就避免了该服务内的分布式事务的问题。而且，读消息后直接保存，也能在很大程度上避免出错。
  从这个方面来说，保存消息到表再处理是有一定好处的。然而，确实会增加一些复杂性。这就看有没有必要这么做了。

• 大漠风 #3

  其实，在大部分分布式系统中，我觉得都会使用最大一次提交的方式处理，然后通过消息队列的重试，或者上面说的，我先把消息保存下来再处理。毕竟我们一开始实施微服务系统，除非是event sourcing模式，否则不会一开始就完全使用消息事件驱动，而只是在某些也去处理上使用这种方式。至少我们的系统是这样，因为这样一开始开发会比较简单快捷。

点开查看后面9条评论