nginx負(fù)載均衡詳解

這篇文章主要介紹“nginx負(fù)載均衡詳解”，在日常操作中，相信很多人在nginx負(fù)載均衡詳解問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”nginx負(fù)載均衡詳解”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

成都創(chuàng)新互聯(lián)秉承實(shí)現(xiàn)全網(wǎng)價(jià)值營(yíng)銷的理念，以專業(yè)定制企業(yè)官網(wǎng)，成都網(wǎng)站建設(shè)、網(wǎng)站制作，小程序設(shè)計(jì)，網(wǎng)頁(yè)設(shè)計(jì)制作，成都做手機(jī)網(wǎng)站，成都全網(wǎng)營(yíng)銷幫助傳統(tǒng)企業(yè)實(shí)現(xiàn)“互聯(lián)網(wǎng)+”轉(zhuǎn)型升級(jí)專業(yè)定制企業(yè)官網(wǎng),公司注重人才、技術(shù)和管理，匯聚了一批優(yōu)秀的互聯(lián)網(wǎng)技術(shù)人才,對(duì)客戶都以感恩的心態(tài)奉獻(xiàn)自己的專業(yè)和所長(zhǎng)。

核心功能

上面簡(jiǎn)短的定義中我們大致可以看到兩個(gè)內(nèi)容：將請(qǐng)求分發(fā)，操作單元；其實(shí)就是控制器+執(zhí)行器模式、Master+Worker模式等等，是不是很熟悉；當(dāng)然一個(gè)成熟的負(fù)載均衡器不光有這兩個(gè)核心功能，還有一些其他的功能，下面看看都有哪些核心功能：

  • 操作單元配置 這里的操作單元其實(shí)就是上游的服務(wù)器，是真正來處理業(yè)務(wù)的執(zhí)行者，這個(gè)需要可配置的（最好能支持動(dòng)態(tài)配置），方便用戶添加和刪除操作單元；這些操作單元就是負(fù)載均衡器分發(fā)消息的對(duì)象；

  • 負(fù)載均衡算法 既然需要分發(fā)，那具體通過何種方式把消息分給配置的執(zhí)行器，這就需要有相關(guān)的分發(fā)算法了，比如我們常見的輪詢、隨機(jī)、一致性哈希等等；

  • 失敗重試 既然配置了多個(gè)執(zhí)行單元，所以某臺(tái)服務(wù)器宕機(jī)是大概率事件，這樣我們?cè)诜职l(fā)請(qǐng)求給某臺(tái)已經(jīng)宕機(jī)的服務(wù)器時(shí)，需要有失敗重試功能，將請(qǐng)求重新分發(fā)給正常的執(zhí)行器；

  • 健康檢查 上面的失敗重試是只有真正轉(zhuǎn)發(fā)的時(shí)候才知道服務(wù)器宕機(jī)了，是一種惰性策略，健康檢查就是提前將宕機(jī)的機(jī)器排除掉，比如常見的通過心跳的方式去檢查執(zhí)行器是否還存活；

有了以上幾個(gè)核心的功能，一個(gè)負(fù)載均衡器大致就形成了，可以把這幾個(gè)原則用在很多地方，形成不同的中間件或者說內(nèi)嵌在各種中間件中，比如接入層的LVS，F(xiàn)5，Nginx等，服務(wù)層各種RPC框架，消息隊(duì)列RocketMQ、Kafka，分布式緩存redis、memcached，數(shù)據(jù)庫(kù)中間件shardingsphere、mycat等等，這種分而治之的思路在各種中間件中廣泛使用，下面對(duì)一些常見的中間件是如何做負(fù)載均衡的進(jìn)行分析，大體上可以分為有狀態(tài)和無狀態(tài)兩種類型；

無狀態(tài)

執(zhí)行單元本身沒有狀態(tài)，其實(shí)是更加容易去做負(fù)載均衡，每個(gè)執(zhí)行單元都是一樣的，常見的無狀態(tài)的中間件有Nginx，RPC框架，分布式調(diào)度等；

接入層

Nginx可以說是我們最常見的接入層中間件了，提供四層到七層的負(fù)載均衡功能，提供了高性能的轉(zhuǎn)發(fā)，對(duì)以上的幾個(gè)核心功能提供了支持；

  • 操作單元配置 Nginx提供了簡(jiǎn)單的靜態(tài)的操作單元配置，如下：

