系统间数据对接传输一篇给产品经理的万字总结：接口、otter、MQ、SFTP……

一个别系若很外向，不断撩拨周围的系统，也乐意被撩拨，成为了众系统中的“交际花”，那么这货基本便是中台的性子。

而更多的系统是介于上述两种极度之间的。

像人一样，自己搞生产，也要参与社交——便是系统之间的数据对接。

对接的实质是为了实现数据信息的传输。

在后端产品的天下里，各子系统之间，或与外部系统之间的对接非常常见。

作为产品经理，不仅要知道数据从哪来，还要理清楚获取数据之后的握手办法、运算逻辑、异常规则、容错机制、数据日志等等。

本文考试测验聊聊如下话题：

数据传输的场景和意义

数据传输的办法

数据传输的处理机制

数据传输的把稳事变

原文地址：系统间数据传输，产品经理视角的9千字总结：接口、otter、log4j、SFTP、MQ……

一、 数据传输的场景和意义1、数据传输的运用处景前端和后端本身无时不刻的数据互动。
公司的各个别系之间的信息共享。

比如，式系统支配之后，就须要各个别系模块之间进行数据的合营，比如订单系统的库存扣减数据要同步给备货系统进行采购。

与第三方平台的对接

比如入驻第三方发卖平台亚马逊之后，店家可能自己须要管理自己的订单，这时候就要从亚马逊平台获取订单数据，也便是抓取。

调用现成的公共插件

避免重复造轮子，市场上很多开放性的功能插件可以调用或接入，比如接入百度舆图的API，接入微信小程序的二次开拓。

2、数据传输的意义不重复生产数据库，避免资源和功能的摧残浪费蹂躏。
统一数据的掩护或生产源头，避免数据不同步。

比如同一个公司的两个别系都要用职员信息架构数据，如果各自都能掩护，势必涌现不一致，也摧残浪费蹂躏资源。

别人家的数据，自己没办法生产。
复用现成的轮子，API或SDK共享（可能自己也发明不出来）。

二、 数据传输的办法

数据传输的办法，作为产品经理我将其分为：接口传输、中间件传输、message办法传输等。
散开了说，比如：MQ（行列步队）、HTTP接口、otter、文件共享传输等。
每一种又有细分的办法和适宜的场景。

1、接口

这是一种传统的问答式的传输办法，是范例才c/s 交互模式。

相称于一台客户机，一台做事器（注：这里的客户机或做事器根据数据的供应方和吸收方相对而言的，并不一定是实际的）。

目前我们常用的http调用、java远程调用、webserivces 都属于这种办法，只不过，不同的便是传输协议以及报文格式的差异。

1）接口的浸染

通过接口，可以调用成熟的第三方功能插件为我所用（一样平常便是API接口），也可以根据实际需求由开拓写详细的接口代码办理详细场合的信息传输问题（一样平常所说的http接口）。

对后端产品经理来说，http接口的利用场景最多。
比如：公司先上线了OA系统，后上线了订单系统，订单系统须要同步OA系统的职员组织构造信息。
那么一个可行做法便是OA系统创建一个接口，订单系统要求，获取最新的职员构造信息。

这个笼统的方案描述中，包含了这么些信息：创建接口、要求接口、获取最新信息等，那么分别是什么以及有什么原则呢？下面分别谈论。

2）哪一方卖力创建接口？

在谈论需求的时候，开拓会问哪方创建接口呢？有时候产品经理只知道须要建接口，不知道哪个别系来建。

可以这样理解，如果把数据源比成一缸水，那么接口就像是凿的一个口，口只能是在缸上面的。

以是接口必须是在被要求的数据源这边，由被要求的一方定义接口。

把稳，这里的数据源是相对的数据源，便是被要求的一方便是数据源方。

实际上可能目标数据在要求方。
比如例子中也可以是OA系统要求订单系统，但是如果这样的话，接口便是订单系统创建了。
因此确切说是被要求的一方创建接口。

普通的讲就像是求婚：男方去求婚带一百万，女方接到后就把姑娘嫁过去，这是一来一回。

