Nginx實現(xiàn)10萬+并發(fā)

在優(yōu)化內(nèi)核時，可以做的事情很多，不過，我們通常會根據(jù)業(yè)務(wù)特點來進行調(diào)整，當Nginx作為靜態(tài)web內(nèi)容服務(wù)器、反向代理或者提供壓縮服務(wù)器的服務(wù)器時，期內(nèi)核參數(shù)的調(diào)整都是不同的，

概述：

由于默認的linux內(nèi)核參數(shù)考慮的是最通用場景，這明顯不符合用于支持高并發(fā)訪問的Web服務(wù)器的定義，所以需要修改Linux內(nèi)核參數(shù)，讓Nginx可以擁有更高的性能；

注：本文以 PDF 持續(xù)更新，最新尼恩 架構(gòu)筆記、面試題 的PDF文件，請從下面的鏈接獲取： 碼云

參考關(guān)鍵的Linux內(nèi)核優(yōu)化參數(shù)

/etc/sysctl.conf

修改 /etc/sysctl.conf 來更改內(nèi)核參數(shù)

修改好配置文件，執(zhí)行 sysctl -p 命令，使配置立即生效

fs.file-max = 2024000
fs.nr_open = 1024000

net.ipv4.tcp_tw_reuse = 1

ner.ipv4.tcp_keepalive_time = 600

net.ipv4.tcp_fin_timeout = 30

net.ipv4.tcp_max_tw_buckets = 5000

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_rmem = 10240 87380 12582912

net.ipv4.tcp_wmem = 10240 87380 12582912

net.core.netdev_max_backlog = 8096

net.core.rmem_default = 6291456

net.core.wmem_default = 6291456

net.core.rmem_max = 12582912

net.core.wmem_max = 12582912

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_tw_recycle = 1

net.core.somaxconn=262114

net.ipv4.tcp_max_orphans=262114

針對Nginx支持超高吞吐，需要優(yōu)化的，主要是文件句柄數(shù)，TCP網(wǎng)絡(luò)參數(shù)：

系統(tǒng)最大可以打開的句柄數(shù)

fs.file-max = 2024000

將TIME_WAIT狀態(tài)的socket重新用于新的TCP鏈接

net.ipv4.tcp_tw_reuse = 1

#參數(shù)設(shè)置為 1 ，表示允許將TIME_WAIT狀態(tài)的socket重新用于新的TCP鏈接，這對于服務(wù)器來說意義重大，因為總有大量TIME_WAIT狀態(tài)的鏈接存在；

TCP發(fā)送keepalive消息的頻度

ner.ipv4.tcp_keepalive_time = 600
#當keepalive啟動時，TCP發(fā)送keepalive消息的頻度；
默認是2小時，將其設(shè)置為10分鐘，可以更快的清理無效鏈接。

socket保持在FIN_WAIT_2狀態(tài)的最大時間

net.ipv4.tcp_fin_timeout = 30 
#當服務(wù)器主動關(guān)閉鏈接時，socket保持在FIN_WAIT_2狀態(tài)的最大時間

允許TIME_WAIT套接字數(shù)量的最大值

net.ipv4.tcp_max_tw_buckets = 5000
# 這個參數(shù)表示操作系統(tǒng)允許TIME_WAIT套接字數(shù)量的最大值，
# 如果超過這個數(shù)字，TIME_WAIT套接字將立刻被清除并打印警告信息。
# 該參數(shù)默認為180000，過多的TIME_WAIT套接字會使Web服務(wù)器變慢。

本地端口的取值范圍

net.ipv4.ip_local_port_range = 1024 65000 
#定義UDP和TCP鏈接的本地端口的取值范圍。

每個Socket在Linux中都映射為一個文件，并與內(nèi)核中兩個緩沖區(qū)（讀緩沖區(qū)、寫緩沖區(qū)）相關(guān)聯(lián)?；蛘哒f，每個Socket擁有兩個內(nèi)核緩沖區(qū)。通過下面的四個選項配置

• rmem_default：一個Socket的被創(chuàng)建出來時，默認的讀緩沖區(qū)大小，單位字節(jié)；
• wmem_default：一個Socket的被創(chuàng)建出來時，默認的寫緩沖區(qū)大小，單位字節(jié)；
• rmem_max：一個Socket的讀緩沖區(qū)可由程序設(shè)置的最大值，單位字節(jié)；
• wmem_max：一個Socket的寫緩沖區(qū)可由程序設(shè)置的最大值，單位字節(jié)；