upstream tomcatTest {
     server 127.0.0.1:8081;   #tomcat-8081
     server 127.0.0.1:8082;   #tomcat-8082
}
location / {
     proxy_pass http://tomcatTest;
}

以上配置是靜態(tài)的，如果需要添加或者刪除，需要對(duì)Nginx重啟，很不方便，當(dāng)然也提供了動(dòng)態(tài)的單元配置，需要借助第三方的服務(wù)注冊(cè)中心比如Consul，etcd等；原理大致如下：

操作單元啟動(dòng)就會(huì)注冊(cè)到Consul中，同樣宕機(jī)會(huì)從Consul中移除；Nginx側(cè)會(huì)啟動(dòng)一個(gè)Consul-template監(jiān)聽程序，監(jiān)聽Consul上操作單元的變更，然后更新Nginx的upstream，最好重加載upstream；

  • 負(fù)載均衡算法 常見的比如：ip_hash，round-robin，hash；配置也很簡(jiǎn)單：

upstream tomcatTest {
     ip_hash  //根據(jù)ip負(fù)載均衡，也就是常說的ip綁定
     server 127.0.0.1:8081;   #tomcat-8081
     server 127.0.0.1:8082;   #tomcat-8082
}

  • 失敗重試

upstream tomcatTest {
     server 127.0.0.1:8081 max_fails=2 fail_timeout=20s;
}
location / {
     proxy_pass http://tomcatTest;
     proxy_next_upstream error timeout http_500;
}

當(dāng)在fail_timeout內(nèi)出現(xiàn)了max_fails次失敗，表示此執(zhí)行單元不可用；通過proxy_next_upstream配置，當(dāng)出現(xiàn)配置的錯(cuò)誤時(shí)，會(huì)重試下一臺(tái)執(zhí)行單元；

  • 健康檢查 Nginx通過集成nginx_upstream_check_module模塊來進(jìn)行健康檢查；支持TCP心跳和Http心跳檢測(cè)；

upstream tomcatTest {
     server 127.0.0.1:8081;
     check interval=3000 rise=2 fall=5 timeout=5000 type=tcp;
}

interval：檢測(cè)間隔時(shí)間； rise：檢測(cè)成功多少次后，操作單元標(biāo)識(shí)為可用； fall：檢測(cè)失敗多少次后，操作單元標(biāo)識(shí)為不可用； timeout：檢測(cè)請(qǐng)求超時(shí)時(shí)間； type：檢測(cè)類型包括tcp，http；

服務(wù)層

服務(wù)層主要的就是微服務(wù)框架比如Dubbo，Spring Cloud等，內(nèi)部都集成了負(fù)載均衡策略，使用起來也是非常方便；

  • 操作單元配置 RPC框架一般都依賴注冊(cè)中心組件，其實(shí)和Nginx通過注冊(cè)中心來動(dòng)態(tài)改變操作單元是一樣的，RPC框架默認(rèn)就已經(jīng)依賴注冊(cè)中心了，服務(wù)啟動(dòng)就注冊(cè)到中心，服務(wù)不可用就移除，并且會(huì)自動(dòng)同步到消費(fèi)端，用戶完全無感知，消費(fèi)端要做的就是根據(jù)注冊(cè)中心提供的服務(wù)列表，然后使用分發(fā)算法進(jìn)行負(fù)載均衡；

  • 負(fù)載均衡算法 Spring Cloud提供了Ribbon組件來實(shí)現(xiàn)負(fù)載均衡，而Dubbo直接內(nèi)置均衡策略，常見的算法包括：輪詢，隨機(jī)，最少活躍調(diào)用數(shù)，一致性 Hash等等；比如dubbo配置輪詢算法：

<dubbo:reference interface="" loadbalance="roundrobin" />

Ribbon配置隨機(jī)規(guī)則：

@Bean
public IRule loadBalancer(){
	return new RandomRule();
}

  • 失敗重試 對(duì)于RPC框架來說其實(shí)就是容錯(cuò)機(jī)制，比如Dubbo內(nèi)置了多種容錯(cuò)機(jī)制包括：Failover、Failfast、Failsafe、Failback、Forking、Broadcast；默認(rèn)的容錯(cuò)機(jī)制就是Failover失敗自動(dòng)切換，當(dāng)出現(xiàn)失敗重試其它服務(wù)器；配置容錯(cuò)機(jī)制也很簡(jiǎn)單：

