在后端产品的世界里，各子系统之间，或与外部系统之间的对接非常常见，对接的本质是为了实现数据信息的传输。

系统间数据传输的方式主要有接口传输、数据库传输、文件共享传输、消息队列方式传输等，以上在另一篇文章中已经有所介绍。本文仅关于获取数据之后的运算逻辑、异常机制等，在这里做具体的举例探讨。

一、触发式和定时任务方式获取数据

数据获取的方式，一种是操作事件触发，比如点击页面按钮，则触发传递最新数据。

这种的时效性比较高，但是也会由于并发而增加系统负荷。

如果对时效要求不高，就可以采用另一种方式，即定时任务方式获取数据。

定时任务在后端产品中是很常用的。就是建立起一个脚本，然后布置到定时任务管理系统上，按一定的频率，从数据生产方查询满足条件的数据，并进行数据推送或者拉取操作。

定时任务获取数据示意图如下所示：

如上图所示，“定时任务”即按照一定的频率，查询“数据提供方”的数据源中，满足条件的数据（如图中的“数据4”和“数据1”），并获取到“数据需求方”。

定时任务的方式，可以从增量数据中查询满足条件的数据，比如：

设定每次获取6小时内更新的数据，获取频率为6小时一次（注意：该例子中，执行的时间间隔不能大于6小时，以避免遗漏）；

也可以从全量数据中查询，比如：定义表字段“is_got”为“是否已获取”，初始值为否，每次获取表中“is_got”为否的数据。

注意这种方案下，“is_got”是要做表索引的，这样每次遍历数据库的时候才不会影响运算速度。

二、数据获取和应用是否异步执行

上文提到的“触发式和定时任务方式”，是获取数据时候的机制，那么获取之后，写入或应用的时候，也可以设计适合的机制。

一般而言，如果获取数据后还要在本地进行规则运算或数据处理，那么最好先落地到本地的中转表，再由中转表写入最终表或参与运算，也就是将数据的获取和应用异步进行。

异步执行如下图所示：

看下面的例子：

需求：按照“订单+包裹号”维度，从物流系统获取包裹的运费到财务系统，然后财务系统再将该运费分摊到该包裹的商品上面，算出每个商品分摊的运费金额。

如果采用从获取数据到分摊运算一步完成的话，那么一旦因初始数据不准确或者算法BUG导致结果出错，想要追查错误原因并修复数据，就需要追溯到数据提供方，耦合性和复杂程度就很高。

所以对这种含有复杂运算的场景，建议采用异步机制：

即在进行分摊之前，先落地到财务系统的中间表中。然后待获取数据完成，再启动第二个独立的机制，进行分摊并最终写入。

总的来说，异步处理数据的获取和应用，一方面方便追溯异常问题，另一方面减少系统或功能之间的藕联；同时它作为一个基础数据，存入本地也可以被其他功能调用。

在获取的数据若数据量万级以上，或运算逻辑复杂的，只要时效性允许，建议都采用异步机制。

三、判重机制

数据通道搭建好之后，系统间的数据流往往是持续的传输。由于各种原因，常常同一条数据可能会多次被获取到。

这种情况下，是新插入该数据、覆盖原数据，还是更新旧数据呢？

在确定这个机制之前，首先要先确定表关键字，即确定若干字段做为判断重复的标准。

比如，职工信息表字段：姓名+手机号+性别+家乡+身份证号。这几个字段中身份证号对一个职工是唯一的。因此如果我们更新这里的数据，就以身份证号为唯一标示。

当获取到数据库不存在的身份证号码，则插入该数据；获取到的身份证号在数据库中已经存在，而手机号不同，就可以更新数据库中该数据的手机号。

注意：若改变了表的去重字段，则需要考虑新数据对历史数据的影响，因为二者的判重维度不一样，可能会获取到和以前的历史数据冲突，但又不被新判重规则识别的数据。

四、记录数据获取日志

从其他系统的获取的过程，一般都要创建数据日志：目的是记录数据的来龙去脉，以便追溯。

数据对接的日志重点要记录三个事项：数据提供方是否提供了该数据、数据接收方是否接收到该数据、数据接收方是否写入了该数据。

在设定数据对接日志的时候，需要告知开发员是否将日志数据存到本地数据库中。

因为开发者后台本身是有一个系统运作记录的（Server log），只是保存时间不会太长，比如一个月就会清除了。

因此如果需要保留较长的时间，则可以将其保存到本地数据库。

小结

在后端产品工作中，技术与产品的交叉领域较多。后端产品经理需要深入了解这些边界知识，才能更好地完成后端产品的方案，提高沟通和需求实现的效率。

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家。书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交App。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议