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

已经打算旷工处理了。#中关村科金

真逆天

刚加入宁德时代时，我对离职率没什么概念，但最近一段时间，我目睹了4位工程师同事的离职，都是我很欣赏的同事，他们离开后，我开始反思部门内部可能存在的问题：我们部门虽然不是公司的核心部门，但工作压力却很大，加班情况也很严重。就工程师的工作时间来说，大概有三分之一的人是“896”模式，三分之一是“8105”，还有三分之一是“895”……另外，部门内部存在派系斗争，不同派系之间似乎很难达成一致，工作推进很困难。而且岗位职责划分不清晰，导致工作开展时容易出现扯皮现象。很多时候，大家都不清楚自己的工作边界在哪里，非常影响工作效率。我最近也经常思考，留在CATL的意义到底是什么？除了存钱，我感觉可能还需要积...