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

前些日子，以前组里的同事参加一个POC测试，测试中有一个异常测试用例，就是在测试程序运行的时候，将流程kill掉来模仿系统宕机的情况，然后将流程重新启动，最后检查是否有数据丢失。这个测试用例出现了问题，最后检查数据，总共有几十万条数据，大约丢失了十几条。同事将他们的做流程发给我，让我帮忙看一下，流程大致如下：



该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掉，这样在流程重新启动的时候，就可以重新处理这个数据了。流程修改如下：



在这个流程中JMS Queue Receiver使用ClientAcknowledge Mode，并且在添加了Confirm
Activity。这样只有当流程运行到Confirm的时候才会将消息从JMS Server上Confirm掉。如果流程在运行的过程中中断，没有Confirm的消息还在JMS服务器上，流程下次重新启动的时候，还会再次处理这个数据。
但是这样还是会有问题，流程中有一个JMS Queue Sender，需要将处理后的数据发送到另一个Queue上去。如果按照上面图中的流程进行设置，JMS
Queue Sender可能会被重复调用，比如了流程中断的时候，正好是在Sender之后，Confirm之前，这样数据是不会丢失了，但是最后的结果可能是数据多了，因为有数据被Queue
Sender重复发送了。流程还需要再改进一下。



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



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

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

补充说明：

非常感谢各位朋友的关注，对于junjiez1984和lin49940所提的问题我这里做一下解释，在这个poc里面，我们采用transaction是TIBCO提供的分布式事务插件XA
Transaction Manager，并不是BW里面默认自带的jms transaction，JMS transaction确实达不到我们上面的要求。XA Transaction Manager需要单独购买并安装，目前最新版本为1.0.2，配合BW进行使用，其支持的事务如下：

活动类型	是否支持	支持条件
JDBC activities	是	使用XA连接方式
JMS activities	是	使用XA连接方式
ActiveEnterprise Adapter activities	是	使用JMS通信方式；对应的JMS使用XA连接方式
TIBCO iProcess BusinessWorks Connector activities	是	使用XA连接方式(XA connection type)
EJB activities	否

另外对于消息没有Confirm而产生的多个job问题，因为这个流程是当时的一个poc流程我们只是简单的处理中断问题，所以没有care这种多余job，在实际的实施过程中，我个人更倾向于Confirm掉所有的消息，将出错的消息记录入日志，进行重做来保证数据的完整性。本篇文章只是用于介绍TIBCO所支持几种能够确保事务完整的技术手段，希望能够起到抛砖引玉的作用。
再次感谢各位朋友的关注，希望能够更多的与大家进行交流。