分庫分表

分庫分表

拆分的目的是什麼？

拆庫，仍是拆表？二者結合？

拆庫方便進行擴容

其規則設計的好，表也能夠移動

拆成多少合適

單實例最多1千張表

單表按1千萬~1億條數據規劃，10G左右

對於大字段blob，text字段建議拆分並壓縮，用主鍵關聯(查詢)

每一個表必須有主鍵，主鍵採用自增int/bigint

單庫200~400張表

Hash拆分

拆分紅10庫10表

dbRule: db + (id/10 % 10)

tbRule: t + (id % 10)

Range拆分

id < 1千萬在DB0

1千萬 <= id <2千萬 DB1

按日期拆分

create_time按月一個表 

按業務垂直拆分

用戶基本資料庫

好友關係庫

等等

 

數據庫拆分後續

拆分策略最好一開始就想清楚，不要在實施過程當中多變

優先採用可控性強的策略，也就是更方便後續擴展的策略

不單純追求拆分後的均衡離散性 

拆分以後，須要選擇一個合適的proxy方案

不必定非要proxy，單總體改造代價必定不能過高

proxy方案選擇更適合本身場景的

 

數據分級決定緩存策略不一樣

第一級：訂單數據和流水數據，這兩塊數據對實時性和精確性要求很高，因此不添加任何緩存，讀寫操做將直接操做數據庫 

第二級：用戶相關數據，這些數據和用戶相關，具備讀多寫少的特徵，因此咱們適用redis進行緩存

第三級：配置信息，這些數據和用戶無關，具備數據量小，頻繁讀，幾乎不修改的特徵，可使用本地內存進行緩存 

 

架構方案關鍵點 

如何保證多節點的寫入可用性

keepalived+雙主，但只寫一個節點

PXC，多庫多表並行寫入

MHA，一主多從，或者雙主多從

大殺器，MGR 

如何提升讀可用性

一主一從，從故障時切換到主

一主多從，多從可作高可用，或者根據狀況切到主

雙主多從，同上

寫壓力分攤

垂直拆分

水平拆分

混合方案

讀壓力分攤

多從

nosql/cache

而且採用多級分層方案 

大數據量，而且進行分庫分表後，不建議的SQL

複雜鏈接查詢

跨庫、跨表查詢

分佈式事務

子查詢

涉及到跨庫跨表查詢時，一般須要好的中間層來解決

這個中間層大多靠自主開發，不多有現成的通用方案

跨表JOIN代價較高時，甚至能夠考慮反範式，把多列存放在一個冗餘表中，更方便查詢 

 

如何應對瞬間暴增的業務壓力 

快速響應，但延遲服務

前端利用CDN、緩存、靜態內容抗住第一道訪問

前端頁面/APP端/轉發層，增長刷新頻率控制

動態請求須要有流控

業務隔離

區分不一樣業務所在資源池

重點業務，重點保障

彈性資源池(雲) 

 

秒殺業務 

面臨問題：高併發、超賣

前端提早準備措施：靜態化、擴容、限流、服務降級機制

後端：限制MySQL的併發線程(並啓用thread pool)、訂單提交時再次判斷，是否還有庫存，能夠直接使用AliSQL分支版本(應對秒殺場景特別有效)

提早把商品分攤到多個Redis實例中，根據用戶ID哈希分配到各實例 

Redis中保存2個隊列，一個被秒的，一個待秒的

還有個隊列保存已經參加過秒殺的用戶列表

秒殺成功後，被秒隊列+1，待秒隊列-1，加入已秒用戶列表

讀取已秒隊列及已秒用戶列表，更新到MySQL中

重點：入口請求有序排隊避免蜂擁，合併寫請求減少寫壓力

 

互聯網經常使用高可用架構方案

架構案例

 

NOSQL、NEWSQL對MySQL的影響

不管NOSQL仍是NEWSQL，都不能很好支持事務原子性

NOSQL更多的是cache做用

簡單的KV數據，能夠用innodb memcached plugin解決

複雜的文檔數據，能夠用JSON數據類型解決

NOSQL因爲弱關係約束，後期反倒多是災難

NEWSQL主要解決數據分佈式存儲

真正須要存儲海量數據時，更多的是考慮用大數據解決方案 

 

數據庫安全 

防止SQL注入

SQLmap

BSQL Hacker

Havij

Safe3 SQL Injector

防止長時間運行的SQL

及時幹掉

啓用timeout