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

算法刷卡了200道左右，八股看的也差不多了，就是项目可能已经烂大街了，现在想找个日常实习，简历还有可以优化的地方吗 #投递实习岗位前的准备#

学JAVA时间比较短，纯靠狗运混了两段实习，现在在全力背八股和算法，想问问大佬们简历哪些方面还能修改，今年的暑期实习和秋招够用吗

华为OD的招聘铺天盖地，尽管已经有很多前辈进行了血泪控诉，但华为依然是某些时候的最高选择，让拿到了OD橄榄枝的朋友们十分纠结。如此庞大的公司，大家也很容易认为如果有烂的部门，一定也有好的部门；恶评虽然大多是经验之谈，但也难以逃避幸存者效应，待遇还可以的OD很可能不发声，给了OD招聘者很多回旋的余地。那么如何判断一个部门，乃至一个项目组到底是否适合OD生存呢？本文提出两个判断某个项目组是否适合OD生存的铁标准：三级部门总共有多少人？其中租赁员工多少人？项目组总共有多少人？其中OD有多少人？招聘时，接口人总有花言巧语，吹嘘部门前景、工作氛围、上升空间，但这都是难以衡量与判断的，尤其是对于尚未入职的...