字节提前批一二面面经

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包中携带窗口大小。发送方根据这个窗口动态调整发送数据量，避免接收方缓冲区溢出。

说起实习，大家的日常真的五花八门。有人在正经跟进项目、整理数据、写工作报告，实打实学技能攒经验；也有人基本都是打杂，复印文件、核对表格、跑腿对接琐事。还有人一边摸鱼一边自学，一边打杂一边偷偷攒职场经验。其实实习本就没有统一模板，哪怕做小事，能学到东西就是赚到，慢慢积累就好啦。

实习/项目拷打：1、项目和实习的来源？2、介绍一下实习中做了哪些事情？你认为实习与在学校做的项目有什么区别？3、简历上写了实习中排查优化30%，这个数据怎么得到的4、举例子说明一下你做的优化对bug排查效率的提升？运维人员如何去排查的？5、如何实现的日志记录审计（aop 线程池）6、记录的日志数据存储在哪里了？怎样存储的？7、冷数据都直接存储在mysql会导致性能问题，有没有其他更好的方法？mysql对应表上打了哪些索引？8、系统每天的请求量有多少？9、热数据怎样存在redis中的？利用zset能够快速根据key（时间戳）进行时间范围查询日志，那如果是按用户id查询呢？你用redis存储日志的热数据，如何处理redis宕机的情况？10、项目/实习中多线程情况的解决，举例子说一下八股：1、介绍一下hashmap？2、如果此时一个对象没有重写equals方法，作为key，put到hashmap中，会产生什么问题？3、如何实现把hashmap的数据按key排序，可以利用其他的数据结构也可以在hashmap上实现，有哪些方法？手撕：lc 560

rt，lz本人大二，之前在牛客上发了个为什么没大厂约面的帖子，后面被说是简历问题很大，听周围朋友建议我把项目经历删了，直接都换成实习经历，早上用latex写了个新的简历出来简历上稍微包装了下，因为购物车和营销补差这两块业务侧没提这个需求，但是我自己练手写了一点，也大概知道咋做在小厂安逸的环境待久了，其实11月和12月都没学到什么东西，这几天准备离职，等考完试沉淀一个寒假试试大厂。希望大家能对我多提点建议，不甚感激。