net.core.rmem_default = 6291456 
#表示內(nèi)核套接字接受緩存區(qū)默認大小。

net.core.wmem_default = 6291456 
#表示內(nèi)核套接字發(fā)送緩存區(qū)默認大小。

net.core.rmem_max = 12582912 
#表示內(nèi)核套接字接受緩存區(qū)最大大小。

net.core.wmem_max = 12582912 
#表示內(nèi)核套接字發(fā)送緩存區(qū)最大大小。

注意：以上的四個參數(shù)，需要根據(jù)業(yè)務(wù)邏輯和實際的硬件成本來綜合考慮；

還有兩個參數(shù)，tcp_rmem、tcp_wmem。為每個TCP連接分配的讀、寫緩沖區(qū)內(nèi)存大小，單位是Byte

tcp_rmem接受緩存的最小值、默認值、最大值

net.ipv4.tcp_rmem = 10240 87380 12582912 
#定義了TCP接受緩存的最小值、默認值、最大值。

第一個數(shù)字表示緩沖區(qū)最小值，為TCP連接分配的最小內(nèi)存，默認為pagesize（4K字節(jié)），每一個socket接收窗口大小下限；

第二個數(shù)字表示緩沖區(qū)的默認值，為TCP連接分配的缺省內(nèi)存，默認值為16K，為接收窗口大小，所謂的窗口大小只是一個限制數(shù)值，實際對應(yīng)的內(nèi)存緩沖區(qū)由協(xié)議棧管理分配；

第三個數(shù)字表示緩沖區(qū)的最大值，為TCP連接分配的最大內(nèi)存，每個socket鏈路接收窗口大小上限，用于tcp協(xié)議棧自動調(diào)整窗口大小的上限。

注意：實際對應(yīng)的內(nèi)存緩沖區(qū)由協(xié)議棧管理分配

一般按照缺省值分配，上面的例子最新為10KB，默認86KB

發(fā)送緩存的最小值、默認值、最大值。

net.ipv4.tcp_wmem = 10240 87380 12582912 
#定義TCP發(fā)送緩存的最小值、默認值、最大值。

以上是TCP socket的讀寫緩沖區(qū)的設(shè)置，每一項里面都有三個值：

• 第一個值是緩沖區(qū)最小值
• 中間值是緩沖區(qū)的默認值
• 最后一個是緩沖區(qū)的最大值

net.core與net.ipv4開頭的區(qū)別

net.core開頭的配置為網(wǎng)絡(luò)層通用配置，net.ipv4開頭的配置為ipv4使用網(wǎng)絡(luò)配置。

雖然ipv4緩沖區(qū)的值不受core緩沖區(qū)的值的限制，但是緩沖區(qū)的最大值仍舊受限于core的最大值。

net.core.netdev_max_backlog = 8096 
#當網(wǎng)卡接收數(shù)據(jù)包的速度大于內(nèi)核處理速度時，會有一個列隊保存這些數(shù)據(jù)包。這個參數(shù)表示該列隊的最大值。

TCP socket緩沖區(qū)大小是他自己控制而不是由core內(nèi)核緩沖區(qū)控制。

TCP發(fā)送緩沖區(qū)和接收緩沖區(qū)的模型如下：

Client 創(chuàng)建一個 TCP 的 socket，并通過 SO_SNDBUF 選項設(shè)置它的發(fā)送緩沖區(qū)大小為 4096 字節(jié)，連接到 Server 后，每 1 秒發(fā)送一個 TCP 數(shù)據(jù)段長度為 1024 的報文。Server 端不調(diào)用 recv()。預(yù)期的結(jié)果分為以下幾個階段：

Phase 1 Server 端的 socket 接收緩沖區(qū)未滿，所以盡管 Server 不會 recv()，但依然能對 Client 發(fā)出的報文回復(fù) ACK;

Phase 2 Server 端的 socket 接收緩沖區(qū)被填滿了，向 Client 端通告零窗口(Zero Window)。Client 端待發(fā)送的數(shù)據(jù)開始累積在 socket 的發(fā)送緩沖區(qū);

Phase 3 Client 端的 socket 的發(fā)送緩沖區(qū)滿了，用戶進程阻塞在 send() 上。

