关于我

<2020年4月>
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

最近来访

加入的俱乐部

留言簿(0)

文章分类

文章档案

相册


最新评论

1. re: 使用OpenSSL制作SSL證書
感谢,很有帮助--【匿名用户】:E-works热心网友 小雪
2. re: 使用OpenSSL制作SSL證書
受益匪浅,非常感谢~--【匿名用户】:E-works热心网友 落叶无边
3. re: 使用OpenSSL制作SSL證書
不错,很详细--【匿名用户】:E-works热心网友
4. re: EDI X12 SPEC从哪来?和大家讨论
--holger
5. re: EDI X12 SPEC从哪来?和大家讨论
根据业务需求分析得到--【匿名用户】:E-works热心网友
6. re: 【译】ANSI ASC X12标准学习指南
well&nbsp;done,i&nbsp;guess&nbsp;you&nbsp;worked&nbsp;in&nbsp;fox&nbsp;--【匿名用户】:E-works热心网友
7. re: 【译】ANSI ASC X12标准学习指南
概述很全面......--【匿名用户】:E-works热心网友
8. re: EDI SPEC从哪来?和大家讨论
您可以到Rosettanet官方网站看看有没有您想要的资料。--传奇

阅读排行榜

评论排行榜

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


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

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


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

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


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

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


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

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

 

补充说明:

在这个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所支持几种能够确保事务完整的技术手 段,希望能够起到抛砖引玉的作用。

再次感谢各位朋友的关注,希望能够更多的与大家进行交流。

发表于: 2014-05-25 18:46 阅读(832) 评论(0) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册