@loongxin 当然是公开渠道采集的了

openstreetmap

我是 debian host + win11 guest, 使用 vmware workstattion, 不知道为啥 win11 非常卡, 分配的 cpu 内存资源是绝对够的

谁叫你用 pdd

@clbigdata 当然不合理
失败就失败了,赶紧查问题解决,存下来有啥用. 他存下来难道想自动重试不成

"结算 id 落库存储"是把整个 json 落库吗, 估计是为了异常情况补偿、业财对帐等场景使用吧, 实际业务意义不大.
我们目前也是节点串行执行,哪一个节点失败,就从该节点开始进行回滚

都是多套存储混用的,面向不同的使用场景.
比如面向 C 端用户,追求 TPS 和 TP99,有些场景直接用 redis 缓存扛量(购物车秒杀等),然后再异步写数据库(mysql 分库分表、tidb 之类); 很多系统会再存一份 es 数据,面向 B 端复杂查询; 至于离线场景, 通常又会通过 ETL 抽数,数据同步到 hadoo spark flink 之类的大数据平台

1. REDIS 单实例写 ops 扛 1w 毫无压力, 正常 key 分散的情况下 5-6w 应该可以, 但这种热 key 不确定
2.预计就是实现了一个 id 生成器, jvm 中预先分配号段, 我之前实现过, 这种简单的接口单机扛百万 qps 毫无压力

@JavenXiao 我自己做的博客聚合网站,也收录快 3000 个独立博客,这几年下来, 还坚持更新的只有极少数了

@trumandu 已删除,谢谢!

上面大佬的 rss 都已经被我的博客聚合网站收录了(需要翻墙的除外), 如果不希望被收录,麻烦大佬跟我讲一下.

对应的收录地址分别如下:
https://bokehui.net/source/2041/
https://bokehui.net/source/2042/
https://bokehui.net/source/2043/
https://bokehui.net/source/2044/
https://bokehui.net/source/2045/
https://bokehui.net/source/2046/
https://bokehui.net/source/2047/
https://bokehui.net/source/2048/
https://bokehui.net/source/2049/
https://bokehui.net/source/2050/
https://bokehui.net/source/2051/
https://bokehui.net/source/2052/
https://bokehui.net/source/2053/
https://bokehui.net/source/2054/

“妄图”....
人家程序员不吃饭么, 总不能一直靠爱发电吧

@lsk569937453 所以我说了嘛,看行重复比例. 同时哈希值前缀相同, 也能节省一些内存吧.
这个方案只是存在一定可行性,但不保证

203 亿行,逐行 hash, 假设 hash256, 单个值占用内存 32 字节, 203 亿行差不多试用内存 604G

1. 逐行读取并进行 hash
2. 使用 hash 值构建前缀树
3. 对每一行的哈希值,有两种情况:
1) 前缀树中已经存在, 说明哈希值重复, 该行重复了. 操作: 直接忽略本行,读取并处理下一行
2) 前缀树中不存在, 说明行不重复. 操作: 新建文件 result.csv, 将该行追加到 result.csv 中, 再处理下一行

关键点:
1.所有行的哈希值占用空间 604G, 内存才 256G 无法直接存储; 使用硬盘存储后续逐行比对查找的性能太差, 所以这里使用前缀树来存储, 减少相同前缀的哈希值使用的内存空间.(具体能节省多少内存,取决于哈希值/文本行的重复比例, 极端情况 203 亿行都不重复的情况下, 前缀树估计也会把内存耗尽?)
2.发现重复行,不直接从原文件中删除, 而是新建文件保存结果. 目的是使用追加写文件的形式、减少随机读写文件造成的性能磁盘 io 损耗

读写分离、异步处理、多级缓存、分库分表/ 分片、一主多从/多级从、限流、降级、熔断
无非就这几板斧

1 楼已经说出答案了, 排查下调用方的线程池.
通常是调用方线程池满了

@bzj 不太认同, 按照这个逻辑, 生产汽车的一定是车技最好的赛车手, 军火生产商一定是最伟大的军事家, 同花顺万得的老板一定是中国首富