虾皮后端一面-日常实习

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

开头先来整点小感悟这次从滴滴离职之后花了两个礼拜多一点进行了个菜鸟康复训练八股算法手撕啥的还真是四个月没学 忘得一塌糊涂之后又用了七天时间差不多面了10场本小红书梦女拿到🍠offer后就没有再面啦一直忘记整了 这次趁周末整理完秉着开源精神来分享一下我的面筋~汇总如下：虾皮 一面✅️二面✅️hr✅️oc✅️哈啰 一面✅️笔试放弃做了但是莫名其妙说oc✅️了贝壳 一面✅️二面诡异至极 无后续米哈游 一面✅️二面拒了小红书 一面✅️二面✅️（我是🍠梦女）百度 一面无后续（面试体验特烂无比 至少我觉得我的表现没有问题）这次感觉面试都以问实习居多，需要对实习的产出有比较深入的理解感觉主要可以从为什么...

八股： 1.说说Java内存模型2.说说threadlocal，可能会遇到什么问题，怎么解决？3.Java存储一个对象会存在哪？4.Java内存主要包含什么5.说说redis如何保证数据不丢失（答了持久化，哨兵，还有发sql有没有收到确认，但是面试官说不是这个）6.mysql是怎么管理数据的（答了存储引擎和分区页段，好像不对）7.说说redis的日志有哪些（答了RDB和AOF，又问了还有没有其他的）8.说说mysql的日志（说了undolog binlog 和redolog，面试官说还有没有其他的），然后又问了随机写和追加写具体底层是怎么实现的（特别底层的，日志具体是什么，偏移量相关的）9.Linux中的进程10.如何用Java实现redolog的随机写和追加写11.说说mysql和redis日志的区别12.说说你对数据结构的理解13.说说常见的查询数据结构（答了二叉树，二叉搜索树，红黑树，链表，数组，但是面试官想让我说其他的）算法：二叉搜索树的有序遍历

个人BG：双非本硕秋招方向：Android客户端开发实习经历四段：第一段是一个七八百人的小公司、第二段理想汽车、第三段滴滴出行、第四段百度（实习方向均为客户端开发）秋招简历通过情况：除了阿里系 东哥这种强卡学历的 其他基本投了就有面面试情况：前后面了将近40场 真正意义上直接挂掉的应该就只有TME的二面（牛客刷到了好几个友友都是倒在了TME二面一个女面试官手下了），有一些排序死的（类似字节的三分刚过线的情况）offer：9个薪资情况：45w~65w（算上年终+签字费）自己对于客户端的看法： 客户端是真的不如后端，这是毋庸置疑的。客三消也不是没原因的 ，再加上现在各家都在转跨端，把业务往跨端上迁...