那么这个活动中，很关键的一个问题是：系统如何准确的知道在比赛结束10分钟后的结果；基本思路有两种：
一，一个人值班，实时观察比赛，一旦有结果，马上录入系统；
这个方法的好处是：不容易出错，因为是人工确认后录入的，但最大的问题是需要一个人通宵值班，如果同时几场比赛呢？所以运营成本比较大。
二，没错，大家肯定想到了，是不是有某个接口可以实时查询比赛结果，如有，系统可以开发一个批跑脚本，定时去查这个接口，比如10s一次，一旦发现有新的结果，则更新我们系统的比赛结果。
perfect，看起来很不错，但请慢，这里是否有哪些陷阱？比如：
1，如果接口失败呢？即关键时候查不出来？
2，接口服务正常，但返回的结果是错误的，这个可能更致命，特别是业务关键路径严重依赖这个准确性的时候，比如购买彩票
针对这些问题，基本的思路是：
1，对接口进行定时的监控，一旦服务不可用则及时告警，当然这只是提前发现问题的第一步，但是否能够及时解决问题，可能依赖于发现问题后的沟通协调效率等；
2，服务的接口尽量不要存在单点，提供类似集群模式的查询接口，则可以大大降低接口失败的概率；
3，接口服务正常，但返回的结果是错误的，这个大家可能觉得这不可能吧？但笔者恰恰遇到了，接口提供方中间做了系统变更发布，引入了bug导致结果被回溯或者重置，这种问题的解决思路是：既然拉一个地方可能出现问题，那么为什么我们不同时从几个地方拉取比赛结果呢？比如拉取不同公司的接口进行比对，如果都一致，则我们认为出问题的可能性就小很多，这个结果是可信的，至于具体需要拉几个接口进行比对，这个看条件了，当然至少是2个，好的可以3个，太多可能意义也不大，反而使得逻辑变复杂。那么假如我们是使用了3个接口，如果比对结果是一致的，则没问题，如果不一致呢？如何处理？这个时候可能没其他的办法，需要人工确认了，当然具体的开发中，需要处理的细节还是比较多的，比如三方的时间不同步或者更新的节奏不一致，可能存在一定的误差。
ps：其实好的接口是支持事件回溯记录的方式是最好的，是什么意思？即接口返回的不是当前的及时状态，而是一些列进球的时间点和进球比。
4，还有一个重要的问题：既然后续的服务严重依赖这里的准确性，如果我们的比赛更新结果被绕开了，即有人随便修改了db的结果，那怎么办？ 这里有许多的思路，当然最基本的是db核心数据需要防篡改保护，合法的脚本进行更新数据的时候，会对比赛的结果进行签名，而数据的使用者在使用前，需要验签。