狀態(tài)

隨著網(wǎng)路的發(fā)展，使用者互動和顯示的元素數(shù)量不斷增加。這些元素會改變使用者看到的螢?zāi)?。改變螢?zāi)坏氖挛锟梢远x為「狀態(tài)」。

例如，在資訊網(wǎng)頁（例如登陸頁面）的情況下，「狀態(tài)」是要顯示的一條訊息。

接下來，在 GitHub 的情況下，有各種信息，例如我的信息、我的存儲庫信息、星星數(shù)量等。由於向使用者顯示的螢?zāi)灰蜻@些而異，因此所有這些都可以被視為“狀態(tài)” '。

作為一個更複雜的例子，你可以舉出像Figma這樣的例子。螢?zāi)簧系乃袌D形，如點、線、面，都是「狀態(tài)」。此外，協(xié)作功能需要您分享您自己以外的其他人的狀態(tài)。

狀態(tài)與數(shù)據(jù)

狀態(tài)都是數(shù)據(jù)。關(guān)於用戶的資訊、用戶自訂的資訊等都是儲存在某處的數(shù)據(jù)，這些數(shù)據(jù)很快就成為用戶看到的螢?zāi)坏臓顟B(tài)。通常，這些資料會作為單一事實來源儲存在伺服器上。如果您登入某個網(wǎng)站，它將作為單行保存在該網(wǎng)站伺服器上的使用者表中。

數(shù)據(jù)太遠(yuǎn)

現(xiàn)在的網(wǎng)路很複雜。一個螢?zāi)簧巷@示著無數(shù)的按鈕和大量的數(shù)據(jù)。有很多訊息，其時效性很重要。每當(dāng)這些狀態(tài)發(fā)生變化時，資料必須來回傳送到伺服器以確保一致性。如果你只需要每分鐘接收“下一頁”，就像文件一樣，那並不是什麼大問題。然而，在像Notion這樣使用者不斷修改資料的情況下，這就成了一個大問題。如果我每次在頁面上設(shè)定類似功能時都必須加載它，我會感到不安

。

樂觀更新

想像一下在 Instagram 等社群媒體網(wǎng)站上點擊「讚」按鈕。當(dāng)我點讚的時候，我必須去伺服器保存我對帖子點讚的信息，將帖子的點讚數(shù)加一，然後獲取當(dāng)前帖子的點贊數(shù)並顯示給我。

但在 Instagram 上，按讚數(shù)會在 0.001 秒內(nèi)隨著動畫而增加。

這可以透過在資訊到達(dá)伺服器之前更新客戶端的狀態(tài)來實現(xiàn)。這個想法是更新客戶端的狀態(tài)，假設(shè)類似的資料會很好地記錄在伺服器上。大多數(shù)情況下，與伺服器的通訊都會成功，所以我們樂觀地判斷這是成功的。

當(dāng)然，也有發(fā)送到伺服器的請求失敗的情況，所以要注意失敗時回滾客戶端狀態(tài)。

回應(yīng)性高於一致性

優(yōu)化顯示我是否點擊了按讚按鈕是非常合理的。但是當(dāng)我點擊的時候，其他人也點擊了，所以按讚數(shù)可能增加了一個或多個，我該如何處理？

只要稍微忽略資料一致性就可以輕鬆解決這個問題。如果該帖子是熱門帖子，那麼在我查看該帖子期間，按讚數(shù)不可能不增加。這只是軟體的策略。為了快速回應(yīng)，犧牲了一些資料一致性

。

CAP定理

在分散式系統(tǒng)研究中，有CAP理論。理論指出，配置分散式系統(tǒng)時，只能使用 C、A、P 中的兩個。

C 代表一致性。無論從哪個節(jié)點讀取數(shù)據(jù)，都必須讀取相同的數(shù)據(jù)

。

A是Availability，表示即使某個節(jié)點掛掉了，是否所有的請求都能得到回應(yīng)。

P 是 Partition-tolerance，也就是網(wǎng)路連線遺失時可以運行多少個節(jié)點以及網(wǎng)路連線後是否可以恢復(fù)。

根據(jù)這個理論，最終可能存在三種系統(tǒng)：CA、AP 和 CP。

CA

理論上，分散式系統(tǒng)可以選擇CA，但我們決定不將網(wǎng)路連線遺失時不運作的系統(tǒng)稱為分散式系統(tǒng)。

最後，如果是分散式系統(tǒng)，P一定要保證。

美聯(lián)社

可用性高於一致性

當(dāng)多個節(jié)點與網(wǎng)路斷開連接時，即使所有節(jié)點對值的最新狀態(tài)不一致，連接節(jié)點的值也會降低。因此，斷開連接的節(jié)點之間的最新數(shù)據(jù)可能不匹配。不過，用戶可以繼續(xù)使用該服務(wù)，就像收到最新數(shù)據(jù)一樣。

一個代表性的例子是社群媒體。儘管這在現(xiàn)實中不太可能發(fā)生，但我們假設(shè) Instagram 歐洲節(jié)點和亞洲節(jié)點之間的網(wǎng)路連線遺失。在此中斷期間，從亞洲訪問的用戶和從歐洲訪問的用戶看到的追蹤者數(shù)量、按讚數(shù)等略有不同，這是正常的。但該功能仍然有效。

CP

一致性優(yōu)於可用性

這是一個在網(wǎng)路故障情況下無法保證最新資料的情況下不會回應(yīng)使用者要求的系統(tǒng)。

例子通常與金錢（交易）有關(guān)。假設(shè)飯店只剩下一間 50% 折扣的房間，但出現(xiàn)網(wǎng)路中斷。在AP系統(tǒng)中，預(yù)訂是假設(shè)兩個房間都有空的情況下進行的，因此存在超額預(yù)訂的可能性。 CP 系統(tǒng)不確定該資料的最新狀態(tài)，因此延遲或拒絕請求。

PACELC定理

CAP理論其實是一個關(guān)於分割的理論。如果發(fā)生分割區(qū)，則必須選擇A或C。

但實際上，正常情況下，是不會發(fā)生分割的?？梢詰?yīng)用於這種情況的理論是PACELC理論。

如果 (P) 則 (AC) 否則 (LC)

也就是說，分區(qū)的情況下考慮AC，否則考慮LC。

液相層析

延遲與一致性

正常情況下，系統(tǒng)會在延遲和一致性之間進行權(quán)衡。這是一個宏大的理論，但事實上，它就像整個電腦工程的真理

。

考慮權(quán)衡意味著在這兩個標(biāo)準(zhǔn)之間找到一定程度的妥協(xié)。

延遲可以直觀地確定從慢到快，但很難直觀地知道什麼是一致性。

一致性強

一致性很強，光聽名字就感受到了。無論存取哪個節(jié)點，都必須看到相同的資料。換句話說，只有所有節(jié)點都有相同的數(shù)據(jù)，一致性才有可能。

我認(rèn)為你可以考慮一家銀行。

最終一致性

這是一種稱為

總有一天它會保持一致的一致性。這意味著對於某個更改，並非所有客戶端都會同時看到相同的值，但在同步完成後它們最終會看到相同的值。

因此，根據(jù)軟體的特點，決定犧牲延遲的同時兼顧一致性，還是為了快速回應(yīng)而犧牲一致性。

以上是本地優(yōu)先軟體的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！