TIBCO BusinessWorks实战系列：交易完整性实例

TIBCO BusinessWorks实战系列：交易完整性实例 收藏

<script type="text/javascript"></script><script type="text/javascript"></script> <!--[if !vml]--><!--[endif]-->

 

该BW流程从JMS的Queue上接收消息，将消息进行处理后发送到另一个Queue中。流程中的JMS Queue Receiver的Acknowledge Mode是Auto。从这个流程中，不难判断出，出现数据丢失的原因是当kill掉BW 流程的进程的时候，流程已经从JMS服务器上取到消息，但是整个流程还没有运行结束。因为JMS Queue Receiver使用了Auto Acknowledge方式，在Receiver接收到JMS消息的时候就会将消息从JMS Server中Confirm掉。如果这时流程被kill掉，JMS已经被Confirm掉，但是数据还没有处理完，这条数据就丢失了。

要解决这个问题，就要保证流程在运行完成之前，不要将消息数据从JMS服务器上Confirm掉，这样在流程重新启动的时候，就可以重新处理这个数据了。流程修改如下：

<!--[if !vml]--><!--[endif]-->

在这个流程中JMS Queue Receiver使用Client Acknowledge Mode，并且在添加了Confirm Activity。这样只有当流程运行到Confirm的时候才会将消息从JMS Server上Confirm掉。如果流程在运行的过程中中断，没有Confirm的消息还在JMS服务器上，流程下次重新启动的时候，还会再次处理这个数据。

但是这样还是会有问题，流程中有一个JMS Queue Sender，需要将处理后的数据发送到另一个Queue上去。如果按照上面图中的流程进行设置，JMS Queue Sender可能会被重复调用，比如了流程中断的时候，正好是在Sender之后，Confirm之前，这样数据是不会丢失了，但是最后的结果可能是数据多了，因为有数据被Queue Sender重复发送了。流程还需要再改进一下。

<!--[if !vml]--><!--[endif]-->

在这个流程中，将Confirm提到了JMS Queue Sender前面，并且在Confirm和Queue Sender之间添加了Checkpoint。Checkpoint可以存储当前流程的数据和状态，通过这些数据和状态，可以对运行失败的流程进行恢复。恢复操作是从流程中断前的最后一个Checkpoint开始执行的。我们看一下这个流程，如果流程是在Confirm之前中断的，那流程在下次启动的时候就会重新处理这个消息，因为没有运行到Sender，所以就不会有重复消息。如果流程是在Checkpoint之后中断的，那么在下次启动的时候，就会从Checkpoint开始运行将消息通过Sender发送出去，也保证了数据不会丢失。当然了，这个流程也不完美，如果中断发生在Confirm和Checkpoint之间，那这个数据可能就丢失了。也许你会说这样不就和前面那个流程一样了？上一个流程在Queue Sender和Confirm之间中断的话，会出现重复数据；这个流程在Confirm和Checkpoint之间中断会丢失数据，而且从流程上看，发生这种情况的概率是差不多的，貌似没有什么改进。其实在我们测试的过程中，发现JMS Queue Sender的耗时比其他的Activity多几倍甚至多一个数量级，所以这个流程出问题的可能性比前面一个流程要小很多，所以目前这个流程比前一个要可靠很多。即便是真的发生了数据丢失，那几十万条数据丢失一两条，这样的POC结果用户也是可以接受的，而且这个流程也有性能的保证。

如果是用户的生产环境，我们要保证业务的万无一失那怎么办呢。最保险的办法就是使用Transaction了。我们修改流程如下：

<!--[if !vml]--><!--[endif]-->

将Confirm和JMS Queue Sender放到一个事务中，只有两个都成功才会起将消息从JMS Server上Confirm掉并把处理后的消息发送出去。这样不论流程在何时中断，都不会出现数据的丢失和重复。但是使用Transaction的时候性能通常会比不使用Transaction差一些。这个需要根据客户的实际业务场景进行使用。

这里也只是个简单的例子，真正的客户业务环境要复杂的多，需要灵活的使用和搭配这些确保交易完整性的技术，确保业务系统的可靠性。