同花顺进了HR面，b2b集群前端

原TPG部门，有过保温，换了新的HR，还未开奖

哈哈哈，都鸣谢，只是不那么鸣谢DIDI滴滴：暑假实习二面挂、秋招提前批一面挂、秋招正式批三面跑完挂百度：提前批、正式批都一面挂PDD：最想去的公司之一，虽说给我很多信心，但不要太能泡，今天整整HR面完100天，提前批不挂还加面了，给人一种稳了的感觉，却迟迟什么都不发（要不挂吧，快开就不“骂”了！！！）得物：三面别太恶心人，应该是第一批次面到三面的，三面选的下午三点半，三点点进链接还是可访问，面试前10分钟HR打电话来说技术问题，然后后面转岗，没想到还没面就招满了，后面就懂的都懂，实习部门都没HC好想去其他部门，问秋招HR就让等，估计今年开挺高招满了（教训：面试能约早上就早上，特别很多公司HC就少）但还是感谢得物实习的一切，感恩🥹，只是觉得流程不合理，这可能是运气不够吧，没缘分。秋招：实力+运气+缘分，一个不那么好就……

1.实习介绍2.介绍一下你做的贷款项目3.这个项目这里的话，比如说你这的一些针对大额去做了一些风控的定价加折扣的一个逻辑的话，这个规则是如何和用户的标签系统。系统去做联动的呢4. 如果出现同一个用户，同时命中小额和大额的规则规则这种冲突场景你是怎么去做处理5.重复还款的这个场景下，我看你设计了一个双锁的机制，可以简单介绍一下这个机制具体的一个实现逻辑吗6.这个是本地锁还是分布式锁？为什么7.那为啥这里选择双锁的一个机制？如果单锁不行么，我们对比单一的一个分布式锁的话，双锁的优势在哪里8.有用到乐观锁么，为什么不用9. 乐观锁不能解决跨服务的“流程级并发”，这个怎么理解10.介绍一下你做的支付项目11.这里的话，你去做一些上下游对接的时候，上下游的一些参数格式，还有超时时间不一致的情况下，你这边是怎么去做适配的，然后这里有没有降级和一些熔断的一些策略？12.我有这样一个场景，就以你刚刚说到的那些做过项目为例，以刚刚项目的场景设计一个多级缓存的机制，其中要说清楚哪些技术选项，为什么这么选，然后数据用什么数据结构，哪些数据放进缓存里面存，以及这个缓存肯定有过期时间嘛是吧，怎么设置这个过期时间，包括里面有什么坑，比如同步问题啊，一致性问题啊血崩问题啊，预热问题啊等等，你来设计一下13. 如果用本地缓存的话，你这里技术站选择是什么呢？为什么用这个，还有怎么保证本地缓存跟数据的一致性14. 如果这个时候，如果我当前你说的那个xx借款，某个爆款的一个营销策略可以过期了，然后我大量的请求瞬间打到了数据库，那我怎么去解决这样的一个问题呢？15.那缓存雪崩的问题怎么去解决呢？这里的话，你可以通过事前的一个预防，然后事中的一个处理，还有事后的一个恢复，大概去讲一下整体的一个落地16.手撕：给定一颗二叉树，从根节点开始依次输出每一层的第一个和最后一个节点的值，若该层只有一个节点则只输出一次，输出一个字符串表示结果，用逗号隔开节点值

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