MySQL高性能架構(gòu)設(shè)計(jì)原則有哪些

這篇文章主要講解了“MySQL高性能架構(gòu)設(shè)計(jì)原則有哪些”,文中的講解內(nèi)容簡(jiǎn)單清晰,易于學(xué)習(xí)與理解,下面請(qǐng)大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“MySQL高性能架構(gòu)設(shè)計(jì)原則有哪些”吧!

創(chuàng)新互聯(lián)建站堅(jiān)持“要么做到,要么別承諾”的工作理念,服務(wù)領(lǐng)域包括:成都網(wǎng)站制作、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù),滿足客戶于互聯(lián)網(wǎng)時(shí)代的番禺網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求,幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴!

01.  技術(shù)選型

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

02.  高可用選擇

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

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

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

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

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

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

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

  •  表使用規(guī)范

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

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

  •  索引規(guī)范

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

       2.單個(gè)索引中的字段數(shù)不超過 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)化原則

MySQL高性能架構(gòu)設(shè)計(jì)原則有哪些

05.  復(fù)制方式

MySQL復(fù)制方式提供異步方式、半同步方式、全局事務(wù)強(qiáng)一致性、binglog同步。需要不同業(yè)務(wù)系統(tǒng)間 或 兩個(gè)數(shù)據(jù)庫間進(jì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è)置 最佳為分庫,多活 專用高速公路,其他業(yè)務(wù)可以做讀寫分離,緩存。

07.  擴(kuò)展性

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

08.  讀寫分離

  •  讀多寫少場(chǎng)景(10%寫 90%讀)

  •  復(fù)制存在延遲,業(yè)務(wù)對(duì)延遲不敏感的

  •  實(shí)現(xiàn)方式:

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

        2. 通過中間代理方式路由只讀庫 &

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

09.  分庫分表

  •  當(dāng)表中數(shù)據(jù)記錄的數(shù)量超過3000萬條,再好的索引也已經(jīng)不能提高數(shù)據(jù)查詢的速度,這時(shí)需要將表拆分成更多的小表,增加性能,增加彈性,避免發(fā)生垮庫進(jìn)行操作。

  •  引入中間價(jià)要考慮性能代價(jià),聚合需求。

  •  分庫原則盡量在app 上層進(jìn)行分庫,就是流量。

  •  分多少合適:可用性和性能滿足TPS。

  •  路由:寫入配置文件 或則 插表 或則 zookeeper。

10.  歸檔原則

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

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

11.  連接池的要求

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

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

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

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

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

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

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

12.  應(yīng)用解耦

通過應(yīng)用訪問數(shù)據(jù)庫而不是直接訪問,重要業(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ù)庫訪問,數(shù)據(jù)庫成本最高,擴(kuò)展性最難,可用性保障最難,恢復(fù)難度和時(shí)間最大。

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

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

減少發(fā)布時(shí)變更數(shù)據(jù)庫對(duì)全局的影響,只有應(yīng)用程序灰度是不夠的,還要有專門的灰度數(shù)據(jù)庫。在分庫、讀寫分離架構(gòu)下,一套含數(shù)據(jù)庫的完整應(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ù)庫,操作系統(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ù)庫是一個(gè)整體

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

20.  性能提升

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

總結(jié)

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

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

3. 不適合分庫的應(yīng)該考慮竭盡所能把核心庫做小,然后通過垂直擴(kuò)展來擴(kuò)容;

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

感謝各位的閱讀,以上就是“MySQL高性能架構(gòu)設(shè)計(jì)原則有哪些”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對(duì)MySQL高性能架構(gòu)設(shè)計(jì)原則有哪些這一問題有了更深刻的體會(huì),具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián),小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章,歡迎關(guān)注!

名稱欄目:MySQL高性能架構(gòu)設(shè)計(jì)原則有哪些
URL分享:http://bm7419.com/article26/pscojg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站營銷、品牌網(wǎng)站設(shè)計(jì)、響應(yīng)式網(wǎng)站商城網(wǎng)站、品牌網(wǎng)站制作App開發(fā)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

微信小程序開發(fā)