PACELC
· 3 min read
突然想到之前開發andriod的同事在群裡面問了後端常見的面試題目有哪些，我就提到CAP，畢竟這算是一個後端很基本的觀念。
然後大神就提到CAP現在已經擴長成PACELC，而且這已經被用formal的證明過了。
查了一下PACELC，其實全稱是 PAC else LC，也就是如果系統會partitioned，那就只能在A或C選一個，也就是原本的CAP。
但即使我們能保證partitioned不會發生，也只能在latency或consistency之間選一個(ELC的部分)。
這件事其實也沒那麼難理解，就拿quorum類型的演算法來舉例好了，假設今天要求每個write都要一半以上的node收到並處理完，我們才會返回前端，而且我們也系統保證訊息一定送得到其他node，也就是說不會有partitioned的狀況。
在這個狀況，考量某個node可能會因為不明的原因陷入繁忙，所以請求可能無法及時處理，但只要給足夠長的時間，就一定可以處理完並ack。這時候我們就只能在latency和consistency之中選一個，如果系統可以等某個node處理完，那就是犧牲latency(可能等待好幾個小時甚至好幾天以上)。
如果我們設定一個timeout，timeout時間到了，不管有幾個node完成都回報已經完成，那就是犧牲了 consistency(系統無法保證能讀到最新的資料)。