通用面試：如何解釋線性一致性與順序一致性？
題干與適用場景
請解釋線性一致性和順序一致性的差別，畫出一個兩者行為不同的讀寫時間線，並說明分散式系統為什麼要在一致性、延遲和可用性之間取捨。題目適合系統設計、後端、資料和基礎設施職位的通用追問。
這題不是背定義：面試官想看你能否把最新值、實時順序、單一客戶端順序與跨副本延遲放進同一條可驗證時間線。
面試官考察點
- 能否說明線性一致性要求每個操作看起來在呼叫與回傳之間瞬間生效。
- 能否說明順序一致性只要求存在一個符合每個執行緒程式順序的全局序列，不要求尊重真實時間。
- 能否用反例證明順序一致但不線性，而非只說「一個更強」。
- 能否把一致性模型映射到 etcd 這類系統的讀取模式與成本。
回答前需要釐清的問題
先問討論的是單一物件還是交易、多客戶端還是單一客戶端、讀寫是否有明確呼叫與回傳時間，以及問題關注安全性還是可用性。線性一致性通常描述單個並行物件；跨物件交易還需要額外的原子性與隔離保證。
30 秒回答框架
線性一致性要求所有操作存在一個全局順序，並尊重真實時間：已完成的寫入必須被之後開始的讀取看到。順序一致性只保留每個執行緒內的程式順序，跨執行緒可以重排。用「寫 A 完成後，另一執行緒讀到舊值」說明違反線性；若沒有實時重疊約束，仍可能滿足順序一致。更強模型通常需要協調，帶來延遲與分區時的可用性成本。
分步驟深入解答
用歷史記錄描述操作
把每次操作寫成呼叫時間、回傳時間、執行緒與結果。線性化要求為每個操作選擇一個位於呼叫與回傳之間的瞬間，使所有操作組成合法的單執行緒執行，且不違背已完成操作的真實先後。
順序一致性的條件
順序一致性要求存在一個全局序列，且每個執行緒在該序列中的操作順序與自身程式順序一致。不同執行緒的操作可以重新排列，即使它們在牆上時鐘上有先後，只要呼叫期間重疊或系統沒有要求實時順序。
反例時間線
執行緒 A：write(x=1) 回傳；執行緒 B 隨後呼叫 read(x) 卻回傳 0。若讀寫針對同一物件且讀確實在寫回傳後開始，這個歷史無法線性化。若兩個執行緒的操作在時間上重疊，系統可能先把 B 的讀放進全局序列，再放 A 的寫，從而滿足順序一致性但不滿足實時順序。
~~~text Linearizable: A: write(1) ---- returns B: read() -> 1
Not linearizable: A: write(1) ---- returns B: read() -> 0
Sequentially consistent but not necessarily linearizable: A: write(1) ========= B: read() -> 0 ========= Global order may place B before A when the calls overlap. ~~~
與最終一致性的差別
最終一致性只承諾在沒有新寫入並經過足夠時間後副本趨於一致；它允許讀到舊值，也不自動提供讀己之寫或單調讀。線性一致性提供更強的實時語義，但通常需要讀寫經過領導者或 quorum 協調。
高品質示範回答
我會把線性一致性理解為「單副本實時物件的錯覺」：每個操作在自己的呼叫和回傳區間內有一個線性化點，所有操作可排成合法單執行緒順序，並尊重已完成操作的先後。順序一致性只要求全局序列保持每個執行緒的程式順序，因此跨執行緒的實時先後可以不保留。
例如 A 寫入 1 並回傳後，B 才開始讀卻讀到 0，這違反線性一致性。若 A 和 B 的呼叫區間重疊，B 的讀可以在全局序列中排在 A 的寫之前，因此可能滿足順序一致性。選擇模型時要看業務：鎖服務、租約和條件更新通常需要線性化；搜尋索引或分析副本可能接受較弱模型換取更低延遲和更高可用。
常見錯誤
- 把「強一致性」當作沒有嚴格定義的口號，不說明實時順序。
- 說順序一致性按伺服器時間排序，忽略它只約束每個執行緒的程式順序。
- 用最終一致性描述最終會讀到最新值，卻沒有討論讀己之寫或單調讀。
- 看到 quorum 就斷言線性一致，忽略實作是否真正把讀納入共識路徑。
- 把單物件線性一致性當成跨多物件交易的完整隔離保證。
追問及應對
為什麼線性一致性通常更昂貴？
讀請求需要確認目前領導者或 quorum 的狀態，跨區域時會增加往返延遲；分區期間，系統可能拒絕部分請求，以避免回傳違反實時順序的結果。
順序一致性比線性一致性弱在哪裡？
它不要求尊重跨執行緒的牆上時鐘順序。只要存在一個符合每個執行緒程式順序的全局序列，歷史就可能合法，因此更容易隱藏「已完成卻讀不到」的使用者體驗問題。
etcd 的兩種讀取有什麼差別？
etcd 文件說明預設操作提供線性化保證；serializable 讀取可存取相對 quorum 陳舊的資料，以換取更低延遲和更高吞吐。回答時應把讀取模式與業務風險綁定，而不是只報設定名稱。
如何測試線性一致性？
記錄每個操作的呼叫與回傳時間、執行緒、輸入與結果，尋找是否存在一個合法線性化順序。並行測試需要注入延遲、程序暫停與領導者切換，避免只在無故障順序執行下驗證。
什麼時候最終一致性足夠？
推薦流、搜尋索引、統計報表等允許短暫陳舊的場景可以選擇最終一致性。前提是產品能接受舊值，並為重要寫入提供讀己之寫、版本號或明確刷新路徑。
一句話怎麼收尾？
先給時間線，再說模型約束，最後說明業務需要哪種保證及其延遲、可用性成本。這比背「CAP 只能三選二」更能證明你理解實際語義。