陕西烽火电子股份有限公司

1. 你们系统里如果用了消息队列，怎么保证消息不丢失、不重复消费，并且实现最终一致性？答案：先保证生产者发送可靠，发送失败要重试，关键业务可以配合事务消息或本地消息表。Broker 这一层要做持久化和副本，避免机器故障导致消息丢失。消费者要在业务处理成功后再 ack，不能先确认再执行业务。MQ 一般只能保证至少一次投递，所以消费者一定要做幂等。幂等常见做法是业务唯一 ID、去重表、Redis 去重、数据库唯一索引。最终一致性一般靠异步重试、死信队列、补偿机制来保证。面试里可以总结一句：生产者可靠发送，Broker 持久化，消费者幂等消费，失败靠补偿实现最终一致。2. 分布式事务有哪些常见方案？...

都是客户端岗位。求各位niu友给点意见

快手专属内推码：ymIgedltz 快手内推链接（复制完整链接到浏览器打开）： https://campus.kuaishou.cn/#/campus/jobs?code=ymIgedltz 欢迎大家投递我们的快手！ 快手内推，我们鼓励创业精神和创新思维，让你的梦想在这里起航。在这里，你将得到创业项目的支持和资源，实现自己的创业梦想，成为创业领域的领军人物。

虽然进来字节之前，是先了解到这个岗位，说是全栈，其实是主客户端，但还是抱着“title优先，到时秋招初筛应该好通过”的想法入职了。看到牛客上一些疯狂劝退客户端 以及 字节转正率低 的帖子，还是动摇了title优先的想法。而且感觉二面也很差 还让我进来了，所以又不由得想到就是因为比较缺人 而我又刚好接offer了，所以就让我来了，然后到时候就算我想留着 也不给我转正，毕竟大厂想招人应该是挺简单的hhh。而且在接字节offer之前，已经接了一家小厂后端offer，实习薪资也有8k+，也很可以了 但还是拒了。所以我在想到底 这个选择是对的还是错的，是要all in转正客户端岗位(之前是学的c++，进来之后要写kotlin，怕成本太大了，到时秋招两个都投不了)，还是直接跑路，还是自己补充后端技术然后秋招再投别的，大家是怎么看的