之前看过一个分析。因为现代硬盘和网络发展，不再像之前需要精细的打算存储空间了。作为开发公司，资源存放压不压缩其实无所谓。和以前完全不是一个概念了（本质上现在的研发没以前研发对计算资源操作感更强），再加上 steam 的更新机制。只能是游戏空间无限大。。反正磁盘白菜价

这个吧。。。为啥不听医生的呢。。

这个时代什么时候以车衡量天花板了。。。

知道要商业化恰饭。。但也不用这样频繁吧。。

这个问题嘛。。。怎么说呢。只能说，你经验太少。所以觉得很无所谓。

我作为运维，要是谁的接口涉及到钱的不做防重放。我直接就贴脸放大了。是是是。你懒得做，然后我一看账单短信被刷几十万，被骂的人是我。研发来一句脱裤子放屁试试。。

这是主问题。次问题。。是是是，你用不到就是八股文。

那我是不是可以建一个画像：

1.crud Boy
2.不学习任何计算机底层知识。sync ，lock ，多线程在很多领域都要用。你只会 crud 当然涉及不到，你还不学。业务有啥？很高精尖吗？写个 crud 能写出花来？
3.对于技术只停留在表象，不深究其原理和为什么要这么做

你一句不信，我默默看着我司代码库里面这都是啥？我们组十年前的项目不带防重放，技术评审都过不去

@drymonfidelia 嫌麻烦，就别怨踩雷

初中那点东西。。不说牛逼翻身，再不是读书的料，只要肯，1 年功夫，读个高中肯定没问题。
所以怎么做到只要肯是正解

光一个双休就多了 2 天休息。
也就是多了 2/20 天的隐形工资不算了。。10%呢。。是不是一算比例还挺可观

分治法反而是成本最低的。并没限制时间一定要用最快时间。要加快磁盘吞吐也有很多办法。

说的好像上了 k8s 后就不要 100G 内存一样。。。。

合理方式是：合并微服务。java 的项目。你微服务越多，内存浪费越多。99%的项目，不需要拆他 5-60 个微服务。

合并一半就节省一半云成本。。。

但有一说一，云服务的 support 都那样。除非是他服务有问题。一般情况我都不找。没意义

所有云都是这样。aws/阿里云。当你企业到一个级别，有专属 BD 后。基本是分钟级回复。如果再上一个级别，比如 aws business support 。让他给你看代码有没什么问题都行。

免费的，能解决问题就 ok 。不用强求那么多。

大家都是研发，技术文档是个什么水平，大家都心里有数。。强求也没用

如果你能劝说公司推广一个 AI 工具。不考虑钱的问题的话。版本答案：copilot
这是唯一解。

我也是想多了。。哪有这么复杂。

读一条。算 hash 。然后读下一条，算下一条的 hash 。相同就扔掉。。。没有相同的就写到另一个文件里面去。一个递归好像就完事了。这应该也是 sort|uniq 的逻辑。只需要内存 （每行 byte *2 ）。这就是纯粹比 ssd 的速度。想加速就是利用 cpu 的并行运算搞搞分块就好了。

这么点数据就要 spark ，mr 了？
楼上很多说的没错啊。。你倒是试试 sort |uniq 之后看看结果啊。慢是肯定慢，但是试试不比你纠结强。。

=====

rocksdb 是一个解决方案。但如果不想上东西自己算也不是不行。自己构建结构体和硬盘文件内映射关系。hash 一定要在内存里面才能对比？在文件里面就不行么。现在都是 ssd ，随机读取没啥吧。

我猛的一想就是

1.hash 直接建在硬盘上。每次对比用 seed 偏移来查找。这种业务使用最好别用布隆，毕竟不是近似求结果。而是最终求结果。

2.6T 文件。内存里只建一个够 N 条的 hash 。先读 N 条。计算 N 条里的没有重复的。保存到文件 a 。然后一直递归下去。得到 n 个小文件。然后问题就变成了 n 个小文件去重的问题。内存大，就把第一个文件读出来，去其他文件一个一个比。以此递归处理。当然，连小文件都不需要，自己规划好数据结构把 6T 文件看成 n 个小文件也是一个逻辑。这个逻辑下哪怕 1G 内存也能算出来。就看时间了。

同兔。那就钓鱼，枸杞吧