架構師速成8 3 可用性之分庫分表

有狀態分布式，涉及的知識就比較多了，只是我們能夠拿幾個現實的樣例由淺入深的來理解。

如果你是乙個開發負責人，開始使用單機的資料庫，突然一天資料庫硬碟掛掉了。你沒有做備份，然後就沒有然後了。

進入第2個公司，你意識到備份的重要性。每天定時備份到還有一台機器，突然有一天，資料庫硬碟掛掉了。

你心想幸好我有備份，然後巴拉巴拉的恢復起來。用了2個小時。老闆說不錯，可是—-我們由於宕機造成大量使用者流失，信譽下降，然後就又沒有然後了。上面說的就是單點的問題。

進入第3個公司，你認為單點非常可怕，所以主備做起來，資料自己主動同步到備庫，做到隨時準備切換。突然有一天，主資料庫硬碟掛掉了，你從容的改動資料庫連線指向備庫。重新啟動系統恢復了，僅僅用了5分鐘。

此時掌聲一片，你沉浸在無比的歡樂中，老闆說不錯，可是—就在這5分鐘我們丟了乙個上億的單子。我擦。你不是有益的吧！

（事實上這有可能是真實的片段，我們創業時，就30分鐘斷網。結果正好在舉行乙個大型的營銷策劃，不說了，我擦一會眼淚）。然後就又沒有然後了。事實上當你用上主備時，說明資料庫已經有狀態了，必須要區分誰是主，誰是備。

進入第4個公司，你不但做了主備，還做了高可用，通過ha實現了瞬時切換。

突然有一天。主資料庫硬碟掛掉了。你從容的端起了你的屌絲杯，世界清靜了。

老闆說不錯，小子我看好你。

從此你走向人生巔峰。出任cto，迎娶白富美。可是沒過多久問題來了，隨著使用者不斷的新增。你的資料庫搖搖欲墜，不時就抽瘋。老闆說搞定他，不然我就搞定你。

咋辦，分庫分表啊！

怎樣分，這就涉及到很多其它的規則了，比方依照使用者id是最常見的做法。此時你不但須要管主備並且還須要在程式中確定怎樣路由。結果集合並，如果再有機器新增。還要涉及資料遷移。另外還要防止出現反覆id的髒資料，須要全域性唯一主鍵。等等。

亞美蝶！知道有狀態的痛苦了吧。這也是為什麼有些同學轉投nosql的儲存的非常大原因，nosql替你遮蔽了這些規則。他在內部實現了路由、分庫、合併等等。

提到這裡不得不提一下**的牛逼產品–drds（沈公子是不是應該給些廣告費啊）。

自主運維

小表複製

分布式全域性唯一id

看到了吧。這就是有狀態帶來的痛苦。為了把有狀態變為無狀態有時候你須要做大量的工作。

有關分庫分表的關鍵點和難點，我新一章統一解說。