首先，实现主要业务的服务，必须保证具有事务一致性的特性，比如依赖于普通的RDMS。这时候如果发生业务，则同时向消息队列发布一条事件消息，这样其他的服务可以订阅这个消息，并对这个消息进行处理，并产生自己业务的数据，保证到最后的一致性。
这样带来一个问题，保存到数据库和向消息队列发布消息无法做到事务一致性。比如你数据库操作完成了，MQ连接不上怎么办？我们可以在操作数据库的事务中，增加一个插入事件数据的任务，这个任务和主业务是同一个事务，保证一致性。另外起一个定时任务，从数据库读取插入的事件数据，转化成消息发布到消息队列，发布成功后删除事件数据。
这样带来另外一种可能，比如消息发布到消息队列后，删除事件失败，可能就会造成消息多发。这样需要我们保证接受事件处理程序，需要保证幂等性或者具有去重的功能。这样即使消息被重复发送，也最多是浪费一点资源重跑了一下。
在这种情况下，依然可能出现其他业务拿到消息后，无法执行本地业务成功。这时候可以让其他业务把失败的任务保存下来，由一个专门的异常处理程序来集中起来人工处理。
这里我们举个会员注册自动送积分的例子。我们这里有两个服务：会员管理、积分管理。会员在注册后，根据一定条件产生一条送积分的记录。首先用户在会员管理中调用插入一条会员记录，并同时插入一条事件是“新会员”这样一条记录。定时任务读取到“新会员”的事件后，向MQ发布一条“新会员”的消息。积分管理模块订阅了“新会员”的消息，收到后从会员管理服务查询到会员状态，经过计算后插入一条积分记录。如果操作失败，则发送一条消息处理失败的消息到MQ，由专门的异常业务处理模块记录下来并通知到管理员。
最后，记录好日志，极端情况实在不行可以根据日志进行人工操作。
