面試造火箭：手寫消息隊列的三條鐵律

凌晨兩點刷題，突然撞上一道"設計類Kafka消息隊列"。你以為考的是API調用，結果面試官要你在45分鐘里從零擼出線程安全的生產級代碼——這道題在硅谷L5+面試里出現頻率漲了300%，但90%的人死在同一個坑里。

坑一：別把隊列當隊列

看到"消息隊列"四個字，本能反應是LinkedBlockingQueue？恭喜你，掉進面試官的第一個陷阱。

原文給出的核心設計完全反直覺：用ArrayList做底層存儲，追加寫、不刪除。生產者只管往末尾塞消息，消費者通過offset自己讀——這不是隊列，是只追加日志。

為什么？傳統隊列的消費是破壞性的，消息pop就沒了。多個消費者組要同時讀同一條消息怎么辦？復制N份？Kafka的解法是把存儲和消費徹底解耦：消息持久化在日志里，消費者各自維護"讀到哪里"的指針。原文代碼里getMessagesFrom(int offset)這個接口，暴露的正是這種設計哲學。

面試現場寫poll()的人，基本止步于此。

坑二：鎖要鎖對地方

多線程生產者并發寫日志，線程安全怎么保證？原文用了ReentrantLock，但關鍵不在"用了鎖"，而在鎖的粒度。

代碼里鎖只包裹messages.add()這一行，讀操作getMessagesFrom完全無鎖。因為ArrayList的subList是視圖，不復制數據，讀操作天然線程安全——前提是寫操作原子化。如果鎖的范圍擴大到整個方法，或者用上synchronized，吞吐量直接崩盤。

更隱蔽的坑：finally塊釋放鎖。面試緊張時漏寫這個，內存泄漏和生產事故在向你招手。原文三行代碼里藏了兩個考點，這就是L5+面試的惡意。

坑三：消費者狀態誰管

最反直覺的設計留到最后：Topic類完全不認識Consumer。

代碼里沒有Consumer對象，沒有subscribe方法，只有一個int offset參數。消費者進度完全外置——每個消費者組自己記offset，想重讀就調小數字，想跳過就調大。原文第三個要點說得直白：獨立offset讓每個消費者組按自己節奏處理。

這意味著什么？系統沒有"消費完刪除"的概念，消息保留策略變成時間/容量維度的問題，和消費者解耦。面試時能把這一點講清楚的人，說明真的理解Kafka的存儲層設計，而不是背過八股文。

完整實現和執行 trace 在原文鏈接里能跑通，但面試現場沒人讓你抄代碼。這道題真正篩的是：面對模糊需求時，能否從第一性原理推導出架構取舍。

下次刷到"設計消息隊列"，先問自己三個問題：存儲結構是不是只追加？鎖的邊界在哪里？消費者狀態歸誰管。答對再寫代碼，至少省20分鐘調試時間。