女方也可以去求婚，只是是直接带着姑娘去敲开男方的门，而后男方才把一百万送到女方，这也是一来一回。

3）什么是定义接口

定义接口，实在便是定义缸上的出水口。
口的大小、滤网、放水的频率等，便是个规则。

这个规则约定了哪些数据是须要流过去，以及流过去的条件（像门禁密码一样）。

定义接口便是设定口令、数据范围、推送前的筛选、转化运算规则等，这是接口的核心内容。

4）数据在哪一方做转义？

某些时候，数据从源头到运用端不是原封不动的，而是转化了。
比如80分、90分都是及格，可能利用者只须要两个值：及格or不及格。

那么这就涉及到是在吸收之前就转化为是否及格，还是吸收之后自己转化的问题。

考虑的依据紧张是：该数据获取之后是否还有其他用途，只要有可能被二次利用，最好是取原数据。

提前转化的好处是，流转的数据会变得大略直接。
但是须要把稳的是转化后数据量不一定会少，比如：数据源是订单维度的，而目标是转化为订单+商品维度的数据，这就可能一条变多条了。

5）是主动获取还是对方推送

有时候开拓还会问是对方推，还是我们主动去取，这便是接口的post/ get办法问题。

get是从做事器方要求数据，post是向做事器方传送数据。
前面也提到了，接口交互数据可以是主动推送，也可以是要求获取。

主动推送一样平常是数据生产方一旦更新，则触发推送，将所需字段对应值通报过去。

要求获取便是数据需求方通报要求参数（要求参数一样平常是多少条件，比如：账号+密码）。
数据生产方则按照协议相应，给出知足条件的数据到要求方（也便是返回参数）。

以是可以看出来，如果对时效哀求高的，则建议生产方主动推。
比如产生一个新用户，那么就可以理解把用户的信息主动推送给运营方利用。

如果是时效不高或者数据量大，则可以按一定频率主动要求，有利于系统负荷压力稳定。

在详细利用的时候，如果你对接的系统比较多，那么建议做一个公共接口，往后谁想用他们自己来对接就好了，不然就要来一个对接一次，麻烦还有风险。

其余，选择post/ get，终极由双方开拓权衡决定，但是一样平常而言：

get传送的数据量较小，不能大于2KB。

post传送的数据量较大，一样平常被默认为不受限定。
get安全性非常低，post安全性较高。

6）接口定义是开拓的事情，但产品经理须要给出轮廓

在输出方案的时候，接口定义的规则是什么？传参和返回参数是什么？重复传参时是跳过还是再次获取（一样平常都再获取）？必传参数是什么？是否回传吸收结果给数据生产方？这些都是要有大致明确并传达给开拓测试的。

比如：每小时/次取对方表中第一页最新的50条数据。
超过的数据下个小时连续取。
可以这样设计：

由于一些关键参数牵扯到业务的唯一性维度，这些都在产品经理调研的时候获知的，而这些可能开拓根本不知道。
因此产品经理要给出轮廓和大概方向。

7）数据流转的时效

接口创建之后，如果是吸收的对方数据库中的信息，那么上线之后，要考虑前辈行数据的初始化（保持根本数据同等）。
然后确保后续双方是同步的。

同步的机制和哀求是在定义方案的时候就确定的。
那么怎么确保同步呢?方法是两种：触发式和定时任务。

触发式便是一旦一个参数值知足条件，则触发同步。

定时任务式一样平常用在不知道数据源什么时候更新，需求方就要设置一个定时任务的脚本，隔一段韶光查询一次。
要求的频率须要与更新的频率相折衷。

8）总结接口的特点

优点：时效性强，可以触发式实时问答。
随意马虎掌握权限，通过传输层协议https，加密传输的数据，使得安全性提高。
通用性比较强，无论客户端是.net架构，java，python 都是可以的。

缺陷：做事器和客户端必须同时事情，当做事器端不可用的时候，全体数据交互是不可进行。
当传输数据量比较大的时候，严重占用网络带宽，可能导致连接超时。
使得在数据量交互的时候，做事变的很不可靠。

9）干系观点扩展

