高併發，大資料量系統的資料結構優化思路

1.網際網路浪潮面臨的問題

大資料量

設計及測試階段，由於資料量小，很難發現薄弱之處。

高併發

系統投產初期，由於負荷低，可以滿足常規的使用要求，不易發現問題。

隨著業務量逐漸增大，各種營銷活動的開展。資料效能問題成為系統執行的主要瓶頸。

2.常規的解決手段

2.1資料庫連線池

• 選擇高效能的資料庫連線池元件，如druid，hikari

2.2讀寫分離

• 考慮主庫與只讀庫同步的問題。

2.3資料庫設計

2.3.1分庫分表

• 單庫單表與分庫分表存在效能差異。
• 分割槽與分庫分表存在效能差異，且分割槽靈活性不夠。

水平拆分

拆分原則：3年內，oracle單表達2000w，mysql單表達500萬

• 常見方案：按照uid拼接的一定規則進行拆分，查詢時確保單庫單表。
• 基礎資料同步問題：定時從主庫拉取重新整理+訊息通知。
• 服務端框架Mycat，sharding-proxy
• 客戶端框架sharding-jdbc
• 熱點賬戶問題：賬戶切分

垂直拆分

拆分原則：按業務

• 目的：減少單表欄位數。
• 按業務拆分：如訂單資料，按照商戶，使用者，支付通道進行拆分。
• 各庫儲存全域性（流程）的唯一流水號，以方便追溯。

2.3.2適度的反正規化設計

• 在保證資料完整性，唯一性的前提下，可適度的增加冗餘欄位，避免聯表查詢。一般情況下，如果join的表資料超過1萬條，就會出現效能問題。

2.3.3儘量不用sequence做主鍵

• 不便於系統的遷移和資料恢復
• 多一次與資料庫的互動

2.4優化查詢

• 儘量減少對資料庫的訪問次數

第1級：訂單資料和支付流水資料；這兩塊資料對實時性和精確性要求很高，所以不新增任何快取，讀寫操作將直接運算元據庫。

第2級：使用者相關資料；這些資料和使用者相關，具有讀多寫少的特徵，所以可使用redis進行快取。

第3級：支付配置資訊；這些資料和使用者無關，具有資料量小，頻繁讀，幾乎不修改的特徵，所以我們使用本地記憶體進行快取。

• 儘量減少對錶的訪問行數
• 儘量最小化結果集
• 查詢業務資料必須使用索引
• 關鍵SQL，需分析執行計劃

3.微服務面臨的問題

3.1資料一致性問題

• 2PC
• 3PC
• TCC
• 訊息確保
• saga

推薦訊息確保和saga

3.2連線數過多問題

• 在交易量較小，應用拆分顆粒度較粗的階段，可通過制度手段管理應用配置資料庫連線數過大的問題。
• 微服務及容器化後，子系統拆分的越來越多，資料庫連線數會成為珍貴資源，可採用中心化的資料庫服務中介軟體（如Mycat）做為解決方案。

4.附錄

資料型別對比

Mysql	Oracle	Java	說明
BIGINT	NUMBER	java.lang.Long
CHAR	CHAR	java.lang.String	定長
DECIMAL	NUMBER	java.math.BigDecimal	金額（分）
VARCHAR	VARCHAR2	java.lang.String
FLOAT	FLOAT	java.lang.Float
INT	NUMBER	java.lang.Integer
TIMESTAMP	TIMESTAMP	java.sql.Timestamp

參考資料：https://blog.csdn.net/chenpeng19910926/article/details/51789934