隨著網路的發展，使用者互動和顯示的元素數量不斷增加。這些元素會改變使用者看到的螢幕。改變螢幕的事物可以定義為「狀態」。
例如，在資訊網頁（例如登陸頁面）的情況下，「狀態」是要顯示的一條訊息。
接下來，在 GitHub 的情況下，有各種信息，例如我的信息、我的存儲庫信息、星星數量等。由於向使用者顯示的螢幕因這些而異，因此所有這些都可以被視為“狀態” '。
作為一個更複雜的例子，你可以舉出像Figma這樣的例子。螢幕上的所有圖形，如點、線、面，都是「狀態」。此外，協作功能需要您分享您自己以外的其他人的狀態。
狀態都是數據。關於用戶的資訊、用戶自訂的資訊等都是儲存在某處的數據，這些數據很快就成為用戶看到的螢幕的狀態。通常，這些資料會作為單一事實來源儲存在伺服器上。如果您登入某個網站，它將作為單行保存在該網站伺服器上的使用者表中。
現在的網路很複雜。一個螢幕上顯示著無數的按鈕和大量的數據。有很多訊息，其時效性很重要。每當這些狀態發生變化時，資料必須來回傳送到伺服器以確保一致性。如果你只需要每分鐘接收“下一頁”，就像文件一樣，那並不是什麼大問題。然而，在像Notion這樣使用者不斷修改資料的情況下，這就成了一個大問題。如果我每次在頁面上設定類似功能時都必須加載它，我會感到不安
。想像一下在 Instagram 等社群媒體網站上點擊「讚」按鈕。當我點讚的時候，我必須去伺服器保存我對帖子點讚的信息，將帖子的點讚數加一，然後獲取當前帖子的點贊數並顯示給我。
但在 Instagram 上，按讚數會在 0.001 秒內隨著動畫而增加。
這可以透過在資訊到達伺服器之前更新客戶端的狀態來實現。這個想法是更新客戶端的狀態，假設類似的資料會很好地記錄在伺服器上。大多數情況下，與伺服器的通訊都會成功，所以我們樂觀地判斷這是成功的。
當然，也有發送到伺服器的請求失敗的情況，所以要注意失敗時回滾客戶端狀態。
優化顯示我是否點擊了按讚按鈕是非常合理的。但是當我點擊的時候，其他人也點擊了，所以按讚數可能增加了一個或多個，我該如何處理？
只要稍微忽略資料一致性就可以輕鬆解決這個問題。如果該帖子是熱門帖子，那麼在我查看該帖子期間，按讚數不可能不增加。這只是軟體的策略。為了快速回應，犧牲了一些資料一致性。
CAP定理C 代表一致性。無論從哪個節點讀取數據，都必須讀取相同的數據
。
A是Availability，表示即使某個節點掛掉了，是否所有的請求都能得到回應。P 是 Partition-tolerance，也就是網路連線遺失時可以運行多少個節點以及網路連線後是否可以恢復。
根據這個理論，最終可能存在三種系統：CA、AP 和 CP。
CA
最後，如果是分散式系統，P一定要保證。
美聯社
當多個節點與網路斷開連接時，即使所有節點對值的最新狀態不一致，連接節點的值也會降低。因此，斷開連接的節點之間的最新數據可能不匹配。不過，用戶可以繼續使用該服務，就像收到最新數據一樣。
一個代表性的例子是社群媒體。儘管這在現實中不太可能發生，但我們假設 Instagram 歐洲節點和亞洲節點之間的網路連線遺失。在此中斷期間，從亞洲訪問的用戶和從歐洲訪問的用戶看到的追蹤者數量、按讚數等略有不同，這是正常的。但該功能仍然有效。
一致性優於可用性
這是一個在網路故障情況下無法保證最新資料的情況下不會回應使用者要求的系統。
例子通常與金錢（交易）有關。假設飯店只剩下一間 50% 折扣的房間，但出現網路中斷。在AP系統中，預訂是假設兩個房間都有空的情況下進行的，因此存在超額預訂的可能性。 CP 系統不確定該資料的最新狀態，因此延遲或拒絕請求。
CAP理論其實是一個關於分割的理論。如果發生分割區，則必須選擇A或C。
但實際上，正常情況下，是不會發生分割的。可以應用於這種情況的理論是PACELC理論。
如果 (P) 則 (AC) 否則 (LC)
也就是說，分區的情況下考慮AC，否則考慮LC。
延遲與一致性
正常情況下，系統會在延遲和一致性之間進行權衡。這是一個宏大的理論，但事實上，它就像整個電腦工程的真理
。考慮權衡意味著在這兩個標準之間找到一定程度的妥協。
延遲可以直觀地確定從慢到快，但很難直觀地知道什麼是一致性。
一致性很強，光聽名字就感受到了。無論存取哪個節點，都必須看到相同的資料。換句話說，只有所有節點都有相同的數據，一致性才有可能。
我認為你可以考慮一家銀行。
總有一天它會保持一致的一致性。這意味著對於某個更改，並非所有客戶端都會同時看到相同的值，但在同步完成後它們最終會看到相同的值。
因此，根據軟體的特點，決定犧牲延遲的同時兼顧一致性，還是為了快速回應而犧牲一致性。
以上是本地優先軟體的詳細內容。更多資訊請關注PHP中文網其他相關文章！
