得物9.27java一面 已挂

如果用 userId 分表，要用merchantId 查询的话，如何查询？维护索引表：用一张单独的索引表存储 merchantId -> userId，查询时先查索引表拿到 userId。自己手写实现 一致性哈希分表一、核心原理（3 句话记住）把 userId 哈希成一个 0 ~ 2^32-1 的整数把 分表（表名后缀 0、1、2、3...） 也哈希后放到哈希环上userId 顺时针找最近的表 → 得到表序号（0、1、2...）关键：加表只影响少量数据二、手写实现一致性哈希（完整可复制）结构哈希环（排序的 Map）物理节点（真实表：0、1、2、3）虚拟节点（让数据分布更均匀）路由方法：输...

总时长35分钟，无手撕，感觉遇到KPI面了，唉35分钟一直在问实习，八股就问了下面的1.redis与数据库的缓存一致性2.redis的zset数据结构3.redis的两个持久化机制4.分布式cap理论5.什么时候ap，什么时候cp6.进程线程协程问怎么没手撕，说一面撕过了，业务是应用宝游戏商城，后面过了还有一面技术面，问面试表现，说挺顺的，可以再关注一下运维数据，然后问转go有难度嘛，就结束了

rt 不知道是真的假的丁老板 太难绷了

那是一个周四下午，距离大促还有不到两天。 我正在按照清单做最后的上线检查，没什么特别的。监控正常，流量平稳，接口响应也没有问题。照理说，我应该打个对勾，然后准时下班。 但那条日志让我停了下来。 不是报错，也没有触发告警。只是一条看起来有点奇怪的日志：某个下游服务在低频情况下返回了一个不太对劲的状态码，没有被任何监控规则捕获，却在日志里安静地躺着。 我盯着它看了很久。 说实话，我不确定这算不算问题。我在这里实习才一个多月，对这套系统的了解还不够深。也许这是正常的降级逻辑，也许是某个不影响主流程的边缘情况。我甚至想过，要不先记下来，等大促过了再说。 但我还是在群里发了一条消息，@了我的导师：&qu...