银行业务概念 1

银行业务概念 1"/>

银行业务概念 1

1、

/  很久之前整理的，忘了具体的网址

[win_bigboy] 1-银行在做某些业务时,柜台上看的一个交易.实际上可能是几个交易的组合, 比如说, 我们行现在的取款交易就分成了 1-记帐, 2-记现金 3-打折; 在交易当中,常常会碰到网络或其他问题可能造成帐记了, 现金没记, 或帐记了,现金也 记了,但打折没打, 在此想问问在座的各位,你们在处理这类问题时采取了什么方法来控制?   是中间件层控制呢? 还 是通过其他方法. 2-现在的银行系统都采用的交易码驱动的方式,先是将帐户锁定,然后开始业务系统处理,处理成功后更新数据库中的实 际帐户信息.我想问的是如果交易当中失败了怎么样?有谁能告诉我现在大行采用的业务系统框架是什么样的? begin work; 处理银行业务 commit work; 但我们行没有用事务,据说是因为处理时间太慢. 所有我想问问大家. 这么说是不用什么回滚机制了? 不过我查了一些软件公司的白皮书, 好象是在用什么回滚机制. 我们行如果做一笔业务的话先要把帐户锁定不让其他用户使用然后处理完帐户后再解开这样的话中间如果速度慢,或者 进程死了的话其他人根本做不了业务这中事一忙的话就会发生. 我以前碰到的系统是用事务控制的, 打印和会计记帐在柜台上是一个交易,但 实际是分开的,好象出来没有出现过记帐了打印 不出来的情况. 不太清楚是不是使用了交易联动的缘故. 现在的系统一个交易可能分为记会计帐,记现金库, 打印,当中中断了, 交易就很不完整了麻烦很多. 我觉得是应该用事务控制但据负责该项目的软件公司介绍是因为用了事物交易太慢了(我们是江苏某地的地方商业银行),但 据我所知道的南京商业银行也是用事务控制的,而我们的业务量是比不上他们的. 所以我觉得也应该用事务控制,而不应该在 表中用记标志(流水戳) 的方法去锁住记录. 原子交易体现了程序的可重用性和交易配置的灵活性,我到是很赞成的. 因为也很多不懂,所以才想问问大行的做法.  我总觉得如果大行也象我们的软件一样的话,那肯定是不可想象的. 我在网上也看过很多软件公司的解决方案大同小异什么 会计一本帐, 以客户为中心原子交易配置等等大同小异, 没什么实在的参考价值. 我感觉我们的系统差就差在中间件上,接到前台相应后往共享内存一放就完事了, 根本谈不上有什么功能了. [无双] 这些都是通过事务来实现的 一般数据库都会提供事务支持 如果没有提交 那么所做的改变没有写到数据库中 中间件也有事务功能 事务可以保证操作的正确性 如果操作结果都不正确了 那么再快的速度也没有用 如果速度慢,或者进程死了的话其他人根本做不了业务这中事一忙的话就会发生. 中间件应该有处理这个的方法吧 ORACLE中也有处理进程死时的情况 如果进程死了 那么它的锁会被释放 事务会被ORACLE回滚 所以其它进程不会发生死等的情况 如果是短时间的操作 那么没有必要自己管理事务 因为事务中每一步都可能出错 或者是程序异常退出 这时数据库的数据就会导致不一致 这样的后果就很严重 如果是时间长的操作 那么也可以分成几个事务实现 我原来碰到的一个系统 它的消息中间件支持 1-二次重发(将请求或回应发在buff中,如在规定时间未收到响应,可重新再发), 2-交易转发(适用于分步式数据库, 他的数据库放在几个不同的地方), 3 二次提交,,交易要么都成功,要么都失败. 还有一个数据库中间件: 定义了sql操作表的统一接口 这个中间件技术真是我碰到的比较好的一个. 但他的应用系统是面向业务的流程式的.网上说是第四代技术,现在不行这个, 现在都用原子交易,所以现在在银 行的应用不是很多了. 数据库中间件 [蓝色键盘] 楼主，不知道你们是做一个银行中间业务或者核心业务的系统，还是？ 如果是说说你的需求。你的描述不够详细。 你描述得哪种业务问题，在国内的银行业中一般的是通过冲正机制来实现的。 需要补充的是：业务系统之所以是事务型的，完全是因为数据库系统提供了OLTP的功能导致的。 如果业务逻辑复杂，并且需要保证操作的完整性，这个根据不同的交易类型，处理方式不一样。 例如，中间业务，要不要冲正以及怎么冲正，要看错误发生在那个环节，是在与第三方的通讯中还 是与核心主机的通讯中，两别帐务是否平。是否出现了单别张等等。 事务的布局和划分很重要，当然在保证业务逻辑完整性的基础上而言的。 可以参照建行的 听到opentp这个名字很亲切，如果有人再用，说明生命力还是较强的。是好事。 TongLINK/Q（或TongEASY)是基于消息（或交易）的中间件产品。 这些都是国内的厂家开发的，尽管这两者在市场占有率方面比不上Tuxedo、MQ、CICS等。但是作为国产软件， 还是应该支持。 题外话：opentp可惜没有人继续做了。东方通现在还在做Tong系列，可惜没有多少突破。 UB在建行用的比较多，如果我没有猜错的话，UB现在还用在规面系统到前置系统之间。（大集中业务除外） [hb317 ] 是这样的，对于银行业务来说，如果帐已经记了，只是打印失败是不需要回滚的。一般来说都会有补打的单独交易。 对于数据库操作的问题可以通过 commit起事物，如果是网络的问题 可以通过中间件来保证交易的完整性。如果是跨系统的业务（中间业务）一般都会对帐的。 如果只是打印失败，是不需要回滚的。一般都回有补打的交易。 交易连动和原子交易是不同的。 如果是数据库中要记好几个表，可以通过数据库的事务来实现事务的完整性。 如果是行内通信问题可以利用中间件来保证交易的完整性。 如果涉及第三方一般都要对帐的。 另外由于业务的要求，不一定所有的交易都是一记双迄的。 如果是批扣或对帐一类的东东是要考虑断点恢复，逐步提交的。 日常交易应该都是一样的。有的行通信速度真的很慢。和数据库本身无关。 有时有的系统比较喜欢设制一堆外键。加上数据比较多，可能会影响速度。典型的例子是对历史表的操作。 一般是通过冲正来实现的，为了保证交易的成功率，在交易上要使用一圈半的模式。比较好 就是通讯时，一般都采用，请求和应答方式，这个叫一圈 如果由请求方再发一个ok交易给应答方，那就是多半圈 不过要看接入渠道了。应该不是所有的，涉及第3方的应该比较多。 国外的新系统是从业务上有突破，从而推动架构的革新。其实现在很多东西不是技术上的问题。现在的东西都不是什么 抄来的，我认为主要是原来会计制度就有相应的做法，偶们只是翻译成c而已。 9999吓得偶都不敢说话了。理论上来说交易中间件就是为了解决分布式系统中的事务的。但是，现在一个系统只有一个数据DB主机， 所以主要还是解决了通信上的问题，以便出错时回滚。有时有的行有两个系统，典型的是卡一套，核心业务一套，当时做的时候就只能靠对帐了，不知9999兄有何高见？ ps 他说的记现金可能是记尾箱吧。出纳的那几张明细是单独记的。 [superzhang] 程序控制是一个方面，不多说了，大部分都是使用事务来控制， 还有就是业务的设计。 各种反交易，冲正交易等都是为了处理这种东西， 还有各种的“补××” 的业务操作也是这为了这个。 对于任何一个业务设计都要考虑到错误的情况，以及错误处理的情况。 不用在讨论了，这些问题讨论到明年的今天还是如此！ 给大家讲一个我的经历，也是笑话，轻松一下： 需要完成的功能： 记帐，然后打印东西。 经历： 1>;完成记帐,传递文件到前台,打印. 不行:要是文件没有接受成功? 2>;交易联动,完成记帐,传递文件到前台,打印. 不行:前台打印机坏了咋办? 3>;加重打各种东西的交易,后台需要保留许多文件和交易的对照. 不行:后台文件太多,没地方,而且不敢删除. 4>;加前台重打各种文件的功能. 不行:前台操作员看不懂文件名. 5>;找领导! 领导说:打印机要坏了,修! 完了. [stroustrup] 首先银行的核心帐务系统的运作方式这里我不做解答。 至于记帐方式，一般是通过事务处理。 原子交易、组合交易一般运用在后台（处理方法不太一样，但区别也不是太大）。 比如：前台通过中间件提交交易1234（等待结果或立即返回），后台就按照1234规则解包、处理（返回结果或不返回）， 完成一次交易。 楼上的兄台说的有道理。现在的关键不是技术，而是对技术的运用与管理的创新。 ps: 有基于数据库（也不一定就是数据库）的帐务处理不用事务机制的？ 建行的前台采用的是联想的ace平台 我不知menp9999对银行业务有什么建议，大家等着呐。 另：我不在建行工作。 中间件不但是将前台数据采集、业务逻辑、后台数据仓库分开，在系统的横向扩展上有很大的灵活性。不一定是3层， 可以是N层，主要看你的应用了。我们用CICS。 [kinghood] 恩，看了楼上各位高见之后才知道天下乌鸦真的一般黑啊，哈哈 无非就是原子交易，事务，系统冲正，一圈半。。。合合合 估计都是抄国外的。 [menp9999] [quote]原帖由 "win_bigboy"]1-银行在做某些业务时,柜台上看的一个交易.实际上可能是几个交易的组合, 比如说, 我们行现在的取款交易就分成了 1-记帐, 2-记现金 3-打折; 在交易当中,常常会碰到网络或其他问题可能造成帐记了, 现金没记, 或帐记了..........[/quote ] 从概念上,确实是一个事务不完整,但是实际上没有那个系统能做到真正的分布式数据库应用.所以事物的概念没有办法 应用在这里来解决问题.目前这帮臭手们也只能在我们面前牛,呵呵,真的问题他们就解决不了,呵呵. 对于C和S端,是应用事务,对于交易的完整性,一般的他们没有什么好的办法处理.手工调帐吧,不过现在舍得花钱,基本上 出现那些问题比较少了. [gadfly] 呵呵，集思广益。 我还有些朋友在相关公司。有些做过一些大行的业务系统，包括使用中间件opentp(现在可能都没人用了)。问了其中 一个，以下是对话,也许有点帮助: QUOTE: Q: 说： 有个人问个银行业务处理的问题 Q: 说： 你清不清楚 Q: 说： 1-银行在做某些业务时,柜台上看的一个交易.实际上可能是几个交易的组合, 比如说, 我们行现在的取款交易就分成了 1-记帐, 2-记现金 3-打折; 在交易当中,常常会碰到网络或其他问题可能造成帐记了, 现金没记, 或帐记了,现金也记了 ,但打折没打, 在此想问问在座的各位,你们在处理这类问题时采取了什么方法来控制? 是中间件层控制呢? 还是通过其他方法. 2-现在的银行系统都采用的交易码驱动的方式,先是将帐户锁定,然后开始业务系统处理,处理成功后更新数据库中的实 际帐户信息.我想问的是如果交易当中失败了怎么样?有谁能告诉我现在大行采用的业务系统框架是什么样的? A: 说： o A: 说： 中间件控制 Q: 说： 就是通过中间件的配置 A: 说： 这个属于所谓的联级交易 Q: 说： 将这些交易整合为一个交易？ A: 说： 成功就都成功，失败就都失败 A: 说： 不是 A: 说： 联级交易 Q: 说： 哦 Q: 说： 2呢？ A: 说： 把若干个单独的交易串联起来 Q: 说： 涉及很多业务系统怎么办？ A: 说： 所以要综合业务系统阿 Q: 说： 综合？总有些事独立的业务吧？ A: 说： 没有综合业务系统，就没有综合柜员 A: 说： 你就不可能在一个柜员做完整个交易 Q: 说： 哦 A: 说： 要到处跑 Q: 说： 明白你的意思了 Q: 说： 就是要专门做这样一个系统 A: 说： 独立的事务，就需要去专门的柜台 A: 说： 是的 A: 说： 这就是为什么有的时候你需要开很多的账号的原因 A: 说： 当然，银行很想改变这种状态 Q: 说： 2的问题我都看不懂什么意思 A: 说： 但是，这种状态的改变，需要投资很多钱 Q: 说： 你是指综合业务系统？ A: 说： 2里他在胡说八道 Q: 说： 呵呵 A: 说： 他以为是在做企业系统呢 A: 说： 还锁定账号 Q: 说： 这些处理都不需要应用管的吧 A: 说： 二次提交都不知道 A: 说： 我去吃饭去了 [一颗流星] 当一方完成交易，发送了报文，并未收到对方的回应时，在进行下次操作前将自动冲正上次操作。 冲正的关键是看帐务是否平。若平不冲，不平则冲。（有些少数银行，平了也冲，可能为了安全起见） [幸福的秋天 ] 至于冲的时机那是要看出现在应用逻辑的什么地方了。 回滚是必要的，关键是回滚的时机。 比如我们银行和移动公司之间的代收程序经常出现这样的问题，不是有单边交易就是有交易以后发票 不能打印，我一直在考虑是否可以找到一种检测打印机功能的办法，但是似乎并不可行。 我有个想法，就是把回滚的权利交给代办员，在打印命令以后不要立刻退出系统，而给代办员提供一个 打印是否成功的确认，如果成功，那么就提交，如果打印失败那么就立刻自动启动回滚。     事实上，根本没有和代理单位之间启用中间件呀，所谓的回滚也只能靠自己做程序完成逻辑上的回滚，就是交费——>;退费 本人就在银行科技部作软件开发，数据一致性肯定是靠事务控制的，一般银行软件不可能出现你说的那种单边帐（ 如果数据集中的话，跨主机清算的业务有可能单边帐，不过一般都有自动冲正，但不能保证没单边帐），集中式 系统肯定要靠中间件支持，中间件功能很强大，事务处理也会接管过去，（我不知道你们用哪种中间件，不可能 没有中间件的）类似Begin work;commit等语句可能你在开放的代码中查不到的，由中间件控制了。通常的柜台交易整 个交易就是一个事务，所以集中式不可能出现记客户帐而不记现金等之类。打存折有些信息（如打印行数、未过折记录等 信息数据库肯定有记录），这些信息的修改也在事务之内的，但柜台由于打印机错误等原因，那是不能恢复的，一般等到 打印机工作，后台交易已经完成，只是一些打印控制传给打印机而已，肯定不能回滚的。 银行业务是典型的联机事务（OLTP），一般是C/S三层结构，一定有中间件， tuxedo和CICS最常见，有些开发商自己也 有中间件产品，（相对便宜）比如南天、太极、联想等，不过我觉得用成熟产品好很多（虽然贵很多），你们系统用的 tuxedo在全球市场占有率最大，很不错的，我们用CICS，但我看过tuxedo很多函数名和CICS一样，有机会大家交流下！ 我认为银行业务的范围太大了，内容也太多了，不能简单的以一种方式实现，应该是几种方法的结合。这其中应该考虑 多方面的因素：必要性，可行性等等，尽可能利用可以利用最现实的机制或者技术 如： 蓝色键盘 提到的 “业务系统之所以是事务型的，完全是因为数据库系统提供了OLTP的功能导致的”应该是指可行性； hb317 提到的“对于银行业务来说，如果帐已经记了，只是打印失败是不需要回滚的”这考虑的就是必要性。 同样以实时性中间业务为例：一般在涉及客户的账务方面应该用的是数据库的事务一致性，同时假如中间业务数据和基本 的帐务数据不在同一个数据库中，还要考虑这两个数据库中的数据一致性，此时如果是在同一个交易中实现，一般也采 用数据库的事务机制；而与第三方一般多采用实时冲正和事后对账相结合的形式。 [superchao] 据我所知，事务是不是完全可靠的，教训深刻。 要结合记录标志的办法，可以清楚的在本地日志上反映已经完成的步骤。然后反冲！ [wohwdm] 前我听中行一位长期在欧洲出差的讲，欧洲有的银行就没有考虑并发处理，原因是并发的几率几乎为零，从这个角度出发就不用锁记录了，呵呵。 大银行都是有自动充正的，也可以手工充正，隔日充正以前我们也有，新的公司好像没有隔日充正交易。 此你在做系统设计的时候要考虑到单边帐情况 , 在数据库中需要记录标志 .. 失败时候根据标志去冲正