API：即“运用程序编程接口”，是一些预先定义的函数，无需访问源码或理解内部事情机制的细节，即可调用的工具。
比如和Windows系统沟通，须要调用Windows供应得API。
和新浪微博进行沟通，须要调用新浪微博供应得Api。
实在它便是一个软件系统对其他软件系统供应得做事。

open api：是指对外开拓的接口，比如百度舆图API、facebook的API等。

SDK（“软体开拓工具包”）：可以理解为api的凑集，也便是封装后的API为，功能更完善。

http接口：是基于接口的传输办法（HTTP协议）来命名的，当然也有基于其他协议传输的接口。

比如：

和Windows系统沟通，须要调用Windows的API（CreateWindowEx, bitblt,等等），是C措辞函数形式的接口。

和.Net框架进行沟通，须要调用.Net供应得Api，因此C#，VB函数/类形式的接口。
和新浪微博进行沟通，须要调用新浪微博供应得Api，因此Http要求形式的接口。

API接口的叫法相对http接口叫法更笼统和观点化一些。
因此在写方案的时候，http接口和API接口都可以，在详细的场景开拓都可以理解的。

理解更多，也可以看下这本书：

2、数据库对库同步

接口完成的是信息的传输，相对来说比较守旧，易于保护敏感信息。
而数据库同步实际便是表对表的共享，相对接口就大方多了，因此多发生在企业内部两小无猜的系统之间。

数据库同步有这么几种办法：

1）利用中间表

例如：B系统要用A系统的数据，可以新建一个数据库DB，A系统将数据写入DB，B系统再到数据库中读取数据。

也便是将数据放进一个中间表中，A、B两个别系都对这个表有访问权限。
这样的好处便是选择性地将一大批数据共享出去。

2）直接调取对方数据表

这个办法便是在B系统在开拓时，在代码中加载A系统的数据表，直接从数据表中取数据。

这便是实时拉取对方的数据，B系统自己本地不做表保存。
比较省，事但是耦合性较大，数据量大的时候不建议。

3）同步对方的数据表

直接将对方的数据表copy一份过来，并保持实时同步，otter技能便是常用的一个方法。

otte可以将mysql的数据同步至其余mysql或者oracle，也支持双向同步（即A库同步给B库，B库也同步给A库）、文件同步等，紧张运用运用是多数据中央、BI系统抽取数据、灾备。

该办法须要DB帮忙配置。
也便是做了一个mysql的同步平台（带WEB管理界面），在界面上，你可以定义相应的映射规则，otter进程就会根据你定义的规则读取binlog，并更新到目标库中去。

该办法紧张用于内部系统之间（一样平常一个公司的才这样）库对库的传输，可以实现数据的相互同步更新。
建议运用在数据量大的时候，或者根本数据对周边兄弟系统供应根本支持的时候。
优点是占用资源少，交互更加大略可靠。

当连接B的系统越来越多的时候，由于数据库的连接池是有限的，导致每个别系分配到的连接不会很多，当系统越来越多的时候，可能导致无可用的数据库连接。

这时候otter比较适宜。
而两个不同公司的系统，不太会开放自己的数据库给对方连接，由于这样会有安全性影响。

3、文件包共享办法

一些第三方公司为了保密，不愿意供应接口，那么会把文件存在类似网盘或网页上，供需求方下载。

双方系统约定文件做事器地址、密码、文件命名规则、文件内容格式等，通过上传文件到文件做事器，进行数据交互，对大数据量的也很适宜。

这便是一种异步的上传下载机制，双方的操作割裂开，并且一旦上传可以被多个需求方利用。

比如：第三方支付公司与需求方约定好SFTP做事器（一种文件做事器，可以理解为网盘）的账号密码，然后支付公司将账单数据上传到SFTP做事器上，那么需求方就可以上岸SFTP客户端，进行下载、解析，然后保存利用。
这也实现了数据在做事器之间的传输。

实际上这些数据本身也是加密的，以是只有协议的公司才能拿到解码钥匙。
长期互助的公司就会持续更新，授权的公司就可以持续下载和解析。
这里就有一个下载频率的问题，一样平常利用定时任务按一定频率去下载。
并且要考虑丢包的机制。

案例：

