Http-Sync

众多电商、直播、saas 企业会提供开放平台供客户使用 API 对接，支持生态解决方案。对接开放平台就成为了一个技术需求。

作者来自大数据团队，对接众多开放平台，同步企业自身数据供团队和公司数据分析使用，http-sync 项目即是通过 HTTP 对接开放平台实现数据同步的开源项目。

对接过的开放平台

项目中并未添加所有的开放平台，只是添加了个最常见的场景

时间+分页
- 时间类型
  - 创建时间、更新时间
  - 业务时间。订单创建时间、库存出库时间、账单结算时间。
- 分页
  - pageNum + pageSize
  - cursor + pageSize
全量数据
- 店铺列表，店铺内商品列表，仓库列表，部门、人员列表
- 快照。如发生人员离职情况，昨日接口返回 100 个员工信息，今日只有 99 个员工。部分平台接口此效果，如北森
  - 处理方式有 2 种。第一种：将今日同步的 99 个员工与现有的 100 的员工（其实就是昨天同步的数据）对比，发现有 1 个员工不存在了，则标记为离职。第二种：记录数据同步的日期，并将同步日期作为唯一键之一。如员工表的唯一键应为员工 id，可改为 sync_date + 员工id，存储的数据每日都为一个全量。后续使用的时候需根据场景优化查询，或通过数据处理流程（ETL）产出目前员工信息，所有员工信息，员工在离职记录等数据
- 查询时间。全量数据，针对每天删除后全量在拉取的场景，都可以添加查询日期，记录同步日期。在使用上时
详情接口。只能通过对应数据唯一键查询的接口，如订单详情、员工详情信息接口

时间+分页。如果某个时间范围数据量过大，存在深翻页，开放平台会增加限制（开放平台开发人员线下通知调用方调整，开放平台本身增加限制，至多翻 100 页）。在确定时间范围时，可以通过请求接口，根据接口数据量确定时间范围是否合理。
反复同步
详情接口

核心即是 map-reduce。

如先同步部门员工和员工考勤信息数据，在同步员工的组织数据。因为数据权限原因，无法直接同步所有员工和组织信息，只允许同步某个部门全部员工信息，在通过员工信息的组织信息字段（orgId）同步员工所在的组织信息。

这里有 2 个限制：

同步部门员工信息时，接口会返回一个 cursor，第一次请求时传空，后续每次请求将上次请求响应中的 cursor 带入。cursor 具有时效性，必须在一定时间内完成所有部门员工信息的同步。
同时开放平台有相应的限流，无法大规模地调用接口。

因为上述 2 个限制，难以粗暴地同步员工信息后，直接同步员工对应的部门信息：一个是需快速从开放平台拉取所有员工信息，另一个是部门接口限流低，处理员工信息时不好每个都调用一次。

因为一个部门下会有很多员工，部门数据量会比部门员工数据量少的多。因此在同步员工信息时，将员工的部门id（orgId）存储下来，同步结束后，在根据部门id 同步对应的部门信息。

数据分批扫描：

按照时间范围分批次。每批次数据由开始时间和结束时间决定。每批次数据量由数据本身分布决定，可能出现某个批次数据量特别大，存在数据热点现象。优点是可以支持并发，即同时可以处理多个批次。
按照数据量分批次。每次处理固定数据量数据，如一次处理 1k 条。扫描数据的时候采用 timestamp >= #{startTime} order by timestamp limit 1000，下一次扫描的开始时间即为上一次扫描最后一条数据的时间。优点是不存在数据热点，每次处理数据量相同，缺点是不支持并发，一次只能处理一个批次。
- 时间限制也可以增加结束时间，对数据扫描时间进行限制。timestamp >= #{startTime} and timestamp < #{endTime} order by timestamp limit 1000