<dubbo:reference cluster="failback" retries="2"/>

  • 健康檢查 注冊(cè)中心一般都有健康檢查功能，會(huì)實(shí)時(shí)檢測(cè)服務(wù)器是否可用，如果不可用會(huì)移除，同時(shí)將更新推送給消費(fèi)端；對(duì)用戶來說完全無感知；

分布式調(diào)度將調(diào)度器和執(zhí)行器分離，執(zhí)行器也是通過注冊(cè)中心的方式提供給調(diào)度器，然后由調(diào)度器進(jìn)行負(fù)載均衡操作，流程已基本相似，此處不再一一介紹； 可以發(fā)現(xiàn)無狀態(tài)的負(fù)載均衡其實(shí)更多情況以來注冊(cè)中心，通過注冊(cè)中心來動(dòng)態(tài)的增減執(zhí)行單元，從而很方便的達(dá)到擴(kuò)容縮容；

有狀態(tài)

有狀態(tài)的執(zhí)行單元相對(duì)于無狀態(tài)來說更加有難度，因?yàn)槊總€(gè)節(jié)點(diǎn)的狀態(tài)是整個(gè)系統(tǒng)的一部分，不是能隨意增減的節(jié)點(diǎn)的；常見的有狀態(tài)中間件有：消息隊(duì)列，分布式緩存，數(shù)據(jù)庫(kù)中間件等；

消息隊(duì)列

現(xiàn)在高吞吐量，高性能的消息隊(duì)列越來越成為主流，比如RocketMQ，Kafka等，有強(qiáng)大的水平擴(kuò)展能力；RocketMQ中引入Message Queue機(jī)制，Kafka引入分區(qū)(Partition)，一個(gè)Topic對(duì)應(yīng)多個(gè)分區(qū)，采用分而治之的思路來提高吞吐量，性能；可以看一個(gè)RocketMQ的簡(jiǎn)易圖： nginx負(fù)載均衡詳解

  • 操作單元配置 消息隊(duì)列里面的操作單元其實(shí)就是這里的分區(qū)或者說Message Queue，比如RocketMQ是可以動(dòng)態(tài)去修改讀寫隊(duì)列的數(shù)量；RocketMQ還提供了rocketmq-console控制臺(tái)，可以直接修改；

  • 負(fù)載均衡算法 消息隊(duì)列一般都有生產(chǎn)端和消費(fèi)端，生產(chǎn)端默認(rèn)是輪流給每個(gè)Message Queue發(fā)送消息，當(dāng)然也可以自定義發(fā)送策略可以通過MessageQueueSelector來實(shí)現(xiàn)；消費(fèi)端分配策略包括：分頁(yè)模式(隨機(jī)分配模式)、手動(dòng)配置模式、指定機(jī)房模式、就近機(jī)房模式、統(tǒng)一哈希模式、環(huán)型模式；

  • 失敗重試 對(duì)于有狀態(tài)的執(zhí)行單元來說，不是說宕機(jī)就可以直接移除的，需要保證數(shù)據(jù)的完整性，正常來說一般都會(huì)做主備處理，主機(jī)掛了備機(jī)接管；以RocketMQ為例，每個(gè)分區(qū)都有各自的備份，RocketMQ采取的策略是，備區(qū)僅僅是做數(shù)據(jù)的完整性保證，消費(fèi)者能消息備區(qū)的數(shù)據(jù)，但是并不會(huì)重新來接收數(shù)據(jù)；

  • 健康檢查 消息隊(duì)列也有一個(gè)核心組件，可以理解為協(xié)調(diào)者，或者可以理解為注冊(cè)中心，Kafka使用zookeeper，RocketMQ使用NameServer，里面其實(shí)就是保存了相關(guān)的對(duì)應(yīng)信息比如Topic對(duì)應(yīng)Message Queue，如果發(fā)現(xiàn)某臺(tái)broker不可用，會(huì)將信息告知生產(chǎn)者，方式和注冊(cè)中心類似；

分布式緩存

