实际中碰到的一个异构系统之间数据交换的处理方式设计
2013-07-05 23:04
330 查看
情况描述:
两个不同的业务系统M系统与E系统,两者之间的数据交换采用ESB平台,从而可以保证ESB内部的数据传递流程可以具有一个全局的事务,一旦发生任何异常,都会回滚。
数据传递的方向为从M系统传递至E系统。
前期约定的内容,ESB获取M系统的数据,数据获取方式为从ESB与M系统约定的数据库中间表中获取(相当于M系统的前置机),调用E系统的WebService,将数据写入E系统,并且将调用是否成功的结果写回与M系统约定的中间表中(写回M系统中间表的工作由ESB负责完成),调用E系统的WS之后,除了回写与M系统的中间表,还会有一些其他的数据库更新等操作。
问题:
事务的问题可以交由ESB来处理,可以忽略。
调用WS如果数据未能写入E系统,WS不会抛出异常,而是会返回一个未能写入的代码,并返回原因。
调用WS成功,并且成功写入E系统,但是,在后续ESB处理其他事情的过程中发生异常,事务照样回滚。而E系统的WS,没有补偿机制,不会对数据是否已经存在进行判断,而且E系统的WS由于各种原因,调用时性能不佳
解决方案:
对于问题1。无需关注。
对于问题2。由于前期ESB与M系统约定,一旦发生ESB调用E系统的WS未能写入的情况,M系统会重新生成新的数据,而不是对原有数据进行修改。ESB只需将调用E系统的WS的结果返回写入中间表即可,不管任何一方发生异常,均由M系统重新生成数据,重新传递。这样ESB只需监控新增的数据,并按顺序执行相应操作即可。
对于问题3。就需要在调用E系统的WS之前,对E系统中是否存在相应数据进行判断,如果存在,并且同时最近一次调用时返回的结果为正常,则不再重复调用WS,而是直接执行后续操作;如果不存在或者调用时返回的结果不正常,甚至没有返回结果,则重新从头开始执行相应操作。
另外,如果没有与M系统关于调用E系统WS未能写入的情况的约定,则ESB需要根据E系统的WS的返回值进行判断,如果不正常,则可以直接抛出一个异常,从而回滚整个事务(当然,也可以暂时将异常数据暂存至另外的数据库表中或者其他什么位置,防止此问题数据重复出现),保证流程下次可以再次取得此数值。当然,这样也存在一个问题,就是回滚整个事务,与M系统约定的中间表中,就无法取到调用结果是否正常的信息,除非在ESB平台中有一个地方可以查看异常信息及数据,并且有专人来处理此类事情,否则,表面看起来就是ESB停在某条数据那里不动了,会对业务产生影响。
还有一种方案就是由于监控的增量数据都会记录在一个表中,如果发生调用E系统的WS未能写入数据的情况,则不允许ESB将监控到的增量数据删除,并不是抛出异常回滚整个事务,也就能够正常查看到产生错误的原因。
个人认为最后的解决方案是一个比较不错的思路,记录一下以飨自己。
两个不同的业务系统M系统与E系统,两者之间的数据交换采用ESB平台,从而可以保证ESB内部的数据传递流程可以具有一个全局的事务,一旦发生任何异常,都会回滚。
数据传递的方向为从M系统传递至E系统。
前期约定的内容,ESB获取M系统的数据,数据获取方式为从ESB与M系统约定的数据库中间表中获取(相当于M系统的前置机),调用E系统的WebService,将数据写入E系统,并且将调用是否成功的结果写回与M系统约定的中间表中(写回M系统中间表的工作由ESB负责完成),调用E系统的WS之后,除了回写与M系统的中间表,还会有一些其他的数据库更新等操作。
问题:
事务的问题可以交由ESB来处理,可以忽略。
调用WS如果数据未能写入E系统,WS不会抛出异常,而是会返回一个未能写入的代码,并返回原因。
调用WS成功,并且成功写入E系统,但是,在后续ESB处理其他事情的过程中发生异常,事务照样回滚。而E系统的WS,没有补偿机制,不会对数据是否已经存在进行判断,而且E系统的WS由于各种原因,调用时性能不佳
解决方案:
对于问题1。无需关注。
对于问题2。由于前期ESB与M系统约定,一旦发生ESB调用E系统的WS未能写入的情况,M系统会重新生成新的数据,而不是对原有数据进行修改。ESB只需将调用E系统的WS的结果返回写入中间表即可,不管任何一方发生异常,均由M系统重新生成数据,重新传递。这样ESB只需监控新增的数据,并按顺序执行相应操作即可。
对于问题3。就需要在调用E系统的WS之前,对E系统中是否存在相应数据进行判断,如果存在,并且同时最近一次调用时返回的结果为正常,则不再重复调用WS,而是直接执行后续操作;如果不存在或者调用时返回的结果不正常,甚至没有返回结果,则重新从头开始执行相应操作。
另外,如果没有与M系统关于调用E系统WS未能写入的情况的约定,则ESB需要根据E系统的WS的返回值进行判断,如果不正常,则可以直接抛出一个异常,从而回滚整个事务(当然,也可以暂时将异常数据暂存至另外的数据库表中或者其他什么位置,防止此问题数据重复出现),保证流程下次可以再次取得此数值。当然,这样也存在一个问题,就是回滚整个事务,与M系统约定的中间表中,就无法取到调用结果是否正常的信息,除非在ESB平台中有一个地方可以查看异常信息及数据,并且有专人来处理此类事情,否则,表面看起来就是ESB停在某条数据那里不动了,会对业务产生影响。
还有一种方案就是由于监控的增量数据都会记录在一个表中,如果发生调用E系统的WS未能写入数据的情况,则不允许ESB将监控到的增量数据删除,并不是抛出异常回滚整个事务,也就能够正常查看到产生错误的原因。
个人认为最后的解决方案是一个比较不错的思路,记录一下以飨自己。
相关文章推荐
- 实际中碰到的一个异构系统之间数据交换的处理方式设计
- DataX 在异构的数据库/文件系统之间高速交换数据的工具
- 用共享目录方式实现Windows与Linux虚拟机之间的数据交换
- Java多个线程之间处理共享数据的方式
- 设计模式-生产者消费者模式 常见场景: 某个模块负责产生数据,这些数据由另一个模块来负责处理。产生数据的模块,就形象地称为生产者;而处理数据的模块,就称为消费者。 该模式还需要有一个缓冲区处于生
- Problem Description 输入n(n<100)个数,找出其中最小的数,将它与最前面的数交换后输出这些数。 Input 输入数据有多组,每组占一行,每行的开始是一个整数n,表示这个测试实例的数值的个数,跟着就是n个整数。n=0表示输入的结束,不做处理。 Output 对于每组
- 应用系统之间数据传输的几种方式
- Flume(NG)架构设计要点及配置实践 Flume NG是一个分布式、可靠、可用的系统,它能够将不同数据源的海量日志数据进行高效收集
- 应用系统之间数据传输的几种方式
- 请问MVC4是不是类似于html页+ashx页之间用JSON通过AJAX交换数据这种方式、?
- 35. 百度研发笔试题:设计一个系统处理词语搭配问题
- 应用系统之间数据传输的几种方式
- 秒杀系统:并发队列 接口设计 并发请求数据安全处理
- 今天用Visual C#为客户做一个数据下载分析系统,碰到一个问题 未能启用约束。一行或多行中包含违反非空、唯一或外键约束的值。
- 向记事本里写入数据、一个修改密码的判断方法(用记录本处理密码的方式)
- Java多个线程之间处理共享数据的方式
- 应用系统之间数据传输的几种方式
- Java 大型系统高并发大数据的处理方式
- [技术无关] 以连续的方式对外部数据进行储存、处理的所有物体,都可称作一个“活”的物体
- oracle 同一个数据库,不同用户之间数据交换