这是一个创建于 226 天前的主题，其中的信息可能已经有所发展或是发生改变。
数据全量同步 rpc 方式，目前 11mb ，每天增长 1mb 左右，每天大约 1w 条左右，这种提供全量同步接口，是直接都给他查出来，还是提供分页接口让客户端去分页查询呀
目前的想法就是提供一个分页的查询接口，最大查询条数 5000 条
服务器配置 2c16 核 32 线程，120g 内存，系统应该会稳定运行个 10 年左右
大佬们有更好的实践方式吗
目前的想法就是提供一个分页的查询接口，最大查询条数 5000 条
服务器配置 2c16 核 32 线程，120g 内存，系统应该会稳定运行个 10 年左右
大佬们有更好的实践方式吗
18 条回复 • 2024-04-02 18:10:20 +08:00
 |
1
halov 226 天前
分页吧
|
 |
2
admol 226 天前  2
这配置 这数据量 不随便玩儿吗
|
 |
3
wqhui 226 天前
稳定运行 10 年。。。设计跑个三五年差不多了，到时候自然会有新的方法或者新的需求要重写，另外你这数据量感觉用不着这么好的服务器
|
 |
4
qW7bo2FbzbC0 226 天前
要考虑断点续传以及分页的稳定性，最好加个自增 id ？每次取用时加上 id > lastTimeGotID
|
 |
5
yngzij 226 天前
1W 条直接查了，mongo 可以都直接插入，mysql 分次插入就好了。
|
 |
6
crazyweeds 226 天前 1
一定要做分页，并且一定要限制最大返回数量，不然后续你麻烦，对方你麻烦。
当然，你也可以全部，后面等着刷 KPI ，毕竟老板喜欢员工忙忙的样子，大概是可以治愈他的焦虑罢。 |
 |
7
Curiosity777 OP @crazyweeds 哈哈，明白了，是这样的😁
|
|
8
Curiosity777 OP @qW7bo2FbzbC0 有的，把这个利用上
|
|
9
Curiosity777 OP @admol 还有其他的业务
|
 |
10
sakilascott 226 天前
10 年你都不在这个公司了，即便你在这个公司，也可能不负责这个业务了。
规划 2-3 年足够了 |
|
11
Curiosity777 OP @sakilascott 是这样的，就是想考虑全面些
|
 |
12
meeop 226 天前
随便,现在一个网页都数百兆了,全查回来 2 年以内都没问题
正规做法当然是提供一个支持分页查询接口,一点一点同步 |
|
13
admol 226 天前 1
好吧，认真回答你下
看你的描述，你应该是想问的是：每天去全量同步一次（前一天）增量的所有数据，还是分页去同步（前一天）增量的数据，也就是全量还是分页去同步新增的数据。 建议是： 1 、查询接口一定要限制一个数据范围，所以要分页 2 、要支持指定时间、主键 ID 等范围同步指定数据（失败后人工重试等异常场景） 3 、同步结果是否有通知？同步状态、同步数据条数等 |
|
14
Curiosity777 OP @admol #13 收到，感谢大神，同步结果没有通知，我这边只负责提供数据，剩下的就是业务方自己保证了
|
 |
15
dlmy 226 天前
补充一下：
1 、提供出去的接口一定要限制数据范围，并且这个范围不能太大 2 、下游请求时得带上时间戳，要在你设定的阈值范围内才可拉取 3 、把提供出去的数据封装成一个批次，让下游分批次拉取 4 、记录好下游拉取数据的日志，避免后续扯皮 |
 |
16
Karte 226 天前
如果数据是写入之后无修改, 可以记录上次其获取到的数据 id, 然后将这个 id 之后的数据再发送给他. 有效减少查全库导致性能的下降.
如果修改不大建议最好做个 snapshot. 定时生成一个 snap 节点, 然后用户通过提交上次 snap 节点获悉所有数据更新状态. |
 |
17
rm0gang0rf 226 天前
我这 一天 3000-5000, 2 核 4g.....运行 3 年了...
|
 |
18
1018ji 226 天前
感觉还不如拉文件省事
|
Select Language