11. MQ 突然积压几十条消息如何分析原因结论是几十条本身不一定构成故障关键要看它是否持续增长、最老消息等待了多久以及是否违反业务SLO。我会先比较生产速率和消费速率再按Kafka分区查看Lag和最老消息年龄。原因通常分为几类生产流量突增消费者异常退出或频繁Rebalance下游数据库、RPC或模型变慢毒消息持续失败重试分区Key不均导致单分区热点以及Broker、网络或磁盘异常。处置时先修复或隔离故障依赖把毒消息放入死信队列确认消费者是瓶颈后再在分区数允许的范围内扩容消费者。如果真正瓶颈在数据库盲目加消费者只会把数据库压垮。恢复后还要处理重复消费并验证业务幂等。同时监控消息条数和消息年龄少量但等待很久的消息也可能是严重故障。消费者数量超过分区数不会继续提高同一消费组的并行度。Rebalance、消费超时或进程崩溃可能导致消息重复应通过业务幂等键处理。毒消息要记录失败原因和原始上下文不能无限立即重试。怎么判断是生产变快还是消费变慢对比单位时间生产速率、成功消费速率和消费处理耗时即可区分。直接增加 Kafka 分区可以吗可以提高并行上限但会影响顺序语义、分区映射和运维成本不能作为第一反应。如何保证消息不丢生产端确认、合理副本配置、消费完成后再提交 Offset并用幂等处理重复消息。12. 两个请求同时更新同一条记录会出现什么问题可能出现丢失更新、最后写入覆盖前一次结果严重时还会破坏库存、余额等业务约束。需要区分两种情况。如果执行的是UPDATE count count 1这种数据库原子语句InnoDB会对记录加锁并串行执行一般不会丢增量。如果两个请求先读取同一个旧值在应用中计算后在写绝对值即使第二个写请求等待了行锁它仍可能用旧计算结果覆盖第一个请求。工程上我优先使用带版本号的乐观锁例如更新条件包含id和version受影响行数为0就说明发生冲突计数和扣库存尽量使用带条件的原子SQL。只有冲突率高、事务步骤多且必须串行时才使用SELECT FOR UPDATE 悲观锁乐观锁形式为WHERE id AND version成功后同时执行version version 1重试前必须重新读取并重新计算不能原样重复旧更新。唯一约束和业务条件应落在数据库中不能只依赖应用层判断事务应尽量短避免持锁期间进行网络或模型调用加行锁后就一定正确吗不一定。如果读取发生在事务外后续仍可能拿旧值覆盖锁必须覆盖完整的读改写过程。乐观锁冲突后怎么办对可安全重算的操作有限重试并加入抖动交互式编辑则返回冲突让用户合并。库存扣减怎么写使用UPDATE ... SET stockstock-? WHERE id? AND stock?根据受影响行数判断成功。
