⏮️ 沃爾瑪 CEO 爆料：AI 時代，工作會變這樣？

週末早午餐的困境：關於資料一致性的故事

週末的早午餐，是犒賞自己一週辛勞的最好方式。想像一下，陽光灑進窗邊，空氣中瀰漫著咖啡的香氣，你和朋友們圍繞著豐盛的餐盤，享受著美食和歡笑。但如果這場早午餐的體驗，因為點餐錯誤、上菜混亂、或是結帳時發現帳單不符，而變得一團糟，那可就失去原本的意義了。這就像資料一致性問題，看似微不足道，卻可能讓整個系統崩盤。

點餐系統的失靈：多個資料庫的挑戰

餐廳的點餐系統，通常會連接到多個資料庫。例如，廚房需要知道有哪些餐點需要製作，帳務系統需要記錄每一筆交易，而會員系統則需要追蹤消費者的偏好。這些資料庫彼此獨立，但又相互關聯。當顧客點了一份「蒜香義大利麵」，廚房的資料庫需要更新庫存，帳務系統需要記錄這筆消費，會員系統則需要記錄顧客的消費習慣。如果這些資料庫之間沒有良好的溝通機制，就會出現問題。

假設廚房的資料庫更新了庫存，但帳務系統沒有收到通知，導致結帳時發現蒜頭不足，無法完成訂單。或者，會員系統沒有記錄顧客的消費，導致下次顧客來時，無法提供個人化的服務。這些問題不僅影響顧客的體驗，也增加了餐廳的營運成本。

交易的迷航：ACID 特性的重要性

在資料庫的世界裡，ACID 是資料一致性的關鍵。它代表原子性 (Atomicity)、一致性 (Consistency)、隔離性 (Isolation) 和持久性 (Durability)。想像一下，你點了一份套餐，包含義大利麵和飲料。這筆交易需要同時更新庫存和記錄消費。如果只有義大利麵的庫存更新了，飲料的庫存卻沒有更新，這筆交易就不是原子性的，也就是說，它不是一個不可分割的整體。

一致性確保資料庫的狀態符合定義的規則。例如，如果餐廳規定每份義大利麵需要使用 100 克的蒜頭，那麼資料庫就必須確保每筆交易都符合這個規則。隔離性則確保多個交易同時執行時，不會互相干擾。例如，當兩個顧客同時點一份義大利麵時，資料庫必須確保每個顧客都能得到正確的庫存資訊。

持久性則確保交易一旦提交，就永久儲存在資料庫中，即使發生系統故障也不會丟失。這就像一份正式的訂單，一旦確認，就不能隨意更改或取消。

分布式系統的挑戰：CAP 定理的困境

現代的系統越來越複雜，往往需要將資料分散在多個伺服器上，以提高效能和可靠性。這就引入了 CAP 定理的挑戰。CAP 定理指出，在一個分布式系統中，一致性 (Consistency)、可用性 (Availability) 和分区容錯性 (Partition Tolerance) 這三個特性，最多只能同時滿足其中兩個。

一致性是指所有節點上的資料都是相同的。可用性是指系統能夠持續提供服務。分区容錯性是指系統能夠在網路分区的情況下繼續運作。在早午餐的例子中，如果餐廳的點餐系統需要同時滿足一致性和可用性，那麼在網路分区的情況下，就可能需要犧牲一部分的資料一致性，例如，暫時允許顧客點餐，但延遲更新庫存。

這就像在網路不穩定的情況下，廚房可能無法即時收到點餐資訊，需要暫時依靠過去的資料來製作餐點。雖然這可能會導致一些誤差，但至少能夠維持服務的持續性。

微服務架構的考量：事件驅動的解決方案

微服務架構是一種將應用程式拆分成小型、獨立的服務的架構方式。每個微服務負責特定的業務功能，例如點餐、結帳、會員管理等。這些微服務之間通過 API 進行通信。在微服務架構中，資料一致性問題更加複雜，因為每個微服務可能擁有自己的資料庫。

為了解決資料一致性問題，可以使用事件驅動的架構。當一個微服務發生變化時，它會發布一個事件，其他微服務可以訂閱這個事件並做出相應的反應。例如，當顧客點了一份義大利麵時，點餐微服務會發布一個「點餐事件」，廚房微服務會收到這個事件並開始準備食材，帳務微服務會收到這個事件並開始記錄交易，會員微服務會收到這個事件並開始記錄顧客的消費習慣。

這就像在餐廳裡，點餐員、廚師、收銀員和會員管理員之間有著良好的溝通機制，確保每個人的工作都能順利進行。

Saga 模式的應用：長流程交易的處理

在一些複雜的業務場景中，一個交易可能需要涉及多個微服務，並且需要執行一系列的步驟。例如，一個顧客想要預訂一張飛機票，這個交易可能需要涉及訂位微服務、支付微服務、會員微服務等。在這種情況下，可以使用 Saga 模式來處理長流程交易。

Saga 模式是一種將長流程交易分解成一系列的本地交易的模式。每個本地交易負責特定的步驟，並且可以獨立地提交或回滾。如果其中一個本地交易失敗了，Saga 模式會自動回滾之前的交易，以確保資料的一致性。這就像在預訂飛機票的過程中，如果支付失敗了，系統會自動取消之前的訂位，以避免重複扣款。

最終一致性的權衡：商業決策的考量

在一些情況下，為了提高系統的可用性和效能，可以選擇採用最終一致性。最終一致性是指資料在一段時間內會達到一致狀態，但在此之前，資料可能存在不一致的情況。例如，在電商平台的購物車功能中，當顧客將商品添加到購物車時，資料可能需要一段時間才能同步到庫存系統。

在選擇最終一致性時，需要仔細權衡資料不一致可能帶來的風險和收益。例如，如果資料不一致可能導致顧客無法正常購物，那麼就應該盡量避免採用最終一致性。但如果資料不一致對業務影響不大，那麼可以考慮採用最終一致性來提高系統的效能。

這就像在餐廳裡，如果顧客願意等待幾分鐘才能收到餐點，那麼廚師可以優先處理其他訂單，以提高效率。但如果顧客非常着急，那麼廚師就應該優先處理他的訂單，以確保顧客的滿意度。

原文

標題：Future of Business: Walmart’s CEO on AI, Jobs, and Managing Rapid Change
網址：https://hbr.org/podcast/2025/11/future-of-business-walmarts-ceo-on-ai-jobs-and-managing-rapid-change