用于解決TCP的SYN攻擊

net.ipv4.tcp_syncookies = 1
#與性能無關(guān)。用于解決TCP的SYN攻擊。

接受SYN請求列隊的最大長度

net.ipv4.tcp_max_syn_backlog = 8192
#這個參數(shù)表示TCP三次握手建立階段接受SYN請求列隊的最大長度，默認1024，
# 將其設(shè)置的大一些
# 可以使出現(xiàn)Nginx繁忙來不及accept新連接的情況時，Linux不至于丟失客戶端發(fā)起的鏈接請求。

啟用timewait快速回收

net.ipv4.tcp_tw_recycle = 1 
#這個參數(shù)用于設(shè)置啟用timewait快速回收。

調(diào)節(jié)系統(tǒng)同時發(fā)起的TCP連接數(shù)

net.core.somaxconn=262114 
# 選項默認值是128，
# 這個參數(shù)用于調(diào)節(jié)系統(tǒng)同時發(fā)起的TCP連接數(shù)，
# 在高并發(fā)的請求中，默認的值可能會導(dǎo)致鏈接超時或者重傳，因此需要結(jié)合高并發(fā)請求數(shù)來調(diào)節(jié)此值。

防止簡單的DOS攻擊

net.ipv4.tcp_max_orphans=262114 
# 選項用于設(shè)定系統(tǒng)中最多有多少個TCP套接字不被關(guān)聯(lián)到任何一個用戶文件句柄上。
# 如果超過這個數(shù)字，孤立鏈接將立即被復(fù)位并輸出警告信息。
# 這個限制只是為了防止簡單的DOS攻擊，
# 不用過分依靠這個限制甚至認為的減小這個值，更多的情況是增加這個值。

單進程的文件句柄數(shù)配置

/etc/security/limits.conf

/etc/security/limits.conf

* soft nofile 1024000
* hard nofile 1024000
* soft nproc 655360
* hard nproc 655360
* soft stack unlimited
* hard stack unlimited
* soft   memlock    unlimited
* hard   memlock    unlimited

進程最大打開文件描述符數(shù)

* soft nofile 1000000
* hard nofile 1000000
* soft nproc 655360
* hard nproc 655360

# *代表針對所有用戶
# nproc 是代表最大進程數(shù)
# nofile 是代表最大文件打開數(shù)

hard和soft的區(qū)別：在設(shè)定上，通常soft會比hard小，

舉例來說，soft可以設(shè)置為80，而hard設(shè)定為100，那么你可以使用到90（沒有超過100），但介于80~100之間時，系統(tǒng)會有警告信息通知你。

總之：

a. 所有進程打開的文件描述符數(shù)不能超過/proc/sys/fs/file-max

b. 單個進程打開的文件描述符數(shù)不能超過user limit中nofile的soft limit

c. nofile的soft limit不能超過其hard limit

d. nofile的hard limit不能超過/proc/sys/fs/nr_open

RocketMQ生產(chǎn)環(huán)境配置

參考的broker 配置

集群架構(gòu)為異步刷盤、同步復(fù)制

#請修改
brokerClusterName=XXXCluster
brokerName=broker-a
brokerId=0
listenPort=10911
#請修改
namesrvAddr=x.x.x.x:9876;x.x.x.x::9876
defaultTopicQueueNums=4
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
deleteWhen=04
fileReservedTime=48
mapedFileSizeCommitLog=1073741824
mapedFileSizeConsumeQueue=50000000
destroyMapedFileIntervalForcibly=120000
redeleteHangedFileInterval=120000
diskMaxUsedSpaceRatio=88
#存儲路徑
storePathRootDir=/data/rocketmq/store
#commitLog存儲路徑
storePathCommitLog=/data/rocketmq/store/commitlog
#消費隊列存儲路徑
storePathConsumeQueue=/data/rocketmq/store/consumequeue
# 消息索引存儲路徑
storePathIndex=/data/rocketmq/store/index
# checkpoint 文件存儲路徑
storeCheckpoint=/data/rocketmq/store/checkpoint
#abort 文件存儲路徑
abortFile=/data/rocketmq/store/abort
maxMessageSize=65536
flushCommitLogLeastPages=4
flushConsumeQueueLeastPages=2
flushCommitLogThoroughInterval=10000
flushConsumeQueueThoroughInterval=60000
brokerRole=SYNC_MASTER
flushDiskType=ASYNC_FLUSH
checkTransactionMessageEnable=false
maxTransferCountOnMessageInMemory=1000
transientStorePoolEnable=true
warmMapedFileEnable=true
pullMessageThreadPoolNums=128
slaveReadEnable=true
transferMsgByHeap=false
waitTimeMillsInSendQueue=1000

