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