这是之前在处理一个实时流数据上碰到的。 之前背过很多，类似的关于高并发问题的一些官样文章。初读起来，总感觉索然无味。好像和幼儿园里把大象放进冰箱里的故事一样。 在业务中碰到的情况很特别。 同一个用户，会在同一个时间点有多条订单，即使把时间精确到 00:00:00，依然发现无法区分。前辈提醒后，才发现这其实是一种高并发的情况。 在Flink实时流里，通常碰到高并发的情况下，会进行一次打乱操作。在SQL任务中，我忘记进行了这种操作，后来发现其实是有这样的key by 参数。 大约可以这样处理。 在处理的时候，通过key by 的操作，会将并发数据存储同一个kaf...

从未见过如此厚颜无耻之人！算了，确实也没少见...祝 早日倒闭！

1. 自我介绍2. 问 ACM 情况，什么奖，还熟悉吗，熟悉的话打开vjudge来一道（婉拒了哈）3. 之前有实习过吗，如果你有机会转正会考虑百度转正吗4. 我们在深圳，你能实习多久5. 好的，我们现在根据简历去问一下，我看你做过的东西还挺多的，一个开源的分布式事务框架，一个开源的数据库项目，还有一个分布式kv项目对吧，这三个你觉得哪个有意思，想讲哪一个？（选了自己的分布式kv项目）6. 好的，你先跟我讲一下你这里要解决什么样的问题，主要的难点痛点是什么？7. 打断一下，你这里为什么要使用布隆过滤器？8. 好的，我看你这里有用到raft是吧，那我问一下你存储的基本单元是什么？9. 好的，你可以...