ElasticSearch生產(chǎn)環(huán)境配置

參考的配置文件

/etc/sysctl.conf

fs.file-max = 2024000
fs.nr_open = 1024000

net.ipv4.tcp_tw_reuse = 1

ner.ipv4.tcp_keepalive_time = 600

net.ipv4.tcp_fin_timeout = 30

net.ipv4.tcp_max_tw_buckets = 5000

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_rmem = 10240 87380 12582912

net.ipv4.tcp_wmem = 10240 87380 12582912

net.core.netdev_max_backlog = 8096

net.core.rmem_default = 6291456

net.core.wmem_default = 6291456

net.core.rmem_max = 12582912

net.core.wmem_max = 12582912

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_tw_recycle = 1

net.core.somaxconn=262114

net.ipv4.tcp_max_orphans=262114
net.ipv4.tcp_retries2 = 5
vm.max_map_count = 262144

操作系統(tǒng)

較大的文件描述符

Lucene使用了非常大量的文件。 并且Elasticsearch使用大量的套接字在節(jié)點和HTTP客戶端之間進行通信。

所有這些都需要可用的文件描述符。

可悲的是，許多現(xiàn)代的Linux發(fā)行版每個進程允許一個不允許的1024個文件描述符。

這對于一個小的Elasticsearch節(jié)點來說太低了，更不用說處理數(shù)百個索引的節(jié)點了。

設(shè)置MMap

Elasticsearch還針對各種文件使用NioFS和MMapFS的混合。

確保配置最大映射計數(shù)，以便有足夠的虛擬內(nèi)存可用于mmapped文件。

Elasticsearch默認使用一個mappfs目錄來存儲索引。默認操作系統(tǒng)對mmap計數(shù)的限制可能太低，這可能會導(dǎo)致內(nèi)存不足異常。

暫時設(shè)置 sysctl -w vm.max_map_count=262144

永久設(shè)置

$ vim /etc/sysctl.conf

# 設(shè)置操作系統(tǒng)mmap數(shù)限制，Elasticsearch與Lucene使用mmap來映射部分索引到Elasticsearch的地址空間
# 為了讓mmap生效，Elasticsearch還需要有創(chuàng)建需要內(nèi)存映射區(qū)的能力。最大map數(shù)檢查是確保內(nèi)核允許創(chuàng)建至少262144個內(nèi)存映射區(qū)
vm.max_map_count = 262144

JVM虛擬機

除非Elasticsearch網(wǎng)站上另有說明，否則應(yīng)始終運行最新版本的Java虛擬機（JVM）。

Elasticsearch和Lucene都是比較苛刻的軟件。

Lucene的單元和集成測試通常暴露JVM本身的錯誤。

Number of threads（線程數(shù)或者進程數(shù)）

Elasticsearch為不同類型的操作使用了許多線程池。它能夠在需要時創(chuàng)建新線程，這一點很重要。確保Elasticsearch用戶可以創(chuàng)建的線程數(shù)量至少是4096個。

$ vim /etc/security/limits.conf

elasticsearch soft nproc 4096
elasticsearch hard nproc 4096

給lucene留下一半的內(nèi)存空間

一個常見的問題是配置一個太大的堆。你有一個64GB的機器，并且你想給Elasticsearch所有64GB的內(nèi)存。

更多更好？！堆對Elasticsearch絕對重要，它被許多內(nèi)存數(shù)據(jù)結(jié)構(gòu)使用以提供快速操作。

但是還有另一個主要的內(nèi)存用戶是 Lucene。Lucene旨在利用底層操作系統(tǒng)來緩存內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)。

Lucene的segment 段存儲在單獨的文件中，因為段是不可變的，所以這些文件從不改變。這使得它們非常易于緩存，并且底層操作系統(tǒng)將適合的保持segment駐留在內(nèi)存中以便更快地訪問。

這些段包括反向索引（用于全文搜索）和docvalues（用于聚合）。

