最近知识星球中有位小伙伴问了我一个问题:如何快速同步第三方平台数据?
他们有个业务需求是:需要同步全国34个省市,多个系统的8种业务数据,到他们公司的系统当中。
他们需求同步全量的数据
和增量的数据
。
全量的数据主要是针对多个系统的历史数据,大概有几千万数据,只需要初始化一次即可。
而增量的数据,是系统后续变更的数据。
这个需求其实不简单,至少有以下难点:
-
不能直接访问第三方数据库。 -
不能将历史数据导出到excel中,有泄露数据的风险。 -
如何快速同步历史数据? -
增量数据如何处理? -
接口需要做限流吗? -
增量数据如何校验数据的一致性?
带着这些问题,开始今天的文章之旅。
1. 如何快速同步历史数据?
想要快速同步历史数据,第一个想到的可能是直接同步数据库中的数据。
但多个第三方系统为了数据安全考虑,不可能直接把他们的数据库访问地址和相关账号密码告诉你。
即使他们告诉你了,但有很多个系统,你一个个去连数据库查数据,也非常麻烦。
有些小伙伴可能会说:这好办,让第三方系统把他们的历史数据导出到excel中,我们写个程序解析去这些excel,就能将数据快速导入到我们的数据库中。
这是个好办法,但忽略了一点:这些数据是敏感数据,不能对外暴露。
因此导出excel的方案行不通。
那么,该如何快速同步历史数据呢?
答:使用SFTP
。
不知道你有没有跟银行对接过,SFTP在银行业务中经常会用到。
那么,如何用SFTP同步数据呢?
2. 如何使用SFTP?
说起SFTP
,就不得不说一说FTP
。
我们都知道,FTP
是用来传送文件的协议。使用FTP实现远程文件传输的同时,还可以保证数据传输的可靠性和高效性。
而SFTP
是一种可以安全传输文件的协议,它是一种基于SSH(Secure Shell)的文件传输协议,它允许用户将文件以加密的形式传输到远程服务器上,以保护文件的安全性。
FTP和SFTP有哪些区别呢?
-
链接方式不同
:FTP使用TCP的21号端口建立连接。而SFTP是在客户端和服务器之间通过 SSH 协议 (即TCP22号端口) 建立的安全连接来传输文件。 -
安全性不同
:SFTP使用加密传输认证信息和传输的数据,相对于FTP更安全一些。 -
传输效率不同
:SFTP传输文件时使用了加密解密技术,因此传输效率比普通的FTP要低一些。 -
使用协议不同
:FTP使用了TCP/IP协议,而SFTP使用了SSH协议。 -
安全通道
:SFTP协议提供了一个安全通道,用于在网络上的主机之间传输文件。而FTP协议没有安全通道。
因此可见,我们使用SFTP来传输文件还是比较安全的。
那么,如何使用SFTP来实现同步历史数据的需求呢?
答:这就需要我们做好SFTP的账号、目录和文件格式的规划了。
2.1 账号权限控制
首先需要运维同学搭建一个SFTP服务器,提供一个可以对外访问的域名和端口号。
然后需要在根目录下,创建一个存放文件的目录,比如:/data。
然后给每个省市的第三方系统都创建一个子目录,比如:/data/sichuan、/data/shenzhen、/data/beijing等。
接下来,我们需要给每个子目录创建一个账号,以及分配权限。
比如有个账号是:sichuan,密码是:sisuan123。这个账号只拥有/data/sichuan目录读数据和写数据的权限。
另外一个账号是:shenzhen,密码是:shenzhen123。这个账号只拥有/data/目录读数据和写数据的权限。
以此类推。
当然大家如果不放心,可以用在线工具,将密码设置成一个8位的随机字符串,包含字母、数字和特殊字符,这样的密码安全性相对来说要高一些。
这样相关的第三方系统都有往SFTP自己目录下读和写数据的权限。
在这里温馨提醒一下:上面这些账号读数据的权限,主要是为了后面他们好排查问题用的,不是必须分配的,我们需要根据实际情况而定。
此外,还需要给我们自己分配一个账号,开通对/data整个目录的只读权限。
2.2 统一数据格式
接下来,最关键的一步是要制定一个统一的文件格式和数据格式。
文件名称为:sichuan_20230724.txt。
也就是用 省市拼音_日期.txt
的格式。
这样大家就能非常清楚的看出,是哪个省市,哪个日期产生的数据。
然后我们需要规定txt文件的格式。
比如:id占20个字符,name占30个字符,金额占10个字符等等。
如果有些列的数据不满对应的字符长度,前面可以补0。
这样我们的程序,只需要在解析txt
文件时,先读取一行数据,是一个比较长的字符串,然后按照固定的长度,去解析字符串中每一列的数据即可。
2.3 使用job同步数据
假如第三方系统都按照我们要求,已将历史数据写入到指定目录下的指定文件中。
这时我们需要提供一个job,去读取/data目录下,所有子目录的txt文件,一个个解析里面包含的历史数据,然后将这些数据,做一些业务逻辑处理,然后写入我们的数据库当中。
如图所示:当然如果想快一点处理完,我们可以在job中使用
多线程
解析和读取不同的txt文件,然后写数据。
3. 增量数据如何处理?
对于历史数据,我们通过上面的方案,可以快速的同步数据。
但对于增量的数据如何处理呢?
增量的数据,对实时性要求比较高。
我们没办法跟之前一下,走SFTP同步文件,然后使用job定时解析文件的方案。
为了满足数据实时性的需求,我们不得不走接口实时数据同步的方案。
那么,是第三方系统提供接口,还是我们这边提供接口呢?
很显然,如果让第三方提供接口,第三方有那么多系统,我们需要对接很多很多接口,非常麻烦。
因此,这个接口必须由我们这边提供。
我们这边提供一个统一的数据上报接口,支持传入批量的数据。
为了防止第三方系统,一次性传入过多的参数,导致该接口超时,我们需要对单次上传的数据条数做限制
,例如:一次请求,最大允许上传500条数据。
其实,光限制请求参数还不够。
我们的这个数据上报接口,可能会被多个系统调用,并发量可能也不小。
为了防止在高并发下,请求量突增把我们的接口搞挂了,我们需要对接口限流
。
我们可以使用redis记录第三方系统请求的url和请求账号,然后在程序中查询redis中的次数,是否超过限额。允许每一个第三方系统,在1秒之内调用10次。第三方系统总的请求次数,1秒不超过500次。
如果超过了限额,则数据上报接口提示:请求太频繁,请稍后再试。为了增加数据上报接口的性能,在接收到数据之后,不直接写库。
我们可以将接口中接收到的数据作为mq消息,发送到mq服务器。
然后有专门的mq消费者,实时监听mq服务器的消息,异步读取消息写入数据库。
该方案比较适合,写库操作,包含了一些复杂的业务逻辑。
如果消费速度有点慢,我们可以及时调整mq消费者,使用多线程处理,或者增加mq中队列的数量,增加mq消费者来增加消息的处理速度。
如果mq消费者在处理mq消息的过程中,由于网络问题,写库失败了,可以增加自动重试机制。
一旦mq消费者在mq消费过程中出现失败的情况,则自动重试3次,如果还是失败,则将消息写入
死信队列
,目前RocketMQ
自带了失败重试功能。
然后有个job监控死信队列,如果一旦发现异常数据,则发报警邮件给相关开发,后面人工处理。
4. 如何校验数据一致性?
通过上面的方案,我们把历史数据和增量的数据都已经处理了。
但还有一个问题:如何校验数据一致性。
对于历史数据,其实我们好处理,第三方系统已经生成好txt文件上传到SFTP上了,我们可以直接对比那些文件即可。
但对于增量的数据,是第三方系统调用我们的数据上报接口,去上报的数据,这部分数据如何校验数据一致性呢?
答:我们可以要求第三方系统,在某日凌晨,生成一份昨日的增量数据到txt文件,然后上传到SFTP上。
我们有个job,在每天的凌晨1点会读取第三方系统生成昨日增量数据,跟我们数据库中昨日的增量数据做对比,校验数据的差异性。
如果第三方后面产生的增量数据,只有新增,没有删除和修改,使用上面的方案是没有问题的。
但如果增量的数据,包含了删除和修改的数据,可能会有问题。
因为我们做比较的数据源是昨日的增量数据,而我们的job在比较数据的过程中,万一第三方系统上报了我们正在对比的数据,更新成了一个新值,跟昨日的值不一样,这样对比数据就会产生差异。
那么,该如何解决这个问题呢?
答:我们可以只校验昨日的数据(就修改时间是昨天),今日产生的增量数据,会在明日凌晨1点的job中会去校验的。
在比较时,遍历昨日增量txt文件中的每行数据,跟数据库中的数据做对比,如果id相同,但是修改时间是今天,则忽略这条数据。
如果id相同,修改时间是昨天,则判断数据是否一致,如果不一致,则用txt文件中的数据修复我们数据库中的异常数据。
如果txt文件中的id,在我们数据库中不存在,则新增一条数据。这两种情况产生的数据变动,
修改时间
要设置成昨天
,不然明日的job又会再重新处理一次这条数据。
这个问题是星球中众多问题中的一个。
如果你也有类似的问题,或者有其他的问题找不到答案,戳这里加入我们,向我们提问吧,欢迎你的到来,有问必答。
1、本站所有资源均从互联网上收集整理而来,仅供学习交流之用,因此不包含技术服务请大家谅解!
2、本站不提供任何实质性的付费和支付资源,所有需要积分下载的资源均为网站运营赞助费用或者线下劳务费用!
3、本站所有资源仅用于学习及研究使用,您必须在下载后的24小时内删除所下载资源,切勿用于商业用途,否则由此引发的法律纠纷及连带责任本站和发布者概不承担!
4、本站站内提供的所有可下载资源,本站保证未做任何负面改动(不包含修复bug和完善功能等正面优化或二次开发),但本站不保证资源的准确性、安全性和完整性,用户下载后自行斟酌,我们以交流学习为目的,并不是所有的源码都100%无错或无bug!如有链接无法下载、失效或广告,请联系客服处理!
5、本站资源除标明原创外均来自网络整理,版权归原作者或本站特约原创作者所有,如侵犯到您的合法权益,请立即告知本站,本站将及时予与删除并致以最深的歉意!
6、如果您也有好的资源或教程,您可以投稿发布,成功分享后有站币奖励和额外收入!
7、如果您喜欢该资源,请支持官方正版资源,以得到更好的正版服务!
8、请您认真阅读上述内容,注册本站用户或下载本站资源即您同意上述内容!
原文链接:https://www.shuli.cc/?p=14509,转载请注明出处。
评论0