互联网金融平台——银行交易明细查询和报警机制

一、关于前置机的报警机制：
    1、通道组每日巡检前置机的运行是否出现假死等问题，巡检每两个小时一次，上午10点至晚八点；
    2、关键词监控，已经出现过假死的前置机或者usb不能识别的银行前置机，通过日志监控系统及时报警。
    3、zabbix 报警，只能监控到前置机宕机，不能监控到假死和usb不能识别。
以上方案是都只是借助外部力量，针对以上不足，开发小组后续根据各个通道的假死或者usb不能识别的实际情况，我们自己做短信和邮件报警。
二、关于交易明细查询：
1. 接口使用分析
    1) 浦发的查询是单线程单账户间隔20秒轮询账户交易明细接口。每天是86400秒，86400/20=4320。也就是说浦发账户交易明细查询接口【4.4账户明细查询（8924）】理论上一天最多支持4320个账号查询交易明细，再考虑分页的情况，肯定到达不到这么多就轮询不过来了；
    2) 不管查询T日还是T-1的交易明细，在账户达到4320时，肯定是轮询不完
  综上，查询次数有限，需要有节制的使用。
2. 避免当日交易明细无效查询的建议策略
    1) 在企业结算支付成功之后的账号，发起交易明细查询；
    2) 余额比较法，用余额是否变动来判断账号是否存在交易。账号余额与上一次余额做比较，如果有变化，则发起查询，如果没有，则不查。当日账号余额查询，银行的接口支持批量查询，效率高于当日交易明细查询。 这种方法的弊端是借贷金额相等，有交易发生时不能及时查询。可以在T+1日的时候使用日终明细获取（9003）弥补；
    3) 针对分页查询，从上一次结束的页数开始查询。每个银行返回的交易明细都是有序的，在企业结算发生交易或者余额出现变动，从上一次查询结束的地方开始。 
   综上，如何有节制的减少查询次数。
3. 接口使用策略
     比如浦发银行，日终明细获取（9001），日终明细获取（9003），日间账户明细下载（9004）都是可以使用。没有必要所有场景的交易明细查询都挤一个接口。
4.关于前置机调用频次
    不管是目前的单线程还是将来开通多线程并发，银行提供的资源总是有限的，而业务情况，账号的交易情况是千变万化的，不可预估的。我的建议是在能满足业务需求的情况下应该避免过多无效的查询，节约查询资源，而不是动辄就全部轮询所有账号。