它們是按SMP、NUMA、MPP、集群、分布處理從最緊密到最松散的排列。
創(chuàng)新互聯(lián)是一家專業(yè)提供江寧企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、H5高端網(wǎng)站建設(shè)、小程序制作等業(yè)務。10年已為江寧眾多企業(yè)、政府機構(gòu)等服務。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進行中。
SMP(多處理系統(tǒng)):這種系統(tǒng)是在一臺計算機里有多個CPU,CPU之間的地位是平等的，它們共享內(nèi)存空間和I/O設(shè)備。其工作方法是由操作系統(tǒng)負責將任務分解成多個并發(fā)進程，然后讓其在不同的CPU上運行。
NUMA(非統(tǒng)一內(nèi)存存取):這種系統(tǒng)可以讓多處理計算機的CPU比SMP更高效地共享本地內(nèi)存，CPU可以更快速地存取單一的內(nèi)存區(qū)域，不過如需要也可以用間接方式存取其他區(qū)域的內(nèi)存，這種方法是讓某些CPU在給定范圍的物理內(nèi)存中有更大的優(yōu)先使用權(quán)。
MPP(巨型并行處理):這種系統(tǒng)的節(jié)點都有自己的CPU，并有自己的專有資源。此種結(jié)構(gòu)相對獨立，但各個節(jié)點一般沒有完全存取I/O的能力。
集群:集群系統(tǒng)是由獨立的計算機組成，但有控制管理工具統(tǒng)一管理。
分布處理:它是比我們要構(gòu)筑的集群系統(tǒng)更松散的連接，一般是任務在不同的地方完成，沒有可以作為整體管理的單一實體。
以上的聚合方式有緊有疏，它們都有自己的適用范圍，這里就不多說了，有興趣可自己找些資料看，這里只是想讓大家了解它所處的位置。
實現(xiàn)負載均衡的方法
集群的目的是共享和高效地利用資源，提供大型運算，提供負載均衡分配請求壓力以及出現(xiàn)故障時能夠進行切換實現(xiàn)高可用性。
限于篇幅，本文只對負載均衡的實現(xiàn)做些介紹(針對TurboLinux Cluster Server)。通過對相關(guān)軟件的分析，實現(xiàn)集群負載的功能是通過流量管理實現(xiàn)的，具體有這樣幾種實現(xiàn)方法:直接路由(Direct forwarding)、網(wǎng)絡地址轉(zhuǎn)換(NAT)、隧道技術(shù)(Tunneling)。
直接路由(Direct forwarding)
當參與集群的計算機和作為控制管理的計算機在同一個網(wǎng)段時可以用此法，控制管理的計算機接收到請求包時直接送到參與集群的節(jié)點。優(yōu)點是返回給客戶的流量不經(jīng)過控制主機，速度快開銷少。
網(wǎng)絡地址轉(zhuǎn)換(NAT)
這種方法可能大家較熟悉，地址轉(zhuǎn)換器有能被外界訪問到的合法IP地址，它修改來自專有網(wǎng)絡的流出包的地址，外界看起來包是來自地址轉(zhuǎn)換器本身，當外界包送到轉(zhuǎn)換器時，它能判斷出應該將包送到內(nèi)部網(wǎng)的哪個節(jié)點。優(yōu)點是節(jié)省IP地址，能對內(nèi)部進行偽裝;缺點是效率低，因為返回給請求方的流量經(jīng)過轉(zhuǎn)換器。
隧道技術(shù)(Tunneling)
這種方式是在集群的節(jié)點不在同一個網(wǎng)段時可用的轉(zhuǎn)發(fā)機制，是將IP包封裝在其他網(wǎng)絡流量中的方法，為了安全的考慮，應該使用隧道技術(shù)中的VPN,也可使用租用專線。
集群所能提供的服務是基于TCP/IP的Web服務、Mail服務、News服務、DNS服務、Proxy服務器等等，下面我們將就具體的產(chǎn)品TurboLinux Cluster Server 來實現(xiàn)一個進行負載均衡集群系統(tǒng)，用于提供Web和FTP的服務。四臺服務器的負載均衡實例
所提供的服務:Web、FTP。
系統(tǒng)的實現(xiàn)目的:做一個較完善負載均衡的系統(tǒng)，以便能用到其中的較多的功能。
采用設(shè)備狀況:使用四臺服務器，其中3臺裝TurboLinux Cluster Server,1臺安裝Windows 2000 Sever。系統(tǒng)安裝1.在兩臺服務器上安裝TurboLinux， apache和wu-ftpd也要安裝，因為集群要提供這種服務,安裝完后重啟，掛接光驅(qū)在目錄/mnt/cdrom下，執(zhí) 行./TLCS-install,然后按提示完全安裝。
數(shù)據(jù)庫優(yōu)化一方面是找出系統(tǒng)的瓶頸,提高MySQL數(shù)據(jù)庫的整體性能,而另一方面需要合理的結(jié)構(gòu)設(shè)計和參數(shù)調(diào)整,以提高用戶的相應速度,同時還要盡可能的節(jié)約系統(tǒng)資源,以便讓系統(tǒng)提供更大的負荷.
1. 優(yōu)化一覽圖
2. 優(yōu)化
筆者將優(yōu)化分為了兩大類,軟優(yōu)化和硬優(yōu)化,軟優(yōu)化一般是操作數(shù)據(jù)庫即可,而硬優(yōu)化則是操作服務器硬件及參數(shù)設(shè)置.
2.1 軟優(yōu)化
2.1.1 查詢語句優(yōu)化
1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執(zhí)行信息.
2.例:
顯示:
其中會顯示索引和查詢數(shù)據(jù)讀取數(shù)據(jù)條數(shù)等信息.
2.1.2 優(yōu)化子查詢
在MySQL中,盡量使用JOIN來代替子查詢.因為子查詢需要嵌套查詢,嵌套查詢時會建立一張臨時表,臨時表的建立和刪除都會有較大的系統(tǒng)開銷,而連接查詢不會創(chuàng)建臨時表,因此效率比嵌套子查詢高.
2.1.3 使用索引
索引是提高數(shù)據(jù)庫查詢速度最重要的方法之一,關(guān)于索引可以參高筆者MySQL數(shù)據(jù)庫索引一文,介紹比較詳細,此處記錄使用索引的三大注意事項:
2.1.4 分解表
對于字段較多的表,如果某些字段使用頻率較低,此時應當,將其分離出來從而形成新的表,
2.1.5 中間表
對于將大量連接查詢的表可以創(chuàng)建中間表,從而減少在查詢時造成的連接耗時.
2.1.6 增加冗余字段
類似于創(chuàng)建中間表,增加冗余也是為了減少連接查詢.
2.1.7 分析表,,檢查表,優(yōu)化表
分析表主要是分析表中關(guān)鍵字的分布,檢查表主要是檢查表中是否存在錯誤,優(yōu)化表主要是消除刪除或更新造成的表空間浪費.
1. 分析表: 使用 ANALYZE 關(guān)鍵字,如ANALYZE TABLE user;
2. 檢查表: 使用 CHECK關(guān)鍵字,如CHECK TABLE user [option]
option 只對MyISAM有效,共五個參數(shù)值:
3. 優(yōu)化表:使用OPTIMIZE關(guān)鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日志.,優(yōu)化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執(zhí)行過程中會加上只讀鎖.
2.2 硬優(yōu)化
2.2.1 硬件三件套
1.配置多核心和頻率高的cpu,多核心可以執(zhí)行多個線程.
2.配置大內(nèi)存,提高內(nèi)存,即可提高緩存區(qū)容量,因此能減少磁盤I/O時間,從而提高響應速度.
3.配置高速磁盤或合理分布磁盤:高速磁盤提高I/O,分布磁盤能提高并行操作的能力.
2.2.2 優(yōu)化數(shù)據(jù)庫參數(shù)
優(yōu)化數(shù)據(jù)庫參數(shù)可以提高資源利用率,從而提高MySQL服務器性能.MySQL服務的配置參數(shù)都在my.cnf或my.ini,下面列出性能影響較大的幾個參數(shù).
2.2.3 分庫分表
因為數(shù)據(jù)庫壓力過大，首先一個問題就是高峰期系統(tǒng)性能可能會降低，因為數(shù)據(jù)庫負載過高對性能會有影響。另外一個，壓力過大把你的數(shù)據(jù)庫給搞掛了怎么辦？所以此時你必須得對系統(tǒng)做分庫分表 + 讀寫分離，也就是把一個庫拆分為多個庫，部署在多個數(shù)據(jù)庫服務上，這時作為主庫承載寫入請求。然后每個主庫都掛載至少一個從庫，由從庫來承載讀請求。
2.2.4 緩存集群
如果用戶量越來越大，此時你可以不停的加機器，比如說系統(tǒng)層面不停加機器，就可以承載更高的并發(fā)請求。然后數(shù)據(jù)庫層面如果寫入并發(fā)越來越高，就擴容加數(shù)據(jù)庫服務器，通過分庫分表是可以支持擴容機器的，如果數(shù)據(jù)庫層面的讀并發(fā)越來越高，就擴容加更多的從庫。但是這里有一個很大的問題：數(shù)據(jù)庫其實本身不是用來承載高并發(fā)請求的，所以通常來說，數(shù)據(jù)庫單機每秒承載的并發(fā)就在幾千的數(shù)量級，而且數(shù)據(jù)庫使用的機器都是比較高配置，比較昂貴的機器，成本很高。如果你就是簡單的不停的加機器，其實是不對的。所以在高并發(fā)架構(gòu)里通常都有緩存這個環(huán)節(jié)，緩存系統(tǒng)的設(shè)計就是為了承載高并發(fā)而生。所以單機承載的并發(fā)量都在每秒幾萬，甚至每秒數(shù)十萬，對高并發(fā)的承載能力比數(shù)據(jù)庫系統(tǒng)要高出一到兩個數(shù)量級。所以你完全可以根據(jù)系統(tǒng)的業(yè)務特性，對那種寫少讀多的請求，引入緩存集群。具體來說，就是在寫數(shù)據(jù)庫的時候同時寫一份數(shù)據(jù)到緩存集群里，然后用緩存集群來承載大部分的讀請求。這樣的話，通過緩存集群，就可以用更少的機器資源承載更高的并發(fā)。
一個完整而復雜的高并發(fā)系統(tǒng)架構(gòu)中，一定會包含：各種復雜的自研基礎(chǔ)架構(gòu)系統(tǒng)。各種精妙的架構(gòu)設(shè)計.因此一篇小文頂多具有拋磚引玉的效果,但是數(shù)據(jù)庫優(yōu)化的思想差不多就這些了.
mysql負責高可用，可以參考如下幾種方案：
1.基于共享存儲的方案SAN
方
案介紹：SAN(Storage Area
Network)簡單點說就是可以實現(xiàn)網(wǎng)絡中不同服務器的數(shù)據(jù)共享，共享存儲能夠為數(shù)據(jù)庫服務器和存儲解耦。使用共享存儲時，服務器能夠正常掛載文件系統(tǒng)
并操作，如果服務器掛了，備用服務器可以掛載相同的文件系統(tǒng)，執(zhí)行需要的恢復操作，然后啟動MySQL。共享存儲的架構(gòu)如下:
優(yōu)點:
1.可以避免存儲外的其它組件引起的數(shù)據(jù)丟失。
2.部署簡單，切換邏輯簡單，對應用透明。
3.保證主備數(shù)據(jù)的強一致。
限制或缺點:
1.共享存儲是單點，若共享存儲掛了，則會丟失數(shù)據(jù)。
2.價格比價昂貴。
2.基于磁盤復制的方案 DRBD
方
案介紹：DRBD(Distributed Replicated Block
Device)是一種磁盤復制技術(shù)，可以獲得和SAN類似的效果。DBRD是一個以linux內(nèi)核模塊方式實現(xiàn)的塊級別同步復制技術(shù)。它通過網(wǎng)卡將主服務
器的每個塊復制到另外一個服務器塊設(shè)備上，并在主設(shè)備提交塊之前記錄下來。DRBD與SAN類似，也是有一個熱備機器，開始提供服務時會使用和故障機器相
同的數(shù)據(jù)，只不過DRBD的數(shù)據(jù)是復制存儲，不是共享存儲。DRBD的架構(gòu)圖如下：
優(yōu)點：
1.切換對應用透明
2.保證主備數(shù)據(jù)的強一致。
限制或缺點：
1.影響寫入性能，由于每次寫磁盤，實質(zhì)都需要同步到網(wǎng)絡服務器。
2.一般配置兩節(jié)點同步，可擴展性比較差
3.備庫不能提供讀服務，資源浪費
3.基于主從復制(單點寫)方案
前面討論的兩種方案分別依賴于底層的共享存儲和磁盤復制技術(shù)，來解決MYSQL服務器單點和磁盤單點的問題。而實際生產(chǎn)環(huán)境中，高可用更多的是依賴
MySQL本身的復制，通過復制為Master制作一個或多個熱副本，在Master故障時，將服務切換到熱副本。下面的幾種方案都是基于主從復制的方
案，方案由簡單到復雜，功能也越來越強大，實施難度由易到難，各位可以根據(jù)實際情況選擇合適的方案。
您好，很高興為您解答。
第一先限制Innodb的并發(fā)處理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看機器壓力,如果
非常大,先改成16讓機器的壓力下來,然后慢慢增達,適應自已的業(yè)務.
處理方法: set global innodb_thread_concurrency=16;
第二: 對于連接數(shù)已經(jīng)超過600或是更多的情況,可以考慮適當?shù)南拗埔幌逻B接數(shù),讓前端報一下錯,也別讓DB掛了.
DB在了,總是可以用來加載一下數(shù)據(jù),當數(shù)據(jù)加載到了nosql里了,慢慢的DB壓力也會降下來的.
限制單用戶連接數(shù)在500以下. 如:
set global max_user_connections=500;
(MySQL隨著連接數(shù)的增加性能會是下降的,這也是thread_pool出現(xiàn)的原因)
另外對于有的監(jiān)控程序會讀取information_schema下面的表的程序可以考慮關(guān)閉下面的參數(shù)
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0;
這個參數(shù)主要防止對讀取information_schema時造成大量讀取磁盤進行信息統(tǒng)計(如果慢查詢中出現(xiàn)關(guān)于information_schema中表時,也可以考慮禁用該參數(shù))
處理依據(jù):
當學校的一個食堂一分鐘只能為兩個打飯, 忽然來了100個時人來打飯,又沒排隊, 不出會現(xiàn)了打飯的師傅要用點時間
去選擇為那個用戶服務了, 人越多,場面就越亂, 難免出現(xiàn)用戶大吼該他的場面, 最后有可能就出現(xiàn)不是打飯了,而時之間相互
打架了,打飯的師傅也將收到同時有90個以上的Server too busy. 如果能排一下隊.最多也就50分鐘能處理完了.
以前辦法,應該可以讓MySQLD不會掛掉.如果業(yè)務支撐受到限制,還是想辦法處理一下.
如若滿意，請點擊右側(cè)【采納答案】，如若還有問題，請點擊【追問】
希望我的回答對您有所幫助，望采納！
~ O(∩_∩)O~
大家好，一起來搞一下mysql的負載均衡這個技術(shù)點。
1. haproxy介紹與配置
2. keeplived介紹與配置
3. mysql高可用搭建
1. 可靠性與穩(wěn)定性都非常出色，可與硬件級設(shè)備媲美。
2. 支持連接拒絕，可以用于防止 DDoS 攻擊
3. 支持長連接、短連接和日志功能，可根據(jù)需要靈活配置
4. 路由 HTTP 請求到后端服務器,基于 cookie 作會話綁定;同時支持通過獲取指定的 url 來檢測后 端服務器的狀態(tài)
5. HAProxy 還擁有功能強大的 ACL 支持，可靈活配置路由功能，實現(xiàn)動靜分離，在架構(gòu)設(shè)計與實現(xiàn)上 帶來很大方便
6. 可支持四層和七層負載均衡，幾乎能為所有服務常見的提供負載均衡功能
7. 擁有功能強大的后端服務器的狀態(tài)監(jiān)控 web 頁面，可以實時了解設(shè)備的運行狀態(tài) ，還可實現(xiàn)設(shè)備上 下線等簡單操作。
8. 支持多種負載均衡調(diào)度算法，并且也支持 session 保持。
9. Haproxy 七層負載均衡模式下，負載均衡與客戶端及后端的服務器會分別建立一次 TCP連接，而在 四層負載均衡模式下(DR)，僅建立一次 TCP 連接;七層負載均衡對負載均衡設(shè)備的要求更高，處理能力 也低于四層負載均衡。
全局設(shè)定
global settings:主要用于定義 haproxy 進程管理安全及性能相關(guān)的參數(shù)。
代理設(shè)定
proxies 共分為4段:defaults，frontend，backend，listen
注意：此處只做配置文件介紹，不做為后期負載均衡配置
在192.168.199.175與192.168.199.172(負載均衡服務器)中安裝與配置如下
haproxy狀態(tài)檢測腳本不執(zhí)行問題，如果是使用的service keeplived start 或者是 systemctl 方式啟動，腳本可能會不執(zhí)行，可以使用 Keepalived -f /etc/keepalived/keepalived.conf方式啟動Keepalived
重慶分公司
重慶分公司
