隨著豐巢業務系統快速增長，其核心系統的資料量，早就跨越了億級別，而且每年增量仍然在飛速發展。整個核心系統隨著資料量的壓力增長，不但系統架構複雜度急劇增長，資料架構更加複雜，傳統的單節點資料庫，已經日漸不能滿足豐巢的需求，當單錶數量上億的時候，oracle 還能勉強抗住，而 mysql 到單錶千萬級別的時候就難以支撐，需要進行分表分庫。為此，一款高效能的分布式資料庫，日漸成為剛需。
在網際網路公司業務量增大之後，並行擴充套件是最常用、最簡單、最實時的手段。例如負載均衡裝置拆流量，讓海量流量變成每個機器可以承受的少量流量，並且通過集群等方式支撐起來整個業務。於是當資料庫扛不住的時候也進行拆分。
但有狀態資料和無狀態資料不同，當資料進行拆分的時候，會發生資料分割槽，而整個系統又要高可用狀態下進行，於是資料的一致性變成了犧牲品，大量的核對工具在系統之間跑著保證著最終的一致性。在業務上，可能業務同學經常會遇到分過庫的同學說，這個需求做不了，那個需求做不了，如果有 sql 經驗的業務同學可能會有疑問不就是一條 sql 的事情麼，其實這就是分庫分表後遺症。
為此，我們需要有個資料庫幫我們解決以上問題，它的特性應該是：
根據以上期望進行分析，我們分析了目前市面上存在的 newsql 分布式資料庫，列表如下：
在綜合考慮了開源協議，成熟度，可控度，效能，服務支撐等綜合因素之後，我們選擇了 tidb，它主要優勢如下：
基於如上的原因，我們選擇了 tidb，作為豐巢的核心系統的分布式資料庫，來取代 oracle 和 mysql。
tidb 的基準測試，使用的工具是 sysbanch 進行測試，使用了 8 張基礎資料為一千萬的表，分別測試了 insert，select，oltp 和 delete 指令碼得到資料如下，查詢的 qps 達到了驚人的 14 萬每秒，而插入也穩定在 1 萬 4 每秒。
核心伺服器配置：
測試結果：
通過～
通過～因為是核心系統，安全起見，我們採取了多種方案保證驗證專案接入的可靠性，保證不影響業務。
在尋找第乙個接入專案的時候，我們以一下 4 個特徵，進行了選擇。
最終，我們選擇了推送服務。因為推送服務是豐巢用來傳送取件通知的核心服務，量非常大，但邏輯簡單，而且有備選外部推送方案，所以即便萬一出現問題，而不會影響使用者。
**因為 tidb 是完全相容 mysql 語法的，所以在這個專案的接入過程中，我們對**的修改是很細微的。**sql 基本零改動，主要是外圍**，包括：
以上三點，保證了整個系統在不強依賴於資料庫，並且能在高併發的情況下通過非同步落庫保護資料庫不被壓垮，並且在資料庫發生問題的時候，核心業務可以正常進行下去。
接入 tidb 之後，原先按照時間維度來拆分的十幾個分表，變成了一張大表。最明顯的變化，是在大資料量下，資料查詢能力有了顯著的提公升。
tidb 擁有很完善的監控平台，可以直觀的看到容量，以及節點狀態。
還能了解每個節點負載和 sql 執行的延時：
當然還能了解所在機器上的位置，cpu 記憶體等負載情況：
網路狀態也能清晰的監控到：
所有這些能讓團隊能分析出來有問題的 sql，以及資料庫本身的問題。
tidb 的接入過程，整體還是非常順利的，由於之前做了很多接入的保障工作，當天切換流量到 tidb 的過程只用了 10 分鐘的時間，在此也要感謝 tidb 對於 mysql 語法的相容性的支援，以及 pingcap 提供的各種有用的工具。到目前為止，系統的穩定執行了乙個多月，很好的滿足了豐巢的業務需求。
tidb 的改造完成之後，豐巢推送服務對大部分訊息進行了落地和查詢，截止目前為止，推送服務最大的日落地量已經達到了 5 千萬，而如果現在推送服務還使用的還是 mysql 的方案，就需要上各種的分庫分表方案，很多細緻的業務就無法或者難以開展。
此次 tidb 的改造，只是豐巢對於分布式資料技術探索的一小步，未來豐巢會將更多的分布式技術，引入到更多的業務系統，打造更加極致的產品和服務。
TiDB at 豐巢 嘗鮮分布式資料庫
隨著豐巢業務系統快速增長，其核心系統的資料量，早就跨越了億級別，而且每年增量仍然在飛速發展。整個核心系統隨著資料量的壓力增長，不但系統架構複雜度急劇增長，資料架構更加複雜，傳統的單節點資料庫，已經日漸不能滿足豐巢的需求，當單錶數量上億的時候，oracle 還能勉強抗住，而 mysql 到單錶千萬級別...
TiDB at 豐巢 嘗鮮分布式資料庫
隨著豐巢業務系統快速增長，其核心系統的資料量，早就跨越了億級別，而且每年增量仍然在飛速發展。整個核心系統隨著資料量的壓力增長，不但系統架構複雜度急劇增長，資料架構更加複雜，傳統的單節點資料庫，已經日漸不能滿足豐巢的需求，當單錶數量上億的時候，oracle 還能勉強抗住，而 mysql 到單錶千萬級別...
分布式資料
2017年04月25日 10 36 40 唐大麥 閱讀數 13767 標籤 分布式 mysql 資料庫事務 更多 個人分類 mysql 在開發中，為了降低單點壓力，通常會根據業務情況進行分表分庫，將表分布在不同的庫中 庫可能分布在不同的機器上 在這種場景下，事務的提交會變得相對複雜，因為多個節點 庫...