交易一致性规范和安全生产（网络、非功能、文件传输、接口管理）考试
对于非功能测试案例（UAT、演练），项目组组织开发部、测试部、运维人员三方签字。
对
错
对于网络开通、流量变化项目组必须和维护部、科运中心网络团队沟通一致。
对
错
对于在途交易、在途回盘文件是否已考虑新程序处理旧交易、旧文件的风险，并进行演练。
对
错
在出现交易未明时,可以通过如下模式进行交易的重试:（）
A.如果业务服务明确成功或失败，应该终止重试。
B.如果业务服务首次未明，立即重试。
C.如果业务服务系统繁忙，等待重试。
D.根据一定“频度”尝试获取交易状态,并进行重试,但需要由对交易防重幂等的控制。
对于事务一致性的异常场景，可以（）：
A、使用衰减方式发起重试或查询。
B、关注后台提供的是防重机制还是幂等机制。
C、如果冲正返回处理中,则应该继续发起冲正。
D、完成重试如果还不能获取结果,则应通过交易核对兜底。
文件传输完整性与合规性要求，产品作为文件发送方需要（）
A .在进行文件传输时，产品要判断文件传输状态是否正常，例如FTP PUT完成应该返回226，结果返回425，就代表文件传输异常，抛出异常。
B .程序捕获异常后要结束此次传输，进行报警，对报警处置后重新发起FTP PUT传输文件。
C .如果文件传输后需要对文件进行重命名，也要判断重命名是否成功，如果重命名文件报错，需要报警应急处置，重新传输文件并重命名。
D .文件发送方只要把文件传输给接收方即可，文件内容是否正确由文件接收方保证。
文件传输完整性与合规性要求，产品作为文件接收方需要（）
A.在进行文件接收时，包括外部第三方文件，产品必须要有业务场景的基本判断。
B.业务要求接收的文件不能为空，例如监管报送类文件，必须对文件是否为0字节，是否为空做判断，对于文件头尾信息、文件结束符、笔数是否符合、最后一笔是否完整、关键栏位是否缺失、每笔记录的栏位数据合法性校验都要考虑在家监控报警内。
C.接收的文件80-90%大部分情况不能为空，此种情况如果接收的文件为空，在监控实施中，就要断批，进行报警，进行应急处置，和文件发送方沟通后，要求重新传输文件。
D.文件有时为空，有时不为空，文件为空符合某时点的业务要求。这种情况要对空文件的合规性进行校验，在监控实施中，不合规进行报警，进行应急处置，查看空文件是否正常。
密码密钥与数据保护重点要求包括（）
A、应用系统应采用密码技术保证金融数据4级及以上的数据在存储过程中的保密性。
B、使用数字签名或者信息摘要技术,对存储过程中的金融数据4级及以上的敏感数据进行完整性校验。
C、在传输过程中,应用系统应采用对称加密等密码技术对金融数据4级及以上的数据进行字段级端到端加密,并应保障传输过程的机密性和完整性。
D、应用系统应确保金融数据2级及以上的数据在中国银行网络以外的传输过程中以加密形式存在。
E、用于访问系统资源的系统用户密码密钥（含FTP访问）必须加密保存在配置文件中。
接口的状态不包括：（）
A. 开发基线
B. 功能测试基线
C. 正式版本基线
D. 下线
E. 取消
谁对接口调用关系负责:（）
A .发布方?
B .订阅方?
C .发布方+订阅方
D.项目经理。
对于文件传输监控的要求包括（）
A.文件接收方对文件晚到的情况必须进行监控和报警
B.文件的批量处理必须进行处理时长的监控和异常报警
C.文件发送方必须对文件是否正确传送到文件接收方进行监控报警
交易堵重有多种形式,具体包括:（）
A.交易幂等机制
B.交易幂等是指交易服务方使用全局流水号/UUID等键值进行防重的判断,具备防重处理的能力。
C.交易防重机制
D.交易防重是指交易服务方提供接口、方法或服务在多次调用时返回首次处理的结果,交易调用方可以自身业务处理逻辑进行判断处置。
堵重机制的差异性，交易幂等与交易防重使用的主要区别:（）
A.目的不同:防重的目的是防止重复数据的产生,确保相同的数据只会被处理一次,从而避免不必要的重复操作或产生错误的结果。而幂等的目的是保证重复执行的操作不会改变结果,即无论进行多少次相同的操作,最终的结果都是一致的。
B.关注点不同:防重的关注点在于请求或数据的唯一性,确保数据不被重复处理。而幂等的关注点在于结果的一致性,即多次执行同一操作应得到相同的结果。
C.防重侧重于防止数据和请求的重复处理,而幂等则侧重于保证操作结果的一致性和可预测性。
D.交易幂等和交易防重最大区别是交易防重必须实现，交易幂等可以不实施。
对于交易一致性与堵重机制的整体要求是（）
A.应用系统如涉及交易一致性要求,应优先使用幂等机制进行交易堵重。
B.原则上应用系统完成信创后,交易接收方应按照幂等机制对外提供服务,并且应该使用技术中台提供的幂等公共机制.。
C.交易堵重机制不仅涉及联机场景,也涉及批量业务场景,在系统设计时均需考虑。
D.如果机制调整出现影响生产安全、影响系统性能等特殊情况,可以一事一议进行审核,由产品组提交申请至产品架构师审核。
堵重机制的主要应用场景有（）
A. 客户端交易提交防重:基于Token机制等对客户发起交易进行堵重。
B. 批量文件的防重:在文件处理时,关注文件的完整性以及文件的一致性。
C. 批转联的防重:交易请求方需要针对批转联的交易处理状态进行记录,审慎的进行交易的重试。
D.普通联机交易的防重:上下游系统确认交易未明的结果,并根据具体的幂等与防重机制,选择后续的处理模式。
在信创改造过程中,交易异常的场景较多,其中比较典型的场景和影响包括:
A.交易未明:因为网络原因导致的系统间信息传递失败,或者发生交易堵塞,导致在超时时间内未收到交易应答结果。
B.补偿失败:应用自身或中台自检时,在红线节点前进行UNDO处理,或者在红线节点后进行RETRY处理失败。
C.交易未明:获取不到交易状态,无法确认交易结果,对于交易结果敏感的系统无法确认结果,导致对客服务未明。
D.补偿失败:无法到达交易终态,导致本交易被挂起,后续可能需要基于人工处置才能到达终态。
对于事务一致性的解决手段（）
A.主要基于联机与批量两种模式
B.联机包括查询、重试、补充（正向或逆向）
C.批量包括交易交易核对
D.主要由业务手工进行调账
业务系统在交易未明时的处理要求有（）
A.需要通过不断重试、查询等手段获取交易终态,并关注交易核对的结果,用于调整自身交易终态。需要注意幂等与防重的使用。
B.对于不能接收未明交易结果的系统,需要调整支持对交易未明的处理,通过重试、查询、交易核对等手段获取终态。
C.对于通过发起冲正试图回滚交易的系统,需要关注冲正是否真正成功,特别是针对返回处理中的冲正返回,需要特别关注。
D.如果当日无法获取交易状态,则针对金融类交易,可以采用交易核对的方式作为兜底验证手段。
对于交易推定叙述正确的是（）
A.针对核心系统返回交易未明或者无应答的情况,由外围系统根据交易的借贷记方向和业务场景决定是否进行交易推定。
B.主要原则为：银行侧无资金风险。借记类交易推定失败;贷记类交易推定成功。
C.后续处理:根据交易核对结果调整推定状态。
D.交易推定主要由核心系统实施。
下列属于分布式交易未明的原因是（）：
A.对于网络原因导致的系统未收到请求方返回信息,或者虽然收到应答,但应答为交易未明。
B.对于由于系统应用处理时间过长（例如交易堆积）,超过超时时间导致上游收到的未明。
C.目前无法识别JVM中哪些进程为业务线程,不能精确结束超时的线程。对于分布式系统来说,无法在明确时间内保证交易可达到终态。
D.由统一的应用服务器进行交易的处理,典型场景如主机核心,通过CICS和DB2的机制实现交易的成功/失败处理,交易在一定时间后可以到达终态。
交易的强一致性在分布式事务中难以保障,应考虑实用最终一致性兜底，方案包括（）：
A.查询:调用查询接口,尝试获取交易状态,并更新本系统状态。
B.补偿:分为正向补偿与逆向补偿。正向补偿:通过通知类模式,努力促使交易完成。逆向补偿:通过冲正、回滚等模式,努力撤销原交易。
C. 重试:进行交易重发,配合幂等防重进行检查与控制。
D.由业务人员手工进行兜底。
红线设置的主要原则包括:
A. 对于非金融类交易,将红线设置在主体流程完成后,提升交易整体处理成功率。
B. 对于金融类交易,需要确保在交易未明情况下,不出现银行侧短款的情况。
C. 对于正向金融类交易:（特殊情况单独商定）• 单边交易:设置在动账环节,一般在完成动账处理后,一般不进行交易的回滚。• 多边交易:设置在贷方,如果贷方失败,则需要对借方进行回滚。
D. 对于正向冲正类交易:将红线节点设置在第一个事务节点,避免出现冲正的Undo。
E. 对于Undo类交易:目前和冲正的红线设置规则一致。
针对金融交易,如果在联机或者批转联场景中,出现交易未明或者单边交易的情况，应进行交易核对（）
A、对于涉及行内与行外核对的场景,一般有对接系统或者专用的业务系统进行交易的核对。
B、对于行内系统之间的交易核对,一般基于T-TCE完成交易核对。
C、基于T-TCE生成的报表（通过C-CRP与P2）,由业务人员在终端进行检查。
D、基于T-TCE生成的核对结果（通过P6下传）,由系统订阅交易核对结果文件进行交易结果的展示。
假设你是一位IT工作者,针对一个转账场景,客户A将资金转给客户B,如何合理设置红线节点?（）
A. 信息查询节点
B.预检节点
C.借记交易节点
D.贷记交易节点
E.数据报送节点
交易一致性处理的技术手段:（）
A.实时（同步），包括交易重试、实时补偿
B准.实时（异步），包括交易通知、交易补偿
C.跨日核对（不晚于D+2），交易与账务核对、单边账手工调整
D.业务人员报表处理
关闭
更多问卷
复制此问卷