延續 Day 24

Sloppy Quorums and Hinted Handoff

資料庫若有適當的 quorums，它能夠允許獨立的節點掛掉而不用完成 failover (failover 意思請看 Day 21)，它也能允許某些節點變慢，因為只要等待到符合 quorums 的量就好了。

然而，quorums 並不能保證 uesr 始終能連線到所有的 n (節點)，網路一不穩就會造成 user 從大量的資料庫叢集中被斷掉某些連線，此時你只剩下小於 w 和 r 的節點可連線，所以你往後不可能達到 quorums 的量。

這個時候工程師們就有些權衡點可以煩惱了：

• 當能連線的節點數不足 w 和 r 的量時，我們應該全部 return error 嗎？
• 或者，就同意讓 client 寫入到某些能被連接的節點，不用寫到所有活著的 n 之中。

後者被稱為 sloppy quorums ，寫入和讀取一樣需要接收到 w 和 r 的量，但在這些節點中，可能不全都是在 n 裡面的節點。

書中用一個例子來說明，想像你被鎖在你家外面，你能敲你鄰居的門，然後坐在他的沙發上看電視。

一旦網路問題解決，剛剛那個被暫存資料的節點就會送資料給所有 n 裡面的節點，這個動作稱為 hinted handoff。

回到那個例子，你找到你家的鑰匙了，你的鄰居就會很有禮貌的請你從他的沙發上滾開然後叫你回家。

最後，sloppy quorums 不是一般我們認為的那種 quorums，它只是一種系統能更加耐用的保證，資料最終還是會被存到 某個地方的 w 個節點上，另外它沒有保證 r 在 hinted handoff 完成後能馬上看到資料。

sloppy quorums 通常在 Dynamo-style 資料庫中都是 optional (非必須)，如 Cassandra 和 Voldemort 皆是。

明天就會把 Replication 這個章節做總結啦！