Lucene的性能依賴于與操作系統(tǒng)的這種交互。但是如果你給Elasticsearch的堆提供所有可用的內(nèi)存，Lucene就不會有任何剩余的內(nèi)存。

這會嚴重影響性能。

標準建議是給Elasticsearch堆提供50％的可用內(nèi)存，同時保留其他50％的空閑內(nèi)存。

它不會不使用; Lucene會愉快地吞噬剩下的任何東西。

如果你不是聚合在分析的字符串字段（例如你不需要fielddata），你可以考慮降低堆更多。你可以做的堆越小，你可以期望從

Elasticsearch（更快的GC）和Lucene（更多的內(nèi)存緩存）更好的性能。

不要超過32G

事實證明，當堆大小小于32GB時，HotSpot JVM使用一個技巧來壓縮對象指針。

可以通過-XX:+PrintFlagsFinal來查看，在es2.2.0后不用設(shè)置，啟動后會打印compressed ordinary object pointers [true]

在Java中，所有對象都在堆上分配并由指針引用。

Ordinary object pointers（OOP）指向這些對象，并且通常是CPU本地字的大?。?2位或64位，取決于處理器。

指針引用值的確切字節(jié)位置。 對于32位系統(tǒng)，這最大堆大小為4GB。

對于64位系統(tǒng)，堆大小可以變得更大，但64位指針的開銷意味著更多的浪費空間，因為指針更大。并且比浪費的空間更糟，當在主存儲器和各種高速緩存（LLC，L1等）之間移動值時，較大的指針占用更多的帶寬。

Java使用一個名為compress oops的技巧來解決這個問題。指針不是指向存儲器中的精確字節(jié)位置，而是引用對象偏移。這意味著32位指針可以引用四十億個對象，而不是40億字節(jié)。

最終，這意味著堆可以增長到大約32 GB的物理大小，同時仍然使用32位指針。

一旦你超越32GB邊界，指針切換回Ordinary object pointers。

每個指針的大小增加，使用更多的CPU內(nèi)存帶寬，并且您有效地丟失了內(nèi)存。

事實上，它需要直到大約40到50GB的分配的堆，你有一個堆的相同有效內(nèi)存剛剛低于32GB使用壓縮oops。所以即使你有內(nèi)存，盡量避免跨越32 GB堆邊界。它浪費內(nèi)存，降低CPU性能，并使GC與大堆爭奪。

swapping是性能的死穴

它應(yīng)該是顯而易見的，但它明確拼寫出來：將主內(nèi)存交換到磁盤會破壞服務(wù)器性能。 內(nèi)存中操作是需要快速執(zhí)行的操作。如果內(nèi)存交換到磁盤，100微秒操作將花費10毫秒。 現(xiàn)在重復(fù)所有其他10us操作的延遲增加。 不難看出為什么交換對于性能來說是可怕的。

1、最好的辦法是在系統(tǒng)上完全禁用交換。 這可以臨時完成：

sudo swapoff -a

要永久禁用則需要編輯/etc/fstab。請查閱操作系統(tǒng)的文檔。

2、如果完全禁用交換不是一個選項，您可以嘗試

sysctl vm.swappiness = 1（查看cat /proc/sys/vm/swappiness）

這個設(shè)置控制操作系統(tǒng)如何積極地嘗試交換內(nèi)存。 以防止在正常情況下交換，但仍然允許操作系統(tǒng)在緊急情況下交換。swappiness值1比0好，因為在一些內(nèi)核版本上，swappiness為0可以調(diào)用OOM-killer。

3、最后，如果兩種方法都不可能，就應(yīng)該啟用mlockall。 這允許JVM鎖定其內(nèi)存，并防止它被操作系統(tǒng)交換。 可以在elasticsearch.yml中設(shè)置：

bootstrap.mlockall: true

TCP retransmission timeout（TCP重傳超時）

集群中的每一對節(jié)點通過許多TCP連接進行通信，這些TCP連接一直保持打開狀態(tài)，直到其中一個節(jié)點關(guān)閉或由于底層基礎(chǔ)設(shè)施中的故障而中斷節(jié)點之間的通信。