到SFTP做事器抓取并解析WP支付平台的账单明细，方案如下：

到SFTP做事器找到文件路径，筛选出须要的类型文件，打开文件，按规则解析所需的字段，对应写入本地数据表。

脚本实行逻辑：每次抓取路径下‘修正韶光’为前一天的文件。
（这里有个隐患：如果出了故障，可能某天的数据就漏了）。

问题：怎么防止丢抓呢？

剖析：由于是外部数据，以是这里无法对源数据做“是否被抓取过”的标注。
因此建议防丢方案是增加断抓补抓机制。

断抓补抓机制：比如4号抓了修正韶光为3号的数据。
5号断抓，则6号连续抓取4、5号的数据。
断抓补抓的机制便是说一旦某一天的数据中断了，创造不连续，那么系统就自动不才次重新抓一次，看看是否能补上。
直到三次都未取到。
则不再补救。

该方案可以降落我方抓取故障导致的抓空情形。
有时候开拓

4、行列步队MQ（Message Queue）

1）MQ观点

行列步队技能是分布式运用间交流信息的一种技能。
目前市场上有很多开源的jms中间件，比如ActiveMQ, OpenJMS。

大略说便是一方不断把信息推到行列步队中，像排队进隧道一样，另一方依次消费这些信息。
行列步队可驻留在内存或磁盘上，行列步队存储直到它们被运用程序读走。

该办法更适用于公司内部，数据量大，规律性强，批量往来的数据。
紧张办理运用解耦，异步，流量削锋等问题。

2）以异步处理举例解释

用户注册后，须要发注册邮件和注册短信。
传统的做法有两种：a.串行的办法；b.并行办法

a、串行办法：

将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。
以上三个任务全部完成后，返回给客户端。

b、并行办法：

将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。
以上三个任务完成后，返回给客户端。
与串行的差别是，并行的办法可以提高处理的韶光。

假设三个业务节点每个利用50毫秒钟，不考虑网络等其他开销，则串行办法的韶光是150毫秒，并行的韶光可能是100毫秒。

由于CPU在单位韶光内处理的要求数是一定的，假设CPU1秒内吞吐量是100次。
则串行办法1秒内CPU可处理的要求量是7次（1000/150）。
并行办法处理的要求量是10次（1000/100）

小结：如以上案例描述，传统的办法系统的性能（并发量，吞吐量，相应韶光）会有瓶颈。
如何办理这个问题呢？

引入行列步队，异步处理。
改造后的架构如下：

按照以上约定，用户的相应韶光相称于是注册信息写入数据库的韶光，也便是50毫秒。
注册邮件，发送短信写入行列步队后，直接返回，因此写入行列步队的速率很快，基本可以忽略，因此用户的相应韶光可能是50毫秒。
因此架构改变后，系统的吞吐量提高到每秒20 QPS。
比串行提高了3倍，比并行提高了两倍。

在设计方案的时候要把稳非常情形的处理机制。
比如：首次消费失落败？

如果第一次数据消费的时候，无法识别没有匹配上，但是又想下次再消费一次看是否匹配的上怎么办？可以设定机制：无法识别的则重新插到行列步队后面连续推送。

如果一贯循环仍消费不掉信息积压怎么办？

设定处理机制：超过一定积压数据量或者循环韶光过长则进行报警。

3）MQ、文件包共享、接口的比拟

MQ推送过去之后，是否推送成功无需对方再用MQ返回，由于推到中间站就意味着我方能做的事情已经做完。

而接口是一来一往才知道是否成功的，也便是要返回一个信息。
这点与mq是不一样的。
但是如果非要对方再返回是否接管成功的话，那么就要做反向MQ，这相称于另一个独立的MQ。

文件包共享也不须要反馈机制，因此传到了文件做事器之后，数据方的事情就做完了。

行列步队的一个信息只能被消费一次，不同系统不能共同消费一个行列步队。
因此如果对接多个别系则要多次创建MQ。
而接口可以创建一个，让其他很多系统调取。

在订单系统对接各个发卖网站和平台的时候就可以采取这样的机制，避免多次对接。
文件包共享也是可以上传一次，供多个需求方下载。
这点和接口有相似之处，是MQ所不具备的。

