就本人经验，仅对错误的生成原因发表一些技术层面个人的个人看法。

首先从事件描述看，问题出在11:02这一笔单上，假设下单是通过message queue的形式达成的，在没有得到回应的情况下重复下单，不知道他这 177笔单子怎么下的，如果是每177笔一起下，多出来的 26082份order，相当于重复下单了146次，这太搞笑了。

作为一个遇错重试的功能，居然没有设置重试上限？如果重新发送的请求不是这177笔而变成了别的，那内部逻辑就太荒谬了，还有作为一个第三方的执行系统，针对外部系统的指令，居然没有采用更加防御性的验证机制？比如重试请求单位时间内的上限？或者对 duplicated order的filter? 还有QA环节，6个月以来没有模拟生产环境的volume么？（个人估计这个问题与正式环境下的大流量有关系） 如果这个理由属实，只能说这2个系统的开发团队都是人才。

相反对于大家质疑的发现敞口后进行对冲，是否是操作市场，我倒认为这是个合理的举动。每个人出血后都要止血。