请教一个数据同步的问题

分页吧

这配置 这数据量 不随便玩儿吗

稳定运行 10 年。。。设计跑个三五年差不多了，到时候自然会有新的方法或者新的需求要重写，另外你这数据量感觉用不着这么好的服务器

要考虑断点续传以及分页的稳定性，最好加个自增 id ？每次取用时加上 id > lastTimeGotID

1W 条直接查了，mongo 可以都直接插入，mysql 分次插入就好了。

一定要做分页，并且一定要限制最大返回数量，不然后续你麻烦，对方你麻烦。
当然，你也可以全部，后面等着刷 KPI ，毕竟老板喜欢员工忙忙的样子，大概是可以治愈他的焦虑罢。

@crazyweeds 哈哈，明白了，是这样的

@qW7bo2FbzbC0 有的，把这个利用上

@admol 还有其他的业务

10 年你都不在这个公司了，即便你在这个公司，也可能不负责这个业务了。
规划 2-3 年足够了

@sakilascott 是这样的，就是想考虑全面些

随便,现在一个网页都数百兆了,全查回来 2 年以内都没问题

正规做法当然是提供一个支持分页查询接口,一点一点同步

好吧，认真回答你下

看你的描述，你应该是想问的是：每天去全量同步一次（前一天）增量的所有数据，还是分页去同步（前一天）增量的数据，也就是全量还是分页去同步新增的数据。

建议是：
1 、查询接口一定要限制一个数据范围，所以要分页
2 、要支持指定时间、主键 ID 等范围同步指定数据（失败后人工重试等异常场景）
3 、同步结果是否有通知？同步状态、同步数据条数等

@admol #13 收到，感谢大神，同步结果没有通知，我这边只负责提供数据，剩下的就是业务方自己保证了

补充一下：
1 、提供出去的接口一定要限制数据范围，并且这个范围不能太大
2 、下游请求时得带上时间戳，要在你设定的阈值范围内才可拉取
3 、把提供出去的数据封装成一个批次，让下游分批次拉取
4 、记录好下游拉取数据的日志，避免后续扯皮

如果数据是写入之后无修改, 可以记录上次其获取到的数据 id, 然后将这个 id 之后的数据再发送给他. 有效减少查全库导致性能的下降.

如果修改不大建议最好做个 snapshot. 定时生成一个 snap 节点, 然后用户通过提交上次 snap 节点获悉所有数据更新状态.

我这 一天 3000-5000, 2 核 4g.....运行 3 年了...

感觉还不如拉文件省事