起因

昨日微信群里有人询问技术问题，忙里偷闲回了两句，闲下来后感觉指的的路有点儿歪。深觉惶恐，顾整理一下思路，希望能减少一些谬误。为了行文需要，没有完全拘泥于群里的原始问题，有故意跑偏意图。
友情提示：本文看一半觉得有理，一定是被带坑里了；如果坚持看完，还能引发更多批评和思考，说明幸免于难：）

问题

前端计算大文件MD5有啥高效的办法吗?
加载800m文件计算太慢了,放后端计算就要先上传上去。

方案0：按需求，直接解。

百度一把，发现 spark-md5.js，号称全宇宙最快的前端类包，可以无需上传文件就快速获取本地文件md5……

document.getElementById('file').addEventListener('change', function () {
    var blobSlice = File.prototype.slice || File.prototype.mozSlice || File.prototype.webkitSlice,
        file = this.files[0],
        chunkSize = 2097152,                             // Read in chunks of 2MB
        chunks = Math.ceil(file.size / chunkSize),
        currentChunk = 0,
        spark = new SparkMD5.ArrayBuffer(),
        fileReader = new FileReader();

    fileReader.onload = function (e) {
        console.log('read chunk nr', currentChunk + 1, 'of', chunks);
        spark.append(e.target.result);                   // Append array buffer
        currentChunk++;

        if (currentChunk < chunks) {
            loadNext();
        } else {
            console.log('finished loading');
            console.info('computed hash', spark.end());  // Compute hash
        }
    };

    fileReader.onerror = function () {
        console.warn('oops, something went wrong.');
    };

    function loadNext() {
        var start = currentChunk * chunkSize,
            end = ((start + chunkSize) >= file.size) ? file.size : start + chunkSize;

        fileReader.readAsArrayBuffer(blobSlice.call(file, start, end));
    }

    loadNext();
});

方案1：加入限制维度

在想不清楚时，先参考行业标杆做法，后续再慢慢理解其为什么要这么做。

腾讯关于上传视频的限制

方案2：加入用户体验维度

再高的计算性能都架不住数据量的挑战，更无法阻止用户心中的怒火。
思路是，先忽略内部实现，从用户视角，分析出能接受的时间限制，然后再思考解决方案。
在这个案例中，让客户等不现实，就需要从算法上下手。需求是如何算MD5，但本质是判重。
可选的方案是，抽取文件的某些片段来生成特征值，再加上文件大小等信息，可解决大部分重复文件的判定；代价是有误判的风险，补充方案是，上传后再依据一定条件再决定是否做完整的MD5值计算。优点的是客户体验好，缺点是系统架构复杂度增加。

足够了吗？等等……

方案3：靠近业务，寻找进一步优化的机会

前面3种方案的共性是，没有充分利用视频这类数据的专用维度，而是实际解决的是通用的文件判重。优点是获取了一定的通用性，缺点是错过了更接地气的方案。视频数据都有其固定格式的，研究一下，从视频文件角度，收集更多元数据信息参与判重计算，从而进一步计算算力。可以参考扩展阅读2，可获得很多灵感。

方案4：我们真的理解需求了吗？

产品提的需求是视频判重。问题是，怎么判定两个视频重复呢？判定标准是什么？以全文算MD5，是错1位都会认为不重复，这样会导致人觉得重复，而机器认为不一样。
回到需求，其实是想避免重复的内容被上传。人判定是否重复并不是对比MD5值是否一致，而是通过模糊对比而给出结果。于是需要和需求方确认更多细节：
1、视频格式不同，内容一致，是否认为重复？
2、视频清晰度不同，内容一致，是否认为重复？
3、视频被剪辑摘录，是否认为重复？多少重复才认为为重复？
4、……

OK？还差一步

我们设计出一个好的方案，于是信心满满的去找产品人员沟通。慢！
以理服人？NO！
产品提需求时，或多或少都会做一些调研工作。研发如直接否决需求，仅希望通过讲道理，是很难达成共识的。所以改变思路，即基于数据沟通。
研发人员PK产品人员，多数都是失败的故事。如果双方不是对比谁更牛，而是共同面对事实、面对数据，聚焦在问题上，则很容易达成共识。
具体方案：提前用数据度量要解决的问题，量化估算方案的效果，包括：
1、设计的算法有多少准确率？
2、对于客户的价值是什么？
3、对于后台系统的影响有多大？节省了多少成本。
4、……