淘天 - 一面 还是喜欢问的偏应用层的，整体都比较简单，我也比较了解，昨天那种偏 OS 的我真的会谢 👻 1 实习 (具体业务略) 1) 什么场景下要使用事务，事务使用的时候要注意什么点 2) 长事务到底是指什么，有什么问题，怎么避免长事务 3) 事务的原理是什么 4) 为什么深分页性能会比较差 5) LIMIT 100000, 10 在 B+ 树中是怎么具体执行的 6) 场景: 让你设计一个商家用户表，这个表数据量会比较大，读取会大于写入，会被其他服务使用，你会怎么设计 >> 我: (1) 索引 (2) 水平分表 + 垂直分表 (3) ES 异构数据 (4) 数据类型 (5) 读写分离 7) 你怎么区分常用的字段和不常用的字段呢，你为什么是根据查询的角度来考虑 >> 面试官: 你不应该根据查询的角度来考虑吧，应该根据写入的角度来考虑，经常修改的字段就会经常加锁，通过这个角度来进行拆分，常写的和不常写的，不能根据查询来分，今天读不到，那下次业务变化了，又读到了，这个表怎么迁移啊 8) 放 ES 查询有什么要注意的点 9) ES 查询和数据库查询有什么区别呢 10) 什么是读写分离，你了解吗 >> 我: 但是对于用户这种比较重要的，感觉必须读写主库吧 11) 那你区分这个重要和不重要，你怎么理解呢 >> 面试官: 所以根本上还是要根据你的使用场景对吧，比如说金额，必须要读到实时变化的，就要查主库对吧，从库和主库最大的不同就在于有延时和数据丢失 2 项目 1) 什么场景下用消息队列 2) 你大概知道 MQ 是怎么实现的消息发布和订阅吗 3) 多个消费者都要消费同一条消息怎么实现的，比如订单创建，有支付服务，履约服务会消费这个订单消息 >> 我: (这边我傻了，忘了有广播了) 4) 那让你来实现你怎么实现 >> 我: 消息中间件作为平台方，主动把消息推给他们 >> 面试官: 那你推送失败了，你怎么保证可靠性呢 >> 我: 分情况吧，(1) 消息成功送达，但是消费者消费失败，他们自己维护本地消息表，看每条消息的任务状态，开定时任务扫本地消息表，发现消费失败的消息作回捞重试，重试先用 CAS 看订单是否消费完成再重试，做一个 double check；(2) 消息没有送达到消费者，维护一个长连接，发消息给消费者之后要给我一个 ACK 回应表示收到，没回 ACK 就用指数退避重试，多次重试失败认为对方宕机，写入中间件维护的消息表，等对方上线之后再推过去 >> 面试官: 这些都是基于你的考虑，那比如说消费方每一个都是集群的环境，但是集群肯定只能一台机器收到一次消息嘛，你怎么实现这一点 >> 我: 他们自己内部做负载均衡 >> 面试官: 你的意思是消费者那边自己做路由吗，那岂不是太复杂了 >> 我: 有道理，那他们来我这做个服务注册，我维护个注册中心，我来做负载均衡 5) 大模型你认为怎么结合业务产生比较有价值的结果呢，从技术角度来考虑呢 6) 你知道限流的原理吗 7) 比如说实际的过程中，应用都是集群服务，都要加限流保护自己，不让上游服务过多调用自己，对于集群的限流你觉得怎么实现，因为你这些算法都是针对于单机的对吧 >> 我: 在网关层做吧，做个 mp := &map[key][]*model.machine{"1": {IP1, IP2, ...}, "2": {IP3, IP4, ...}}，然后负载均衡到哈希的 key >> 面试官: 那你这样有很大的问题啊，这样就相当于你所有的服务上层都要架一个网关层才打到集群啊，有很多的缺点，有其他方案吗 >> (傻了，想不到解决方案) >> 面试官: 你刚刚也提到 Sentinel 了，是不是没有详细了解底层架构，可以去看看它的内嵌上报 8) 反向压力你怎么做的 9) 如果说消息中间件的堆积这种，你看过相关的知识吗，为什么会出现消息堆积 >> 我: 消费速度跟不上 >> 面试官: 你比如成熟的中间件怎么处理消息堆积的你知道吗，消息队列本身，不是从消费者出发 >> 我: 持久化吧 >> 面试官: 持久化是指全部写盘吗 >> 我: (两眼一黑，不知道怎么办) 开备用队列存放吗 >> 面试官: 还有别的思路吗 >> 我: (干沉默了，想不到解决方法) >> 面试官: 没事没事，这种属于那种偏实际的场景了，你可能接触不到这种 10) 给我讲讲什么场景用多线程，多线程要注意什么问题 11) 我看你用的是 Go，基本的 Java 你应该会写吧，Java 中有很多线程不安全的类嘛，你怎么解决这种问题呢 3 结果 面完之后面试官加了我wx，还是很开心的，但是没明确过没过，还没约二面 🙏 面试表现感觉比昨天好，而且也发现很多不懂的，下来去学一下 Sentinel 内嵌上报和消息队列中间件的消息堆积处理 🤡