開源數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)原則

豐滿網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、自適應(yīng)網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)公司從2013年開始到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。

01. 技術(shù)選型

選擇成熟的平臺(tái)和技術(shù)，同時(shí)是最熟悉的，能做到極致的，用好不用壞，用熟不用生。目前業(yè)界的MySQL主流分支版本有Oracle官方版本的MySQL、Percona Server、MariaDB。

02. 高可用選擇

高可用解決方案探討的本質(zhì)上是低宕機(jī)時(shí)間解決方案，可以理解成高可用的反面是不可用，絕大部分情況下數(shù)據(jù)庫(kù)宕機(jī)才會(huì)導(dǎo)致數(shù)據(jù)庫(kù)不可用。隨著技術(shù)發(fā)展，開源數(shù)據(jù)庫(kù)方面很多高可用組件（主從復(fù)制、半同步、MGR、MHA、Galera Cluster）,對(duì)應(yīng)場(chǎng)景，只有適合的，沒有萬(wàn)能的，需要理解每個(gè)高可用優(yōu)缺點(diǎn)。

03. 表設(shè)計(jì)

表設(shè)計(jì)方面目前一致堅(jiān)持和提倡的原則：

• 單表數(shù)據(jù)量
  

所有表都需要添加注釋，單表數(shù)據(jù)量建議控制在 3000 萬(wàn)以內(nèi)

• 不保存大字段數(shù)據(jù)
  

不在數(shù)據(jù)庫(kù)中存儲(chǔ)圖片、文件等大數(shù)據(jù)

• 表使用規(guī)范

拆分大字段和訪問(wèn)頻率低的字段，分離冷熱數(shù)據(jù)

單表字段數(shù)控制在 20 個(gè)以內(nèi)

• 索引規(guī)范
  

1.單張表中索引數(shù)量不超過(guò) 5 個(gè)

2.單個(gè)索引中的字段數(shù)不超過(guò) 5 個(gè)

3.INNODB 主鍵推薦使用自增列，主鍵不應(yīng)該被修改，字符串不應(yīng)該做主鍵，

如果不指定主鍵，INNODB 會(huì)使用唯一且非空值索引代替

4.如果是復(fù)合索引，區(qū)分大的字段放在索引前面

5. 避免冗余或重復(fù)索引：合理創(chuàng)建聯(lián)合索引（避免冗余）

6. 不在低基數(shù)列上建立索引，例如‘性別'

7. 不在索引列進(jìn)行數(shù)學(xué)運(yùn)算和函數(shù)運(yùn)算

• 字符集utf8mb4(偏生字，表情符)
  

04. 優(yōu)化原則

05. 復(fù)制方式

MySQL復(fù)制方式提供異步方式、半同步方式、全局事務(wù)強(qiáng)一致性、binglog同步。需要不同業(yè)務(wù)系統(tǒng)間 或 兩個(gè)數(shù)據(jù)庫(kù)間進(jìn)行同步。異步方式可以防止故障和效率問(wèn)題的蔓延，擴(kuò)大化；但強(qiáng)一致性會(huì)更復(fù)雜，并發(fā)、事務(wù)大小都有求限制。

06. 分離原則

區(qū)分核心的業(yè)務(wù)，重要業(yè)務(wù)，渠道，內(nèi)部業(yè)務(wù)的業(yè)務(wù)系統(tǒng)，對(duì)不同的系統(tǒng)設(shè)置不同的架構(gòu)。為核心業(yè)務(wù)設(shè)置 最佳為分庫(kù)，多活 專用高速公路，其他業(yè)務(wù)可以做讀寫分離，緩存。

07. 擴(kuò)展性

對(duì)于系統(tǒng)來(lái)說(shuō)擴(kuò)展性很重要，盡量做到水平擴(kuò)展。避免過(guò)度依賴縱向擴(kuò)展，同時(shí)具備縱向，橫向擴(kuò)展的能力，例如無(wú)狀態(tài)應(yīng)用應(yīng)該多套負(fù)載均衡多活部署，數(shù)據(jù)庫(kù)分庫(kù)架構(gòu)。

08. 讀寫分離

• 讀多寫少場(chǎng)景（10%寫 90%讀）
• 復(fù)制存在延遲，業(yè)務(wù)對(duì)延遲不敏感的
• 實(shí)現(xiàn)方式：

1. 通過(guò)應(yīng)用代碼配置讀寫分離，

2. 通過(guò)中間代理方式路由只讀庫(kù) &

3. 業(yè)務(wù)和數(shù)據(jù)庫(kù)為一個(gè)單位

09. 分庫(kù)分表

• 當(dāng)表中數(shù)據(jù)記錄的數(shù)量超過(guò)3000萬(wàn)條，再好的索引也已經(jīng)不能提高數(shù)據(jù)查詢的速度，這時(shí)需要將表拆分成更多的小表，增加性能，增加彈性，避免發(fā)生垮庫(kù)進(jìn)行操作。
• 引入中間價(jià)要考慮性能代價(jià),聚合需求。
• 分庫(kù)原則盡量在app 上層進(jìn)行分庫(kù)，就是流量。
• 分多少合適：可用性和性能滿足TPS。
• 路由：寫入配置文件 或則 插表 或則 zookeeper。
  

10. 歸檔原則

歷史數(shù)據(jù)定期進(jìn)行歸檔 或則 移到其他大數(shù)據(jù)平臺(tái)。能讓輕量級(jí)數(shù)據(jù)庫(kù)更多緩存有用的數(shù)據(jù)。

在MySQL分區(qū)表里 注意要避免分區(qū)鎖，只能寫讀的場(chǎng)景。

11. 連接池的要求

長(zhǎng)鏈接，自動(dòng)重鏈，延時(shí)和異常記錄， 彈性鏈接，檢測(cè)滿，異常告警，進(jìn)階要求

