一、关于前置机的报警机制：
    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.关于前置机调用频次
     不管是目前的单线程还是将来开通多线程并发，银行提供的资源总是有限的，而业务情况，账号的交易情况是千变万化的，不可预估的。我的建议是在能满足业务需求的情况下应该避免过多无效的查询，节约查询资源，而不是动辄就全部轮询所有账号。