我們繼續來講分布式，回到我們的創業遊戲。
我們的業務規模上來了，客戶也越來越忠誠了。很多客戶都通過我們的訂票服務，來方便自己的行程。
那對這些老客戶，我們的宗旨是：要不斷超越客戶的期待。
所以，我們要建立我們的客戶資料庫。
我們要記錄下每個客戶的偏好的航空公司，偏愛的酒店。下次服務，才能直接更好地服務客戶。
怎麼辦？
最簡單的辦法，每個客服小姐姐各自用自己的記事本，記錄下客戶的號碼，偏好等資訊。
這些記事本就是我們的「客戶資料庫」。
這些資料都記錄在記事本上，會有乙個問題，如里同乙個客戶，每個客服小姐姐都記錄一次。是不是很費時費力，還重覆記錄，浪費資源。
怎麼辦？
還是跟之前一樣，拆分！垂直拆分。
再拆分一組，就叫：客戶資訊記錄組。
如果客戶小姐姐要記錄客戶資訊，就把資訊寫在紙條上，然後直接扔給：客戶資訊記錄組，讓這個小組自行處理：去除重複，更新資訊。
當然，我們的客戶資訊記錄組，可以用execl把客戶資訊上記錄下來。這樣，也方便資料處理。
現在我們的業務架構是這樣的：
有同學說，這個架構圖好像跟我們的it軟體架構圖很像。
沒錯。其實，所有的it軟體架構，遵從從業務架構設計的。
技術只是工具，業務才是核心。
回到我們的客戶資訊記錄組。這個組也有多個小姐姐記錄，如果大家都各自用自己的excel，怎麼保證大家的資訊沒有重複，都是一致的呢？
這個時候，我們就要上資料庫系統了。什麼是資料庫系統，簡單來說，就是記錄資料的倉庫。
剛開始，資料不大，問題不大。
當資料越來越多時，一台資料庫明顯支援不下。怎麼辦？
很簡單，多買幾台資料庫。能用錢解決的問題，就不是問題。
那現在問題又來了,這些資料庫怎麼保持資料一致性？
這個就是分布式資料庫要解決的問題。什麼是分布式資料庫？
簡單來說，它就是用多台資料庫組成乙個「整體」，給外界提供資料庫服務的資料倉儲系統。
有同學會說了，你要很大很大的資料量才能用分布式資料庫。你一家小公司，用這個是不是浪費了？
有道理！一般情況下，小公司是用不上分布式。但我們做為有夢想的企業家，一定要提前規劃，站在未來看現在！我們才有機會成功！
馬雲說過：夢想還是要有的，萬一實現了呢？
所以，叫那個程式設計師開始幹活！
首先我們要分析一下業務。
客戶小姐姐大部分情況下，都 是查詢客戶資訊的比較多，佔了80%。新增，和更新資訊的情況比較少，佔了20%。
如果查詢和記錄都在乙個資料庫，經常會造成衝突，造成「鎖表」。這會造成嚴重的效能問題，會造成對客戶體驗嚴重的損害！
很自然，我們可以想到，那是不是可以分開兩個庫，乙個用來記錄，乙個用來查詢。
這就是讀寫分離，讀寫分離是很重要的設計原則。可以極大地提高查詢的效率。如下：
儘管採取了讀寫分離的方式，但隨著資料庫的壓力繼續增加，資料庫的瓶頸越來越突出。怎麼辦？
我們分別對讀寫庫的表進行水平拆分，也就是分表。
比如，可以按表中的唯一id的hash值來分，如果hash值是偶數，就放在「偶數表」，如果hash值是奇數，就放在奇數表。
如下圖：
講到這裡，我們基本上就建立了分布式資料庫系統。
明天繼續講分布式架構的演進。
分布式 2分布式事務
分布式 1概述cap和base 分布式 2分布式事務 分布式 3分布式一致性演算法 分布式 4集群 分布式 5服務限流演算法 分布式 6分布式id 分布式 7效能壓測 分布式 8日誌鏈路跟蹤 分布式 9分布式鎖 redis鎖的幾種實現 參考 分布式系統間各種問題 宕機 網路不穩定 本地事務無法滿足需...
分布式隨筆1 分布式概述
分布式，好寬泛的話題，來來咱扯兩句。你乙個人再強壯，也扛不了100袋大公尺，單機的資源也很有限，大 的大資料量 高併發以及各種業務需求 童鞋們的web應用，伺服器 rdb mq 服務 快取以及各類基礎設施，更別說還有安全 大資料方面的需求 於是，我們常見的面向服務的dubbo springcloud...
分布式鎖 3 分布式鎖租約續期
redis分布式鎖在加鎖的時候，我們一般都會給乙個鎖的過期時間 ttl 這是為了防止加鎖後client宕機，鎖無法被釋放的問題。但是所有這種姿勢的用法都會面臨同乙個問題，就是沒發保證client的執行時間一定小於鎖的ttl。雖然大多數程式設計師都會樂觀的認為這種情況不可能發生，但是各種異常情況都會導...