常見的分布式緩存有redis、memcached，為了能夠容納更多的數(shù)據(jù)一般都會(huì)做分片處理，分片的方式也是多種多樣，就拿redis來說可以客戶端做分片，基于代理的分片，還有官方提供的Cluster方案；

  • 操作單元配置 緩存雖然也有有狀態(tài)的，但是有其特殊性，其更多關(guān)注的是命中率，其實(shí)是可以容忍數(shù)據(jù)丟失的，比如基于代理的分片中間件codis，對(duì)客戶端全透明不影響服務(wù)的情況下可以完成增減redis實(shí)例；

  • 負(fù)載均衡算法 基于保證命中率的前提下，基于代理分片的方式一般都會(huì)采用一致性哈希算法；而redis官方提供的Cluster方案，因?yàn)槠鋬?nèi)置有16384個(gè)虛擬槽，所以直接使用取模即完成分片；

  • 失敗重試 有狀態(tài)的分片一般都有會(huì)備區(qū)，在主區(qū)宕機(jī)后，備區(qū)接管實(shí)現(xiàn)故障遷移，比如redis的哨兵模式，或者codis這種中間件內(nèi)置的功能；也無需去切換其他分區(qū)，對(duì)用戶來說這種接管完全是無感知的；

  • 健康檢查 以redis為例，哨兵模式中，sentinel通過心跳的方式實(shí)時(shí)監(jiān)測(cè)節(jié)點(diǎn)，通過客觀下線來實(shí)施故障遷移；可以發(fā)現(xiàn)健康檢查基本都是通過心跳來檢測(cè)的方式；

數(shù)據(jù)庫(kù)層

數(shù)據(jù)庫(kù)層做均衡處理應(yīng)該說是最復(fù)雜的，首先是有狀態(tài)的，其次是數(shù)據(jù)的安全性至關(guān)重要，常見的數(shù)據(jù)庫(kù)中間件包括：mycat，shardingjdbc等；

  • 操作單元配置 以分表為例，這里的操作單元其實(shí)就是一個(gè)個(gè)分片數(shù)據(jù)表，數(shù)據(jù)量有時(shí)候往往出乎我們的預(yù)料，一般很少說固定給它分配多少個(gè)分片，最好是通過負(fù)載算法自動(dòng)生成數(shù)據(jù)表，而且最好事先就評(píng)估好某種負(fù)載算法，不然后期如果想改變是很難的；

  • 負(fù)載均衡算法 以mycat為例提供了多種負(fù)載算法：范圍約定，取模，按日期分片，hash，一致性hash，分片枚舉等等；比如下面的按天分區(qū)配置：

<tableRule name="sharding-by-date">
    <rule>
        <columns>create_time</columns>
        <algorithm>sharding-by-date</algorithm>
    </rule>
</tableRule>
<function name="sharding-by-date" class="io.mycat.route.function.PartitionByDate">
    <property name="dateFormat">yyyy-MM-dd</property>
    <property name="sBeginDate">2021-01-01</property>
    <property name="sEndDate">2051-01-01</property>
    <property name="sPartionDay">10</property>
</function>

指定了開始時(shí)間，結(jié)束時(shí)間，以及分區(qū)的天數(shù)；因?yàn)閿?shù)據(jù)是隨時(shí)間連續(xù)的，所以這種方式擴(kuò)展性是很好的；如果是取模的方式就要考慮清楚分片的數(shù)量了，后面如果想改變分片數(shù)量就很麻煩了，不像緩存可以使用一致性hash來保證命中率就行了；

  • 失敗重試 有狀態(tài)的節(jié)點(diǎn)，備庫(kù)是少不了的，比如mycat提供了故障的主從切換功能，主宕機(jī)切換到從，基本都是這個(gè)套路，數(shù)據(jù)是不能丟的；

  • 健康檢查 同樣的主動(dòng)檢測(cè)也必不可少，一般也是基于心跳語句去定時(shí)檢測(cè)，然后做故障主從切換；

到此，關(guān)于“nginx負(fù)載均衡詳解”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！

本文題目：nginx負(fù)載均衡詳解
轉(zhuǎn)載源于：http://muchs.cn/article10/jojsgo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供、服務(wù)器托管、ChatGPT、網(wǎng)站營(yíng)銷、網(wǎng)站排名、商城網(wǎng)站

廣告

聲明：本網(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)

成都定制網(wǎng)站網(wǎng)頁(yè)設(shè)計(jì)