TCP通過對通信應(yīng)用程序隱藏臨時的網(wǎng)絡(luò)中斷，在偶爾不可靠的網(wǎng)絡(luò)上提供可靠的通信。在通知發(fā)送者任何問題之前，您的操作系統(tǒng)將多次重新傳輸任何丟失的消息。大多數(shù)Linux發(fā)行版默認重傳任何丟失的數(shù)據(jù)包15次。重傳速度呈指數(shù)級下降，所以這15次重傳需要900秒才能完成。這意味著Linux使用這種方法需要花費許多分鐘來檢測網(wǎng)絡(luò)分區(qū)或故障節(jié)點。Windows默認只有5次重傳，相當于6秒左右的超時。

Linux默認允許在可能經(jīng)歷很長時間包丟失的網(wǎng)絡(luò)上進行通信，但是對于單個數(shù)據(jù)中心內(nèi)的生產(chǎn)網(wǎng)絡(luò)來說，這個默認值太大了，就像大多數(shù)Elasticsearch集群一樣。高可用集群必須能夠快速檢測節(jié)點故障，以便它們能夠通過重新分配丟失的碎片、重新路由搜索以及可能選擇一個新的主節(jié)點來迅速作出反應(yīng)。因此，Linux用戶應(yīng)該減少TCP重傳的最大數(shù)量。

$ vim /etc/sysctl.conf

net.ipv4.tcp_retries2 = 5

config/ jvm.options

• Elasticsearch有足夠的可用堆是非常重要的。
• 堆的最小值（Xms）與堆的最大值（Xmx）設(shè)置成相同的。
• Elasticsearch的可用堆越大，它能在內(nèi)存中緩存的數(shù)據(jù)越多。但是需要注意堆越大在垃圾回收時造成的暫停會越長。
• 設(shè)置Xmx不要大于物理內(nèi)存的50%。用來確保有足夠多的物理內(nèi)存預(yù)留給操作系統(tǒng)緩存。
• 禁止用串行收集器來運行Elasticsearch（-XX:+UseSerialGC），默認JVM配置通過Elasticsearch的配置將使用CMS回收器。

-Xms32g
-Xmx32g

硬件方面

內(nèi)存

首先最重要的資源是內(nèi)存，排序和聚合都可能導(dǎo)致內(nèi)存匱乏，因此足夠的堆空間來容納這些是重要的。

即使堆比較小，也要給操作系統(tǒng)高速緩存提供額外的內(nèi)存，因為Lucene使用的許多數(shù)據(jù)結(jié)構(gòu)是基于磁盤的格式，Elasticsearch利用操作系統(tǒng)緩存有很大的影響。

64GB RAM的機器是最理想的，但32GB和16GB機器也很常見。

少于8GB往往適得其反（你最終需要許多，許多小機器），大于64GB可能會有問題，我們將在討論在堆：大小和交換。

CPU

大多數(shù)Elasticsearch部署往往對CPU要求很不大。因此，確切的處理器設(shè)置比其他資源更重要，應(yīng)該選擇具有多個內(nèi)核的現(xiàn)代處理器。通用集群使用2到8核機器。

如果需要在較快的CPU或更多核之間進行選擇，請選擇更多核。 多核提供的額外并發(fā)將遠遠超過稍快的時鐘速度。

硬盤

磁盤對于所有集群都很重要，尤其是對于索引很重的集群（例如攝取日志數(shù)據(jù)的磁盤）。 磁盤是服務(wù)器中最慢的子系統(tǒng)，這意味著大量寫入的群集可以輕松地飽和其磁盤，這反過來成為群集的瓶頸。

如果你能買得起SSD，他們遠遠優(yōu)于任何旋轉(zhuǎn)磁盤。 支持SSD的節(jié)點看到查詢和索引性能方面的提升。

如果使用旋轉(zhuǎn)磁盤，請嘗試獲取盡可能最快的磁盤（高性能服務(wù)器磁盤，15k轉(zhuǎn)速驅(qū)動器）。

使用RAID 0是提高磁盤速度的有效方法，適用于旋轉(zhuǎn)磁盤和SSD。 沒有必要使用RAID的鏡像或奇偶校驗變體，因為高可用性是通過副本建立到Elasticsearch中。

最后，避免網(wǎng)絡(luò)連接存儲（NAS）。 NAS通常較慢，顯示較大的延遲，平均延遲的偏差較大，并且是單點故障。

網(wǎng)絡(luò)

快速和可靠的網(wǎng)絡(luò)對于分布式系統(tǒng)中的性能顯然是重要的。低延遲有助于確保節(jié)點可以輕松地進行通信，而高帶寬有助于分段移動和恢復(fù)?，F(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)（1GbE，10GbE）對于絕大多數(shù)集群都是足夠的。

