隨著業務的發展，使用者數量與資料數量不斷增加，迫使進行分庫分表。所謂分表就是指將乙個表的資料存放到多個表，然後查詢時候按id的範圍到對應的表裡去查。因為資料太多，單個表已經不足以儲存。
所謂分庫就是將資料存放到多個資料庫中，訪問時訪問其中乙個庫。
社群已經黃了，基本不用了。
不支援聯表，且依賴diamond配置中心。
社群也差不多黃了。
使用比較多，社群活躍，不用部署，效能高，但是需要引入依賴，系統間耦合度較高。
從cobar中改造，社群較活躍。需要部署，耦合度低。
顧名思義，水平拆分就是把乙個表的資料放到多個庫多個表中，提高併發量；垂直拆分即把表結構拆開，將字段拆分成多個表，充分利用資料庫快取。
選乙個流量較小的時段，直接停機手動更新。
再搞乙個新的庫，在原來進行增刪改的操作上都加上新的庫的增刪改，進行雙寫。然後使用欄位來判斷資料最後修改的時間，不允許用老資料來覆蓋新資料。同時開始導資料，直到資料完全一致，直接遷移到新庫。
先停機，再手動擴容
設定好幾臺資料庫伺服器，分表分庫分夠。
配置路由的規則
擴容申請增加更多的伺服器。
由dba負責遷移。
修改配置，調整遷移的庫。
修改配置，調整成新庫的位址。
重新發布。
給資料庫自增id設定不同的步長
本地直接生成，但是效能較差，沒有順序。
存在併發場景時出現重複的情況
簡單說就是把乙個64位的長整型id進行操作，第乙個bit捨棄，當前毫秒數作為41bits，工作機器id作為10bits，序列號作為12bits。比較適合高併發場景
簡單說就是基於主從複製架構。通俗的說就是兩個資料庫例項，乙個用來讀，乙個用來寫，然後通過主從架構，將寫的庫的資料搞的和讀的庫的詩句同步。主庫來控制寫，將變化寫入binlog，然後從庫連線到主庫之後，從庫把主庫的binlog複製到自己的binlog，然後從binlog中讀取命令，在自己的庫中執行。
主要分成兩個機制，乙個是半同步複製機制，指主庫寫入binlog後會強制資料同步到從庫，而從庫將日誌寫入之後操作就完成了。另乙個機制是並行複製，簡單說就是從庫開啟多執行緒讀取日誌然後並行重放不同庫的日誌，就是庫級別的並行。
mycat實現分庫分表讀寫分離
mysql8.0 主從同步配置 本地部署mycat的包為 mycat server 1.6.7.6 release 20201112144313 mac.tar.gz 2 解壓mycat包到指定目錄 tar zvf mycat server 1.6.7.6 release 2020111214431...
資料訪問層 分庫分表與讀寫分離
讀寫分離的目的是分擔主庫讀的壓力 對於資料量大並不起作用 但這裡存在乙個資料複製的問題。這裡有幾種解決方案 基於資料庫的日誌進行分庫分表。對資料做平滑遷移！基本原則是讀請求傳送到從庫，寫請求傳送到主庫。為了避免主從延遲帶來的讀不到剛剛更新的資料的問題，同一會話中，寫請求結束後指定時間內的讀請求也發到...
django orm 讀寫分離,分庫分app
1,讀寫分離 第一步 在settings下面配置 databases 第二步 資料庫遷移。python manage.py migrate 預設使用default的資料配置，完整的寫法為 python manage.py migrate database default 同樣的遷移完預設的資料庫後，...