5、其他手段

数据传输包含了数据信息的获取和写入，实在除了线上的自动机制，还有很多土办法，在后端产品系统中也是常利用的。

1）导入导出

场景：没有办法做系统之间的对接，但是线下能得到数据。
数据量不太大，且有规则数据。
则可以通过导入的办法。

文档一样平常用csv格式，该格式文件较小，兼容性好，然后须要定义好excel表格对应字段的关系，比如A列对应字段‘name’，B列对应字段'age'。

上传时须要对文件考验，比如格式不对、必填项为空等，建议一旦一处缺点，就全部不予导入。
并返回缺点提示，修正后连续导入。

若数据太大（与做事器的性能也有关系，比如超过一万条），可以采取异步上传机制，便是上传之后不立即实行写入，而是后台自动分批写入。

2）爬取

作为数据需求方，获取数据可以通过协商接口的办法、SFTP解析的办法、或者直接爬取的办法。
比如须要获取第三方网站牌号库中最新牌号名称、注册地、logo、授权期限等信息，如果该网站不给于开放的接口授权，可能就须要我们开拓写爬虫代码爬取（当然有的商业数据也是带有反爬机制的，这就看谁道高一尺魔高一丈了）。

三、数据传输的处理机制 1、数据同步的触发机制

前面提到了数据获取的办法，那么数据获取频次或者触发机制是怎么样的呢？这要根据运用处景来设定方案，但是一样平常都是哀求持续获取的。

一种办法是操作事宜触发，比如页面的按钮点击则触发通报最新状态。
这种的时效性比较高，但是也会由于并发而增加系统负荷。

如果对时效哀求不高就可以采取异步机制。
比如利用脚本监控。
设定脚本的运行频率，当读取到更新韶光为频宽内的数据，则将其捕获并传输。
定时脚本也叫定时任务等。
定时脚本在后端是很常用的。

比如说每次获取A系统6小时内更新的数据，那么每2小时取一次的话是没问题的。
但是若每7小时获取一次就会漏掉1小时的数据。
因此一定是每次获取的数据韶光区间，要高于数据获取的韶光间隔。

当然用韶光是一种维度，更安全的是用标示性字段。
比如每次获取is_got为0的数据。
前台是is_got做表索引（索引前面讲到过），这样遍历（遍历约即是全表查询）数据库的时候就不会太慢。

2、是否异步实行数据处理

如果获取后还要在本地进行规则运算，则最好先落地到中间表，再由中间表写入终极表。
也便是异步写入。

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

这时候就很随意马虎出错，由于分摊规则是个算法，算法就带有规则的可变动性。
一旦分摊规则的参数不准确，或者算法构造变革，都会导致终极分摊的运费金额缺点。
那么这时候追查缺点缘故原由并修复数据就很麻烦。

以是在进行分摊之前，先落地到财务系统的临时表（中间表）中，然后获取数据完成。
再进行写入分摊运费的操作。

除了上述方便查缺点缘故原由外（有种数据洗濯的意思），这种异步操作同时也确保了较少的偶联，不至于一个环节出错，则联动出错。
同时它作为一个根本数据，也可以被其他功能调用。
若数据量万级以上的，必须这样做。

3、判重机制

数据通道搭建好之后，数据流每每是持续获的。
而数据源在别人那里，可能会被增编削，因此常常有相似或干系的数据进来。

在写入本地表的时候，不管是覆盖、更新还是插入，都因此确定多少字段做为判重的标示为前题的。

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

比如获取到同一个身份证号的手机号与我们的数据库的不同，则更新。
碰着我们的数据库不存在的身份证号码则插入。

某些时候无法确定那几个是唯一字段，则可以添加一个备用字段，人为定义其取值规则，然后作为去重字段，比如这个字段叫unique_code，取数据源表的主键+日期，（或者直接就取源表的id，也便是外键）。

有了判重字段（也便是数据唯一的字段），就可以进行更新、插入或者跳过规则设定了。

把稳:若一段韶光之后，改变了表的去重规则，则须要考虑到历史数据对新数据的影响，由于二者的判重维度不一样，可能会进来和以前的历史数据冲突的交叉数据。