是記錄所有訪問(wèn)情況，可以擴(kuò)展出很多能力。

應(yīng)用和數(shù)據(jù)庫(kù)連接池設(shè)置，數(shù)據(jù)庫(kù)允許的連接數(shù)設(shè)置，常見問(wèn)題。

A ）應(yīng)用的數(shù)據(jù)庫(kù)連接池設(shè)置偏小，一旦數(shù)據(jù)庫(kù)相應(yīng)慢（新上線應(yīng)用，缺少索引 等）則應(yīng)。

用排隊(duì)嚴(yán)重，甚至雪崩，而遺憾的是數(shù)據(jù)庫(kù)能力還遠(yuǎn)為用盡。

B ）不具備失效及時(shí)發(fā)現(xiàn)和重新鏈接數(shù)據(jù)庫(kù)能力。

C ）隔離級(jí)別設(shè)置：RR 和 RC下不同的表現(xiàn)。

12. 應(yīng)用解耦

通過(guò)應(yīng)用訪問(wèn)數(shù)據(jù)庫(kù)而不是直接訪問(wèn)，重要業(yè)務(wù)不能依賴低保障級(jí)別的系統(tǒng)，應(yīng)用層重要業(yè)務(wù)和普通業(yè)務(wù)解耦，關(guān)鍵業(yè)務(wù)要獨(dú)立。

13. 組件失效免疫能力

單一應(yīng)用，單一硬件，甚至單一基礎(chǔ)設(shè)施，單一站點(diǎn)容災(zāi)，業(yè)務(wù)影響，故障恢復(fù)能力，要季度級(jí)別進(jìn)行演練。

14. 關(guān)鍵詞組件減負(fù)

特別是數(shù)據(jù)庫(kù)訪問(wèn),數(shù)據(jù)庫(kù)成本最高，擴(kuò)展性最難，可用性保障最難，恢復(fù)難度和時(shí)間大。

減負(fù)：能不用就不用，使用最簡(jiǎn)單，成本最低的語(yǔ)句，避免大事務(wù)，慎用兩階段事務(wù)。

15. 灰度數(shù)據(jù)庫(kù)

減少發(fā)布時(shí)變更數(shù)據(jù)庫(kù)對(duì)全局的影響,只有應(yīng)用程序灰度是不夠的，還要有專門的灰度數(shù)據(jù)庫(kù)。在分庫(kù)、讀寫分離架構(gòu)下，一套含數(shù)據(jù)庫(kù)的完整應(yīng)用架構(gòu)，變的很自然。

所為灰度環(huán)境就是生產(chǎn)環(huán)境，生產(chǎn)數(shù)據(jù)，所影響的也是生產(chǎn)環(huán)境，只是范圍比測(cè)試環(huán)境更廣，更真實(shí)。其實(shí)就是小范圍的生產(chǎn)環(huán)境。類似于游戲內(nèi)測(cè)。

16. 高仿真架構(gòu)體系

建立高仿真架構(gòu)體系

• 數(shù)據(jù)庫(kù)，操作系統(tǒng)升級(jí)：應(yīng)用是否適應(yīng)，性能會(huì)變好， 還是變壞
• 應(yīng)用上線發(fā)布，系統(tǒng)變更（列如換平臺(tái)），提前判斷業(yè)務(wù)影響和性能瓶頸
• 應(yīng)對(duì)突發(fā)交易量，例如雙十一，性能極限在哪里，瓶頸在哪里。
  

17. 容災(zāi)保障

高可用是運(yùn)維核心要求，容災(zāi)是最后屏障

例如 雙活比單活好，MGR比復(fù)制架構(gòu)好，重要系統(tǒng)要做好高可用，容災(zāi)建設(shè)。

18. 多中心建設(shè)

冗余是基礎(chǔ)，多中心建設(shè)是為了提升容災(zāi)能力和擴(kuò)展能力，并保障業(yè)務(wù)。

19. 應(yīng)用和數(shù)據(jù)庫(kù)是一個(gè)整體

應(yīng)用和運(yùn)維人員一起，解決應(yīng)用解耦，數(shù)據(jù)庫(kù)解耦，追賬補(bǔ)數(shù)，業(yè)務(wù)監(jiān)控，應(yīng)用路由，故障切換等。可用性，效率，故障恢復(fù)等方面都要一起參與。

20. 性能提升

開源數(shù)據(jù)庫(kù)使用應(yīng)該合理且有效的結(jié)合周邊的其他類型數(shù)據(jù)庫(kù)，做到性能大化。比如：Redis、MongoDB、ES、ClickHouse等。

總結(jié)

1. 最適合的架構(gòu)是結(jié)合軟件特性和業(yè)務(wù)場(chǎng)景，又能取得成本收益平衡；

2. 大數(shù)據(jù)情況下可以是利用讀寫分離、分庫(kù)分表，但要選擇合適的；

3. 不適合分庫(kù)的應(yīng)該考慮竭盡所能把核心庫(kù)做小，然后通過(guò)垂直擴(kuò)展來(lái)擴(kuò)容；

4. 用盡各種技術(shù)， 高可用 和 容災(zāi)手段保證其可用。

以上就是MySQL20個(gè)高性能架構(gòu)設(shè)計(jì)原則（值得收藏）的詳細(xì)內(nèi)容，更多關(guān)于MySQL 架構(gòu)設(shè)計(jì)的資料請(qǐng)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司其它相關(guān)文章！

當(dāng)前文章：MySQL20個(gè)高性能架構(gòu)設(shè)計(jì)原則（值得收藏）-創(chuàng)新互聯(lián)
網(wǎng)頁(yè)URL：http://weahome.cn/article/deeodc.html