山月在年前的大廠面試
年前面試據(jù)說(shuō)是一年中最好通過(guò)面試的時(shí)候，這個(gè)時(shí)候面試的人少，加之崗位急，供需關(guān)系決定比以往更容易拿一個(gè)不錯(cuò)的工資。
趁著這幾天結(jié)束了幾月的旅行，在家沒(méi)事，恰好有充分的時(shí)間，面了幾家大廠。最終也有幾家拿了 Offer，再接再厲，最近有面試的同學(xué)也可以與我交流。
總結(jié)題目如下(鏈接在左下角原文打開(kāi))
01 如何實(shí)現(xiàn)一個(gè)元素的水平垂直居中
在 Issue 或者我的網(wǎng)站中交流與討論: 01 如何實(shí)現(xiàn)一個(gè)元素的水平垂直居中
提供一個(gè)較少提過(guò)的方法，使用 grid，它是做二維布局的，但是只有一個(gè)子元素時(shí)，一維布局與二維布局就一樣了。結(jié)合 justify-content/justify-items 和 align-content/align-items 就有四種方案
效果可以見(jiàn) codepen
.container?{
??display:?grid;
??justify-content:?center;
??align-content:?center;
}
.container?{
??display:?grid;
??justify-content:?center;
??align-items:?center;
}
.container?{
??display:?grid;
??justify-items:?center;
??align-content:?center;
}
.container?{
??display:?grid;
??justify-items:?center;
??align-items:?center;
}
02 css 如何實(shí)現(xiàn)左側(cè)固定300px，右側(cè)自適應(yīng)的布局
在 Issue 或者我的網(wǎng)站中交流與討論: 02 css 如何實(shí)現(xiàn)左側(cè)固定300px，右側(cè)自適應(yīng)的布局
使用 flex 布局，左側(cè) 300px，右側(cè) flex-grow: 1。pug 代碼及 css 代碼示例如下
.container
.left
.main
.container?{
??display:?flex;
}
.left?{
??flex-basis:?300px;
}
.main?{
??flex-grow:?1;
}
此處看起來(lái)比較圓滿(mǎn)了，其實(shí)還有一個(gè)缺陷: 如果 .main 區(qū)域過(guò)大擠壓 .left 區(qū)域怎么辦，此時(shí)還需要加一個(gè)禁止擠壓
.left?{
??flex-basis:?300px;
??flex-shrink:?0;
}
總結(jié)
使用 flex 進(jìn)行如下布局
.container
.left
.main
.container?{
??display:?flex;
}
.left?{
??flex-basis:?300px;
??flex-shrink:?0;
}
.main?{
??flex-grow:?1;
}
03 http 狀態(tài)碼 502 和 504 有什么區(qū)別
在 Issue 或者我的網(wǎng)站中交流與討論: 03 http 狀態(tài)碼 502 和 504 有什么區(qū)別
這兩種異常狀態(tài)碼都與網(wǎng)關(guān) Gateway 有關(guān)，首先明確兩個(gè)概念
Proxy (Gateway)，反向代理層或者網(wǎng)關(guān)層。在公司級(jí)應(yīng)用中一般使用 Nginx 扮演這個(gè)角色 Application (upstream serrver)，應(yīng)用層服務(wù)，作為 Proxy 層的上游服務(wù)。在公司中一般為各種語(yǔ)言編寫(xiě)的服務(wù)器應(yīng)用，如 Go/Java/Python/PHP/Node 等
此時(shí)關(guān)于 502 與 504 的區(qū)別就很顯而易見(jiàn)
502 Bad Gateway。一般表現(xiàn)為你自己寫(xiě)的應(yīng)用層服務(wù)(Java/Go/PHP)掛了，網(wǎng)關(guān)層無(wú)法接收到響應(yīng)504 Gateway Timeout。一般表現(xiàn)為應(yīng)用層服務(wù) (upstream) 超時(shí)，如查庫(kù)操作耗時(shí)十分鐘，超過(guò)了 Nginx 配置的超時(shí)時(shí)間
04 如何使用 react hooks 實(shí)現(xiàn) useFetch 請(qǐng)求數(shù)據(jù)
更多描述: 比如設(shè)計(jì)成 `useFetch` 這種形式，它的 API 應(yīng)該如何設(shè)計(jì)
在 Issue 或者我的網(wǎng)站中交流與討論: 04 如何使用 react hooks 實(shí)現(xiàn) useFetch 請(qǐng)求數(shù)據(jù)
可以參考 How to fetch data with React Hooks?
05 react 如何使用 render prop component 請(qǐng)求數(shù)據(jù)
在 Issue 或者我的網(wǎng)站中交流與討論: 05 react 如何使用 render prop component 請(qǐng)求數(shù)據(jù)
參考: https://www.robinwieruch.de/react-fetching-data#how-to-fetch-data-in-render-props
06 什么是 virtual DOM，它的引入帶了什么好處
在 Issue 或者我的網(wǎng)站中交流與討論: 06 什么是 virtual DOM，它的引入帶了什么好處
數(shù)據(jù)與UI的進(jìn)一步分離，這樣也更有利于 SSR
07 http 服務(wù)中靜態(tài)文件的 Last-Modified 是根據(jù)什么生成的
在 Issue 或者我的網(wǎng)站中交流與討論: 07 http 服務(wù)中靜態(tài)文件的 Last-Modified 是根據(jù)什么生成的
一般會(huì)選文件的 mtime，表示文件內(nèi)容的修改時(shí)間
nginx 也是這樣處理的，源碼見(jiàn): ngx_http_static_module.c
????r->headers_out.status?=?NGX_HTTP_OK;
????r->headers_out.content_length_n?=?of.size;
????r->headers_out.last_modified_time?=?of.mtime;
關(guān)于為什么使用 mtime 而非 ctime，可以參考 #116
08 localhost:3000 與 localhost:5000 的 cookie 信息是否共享
在 Issue 或者我的網(wǎng)站中交流與討論: 08 localhost:3000 與 localhost:5000 的 cookie 信息是否共享
共享
09 http 響應(yīng)頭中如果 content-type 為 application/octet-stream，則代表什么意思
在 Issue 或者我的網(wǎng)站中交流與討論: 09 http 響應(yīng)頭中如果 content-type 為 application/octet-stream，則代表什么意思
代表二進(jìn)制流，一般用以下載文件
10 http 響應(yīng)頭中的 Date 與 Last-Modified 有什么不同，網(wǎng)站部署時(shí)需要注意什么
在 Issue 或者我的網(wǎng)站中交流與討論: 10 http 響應(yīng)頭中的 Date 與 Last-Modified 有什么不同，網(wǎng)站部署時(shí)需要注意什么
Date: 報(bào)文在源服務(wù)器的產(chǎn)生時(shí)間，由此可查看報(bào)文已緩存了多久時(shí)間Last-Modified: 源服務(wù)器上資源的上次修改時(shí)間
LM-Factor 與它倆有關(guān)。
簡(jiǎn)而言之，一個(gè)靜態(tài)資源沒(méi)有設(shè)置 Cache-Control 時(shí)會(huì)以這兩個(gè)響應(yīng)頭來(lái)設(shè)置強(qiáng)制緩存時(shí)間：(Date - LastModified) * n，而非直接進(jìn)行協(xié)商緩存。在涉及到 CDN 時(shí)，表現(xiàn)更為明顯，體現(xiàn)在更新代碼部署后，界面沒(méi)有更新。
11 http 1.1 中的 keep-alive 有什么作用
在 Issue 或者我的網(wǎng)站中交流與討論: 11 http 1.1 中的 keep-alive 有什么作用
在 http 1.1 中，在響應(yīng)頭中設(shè)置 keep-alive 可以在一個(gè) TCP 連接上發(fā)送多個(gè) http 請(qǐng)求
避免了重開(kāi) TCP 連接的開(kāi)銷(xiāo) 避免了刷新時(shí)重新建立 SSL 連接的開(kāi)銷(xiāo) 避免了QPS過(guò)大時(shí)，服務(wù)器的連接數(shù)過(guò)大
在服務(wù)器端使用響應(yīng)頭開(kāi)啟 keep-alive
Connection:?Keep-Alive
Keep-Alive:?timeout=5,?max=1000
12 如果使用 SSR，可以在 created/componentWillMount 中訪問(wèn) localStorage 嗎
在 Issue 或者我的網(wǎng)站中交流與討論: 12 如果使用 SSR，可以在 created/componentWillMount 中訪問(wèn) localStorage 嗎
不可以，created/componentWillMount 時(shí)，還未掛載，代碼仍然在服務(wù)器中執(zhí)行，此時(shí)沒(méi)有瀏覽器環(huán)境，因此此時(shí)訪問(wèn) localStorage 將會(huì)報(bào)錯(cuò)
13 CSP 是干什么用的了
在 Issue 或者我的網(wǎng)站中交流與討論: 13 CSP 是干什么用的了
CSP 只允許加載指定的腳本及樣式，最大限度地防止 XSS 攻擊，是解決 XSS 的最優(yōu)解。CSP 的設(shè)置根據(jù)加載頁(yè)面時(shí) http 的響應(yīng)頭 Content Security Policy 在服務(wù)器端控制。
外部腳本可以通過(guò)指定域名來(lái)限制： Content-Security-Policy: script-src 'self'，self代表只加載當(dāng)前域名如果網(wǎng)站必須加載內(nèi)聯(lián)腳本 (inline script) ，則可以提供一個(gè) nonce才能執(zhí)行腳本，攻擊者則無(wú)法注入腳本進(jìn)行攻擊。Content-Security-Policy: script-src 'nonce-xxxxxxxxxxxxxxxxxx'
通過(guò) devtools -> network 可見(jiàn) github 的 CSP 配置如下：
Content-Security-Policy:?default-src?'none';?
??base-uri?'self';?
??block-all-mixed-content;
??connect-src?'self'?uploads.github.com?www.githubstatus.com?collector.githubapp.com?api.github.com?www.google-analytics.com?github-cloud.s3.amazonaws.com?github-production-repository-file-5c1aeb.s3.amazonaws.com?github-production-upload-manifest-file-7fdce7.s3.amazonaws.com?github-production-user-asset-6210df.s3.amazonaws.com?cdn.optimizely.com?logx.optimizely.com/v1/events?wss://alive.github.com;?
??font-src?github.githubassets.com;?
??form-action?'self'?github.com?gist.github.com;?
??frame-ancestors?'none';?
??frame-src?render.githubusercontent.com;?
??img-src?'self'?data:?github.githubassets.com?identicons.github.com?collector.githubapp.com?github-cloud.s3.amazonaws.com?*.githubusercontent.com;?
??manifest-src?'self';?
??media-src?'none';?
??script-src?github.githubassets.com;?
??style-src?'unsafe-inline'?github.githubassets.com;?
??worker-src?github.com/socket-worker.js?gist.github.com/socket-worker.js
相關(guān)鏈接
Content Security Policy 入門(mén)教程 - 阮一峰 Content Security Policy - w3
14 簡(jiǎn)述下 css specificity
在 Issue 或者我的網(wǎng)站中交流與討論: 14 簡(jiǎn)述下 css specificity
css specificity 即 css 中關(guān)于選擇器的權(quán)重，以下三種類(lèi)型的選擇器依次下降
id選擇器，如#appclass、attribute與pseudo-classes選擇器，如.header、[type="radio"]與:hovertype標(biāo)簽選擇器和偽元素選擇器，如h1、p和::before
其中通配符選擇器 *，組合選擇器 + ~ >，否定偽類(lèi)選擇器 :not() 對(duì)優(yōu)先級(jí)無(wú)影響
另有內(nèi)聯(lián)樣式 及 !important(最高) 具有更高的權(quán)重
:not的優(yōu)先級(jí)影響 - codepen 可以看出:not對(duì)選擇器的優(yōu)先級(jí)無(wú)任何影響
15 position: sticky 如何工作，適用于哪些場(chǎng)景
在 Issue 或者我的網(wǎng)站中交流與討論: 15 position: sticky 如何工作，適用于哪些場(chǎng)景
position: sticky 可理解為 relative 與 fixed 的結(jié)合體
16 什么情況下會(huì)發(fā)送 OPTIONS 請(qǐng)求
在 Issue 或者我的網(wǎng)站中交流與討論: 16 什么情況下會(huì)發(fā)送 OPTIONS 請(qǐng)求
當(dāng)一個(gè)請(qǐng)求跨域且不是簡(jiǎn)單請(qǐng)求時(shí)就會(huì)發(fā)送 OPTIONS 請(qǐng)求
滿(mǎn)足以下條件就是一個(gè)簡(jiǎn)單請(qǐng)求:
Method: 請(qǐng)求的方法是GET、POST及HEADHeader: 請(qǐng)求頭是Content-Type、Accept-Language、Content-Language等Content-Type: 請(qǐng)求類(lèi)型是application/x-www-form-urlencoded、multipart/form-data或text/plain
而在項(xiàng)目中常見(jiàn)的 Content-Type: application/json 及 Authorization: 為典型的非簡(jiǎn)單請(qǐng)求，在發(fā)送請(qǐng)求時(shí)往往會(huì)帶上 Options
更詳細(xì)內(nèi)容請(qǐng)參考 CORS - MDN
17 簡(jiǎn)述下 TLS 握手過(guò)程
在 Issue 或者我的網(wǎng)站中交流與討論: 17 簡(jiǎn)述下 TLS 握手過(guò)程
TLS 握手的詳細(xì)過(guò)程可參考下圖：
以上圖片來(lái)自 high-performance-browser
從 wireshark 抓包，也可以看到握手的詳細(xì)流程，建議抓包加強(qiáng)理解，以下是抓包 https://q.shanyue.tech 時(shí)的握手流程
通過(guò) curl -vvv --head 來(lái)查看握手信息:
$?curl?-vvv?--head??https://q.shanyue.tech
*???Trying?111.6.180.235...
*?TCP_NODELAY?set
*?Connected?to?q.shanyue.tech?(111.6.180.235)?port?443?(#0)
*?ALPN,?offering?h2
*?ALPN,?offering?http/1.1
*?successfully?set?certificate?verify?locations:
*???CAfile:?/etc/ssl/cert.pem
??CApath:?none
*?TLSv1.2?(OUT),?TLS?handshake,?Client?hello?(1):
*?TLSv1.2?(IN),?TLS?handshake,?Server?hello?(2):
*?TLSv1.2?(IN),?TLS?handshake,?Certificate?(11):
*?TLSv1.2?(IN),?TLS?handshake,?Server?key?exchange?(12):
*?TLSv1.2?(IN),?TLS?handshake,?Server?finished?(14):
*?TLSv1.2?(OUT),?TLS?handshake,?Client?key?exchange?(16):
*?TLSv1.2?(OUT),?TLS?change?cipher,?Change?cipher?spec?(1):
*?TLSv1.2?(OUT),?TLS?handshake,?Finished?(20):
*?TLSv1.2?(IN),?TLS?change?cipher,?Change?cipher?spec?(1):
*?TLSv1.2?(IN),?TLS?handshake,?Finished?(20):
*?SSL?connection?using?TLSv1.2?/?ECDHE-RSA-AES128-GCM-SHA256
*?ALPN,?server?accepted?to?use?h2
*?Server?certificate:
*??subject:?CN=q.shanyue.tech
*??start?date:?Dec??2?00:00:00?2019?GMT
*??expire?date:?Dec??1?12:00:00?2020?GMT
*??subjectAltName:?host?"q.shanyue.tech"?matched?cert's?"q.shanyue.tech"
*??issuer:?C=US;?O=DigiCert?Inc;?OU=www.digicert.com;?CN=Encryption?Everywhere?DV?TLS?CA?-?G1
*??SSL?certificate?verify?ok.
*?Using?HTTP2,?server?supports?multi-use
*?Connection?state?changed?(HTTP/2?confirmed)
*?Copying?HTTP/2?data?in?stream?buffer?to?connection?buffer?after?upgrade:?len=0
*?Using?Stream?ID:?1?(easy?handle?0x7f95ba80dc00)
握手過(guò)程
在 TLS 1.2 中，握手協(xié)議過(guò)程需要耗費(fèi)兩個(gè) RTT，過(guò)程如下
[OUT] Client Hello，客戶(hù)端選出自身支持的 TLS 版本號(hào)、 cipher suites、一個(gè)隨機(jī)數(shù)、SessionId 傳送給服務(wù)器端 (有可能可服用 Session)[IN] Server Hello，服務(wù)器端選出雙方都支持的 TLS 版本， cipher suite、一個(gè)隨機(jī)數(shù)、SeesionId 給客戶(hù)端[IN] Certificate，服務(wù)器端給客戶(hù)端發(fā)送證書(shū)，用以身份驗(yàn)證及提供公鑰 [IN] Server Key Exchange，服務(wù)器端給客戶(hù)端發(fā)送秘鑰交換算法的一些參數(shù) [IN] Server Finished [OUT] Client Key Exchange，客戶(hù)端給服務(wù)器端發(fā)送秘鑰交換算法的一些參數(shù)，計(jì)算出預(yù)備主密鑰 (pre master key)，作為隨機(jī)數(shù)傳遞給服務(wù)器端 (這個(gè)隨機(jī)數(shù)是安全的)。雙方根據(jù)三個(gè)隨機(jī)數(shù)生成對(duì)稱(chēng)加密中的秘鑰 [OUT] Change Cipher Spec，告知對(duì)方以后的消息將要使用TLS記錄層協(xié)議進(jìn)行加密 [OUT] Finished，發(fā)送第一條加密的消息并完整性驗(yàn)證 [IN] Change Cipher Spec，告知以后的消息將要使用TLS記錄層協(xié)議進(jìn)行加密 [IN] Finished，發(fā)送第一條加密的消息并完整性驗(yàn)證
相關(guān)鏈接
https握手流程詳解 Chapter 4. Transport Layer Security (TLS)
18 TLS1.3 相比 TLS1.2 有何不同
在 Issue 或者我的網(wǎng)站中交流與討論: 18 TLS1.3 相比 TLS1.2 有何不同
以下摘自 RFC 5246: TLS 1.2
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not
always sent.
以下摘自 RFC 8446: TLS 1.3
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
* Indicates optional or situation-dependent
messages/extensions that are not always sent.
{} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N.
Figure 1: Message Flow for Full TLS Handshake
握手時(shí)間從以前的 2RTT 縮短到 1RTT，通過(guò) Pre shared-key減少了單獨(dú)的 ServerKeyExchange 與 ClientKeyExchange 消耗的一個(gè) RTT0-RTT Resumption
19 你使用過(guò)哪些前端性能分析工具
在 Issue 或者我的網(wǎng)站中交流與討論: 19 你使用過(guò)哪些前端性能分析工具
最常見(jiàn)且實(shí)用的性能工具有兩個(gè)：
lighthouse: 可在 chrome devtools 直接使用，根據(jù)個(gè)人設(shè)備及網(wǎng)絡(luò)對(duì)目標(biāo)網(wǎng)站進(jìn)行分析，并提供各種建議webpagetest: 分布式的性能分析工具，可在全球多個(gè)區(qū)域的服務(wù)器資源為你的網(wǎng)站進(jìn)行分析，并生成相應(yīng)的報(bào)告
20 如何找到當(dāng)前頁(yè)面出現(xiàn)次數(shù)最多的HTML標(biāo)簽
在 Issue 或者我的網(wǎng)站中交流與討論: 20 如何找到當(dāng)前頁(yè)面出現(xiàn)次數(shù)最多的HTML標(biāo)簽
這是一道前端基礎(chǔ)與編程功底具備的面試題：
如果你前端基礎(chǔ)強(qiáng)會(huì)了解 document.querySelector(*)能夠列出頁(yè)面內(nèi)所有標(biāo)簽如果你編程能力強(qiáng)能夠用遞歸快速實(shí)現(xiàn)同等的效果
有三種 API 可以列出頁(yè)面所有標(biāo)簽：
document.querySelector('*')，標(biāo)準(zhǔn)規(guī)范實(shí)現(xiàn)$$('*')，devtools 實(shí)現(xiàn)document.all，非標(biāo)準(zhǔn)規(guī)范實(shí)現(xiàn)
>?document.querySelectorAll('*')
593)?[html,?head,?meta,?meta,?meta,?meta,?meta,?meta,?meta,?title,?link#favicon,?link,?link#MainCss,?link#mobile-style,?link,?link,?link,?script,?script,?script,?script,?script,?script,?script,?link,?script,?link,?link,?script,?input#_w_brink,?body,?a,?div#home,?div#header,?div#blogTitle,?a#lnkBlogLogo,?img#blogLogo,?h1,?a#Header1_HeaderTitle.headermaintitle.HeaderMainTitle,?h2,?div#navigator,?ul#navList,?li,?a#blog_nav_sitehome.menu,?li,?a#blog_nav_myhome.menu,?li,?a#blog_nav_newpost.menu,?li,?a#blog_nav_contact.menu,?li,?a#blog_nav_rss.menu,?li,?a#blog_nav_admin.menu,?div.blogStats,?span#stats_post_count,?span#stats_article_count,?span#stats-comment_count,?div#main,?div#mainContent,?div.forFlow,?div#post_detail,?div#topics,?div.post,?h1.postTitle,?a#cb_post_title_url.postTitle2.vertical-middle,?span,?div.clear,?div.postBody,?div#cnblogs_post_body.blogpost-body,?p,?p,?strong,?p,?p,?p,?strong,?div.cnblogs_code,?pre,?span,?span,?span,?span,?span,?p,?span,?strong,?pre,?strong,?span,?strong,?br,?br,?br,?div.cnblogs_code,?pre,?span,?span,?p,?p,?…]
[0?…?99]
[100?…?199]
[200?…?299]
[300?…?399]
[400?…?499]
[500?…?592]
__proto__:?NodeList
使用 document.querySelectorAll 實(shí)現(xiàn)如下
const?maxBy?=?(list,?keyBy)?=>?list.reduce((x,?y)?=>?keyBy(x)?>?keyBy(y)???x?:?y)
function?getFrequentTag?()?{
??const?tags?=?[...document.querySelectorAll('*')].map(x?=>?x.tagName).reduce((o,?tag)?=>?{?
????o[tag]?=?o[tag]???o[tag]?+?1?:?1;
????return?o
??},?{})
??return?maxBy(Object.entries(tags),?tag?=>?tag[1])
}
使用 element.children 遞歸迭代如下 (最終結(jié)果多一個(gè) document)
function?getAllTags(el?=?document)?{
??const?children?=?Array.from(el.children).reduce((x,?y)?=>?[...x,?...getAllTags(y)],?[])
??return?children
}
//?或者通過(guò)?flatMap?實(shí)現(xiàn)
function?getAllTags(el?=?document)?{
??const?children?=?Array.prototype.flatMap.call(el.children,?x?=>?getAllTags(x))
??return?[el,?...children]
}
21 在 nginx 中如何配置負(fù)載均衡
在 Issue 或者我的網(wǎng)站中交流與討論: 21 在 nginx 中如何配置負(fù)載均衡
通過(guò) proxy_pass 與 upstream 即可實(shí)現(xiàn)最為簡(jiǎn)單的負(fù)載均衡。如下配置會(huì)對(duì)流量均勻地導(dǎo)向 172.168.0.1，172.168.0.2 與 172.168.0.3 三個(gè)服務(wù)器
http {
upstream backend {
server 172.168.0.1;
server 172.168.0.2;
server 172.168.0.3;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
關(guān)于負(fù)載均衡的策略大致有以下四種種
round_robin，輪詢(xún) weighted_round_robin，加權(quán)輪詢(xún) ip_hash least_conn
Round_Robin
輪詢(xún)，nginx 默認(rèn)的負(fù)載均衡策略就是輪詢(xún)，假設(shè)負(fù)載三臺(tái)服務(wù)器節(jié)點(diǎn)為 A、B、C，則每次流量的負(fù)載結(jié)果為 ABCABC
Weighted_Round_Robin
加權(quán)輪詢(xún)，根據(jù)關(guān)鍵字 weight 配置權(quán)重，如下則平均沒(méi)來(lái)四次請(qǐng)求，會(huì)有八次打在 A，會(huì)有一次打在 B，一次打在 C
upstream backend {
server 172.168.0.1 weight=8;
server 172.168.0.2 weight=1;
server 172.168.0.3 weight=1;
}
IP_hash
對(duì)每次的 IP 地址進(jìn)行 Hash，進(jìn)而選擇合適的節(jié)點(diǎn)，如此，每次用戶(hù)的流量請(qǐng)求將會(huì)打在固定的服務(wù)器上，利于緩存，也更利于 AB 測(cè)試等。
upstream backend {
server 172.168.0.1;
server 172.168.0.2;
server 172.168.0.3;
ip_hash;
}
Least Connection
選擇連接數(shù)最少的服務(wù)器節(jié)點(diǎn)優(yōu)先負(fù)載
upstream backend {
server 172.168.0.1;
server 172.168.0.2;
server 172.168.0.3;
least_conn;
}
說(shuō)到最后，這些負(fù)載均衡策略對(duì)于應(yīng)用開(kāi)發(fā)者至關(guān)重要，而基礎(chǔ)開(kāi)發(fā)者更看重如何實(shí)現(xiàn)這些策略，如這四種負(fù)載算法如何實(shí)現(xiàn)？請(qǐng)參考以后的文章
- END -最后
如果你覺(jué)得這篇內(nèi)容對(duì)你挺有啟發(fā)，我想邀請(qǐng)你幫我三個(gè)小忙：
點(diǎn)個(gè)「在看」，讓更多的人也能看到這篇內(nèi)容（喜歡不點(diǎn)在看，都是耍流氓 -_-）
歡迎加我微信「huab119」拉你進(jìn)技術(shù)群，長(zhǎng)期交流學(xué)習(xí)...
關(guān)注公眾號(hào)「前端勸退師」，持續(xù)為你推送精選好文，也可以加我為好友，隨時(shí)聊騷。