4、获取到数据之后，如果利用?

一种是直接在页面展示，不保存在本地数据库中。
相称于每刷新一次页面则通过接口调取一次对方的数据展示。
但这种从性能和场景上都是比较少的，一样平常都是先保存到本地数据库上，自己本地各种调用。

对付先保存到本地的情形，有两个问题要考虑：是否异步保存，和如何确保同源同步。

5、处理日志

数据日志：目的是记录数据的来龙去脉，追溯以剖析问题。

日志要记录三个紧张事变：数据源系统是否供应数据、目标系统是否吸收到数据、目标系统是否写入了数据。

产品经理见告开拓加数据捕获日志的时候，须要奉告是否存到表里，由于系统一样平常都有一个类似缓存一样的日记，只是会定期清理的。
只有保存下来才能一贯记录和追溯。

开拓后台本身是有数据log日志的，由于log4j开源代码定义了5个紧张级别的log：FATAL、ERROR、WARN、INFO、DEBUG，一样平常情形下，开拓都会自觉配置INFO或DEBUG级别的日志，以方便查数据。

但是代码中的kog保存韶光不会太长，比如一个月就会打消了。
因此如果须要保留的韶光长，则可以将其保存到本地数据库。

根据演习须要，存了数据库就可以做成页面，展示给用户看，比如可以从以下维度展示：

四、数据传输的把稳事变1、目标数据表最好和中间表的维度同等

假设从A系统获取的数据存入B系统，先落地到中间表b，然后经由一些列运算后将数据从b写入到b'表。

把稳b和b'表的去重字段要对应起来，并通报下去。
由于维度相同，做到一对一，方便实现非常数据溯源。

2、不同入口写入同一类型数据时，如何与自身入口的数据去重，且与其他入口的数据相互去重？

案例：

有新旧两个不同的写入程序，写数据到利润表，写入的都是‘退件入库’利润类型，是殊途同归。
不巧的是两个写入入口各自有本身的去重规则，彼此去重的规则不能通用：假设入口1对应的去重字段是A+B，入口2写入的去重字段是B+C。

这就意味着同一个数据如果分多次写入，有可能从两个入口都会写入。
如何实现避免重复写入是核心问题。

我们首先考虑的是，如果一条源信息从一个入口已经写入了利润表，那么就不能从另一个入口再写。

其次，如果从入口1写入一次，那么后面源数据更新再次触发写入的时候（判重，确定是插入还是更新），就还要从入口1写。
也便是一旦从一个入口写入，后面该数据的变更触发的再次写入也只能从这个入口连续变更。

只有这样才能担保这个数据不重复。
好比先找到是哪家的孩子，再确定是第几个孩子，且只能是基于这家内部去确认。

方案一：比如入口1碰着一个待写入的数据，则先按自己的去重字段A+B校验。
如果创造不存在该数据，则再按照入口2的去重字段B+C（这个事先是知道的）判断是否存在，若也不存在，则回到入口1写入。
若存在，则入口1不在写入，且结束进程（由于入口2会触发写入该数据的）。

方案二：比如入口1碰着一个待写入的数据，则先按入口2的去重字段B+C校验。

查看对方入口下是否有重复数据，有，则本入口不写（连续按对方的路径写）；无，则自己的路径写。
显然方案二的判断路径更短，相对好一点。

3、同步根本数据的时候是否提前过滤

这个在上面内容中也提到过。
比如：A系统掩护了员工的根本信息，个中有个状态为【是否有效】，只有有效状态的才能在全体系统中看得到才是生效的。
B系统要取用员工信息的数据，但不做数据掩护。
那么是否只取启用状态的数据到B，还是不区分状态都取呢？

答案是：在数据量差异不大的情形下，取全量。

缘故原由之一便是，若启用状态的用户忽然被A系统禁用，那么可能该用户在B系统的生产数据报错，这时候到中间表看状态就可以看出来问题，而不需跨系统或跨部门沟通查证。

阅读原文：系统间数据传输，产品经理视角的9千字总结：接口、otter、log4j、SFTP、MQ……