數據庫架構

1、最好不要在主庫上數據庫備份、大型活動前取消這類計劃

2、影響數據庫的因素:SQL查詢速度,服務器硬件、網卡流量、磁盤IO

QPS:每秒鐘處理的查詢量

TPS:

大量的併發:數據庫鏈接數被佔滿(max_connections默認是100)

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

磁盤IO:性能下降,使用SSD等更快的設備

網卡IO:被佔滿

如何避免無法連接數據庫的情況:

1、減少從服務器的數量

2、進行分級緩存

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

4、分離業務網絡和服務器網絡 

大表對DDL操作的影響

修改表結構需要長時間鎖表:mysql<5.5建立索引會鎖表

會造成長時間的主從延遲:mysql>= 5.5

分庫分表難點:分表主鍵的選擇、分表後,跨分區數據的查詢和統計

大錶的歷史數據歸檔:減少對前後端業務的影響

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

事務:

原子性:必須視爲一個不可分割的最小工作單位,要麼全部成功,要麼全部失敗

一致性:事務將數據從一種一致性狀態轉換到另外一種一致性狀態,在事務開始之前和事務開始結束之後數據庫中數據的完整性沒有被破壞

隔離性:一個事務對數據庫中數據的修改,在未提交完成前對於其它事務是不可見的

  未提交讀(READ UNCOMMITED)

  已提交讀(READ COMMITED)

  可重複讀(REPEATATLE READ)

  可串行化(SERIALIZABLE)

從上到下:隔離性越來越高,併發性越來越低

持久性:一旦事務提交,則其所做的修改就會永久保存到數據庫中,即使系統崩潰,已經提交的修改數據也不會丟失

大事務:運行時間比較長,操作的數據比較多的事務

風險:

鎖定太多的數據,造成大量的阻塞和鎖超時

回滾時所需時間比較長

執行時間長,容易造成主從延遲

如何處理大事務

1、避免一次性處理太多的數據

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章