PACELC

less than 1 minute read

突然想到之前開發andriod的同事在群裡面問了後端常見的面試題目有哪些,我就提到CAP,畢竟這算是一個後端很基本的觀念。

然後大神就提到CAP現在已經擴長成PACELC,而且這已經被用formal的證明過了。

查了一下PACELC,其實全稱是 PAC else LC,也就是如果系統會partitioned,那就只能在AC選一個,也就是原本的CAP

但即使我們能保證partitioned不會發生,也只能在latencyconsistency之間選一個(ELC的部分)。

這件事其實也沒那麼難理解,就拿quorum類型的演算法來舉例好了,假設今天要求每個write都要一半以上的node收到並處理完,我們才會返回前端,而且我們也系統保證訊息一定送得到其他node,也就是說不會有partitioned的狀況。

在這個狀況,考量某個node可能會因為不明的原因陷入繁忙,所以請求可能無法及時處理,但只要給足夠長的時間,就一定可以處理完並ack。這時候我們就只能在latencyconsistency之中選一個,如果系統可以等某個node處理完,那就是犧牲latency(可能等待好幾個小時甚至好幾天以上)。

如果我們設定一個timeout,timeout時間到了,不管有幾個node完成都回報已經完成,那就是犧牲了 consistency(系統無法保證能讀到最新的資料)。

因此現在設計系統不只要考慮CAP,還得考慮PACELC

Updated: