shopee虾皮后端日常凉经，Data Infra-Platform-后端开发-BJ岗

1、常见的方案有数据库自增ID、UUID、Redis生成和雪花算法。实际分布式场景下，雪花算法更常用，它将ID分为时间戳、机器ID和序列号三部分，性能高且趋势递增。但要注意时钟回拨问题，可通过记录上次生成时间戳或使用扩展版算法解决。2、雪花算法的ID在时间戳维度是递增的，但同一毫秒多机器生成的ID可能乱序。如需严格单调递增，可用数据库号段模式：服务启动时申请一个ID范围，内存分配用完后再次申请，这样单服务内ID严格递增。3、redo log是InnoDB的物理日志，崩溃恢复时重放提交的事务；undo log记录数据修改前的状态，用于回滚和MVCC读；binlog是MySQL Server层的逻辑日志，用于主从同步和数据备份。4、主库将变更写入binlog，从库通过IO线程拉取binlog到relay log，再由SQL线程重放SQL实现同步。5、优化索引时要减少回表和利用覆盖索引。索引失效常见于：违反最左前缀、对索引列计算、类型转换、LIKE左模糊匹配、OR连接非索引列等情况。6、InnoDB索引用B+树实现，联合索引按字段从左到右排序。如果跳过左侧字段，因为b的值在全局无序，无法利用索引快速定位，导致失效。7、当元素少且小时，用压缩列表节省内存；当元素多或大时，自动转为 "跳跃表+字典" 组合。跳跃表负责按分值排序，支持高效范围查询；字典负责成员到分值的映射，实现O(1)快速查分数。这种设计平衡了内存与性能。8、跳表插入节点时，从最高层向右向下逐层搜索并记录小于目标的分值位置（update[]）；随后随机生成新节点层高，创建节点并按层将其插入：每层链接到对应update[]节点之后，并指向其原后继；最后更新跳表的最大层高和节点总数，实现高效定位与平衡插入。9、Redis有6种淘汰策略，常用的是allkeys-lru和allkeys-lfu。LRU淘汰最近最少访问的，LFU淘汰访问频率最低的。LFU更适合长期热点场景，而LRU对突发流量更敏感。10、Redis用惰性删除+定期删除组合：访问key时检查过期，同时后台定期抽样清理过期key。当内存不足时，再根据淘汰策略主动删除数据。11、TCP通过滑动窗口实现流量控制：接收方在ACK包中携带窗口大小。发送方根据这个窗口动态调整发送数据量，避免接收方缓冲区溢出。

我是码农索隆，我赞成牛友翘课去实习。现在这个卷学历、卷实习、卷技术的时代算是让我们摊上了，也算是赶上好时候了~老话说：“纸上学来终觉浅，绝知此事要躬行”，你看老祖宗都告诉咱们，学了知识之后，要亲自尝试，所以实习这个事是没毛病的，但是，翘课实习，就要考虑怎么护住毕业证这个大事。我分享几个保护毕业证的好方法。一、别玩彻底消失。课全旷、人失踪，这是不对推荐的，也是不理智的，这会导致导员跳脚，直接拿着毕业证威胁你让你回校。靠谱做法是：提前找好代课，作业一次别落，平时分挣满，期末准时赴考。至于查寝，室友的掩护必须打好。二、旷课实习被发现。这个不用慌，我推荐的做法是给父母打个电话，和父母详细阐述一下这个事...

大家好，我是JavaKing，在大厂写了10年Java。☕️最近也是恰逢招聘季，发现很多同学的简历其实底子不错，但90%都挂在了“项目太假”上。满大街的“外卖”、“商城”，我是面试官我也看腻了。😮‍💨与其自己瞎琢磨，不如让我来帮你看看。我想做一期简历点评系列（完全免费）：✅ 如果你愿意公开：把简历发给我，我会严格进行隐私打码（马赛克），只保留技术栈和项目描述。我会发笔记公开点评，告诉大家这种简历在大厂面试官眼里是什么水平，以及如何用真实的大厂项目逻辑去拯救它。大家一起学习避坑。✅ 如果你比较社恐：也可以直接私信我，我给你提几条核心修改建议。🔥 我的核心优势：我不止是改格式，我手里有真实落地的大厂核心业务项目（源码已开源，可去我主页Gitee看）。如果你的项目太单薄，我会告诉你如何把这些高并发、高可用的真实场景植入到你的简历里。👇 想参加的同学：关注我（防走丢）评论区扣 “1” 或者 “求指点”直接后台私信发我简历图片/PDF攒够几个典型案例我就更新第一期！希望能帮到迷茫的Java人。🤝

介绍项目的几个需求实现的方案项目的kafka涉不涉及顺序消费volitail的理解Synchronized放在实例方法和静态方法上的区别反问