用心分享每一篇乾貨
一
是什麼決定了電商雙11大促的成敗？！

就按照市面上的上線電商平臺而言，一個互動性優越的前端架構，一個或多個web伺服器（可橫向擴充套件）及資料庫伺服器。

那麼問題來了，資料庫伺服器並不能和web伺服器一樣進行橫向擴充套件，畢竟不是程式碼，不能隨意的貼上複製，那麼我們就來聊聊雙11中的大促中電商們的資料庫架構。

一般均為一個主伺服器、多個從伺服器

Master——Slave×N

期間沒有主從複用元件，一旦主伺服器出現故障、不能立馬切換

那麼大促中什麼影響了資料庫效能呢？

sql查詢速度、伺服器硬體、網絡卡流量、磁碟IO

超高的QPS和TPS

風險：效率底下的SQL（mysql並不支援多cpu併發查詢）

QPS：每秒鐘處理的查詢量

大量的併發和超高的CPU使用率

風險：大量的併發——資料庫連線數被佔滿（max_connections預設100）

超高的CPU使用率——因CPU資源耗盡而出現宕機

磁碟IO

風險：磁碟IO效能突然下降（使用更快的磁碟裝置）

其他大量消耗磁碟效能的計劃任務（調整計劃任務，做好磁碟維護）

網絡卡流量

風險：網絡卡IO被佔滿（1000Mb）

旅行 心率圖分割線
如何避免無法連線資料庫的情況：

1、減少從伺服器的數量

2、進行分級快取

3、避免使用“ SELECT * ”進行查詢

4、分離業務網路和伺服器網路

當然對於大型電商而言，還有大表給他們帶來的各種問題

什麼樣的表可以稱之為大表？這只是相對而言

·記錄行數巨大，單表超過千萬行

·表資料檔案巨大，表資料檔案超過10G

大表對查詢的影響：

慢查詢：很難再一定的時間內過濾出所需要的資料

顯示訂單——來源少——區分度低——大量磁碟IO——降低磁碟效率——大量慢查詢

大表對DDL操作的影響：

建立索引需要很長時間

風險：MYSQL版本<5.5 建立索引會鎖表

MYSQL版本>=5.5 雖然不會鎖表但會引起主從延遲

修改表結構需要長時間鎖表

風險：會造成長時間的主從延遲（主從複製為單執行緒）

影響正常的資料操作

如何處理資料庫中的大表

1、分庫分表把一張大表分成多個小表

難點：分表主鍵的選擇、分表後跨分割槽資料的查詢和統計

2、大表的歷史資料歸檔

減少對前後端業務的影響

難點：歸檔時間點的選擇、如何進行歸檔操作

除了大表 一定就還有大事務啦！

1、事務是資料庫系統區別於其他一切檔案系統的重要特性之一

2、事務是一組具有原子性的SQL語句，或是一個獨立的工作單元

事務———原子性、一致性、隔離性、永續性

事務的原子性（ATOMICITY）

定義：一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗，對於一個事務來說，不可能只執行其中的一部分操作

（整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾）

事務的一致性（CONSISTENCY）

定義：一致性是指事務將資料庫從一種一致性狀態轉換到另一種一致性狀態，在事務開始之前和事務結束後資料庫中資料的完整性沒有被破壞

事務的隔離性（ISOLATION）

定義：隔離性要求一個事務對資料庫中資料的修改，在未提交完成之前對於其他事務是不可見的

SQL標準中定義的四種隔離級別

·未提交讀（READ UNCOMMITED）

·已提交讀（READ COMMITED）

·可重複讀（REPEATABLE READ）

·可序列化（SERIALIZABLE）

（隔離性由低到高、併發性由高到低）

事務的永續性（DURABILITY）

定義：一旦事務提交，則其所做的修改就會永久儲存到資料庫中。此時即使西永崩潰，已經提交的修改資料也不會丟失

什麼是大事務

定義：執行時間比較長，操作的資料比較多的事務

風險：鎖定太多的資料，造成大量的阻塞和鎖超時、回滾時所需時間比較長、執行時間長，容易造成主從延遲

如何處理大事務

1、避免一次處理太多的資料

2、移除不必要在事務中的SELECT操作