前言：之所以要研究分表分庫這個技術點器联，是因為在開發(fā)的過程中蕉世，因為分表分庫踩了個小坑，雖然坑不算大狭姨，但是還是調試了很久宰啦。就是我在做推薦文章進入好友動態(tài)需求的時候，這個文章本身是一種type=51存儲在數據庫中饼拍，對應地轉發(fā)這篇文章的feed的type也是51赡模，只不過src_fid字段需要存儲源文章的feed_id。
而推薦文章這個需求需要給feed表新增一種類型type=56师抄，對應地在feed的分庫新增一種類型type=302漓柑。后面就發(fā)現遇到坑了，因為我把分庫的類型放到interaction_types中
渲染的時候就查不到源文章欺缘，導致讀取數據庫失敗栋豫。然后調試了很久，發(fā)現在讀取源文章的時候讀取不到谚殊，然后這條數據讀取就失敗了
在往上找，發(fā)現是這里讀取失敗了蛤铜，這里是feed封裝的方法嫩絮，怎么會讀取不到呢，于是我就進去看了看里面的代碼
if (table == conf.TBNAME_FEEDS and id_field in ('id', 'src_fid')) or \
(table != conf.TBNAME_FEEDS and id_field == 'fid'):
for global_fid in ids:
if is_explore_fid(global_fid):
explore_fids.append(self.convert_global_fid_to_fid(global_fid))
elif is_interaction_fid(global_fid):
interaction_fids.append(self.convert_global_fid_to_fid(global_fid))
elif is_generalcard_fid(global_fid):
generalcard_fids.append(self.convert_global_fid_to_fid(global_fid))
因為源文章的類型是e_id围肥，所以在查詢出來某一條feed之后剿干，會給src_fid自動拼裝上前綴，如果一條feed是e_開頭穆刻，會給他的src_fid拼上e_置尔，但是由于前面把分庫的類型寫成i_類型，所以去expolore庫查詢就會查不到氢伟。還有一個坑就是explore類型的type不能大于300榜轿，大于300就會insert失敗，這里也還沒找到根因朵锣。
從這個bug中我就產生了很多疑問谬盐，為什么文章的src_fid需要放到一個庫上呢？以及為什么要在代碼中加上這種前綴呢诚些？feed為什么要做分表分庫飞傀，它是怎么做的呢？數據如何同步的诬烹？
一砸烦、分表分庫的原理
當然第一步我們需要先了解一下分表分庫的基本概念，分表分庫上解決寫請求越來越多的問題绞吁，以及數據量暴增的問題幢痘，因為對于讀請求頻繁的場景，可以加緩存或者用一主多從來解決掀泳，但是如果寫請求過于頻繁雪隧，那么壓力都會集中在master上，master上面的IO员舵，網絡脑沿，連接池都會成為一種瓶頸÷砥В或者如果單表一直膨脹庄拇，那么對于磁盤來說壓力山大，而且很容易帶來慢查詢。所以需要分表分庫來解決這個問題措近。
分表的方式
- 垂直拆分
垂直拆分分為兩種溶弟，垂直分庫和垂直分表。如果單庫寫請求多瞭郑，并且分散在多張表的情況辜御，這種情況可以把庫里面的表分散到多個庫中，每個庫放在不同機器上屈张，不然還是會遇到機器的瓶頸問題擒权。如果壓力集中到一張表，那么可以大表拆小表阁谆，把不常用較長的字段遷移到擴展表碳抄，避免跨表查詢的壓力 - 水平拆分
水平拆分是將單表的數據水平拆分到不同服務器上，可以是按照Hash场绿、地理位置剖效、或者用戶id進行分表。水平拆分的難度比垂直拆分更大一些焰盗。
分表分庫需要解決的問題 - 事務支持
在單庫或者單表中璧尸，可以用MySQL的事務解決一致性問題，但是分表分庫的話姨谷，就需要解決分布式事務的問題了逗宁。 -
order by ,group by，join
分表分庫之后order by 和group by要怎么實現梦湘？以及跨庫的join問題
相關產品
image.png
二瞎颗、實名分表分庫
為什么實名要做分表分庫
- feed庫硬盤將滿，單表過大捌议，性能下降哼拔。
- 慢sql難以優(yōu)化
遇到的問題怎么解決的？
- 如何拆分
備選方案有幾種瓣颅，其中一種按照fid做hash倦逐，然后查詢的時候并行地讀取集群，跟業(yè)務無關宫补。優(yōu)點是邏輯簡單檬姥，易于擴展，缺點是存在無fid的表粉怕，而且有fid和無fid的跨庫join難以實現健民。還有一種是按照type來拆分，按照業(yè)務的type分在不同的庫贫贝，互動類型等等秉犹，優(yōu)點是業(yè)務邏輯清晰蛉谜，易于拆分，缺點是跨業(yè)務的查詢需要查詢多個集群崇堵。最終是選擇了按照type來拆分型诚，對于同一種業(yè)務來說，很少會跨集群鸳劳，這里也解釋了為什么src_fid和fid的前綴要一致狰贯，這是因為要避免跨集群訪問。 - 如何數據同步
數據雙寫->老庫數據遷移到新庫->下掉老庫的寫入邏輯 - join棍辕，order by 暮现，group by怎么做
代碼實現細節(jié)
- 將存在badge的互動消息以及渲染的數據遷移到Redis，減輕數據庫壓力楚昭，能夠給分表分庫，提供一些時間拍顷。
- view層新增一個fid到gfid的轉換抚太，保證在后端的代碼，都是帶前綴（e表示探索類型昔案，i表示互動類型）的gfid尿贫，這樣能夠區(qū)分是在哪個集群。
- 新增一個feed_manager踏揣，提供分表分庫后的數據讀寫方法
- 將對新老數據庫進行數據雙寫封裝成api庆亡，方便調用，保持數據一致捞稿。
三又谋、mycat的一些實現
