跨系统数据对接的相关机制

　　在后端产品的世界里，各子系统之间，或与外部系统之间的对接非常常见，对接的本质是为了实现数据信息的传输。
　　系统间数据传输的方式主要有接口传输、数据库传输、文件共享传输、消息队列方式传输等，以上在另一篇文章中已经有所介绍。本文仅关于获取数据之后的运算逻辑、异常机制等，在这里做具体的举例探讨。
　　一、触发式和定时任务方式获取数据
　　数据获取的方式，一种是操作事件触发，比如点击页面按钮，则触发传递最新数据。
　　这种的时效性比较高，但是也会由于并发而增加系统负荷。
　　如果对时效要求不高，就可以采用另一种方式，即定时任务方式获取数据。
　　定时任务在后端产品中是很常用的。就是建立起一个脚本，然后布置到定时任务管理系统上，按一定的频率，从数据生产方查询满足条件的数据，并进行数据推送或者拉取操作。
　　定时任务获取数据示意图如下所示：
　　如上图所示，定时任务即按照一定的频率，查询数据提供方的数据源中，满足条件的数据（如图中的数据4和数据1），并获取到数据需求方。
　　定时任务的方式，可以从增量数据中查询满足条件的数据，比如：
　　设定每次获取6小时内更新的数据，获取频率为6小时一次（注意：该例子中，执行的时间间隔不能大于6小时，以避免遗漏）；
　　也可以从全量数据中查询，比如：定义表字段isgot为是否已获取，初始值为否，每次获取表中isgot为否的数据。
　　注意这种方案下，isgot是要做表索引的，这样每次遍历数据库的时候才不会影响运算速度。
　　二、数据获取和应用是否异步执行
　　上文提到的触发式和定时任务方式，是获取数据时候的机制，那么获取之后，写入或应用的时候，也可以设计适合的机制。
　　一般而言，如果获取数据后还要在本地进行规则运算或数据处理，那么最好先落地到本地的中转表，再由中转表写入最终表或参与运算，也就是将数据的获取和应用异步进行。
　　异步执行如下图所示：
　　看下面的例子：
　　需求：按照订单包裹号维度，从物流系统获取包裹的运费到财务系统，然后财务系统再将该运费分摊到该包裹的商品上面，算出每个商品分摊的运费金额。
　　如果采用从获取数据到分摊运算一步完成的话，那么一旦因初始数据不准确或者算法BUG导致结果出错，想要追查错误原因并修复数据，就需要追溯到数据提供方，耦合性和复杂程度就很高。
　　所以对这种含有复杂运算的场景，建议采用异步机制：
　　即在进行分摊之前，先落地到财务系统的中间表中。然后待获取数据完成，再启动第二个独立的机制，进行分摊并最终写入。
　　总的来说，异步处理数据的获取和应用，一方面方便追溯异常问题，另一方面减少系统或功能之间的藕联；同时它作为一个基础数据，存入本地也可以被其他功能调用。
　　在获取的数据若数据量万级以上，或运算逻辑复杂的，只要时效性允许，建议都采用异步机制。
　　三、判重机制
　　数据通道搭建好之后，系统间的数据流往往是持续的传输。由于各种原因，常常同一条数据可能会多次被获取到。
　　这种情况下，是新插入该数据、覆盖原数据，还是更新旧数据呢？
　　在确定这个机制之前，首先要先确定表关键字，即确定若干字段做为判断重复的标准。
　　比如，职工信息表字段：姓名手机号性别家乡身份证号。这几个字段中身份证号对一个职工是唯一的。因此如果我们更新这里的数据，就以身份证号为唯一标示。
　　当获取到数据库不存在的身份证号码，则插入该数据；获取到的身份证号在数据库中已经存在，而手机号不同，就可以更新数据库中该数据的手机号。
　　注意：若改变了表的去重字段，则需要考虑新数据对历史数据的影响，因为二者的判重维度不一样，可能会获取到和以前的历史数据冲突，但又不被新判重规则识别的数据。
　　四、记录数据获取日志
　　从其他系统的获取的过程，一般都要创建数据日志：目的是记录数据的来龙去脉，以便追溯。
　　数据对接的日志重点要记录三个事项：数据提供方是否提供了该数据、数据接收方是否接收到该数据、数据接收方是否写入了该数据。
　　在设定数据对接日志的时候，需要告知开发员是否将日志数据存到本地数据库中。
　　因为开发者后台本身是有一个系统运作记录的（Serverlog），只是保存时间不会太长，比如一个月就会清除了。
　　因此如果需要保留较长的时间，则可以将其保存到本地数据库。
　　小结
　　在后端产品工作中，技术与产品的交叉领域较多。后端产品经理需要深入了解这些边界知识，才能更好地完成后端产品的方案，提高沟通和需求实现的效率。