避免跨越多個數(shù)據(jù)中心的群集，即使數(shù)據(jù)中心位置非常接近。絕對避免跨越大地理距離的集群。

Elasticsearch集群假定所有節(jié)點相等，而不是一半的節(jié)點距離另一個數(shù)據(jù)中心中有150ms。較大的延遲往往會加劇分布式系統(tǒng)中的問題，并使調(diào)試和解決更加困難。

與NAS參數(shù)類似，每個人都聲稱數(shù)據(jù)中心之間的管道是穩(wěn)健的和低延遲。（吹牛）。從我們的經(jīng)驗，管理跨數(shù)據(jù)中心集群的麻煩就是浪費成本。

其他配置

現(xiàn)在可以獲得真正巨大的機器如數(shù)百GB的RAM和幾十個CPU內(nèi)核。 另外也可以在云平臺（如EC2）中啟動數(shù)千個小型虛擬機。 哪種方法最好？

一般來說，最好選擇中到大盒子。 避免使用小型機器，因為您不想管理具有一千個節(jié)點的集群，而簡單運行Elasticsearch的開銷在這種小型機器上更為明顯。

同時，避免真正巨大的機器。 它們通常導(dǎo)致資源使用不平衡（例如，所有內(nèi)存正在使用，但沒有CPU），并且如果您必須為每臺機器運行多個節(jié)點，可能會增加后期的運維復(fù)雜性。

技術(shù)自由的實現(xiàn)路徑：

實現(xiàn)你的 架構(gòu)自由：

《吃透8圖1模板，人人可以做架構(gòu)》

《10Wqps評論中臺，如何架構(gòu)？B站是這么做的！?。　?/p>

《阿里二面：千萬級、億級數(shù)據(jù)，如何性能優(yōu)化？ 教科書級 答案來了》

《峰值21WQps、億級DAU，小游戲《羊了個羊》是怎么架構(gòu)的？》

《100億級訂單怎么調(diào)度，來一個大廠的極品方案》

《2個大廠 100億級 超大流量 紅包 架構(gòu)方案》

… 更多架構(gòu)文章，正在添加中

實現(xiàn)你的 響應(yīng)式 自由：

《響應(yīng)式圣經(jīng)：10W字，實現(xiàn)Spring響應(yīng)式編程自由》

這是老版本 《Flux、Mono、Reactor 實戰(zhàn)（史上最全）》

實現(xiàn)你的 spring cloud 自由：

《Spring cloud Alibaba 學習圣經(jīng)》 PDF

《分庫分表 Sharding-JDBC 底層原理、核心實戰(zhàn)（史上最全）》

《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關(guān)系（史上最全）》

實現(xiàn)你的 linux 自由：

《Linux命令大全：2W多字，一次實現(xiàn)Linux自由》

實現(xiàn)你的 網(wǎng)絡(luò) 自由：

《TCP協(xié)議詳解 (史上最全)》

《網(wǎng)絡(luò)三張表：ARP表, MAC表, 路由表，實現(xiàn)你的網(wǎng)絡(luò)自由??！》

實現(xiàn)你的 分布式鎖 自由：

《Redis分布式鎖（圖解 - 秒懂 - 史上最全）》

《Zookeeper 分布式鎖 - 圖解 - 秒懂》

實現(xiàn)你的 王者組件 自由：

《隊列之王： Disruptor 原理、架構(gòu)、源碼 一文穿透》

《緩存之王：Caffeine 源碼、架構(gòu)、原理（史上最全，10W字 超級長文）》

《緩存之王：Caffeine 的使用（史上最全）》

《Java Agent 探針、字節(jié)碼增強 ByteBuddy（史上最全）》

實現(xiàn)你的 面試題 自由：

4000頁《尼恩Java面試寶典 》 40個專題

以上尼恩 架構(gòu)筆記、面試題 的PDF文件更新，請到《技術(shù)自由圈》公號獲取↓↓↓文章來源地址http://www.zghlxwxcb.cn/news/detail-427766.html

到了這里，關(guān)于Nginx生產(chǎn)環(huán)境配置、elasticsearch生產(chǎn)環(huán)境配置、rocketmq生產(chǎn)環(huán)境配置 （史上最全）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！