交警罚没系统基本流程为银行收款、财政记账、交警解锁。

   银行方面要求一分钟内必须有返回结果和交警是通过安全边界进行信息交换。财政居中财政系统要确保財政记账和解锁的数据一致性。

   因为到交警解锁通过安全边界和交警六合一平台通讯有一定延迟为提高对银行端的响应速度，我们采取異步解锁的方式即财政收到银行端请求的情况下，先记账同时在财政端写入一条需要发起请求的记录日志，记账与写日志在一个事物當中记账成功即给银行返回成功消息。

    另外一个工作线程读取财政端日志，根据财政端日志写入安全边界的请求表，在安全边界上建立一个交警端日志，记录发起请求的信息写请求表和写交警端日志在一个事物中完成。每次根据财政端日志写请求表前先检查交警端日志，如果没有写过请求表再写入这2个表。这个动作完成后再删除或者更新财政端的日志记录。

至于返回结果保持数据一致性的問题后面再更新吧

原理上，借鉴了ebay base模式建议看英文原文的论文，讲的比较透彻

实践中，银行发过来的消息偶有乱码，因为我们是socket接口通讯所有，我猜测银行和财政通讯中有噪音与掉包现象

解决办法是：银行没有收到响应消息，就让银行重发消息；问题是银行嘚系统都是自己平台之上构建，不一定能重发请求报文；

另外就是让他们晚上发对账文件，根据对账文件和日间文件对比找出漏发的消息。

ps:如果采取电子渠道缴罚款交易的时候，我们检查的内容包括如下内容：

检查处罚决定书编号是否为空

检查处罚决定书编号长度是否符合规则（默认15位长度）

判断是否是本地交警处理：

取得区划id:   根据银行传过来的银行编码 从银行、交警、区划的字典对照表(account_unit),中查询区划信息（好像没啥控制性作用）

检查支付标志，支付标志用于区分是柜面支付还是电子渠道支付

检查收款标志（是否测试）

根据银行代码查询对应的区划根据区划查询业务年度

查询的字符串格式：查询类型+处罚决定书号+柜员+区划编码