宇视科技三面：RPC 用什么协议、Redisson 看门狗怎么认线程、Kafka 为什么快

《面试题目》

1. RPC 了解吗？RPC 底层使用的是什么请求协议？
2. 为什么 TCP 需要三次握手、四次挥手？
3. UDP 和 TCP 的区别？UDP 是否可以实现可靠传输？
4. 你了解 Redisson 吗？看门狗会监控线程是否执行结束，Redisson 是怎么知道当前线程是哪个线程的？
5. QPS 太高你会怎么排查？
6. Kafka 为什么那么快？

《参考解析》

RPC 的底层协议：RPC 是编程模型，不是协议。传输层可以是 TCP（Dubbo 默认，自定义二进制协议 + 长连接多路复用）或 HTTP/2（gRPC，Protobuf 序列化、流式、多路复用），也有走 HTTP/1.1 的（Feign + JSON，简单但头部开销大、无多路复用）。序列化决定体积与兼容性：Protobuf / Hessian / JSON。要点是能说清「为什么 Dubbo 不用 HTTP/1.1」：连接复用与头部开销、以及自定义协议能带隐式参数（traceId、超时）。

三次握手/四次挥手：三次是为了双方都确认「自己的发送与对方的接收都正常」，同时交换初始序号，防止历史重复连接被误认。四次是因为 TCP 全双工，一方 FIN 只表示「我没数据要发了」，另一方可能还有数据，所以 ACK 与 FIN 分开发；主动关闭方进入 TIME_WAIT 等 2MSL，确保最后的 ACK 能到达并让旧连接的残余报文消失。

UDP 可靠传输：协议层不保证，但应用层可以自己做——序号 + 确认 + 重传 + 去重 + 拥塞控制，QUIC 就是这么干的（基于 UDP 实现可靠、有序、多路复用，还能绕开 TCP 的队头阻塞）。这题的正确答法是「可以，但那是把 TCP 的活搬到用户态重写，收益是可定制与更快的握手」。

Redisson 看门狗与线程：Redisson 的锁记录里带 threadId（RLock 内部用 UUID:threadId 作为 hash field），加锁时把当前线程 ID 写进 Redis 的 hash 结构；看门狗是每 10 秒（lockWatchdogTimeout 默认 30s 的三分之一）检查一次锁是否仍被这个 UUID:threadId 持有，是就续期到 30 秒。所以它「知道」是哪个线程，靠的是本地的 ThreadLocal + Redis 里存的标识，而不是去问 JVM。可重入也靠这个 field 计数。要指出限制：看门狗只在没显式指定 leaseTime 时生效；进程被 kill 后续期停止，锁会自然过期。

QPS 太高怎么排查：先分清是「流量真涨」还是「异常流量」。看入口 QPS 曲线与来源分布（是否有爬虫、刷接口、重试风暴）；再看是不是上游重试放大（一个下游超时引发三倍流量）。定位瓶颈看四个层面：网关/负载均衡的连接数与限流命中、应用侧线程池与 GC（full gc 会导致请求堆积后集中重放）、依赖侧（DB 慢查询、Redis 大 key、下游 RT）、以及是否热点 key 打穿缓存。处置手段按序：限流降级（先保核心接口）、扩容、缓存兜底、异步化削峰，最后才是改代码。

Kafka 为什么快：顺序写磁盘 + 页缓存（写入先进 OS page cache，靠 append-only 日志避免随机 IO）；零拷贝（sendfile 让数据从页缓存直接到网卡，省掉内核态与用户态间的两次拷贝）；批量与压缩（producer 端攒批、broker 端按批存储，减少网络与磁盘的小包开销）；分区并行（一个 topic 多分区，消费与生产都能水平扩展）；以及拉模型 + sendfile 组合让消费端吞吐高。补充一句「快不等于低延迟」：攒批会引入延迟，实时场景要调 linger.ms。