BIGO 后端二面：缓存一致性、Send-Q 排查与重排链表

《面试题目》

1. 能否介绍实习与项目中的工作？
2. Redis 与数据库何时会出现不一致，要求较高一致性时如何处理？
3. B+ 树为什么适合查询，范围查询如何进行？
4. MySQL 慢查询怎样排查？
5. TCP 四次挥手怎样进行，主要解决什么问题？
6. 出现大量 TIME_WAIT 连接时怎么办？
7. Java 线程池有哪些常见参数？
8. CPU 密集型和 I/O 密集型任务，线程池参数应如何选择？
9. Java 死锁如何定位？
10. netstat 有什么用途，Send-Q 持续堆积时怎样排查？
11. 请求超时且 Send-Q 很高时，应如何定位问题？
12. 进程和线程有什么区别？
13. 协程是什么，轻量体现在哪些方面？
14. 如何实现重排链表？

《参考解析》

缓存一致性先定义哪些读取不能旧

数据库更新成功后，缓存删除失败，或读请求把旧值重新填回缓存，都可能造成短暂不一致。可以结合失效策略、可靠的变更通知和重试缩小窗口，但不能把“删缓存”直接说成强一致保证。

对必须读取最新状态的动作，可以让它回到权威存储完成读取或条件更新；能接受短暂延迟的展示数据再使用缓存。支付确认、库存扣减和普通列表展示，通常不需要采用完全相同的读写路径。

Send-Q 高只是排查起点

先区分监听套接字和已建立连接，再定位对应进程与对端。对已建立的 TCP 连接，发送队列积压可能与对端读取慢、接收窗口、链路丢包或重传有关。结合连接状态、重传情况、两端日志和必要的抓包，确认卡在哪里，不能只凭一个队列数值就判定网络带宽不足。

线程数增加也会带来等待和切换

CPU 密集型任务先从可用核心数附近开始测量；I/O 密集型任务可适当增加并发，但还受数据库连接数、下游限流、内存和等待时间影响。调参时一起观察吞吐、尾延迟、队列长度与拒绝数。不存在脱离任务耗时和资源限制的万能线程数公式。

重排链表可以拆成三步

若题目指常见的 L0→Ln→L1→Ln-1 顺序，先用快慢指针找到中点并断开链表，再反转后半段，最后交替合并。时间 O(n)，额外空间 O(1)。空链表、单节点、奇数长度和偶数长度都要检查，合并前先断开两半，避免形成环。原帖只留下题名，具体输入约束仍应在现场确认。