本文涉及的點：
jvm
nginx狀態(tài)
微服務(wù)
spring cloud
keepalived
PV/UV
主從復(fù)制养葵，讀寫分離（同步）
存儲（NFS征堪，rsync）
消峰

JVM

Java虛擬機包括一套字節(jié)碼指令集、一組寄存器关拒、一個棧佃蚜、一個垃圾回收堆和一個存儲方法域
java與語言編譯程序?qū)ava代碼解釋成字節(jié)碼，jvm將字節(jié)碼解釋成及啟指令
JRE：java的平臺着绊，所有java都要運行在JRE里
JDK：程序開發(fā)者用來編譯谐算、調(diào)試java程序的開發(fā)者工具包。JDK的工具也是java程序归露，也需要JDK才能運行
JVM：是JRE的一部分

JVM的執(zhí)行程序的過程

• 加載.class文件
• 管理分配內(nèi)存
• 執(zhí)行垃圾回收

一洲脂、前言

Java的GC（垃圾回收）機制是區(qū)別C++的一個重要特征。C++需要開發(fā)者在代碼中實現(xiàn)垃圾回收邏輯，但在Java中恐锦，JVM幫開發(fā)者代勞了往果。我們只有理解了GC機制，才能編寫出高性能的應(yīng)用一铅。要想理解GC陕贮，就要先理解JVM內(nèi)存管理機制。這樣才能知道回收哪些對象潘飘，什么時候回收以及怎么回收

二肮之、JVM

根據(jù)JVM規(guī)范，JVM把內(nèi)存劃分成了如下幾個區(qū)域：

1.方法區(qū)（Method  Area）
2.堆區(qū)（Heap）
3.虛擬機棧（VM  Stack）
4.本地方法棧（Native  Method  Stack）
5.程序計數(shù)器（Program  Counter  Register）

其中卜录，方法區(qū)和堆區(qū)所有線程共享戈擒。
靜態(tài)變量 + 常量 + 類信息(構(gòu)造方法/接口定義) + 運行時常量池存放在 方法區(qū) 中
實例變量 存放在 堆內(nèi)存 中

2.1 方法區(qū)（Method Area）

方法區(qū)存放了要加載的類的信息（如類名、修飾符等）艰毒、靜態(tài)變量筐高、構(gòu)造函數(shù)、final定義的常量丑瞧、類中的字段和方法等信息凯傲。方法區(qū)是全局共享的，在一定條件下也會被GC嗦篱。當方法區(qū)超過它允許的大小時，就會拋出OutOfMemory：PermGen Space異常幌缝。
在Hotspot虛擬機中灸促，這塊區(qū)域?qū)?yīng)持久代（Permanent Generation），一般來說涵卵，方法區(qū)上執(zhí)行GC的情況很少浴栽，因此方法區(qū)被稱為持久代的原因之一，但這并不代表方法區(qū)上完全沒有GC轿偎，其上的GC主要針對常量池的回收和已加載類的卸載典鸡。在方法區(qū)上進行GC，條件相當苛刻而且困難坏晦。
運行時常量池（Runtime Constant Pool）是方法區(qū)的一部分萝玷，用于存儲編譯器生成的常量和引用。一般來說昆婿，常量的分配在編譯時就能確定球碉，但也不全是，也可以存儲在運行時期產(chǎn)生的常量仓蛆。比如String類的intern（）方法睁冬，作用是String類維護了一個常量池，如果調(diào)用的字符"hello"已經(jīng)在常量池中看疙，則直接返回常量池中的地址豆拨，否則新建一個常量加入池中直奋，并返回地址。

2.2 堆區(qū)（Heap）

堆區(qū)是GC最頻繁的施禾，也是理解GC機制最重要的區(qū)域脚线。堆區(qū)由所有線程共享，在虛擬機啟動時創(chuàng)建拾积。堆區(qū)主要用于存放對象實例及數(shù)組殉挽，所有new出來的對象都存儲在該區(qū)域。

2.3 虛擬機棧（VM Stack）

虛擬機棧占用的是操作系統(tǒng)內(nèi)存拓巧，每個線程對應(yīng)一個虛擬機棧斯碌，它是線程私有的，生命周期和線程一樣肛度，每個方法被執(zhí)行時產(chǎn)生一個棧幀（Statck Frame）傻唾，棧幀用于存儲局部變量表、動態(tài)鏈接承耿、操作數(shù)和方法出口等信息冠骄，當方法被調(diào)用時，棧幀入棧加袋，當方法調(diào)用結(jié)束時凛辣，棧幀出棧。
局部變量表中存儲著方法相關(guān)的局部變量职烧，包括各種基本數(shù)據(jù)類型及對象的引用地址等扁誓，因此他有個特點：內(nèi)存空間可以在編譯期間就確定，運行時不再改變蚀之。
虛擬機棧定義了兩種異常類型：StackOverFlowError(棧溢出)和OutOfMemoryError（內(nèi)存溢出）蝗敢。如果線程調(diào)用的棧深度大于虛擬機允許的最大深度，則拋出StackOverFlowError足删；不過大多數(shù)虛擬機都允許動態(tài)擴展虛擬機棧的大小寿谴，所以線程可以一直申請棧，直到內(nèi)存不足時失受，拋出OutOfMemoryError讶泰。

2.4 本地方法棧（Native Method Stack）

本地方法棧用于支持native方法的執(zhí)行，存儲了每個native方法的執(zhí)行狀態(tài)拂到。本地方法棧和虛擬機棧他們的運行機制一致峻厚，唯一的區(qū)別是，虛擬機棧執(zhí)行Java方法谆焊，本地方法棧執(zhí)行native方法惠桃。在很多虛擬機中（如Sun的JDK默認的HotSpot虛擬機），會將虛擬機棧和本地方法棧一起使用。

2.5 程序計數(shù)器（Program Counter Register）

程序計數(shù)器是一個很小的內(nèi)存區(qū)域辜王，不在RAM上劈狐，而是直接劃分在CPU上，程序猿無法操作它呐馆，它的作用是：JVM在解釋字節(jié)碼（.class）文件時肥缔，存儲當前線程執(zhí)行的字節(jié)碼行號，只是一種概念模型汹来，各種JVM所采用的方式不一樣续膳。字節(jié)碼解釋器工作時，就是通過改變程序計數(shù)器的值來取下一條要執(zhí)行的指令收班，分支坟岔、循環(huán)、跳轉(zhuǎn)等基礎(chǔ)功能都是依賴此技術(shù)區(qū)完成的摔桦。
每個程序計數(shù)器只能記錄一個線程的行號社付，因此它是線程私有的。
如果程序當前正在執(zhí)行的是一個java方法邻耕，則程序計數(shù)器記錄的是正在執(zhí)行的虛擬機字節(jié)碼指令地址鸥咖，如果執(zhí)行的是native方法，則計數(shù)器的值為空兄世，此內(nèi)存區(qū)是唯一不會拋出OutOfMemoryError的區(qū)域啼辣。

總結(jié)：這里，只有方法區(qū)和堆區(qū)的內(nèi)存需要回收

三御滩、GC機制

回收的對象：不存在任何引用的對象

3.1如何判斷對象是垃圾 ?

經(jīng)典的引用計數(shù)算法熙兔，每個對象添加到引用計數(shù)器，每被引用一次艾恼，計數(shù)器+1，失去引用麸锉，計數(shù)器-1钠绍，當計數(shù)器在一段時間內(nèi)為0時，即認為該對象可以被回收了花沉。但是這個算法有個明顯的缺陷：當兩個對象相互引用柳爽，但是二者都已經(jīng)沒有作用時，理應(yīng)把它們都回收碱屁，但是由于它們相互引用磷脯，不符合垃圾回收的條件，所以就導致無法處理掉這一塊內(nèi)存區(qū)域娩脾。因此赵誓，Sun的JVM并沒有采用這種算法，而是采用一個叫——根搜索算法，如圖：

image.png

基本思想是：從一個叫GC Roots的根節(jié)點出發(fā)俩功，向下搜索幻枉，如果一個對象不能達到GC Roots的時候，說明該對象不再被引用诡蜓，可以被回收熬甫。如上圖中的Object5、Object6蔓罚、Object7椿肩，雖然它們?nèi)齻€依然相互引用，但是它們其實已經(jīng)沒有作用了豺谈，這樣就解決了引用計數(shù)算法的缺陷郑象。

3.2內(nèi)存分代

新生代    位于堆區(qū)

新生代適合生命周期較短，快速創(chuàng)建和銷毀的對象

大致分為Eden區(qū)和Survivor區(qū)核无，Survivor區(qū)又分為大小相同的兩部分：FromSpace和ToSpace扣唱。
新建的對象都是從新生代分配內(nèi)存，Eden區(qū)不足的時候团南，會把存活的對象轉(zhuǎn)移到Survivor區(qū)噪沙。
當新生代進行垃圾回收時會出發(fā)Minor  GC（也稱作Youn  GC）

老年代      位于堆區(qū)

適合生命周期較長的對象

老年代用于存放新生代多次回收依然存活的對象，如緩存對象吐根。
當老年代滿了的時候就需要對老年代進行回收正歼，老年代的垃圾回收稱作Major  GC（也稱作Full  GC）

持久代      位于方法區(qū)

Sun  Hotp ot虛擬機中就是指方法區(qū)

結(jié)合我們經(jīng)常使用的一些 jvm 調(diào)優(yōu)參數(shù)后，一些參數(shù)能影響的各區(qū)域內(nèi)存大小值拷橘，示意圖如下：

image.png

注：jdk8 開始局义，用 MetaSpace 區(qū)取代了 Perm 區(qū)（永久代），所以相應(yīng)的 jvm 參數(shù)變成 -XX:MetaspaceSize 及 -XX:MaxMetaspaceSize冗疮。

3.3常用GC算法

1）復(fù)制算法
復(fù)制算法采用的方式為從根集合進行掃描萄唇，將存活的對象移動到一塊空閑的區(qū)域

image.png

2）標記-清除算法
該算法采用的方式是從跟集合開始掃描，對存活的對象進行標記术幔，標記完畢后另萤，再掃描整個空間中未被標記的對象，并進行清除

image.png

3）標記-壓縮算法
該算法與標記-清除算法類似诅挑，都是先對存活的對象進行標記四敞，但是在清除后會把活的對象向左端空閑空間移動，然后再更新其引用對象的指針

image.png

4）分代收集算法
在新生代中拔妥，由于對象生存期短忿危，每次回收都會有大量對象死去，那么這時就采用復(fù)制算法没龙。
老年代里的對象存活率較高铺厨，沒有額外的空間進行分配擔保缎玫，所以可以使用標記-整理 或者 標記-清除。

具體過程：新生代(Young)分為Eden區(qū)努释，F(xiàn)rom區(qū)與To區(qū)

image.png

當系統(tǒng)創(chuàng)建一個對象的時候碘梢，總是在Eden區(qū)操作，當這個區(qū)滿了伐蒂，那么就會觸發(fā)一次YoungGC煞躬，也就是年輕代的垃圾回收。一般來說這時候不是所有的對象都沒用了逸邦，所以就會把還能用的對象復(fù)制到From區(qū)恩沛。

image.png

這樣整個Eden區(qū)就被清理干凈了，可以繼續(xù)創(chuàng)建新的對象缕减，當Eden區(qū)再次被用完雷客，就再觸發(fā)一次YoungGC，然后呢桥狡，注意搅裙，這個時候跟剛才稍稍有點區(qū)別。這次觸發(fā)YoungGC后裹芝，會將Eden區(qū)與From區(qū)還在被使用的對象復(fù)制到To區(qū)部逮，

image.png

再下一次YoungGC的時候，則是將Eden區(qū)與To區(qū)中的還在被使用的對象復(fù)制到From區(qū)嫂易。

image.png

經(jīng)過若干次YoungGC后兄朋，有些對象在From與To之間來回游蕩，這時候From區(qū)與To區(qū)亮出了底線（閾值）怜械，這些家伙要是到現(xiàn)在還沒掛掉颅和，對不起，一起滾到（復(fù)制）老年代吧缕允。

image.png

老年代經(jīng)過這么幾次折騰峡扩，也就扛不住了（空間被用完），好障本，那就來次集體大掃除（Full GC）教届，也就是全量回收。如果Full GC使用太頻繁的話彼绷，無疑會對系統(tǒng)性能產(chǎn)生很大的影響。所以要合理設(shè)置年輕代與老年代的大小茴迁，盡量減少Full GC的操作寄悯。

方法區(qū)對象回收

永久代指的是虛擬機內(nèi)存中的方法區(qū)，永久代垃圾回收比較少堕义，效率也比較低猜旬，但也必須進行垃圾回收脆栋，否則永久代內(nèi)存
不夠用時仍然會拋出OutOfMemoryError異常。永久代也使用“標記-清除”或者“標記-整理”算法進行垃圾回收洒擦。

四、垃圾回收器

4.1.Serial收集器

串行收集器是最古老，最穩(wěn)定以及效率高的收集器
可能會產(chǎn)生較長的停頓朴上，只使用一個線程去回收
-XX:+UseSerialGC

新生代机错、老年代使用串行回收
新生代復(fù)制算法
老年代標記-壓縮

image.png

4.2. 并行收集器

4.2.1 ParNew
-XX:+UseParNewGC（new代表新生代，所以適用于新生代）

新生代并行
老年代串行

Serial收集器新生代的并行版本
在新生代回收時使用復(fù)制算法
多線程掸茅，需要多核支持
-XX:ParallelGCThreads 限制線程數(shù)量

image.png

4.2.2 Parallel收集器
類似ParNew
新生代復(fù)制算法
老年代標記-壓縮
更加關(guān)注吞吐量

-XX:+UseParallelGC

使用Parallel收集器+ 老年代串行

-XX:+UseParallelOldGC

使用Parallel收集器+ 老年代并行

image.png

4.2.3 其他GC參數(shù)

-XX:MaxGCPauseMills

最大停頓時間椅邓，單位毫秒
GC盡力保證回收時間不超過設(shè)定值
-XX:GCTimeRatio

0-100的取值范圍
垃圾收集時間占總時間的比
默認99，即最大允許1%時間做GC
這兩個參數(shù)是矛盾的昧狮。因為停頓時間和吞吐量不可能同時調(diào)優(yōu)

4.3. CMS收集器

Concurrent Mark Sweep 并發(fā)標記清除（應(yīng)用程序線程和GC線程交替執(zhí)行）
使用標記-清除算法
并發(fā)階段會降低吞吐量（停頓時間減少景馁，吞吐量降低）
老年代收集器（新生代使用ParNew）
-XX:+UseConcMarkSweepGC

CMS運行過程比較復(fù)雜，著重實現(xiàn)了標記的過程逗鸣，可分為

1. 初始標記（會產(chǎn)生全局停頓）

根可以直接關(guān)聯(lián)到的對象
速度快
2. 并發(fā)標記（和用戶線程一起） 

主要標記過程合住，標記全部對象
3. 重新標記 （會產(chǎn)生全局停頓） 

由于并發(fā)標記時，用戶線程依然運行撒璧，因此在正式清理前透葛，再做修正
4. 并發(fā)清除（和用戶線程一起） 

基于標記結(jié)果，直接清理對象

image.png

這里就能很明顯的看出沪悲，為什么CMS要使用標記清除而不是標記壓縮获洲，如果使用標記壓縮，需要多對象的內(nèi)存位置進行改變殿如，這樣程序就很難繼續(xù)執(zhí)行贡珊。但是標記清除會產(chǎn)生大量內(nèi)存碎片，不利于內(nèi)存分配涉馁。

4.4. G1收集器

G1是目前技術(shù)發(fā)展的最前沿成果之一门岔，HotSpot開發(fā)團隊賦予它的使命是未來可以替換掉JDK1.5中發(fā)布的CMS收集器。

與CMS收集器相比G1收集器有以下特點：

(1) 空間整合烤送，G1收集器采用標記整理算法寒随，不會產(chǎn)生內(nèi)存空間碎片。分配大對象時不會因為無法找到連續(xù)空間而提前觸發(fā)下一次GC帮坚。

(2)可預(yù)測停頓妻往，這是G1的另一大優(yōu)勢，降低停頓時間是G1和CMS的共同關(guān)注點试和，
但G1除了追求低停頓外讯泣，還能建立可預(yù)測的停頓時間模型，能讓使用者明確指定在一個長度為N毫秒的時間片段內(nèi)阅悍，
消耗在垃圾收集上的時間不得超過N毫秒好渠，這幾乎已經(jīng)是實時Java（RTSJ）的垃圾收集器的特征了昨稼。

上面提到的垃圾收集器，收集的范圍都是整個新生代或者老年代拳锚，而G1不再是這樣假栓。使用G1收集器時，Java堆的內(nèi)存布局與其他收集器有很大差別霍掺，它將整個Java堆劃分為多個大小相等的獨立區(qū)域（Region）匾荆，雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔閡了抗楔，它們都是一部分（可以不連續(xù)）Region的集合棋凳。

G1的新生代收集跟ParNew類似，當新生代占用達到一定比例的時候连躏，開始出發(fā)收集剩岳。

和CMS類似，G1收集器收集老年代對象會有短暫停頓入热。

五拍棕、總結(jié)

1、JVM哪些分區(qū)需要垃圾回收勺良？

JVM5個分區(qū)中：
1.方法區(qū)（Method Area）
2.堆區(qū)（Heap）
3.虛擬機棧（VM Stack）
4.本地方法棧（Native Method Stack）
5.程序計數(shù)器（Program Counter Register）
方法區(qū)和堆區(qū)是線程共享的绰播，所以這兩個區(qū)需要回收

2.這兩個分區(qū)中，哪些對象需要回收（如何判斷垃圾）尚困？

兩種算法：
1.引用計數(shù)算法
2.根搜索算法

3.GC常見算法蠢箩？

1.復(fù)制算法
2.標記--清除算法
3.標記--壓縮算法
4.分代回收算法

4.垃圾回收器

1.串行收集
2.并行收集
3.CMS收集器
4.G1收集器

nginx狀態(tài)

Active connections: 3
server accepts handled requests
8 8 67
Reading: 0 Writing: 1 Waiting: 2

Active connections:表示nginx正在處理的活躍連接數(shù)
server：nginx啟動到現(xiàn)在共處理了8個請求
accepts：nginx啟動到現(xiàn)在共成功創(chuàng)建8次握手
handled requests：共處理了67個請求
Reading：讀取到客戶端的header信息數(shù)
Writing：nginx返回給客戶端的header信息數(shù)
Waiting：nginx已經(jīng)處理完正在等候下一次指令的駐留連接（在開啟keep-alive的情況下這個值為Active-（READING+Writing））

keepalived

C語言編寫。keepalived是以VRRP協(xié)議為實現(xiàn)基礎(chǔ)的事甜，VRRP是虛擬路由冗余協(xié)議

虛擬路由冗余協(xié)議谬泌，可以認為是實現(xiàn)路由器高可用的協(xié)議，即將多個提供相同功能的路由器組成一個路由器組逻谦，這個組里面有一個master和多個backup掌实，master上面有一個對外提供服務(wù)的vip（該路由器所在局域網(wǎng)內(nèi)其他機器的默認路由為該vip），master會發(fā)組播邦马，當backup收不到vrrp包時就認為master宕掉了贱鼻，這時就需要根據(jù)VRRP的優(yōu)先級來選舉一個backup當master。這樣的話就可以保證路由器的高可用了滋将。

keepalived有3個模塊：

• core模塊為keepalived的核心邻悬，負責主進程的啟動、維護以及全局配置文件的加載和解析
• check負責健康檢查随闽，包括常見的各種檢查方式
• vrrp模塊是來實現(xiàn)VRRP協(xié)議的

keepalived有三種監(jiān)聽模式layer3父丰、4、5橱脸，分別工作在TCP/IP础米、TCP及應(yīng)用層下
layer3工作時，會定期向服務(wù)器群集中發(fā)送一個ICMP的數(shù)據(jù)包(即ping)添诉，如果某臺服務(wù)器沒有響應(yīng)數(shù)據(jù)包請求時屁桑，keepalived則會視為此臺服務(wù)器不能提供服務(wù)，則在服務(wù)器群集里把它剔除栏赴，運用場景：來判斷某臺服務(wù)器非法關(guān)機
layer4方式工作：keepalived會向服務(wù)器群集里發(fā)送TCP的數(shù)據(jù)包蘑斧，主要監(jiān)聽TCP端口來判斷是否在正常狀態(tài)，如果發(fā)現(xiàn)該端口無法訪問及沒有啟動(如80)须眷，則剔除掉這臺服務(wù)器
layer5工作方式：layer5比layer3竖瘾、4要復(fù)雜，占用帶寬也要多一些花颗，根據(jù)用戶設(shè)定檢查程序是否正常捕传，如果與用戶設(shè)定不符。keepalived則剔除這臺機器

腦裂：由于HA的原因扩劝，服務(wù)器的數(shù)量通常大于1臺庸论。本來，這些節(jié)點的活動應(yīng)該為協(xié)調(diào)的棒呛，統(tǒng)一的聂示，但是，由于master與node的心跳線的斷開簇秒，使得雙方不能正常的通信鱼喉，這是會出現(xiàn)兩個問題：
1.雙方相互爭搶資源，導致雙方服務(wù)都無法正常使用
2.兩邊服務(wù)都起來了趋观，同時提供服務(wù)扛禽，同時讀寫存儲，導致數(shù)據(jù)不一致甚至損壞拆内。

腦裂的原因：

• HA服務(wù)器之間心跳線故障旋圆，導致無法正常通信；
• HA服務(wù)器上開啟了防火墻麸恍，阻擋了心跳線的信息傳輸灵巧；
• HA服務(wù)器上心跳網(wǎng)卡配置不正確，導致心跳信息發(fā)送失斈ɑΑ刻肄；
• 其他服務(wù)器配置不當?shù)脑颉１热缧奶绞讲煌谂罚奶鴱V播沖突敏弃，軟件BUG等；

PV/UV

• UV：指的是通過互聯(lián)網(wǎng)訪問噪馏、瀏覽頁面的人麦到。訪問網(wǎng)站的一臺電腦客戶端為一個訪客绿饵，00:00 - 24:00 相同的客戶只能計算一次
• IP：獨立IP指訪問過某站點的IP總數(shù)。因此瓶颠，可能同一個IP拟赊，但是UV數(shù)不為1
• PV：頁面的點擊數(shù)，用戶對同一頁面多次訪問粹淋，PV會累積
• VV： 指的是統(tǒng)計用戶1天內(nèi)訪問網(wǎng)站的次數(shù)吸祟。同一個人一天可以有多次訪問行為，訪問次數(shù)累計

mysql主從復(fù)制的同步延遲

mysql的主從復(fù)制都是單線程的操作桃移，主庫對所有DDL和 DML產(chǎn)生binlog屋匕，binlog是順序?qū)懀孕屎芨呓杞埽瑂lave的Slave_IO_Running線程到主庫取日志过吻，效率很比較高，下一步蔗衡， 問題來了疮装，slave的Slave_SQL_Running線程將主庫的DDL和DML操作在slave實施。DML和DDL的IO操作是隨即的粘都，不是順 序的廓推，成本高很多，還可能可slave上的其他查詢產(chǎn)生lock爭用翩隧，由于Slave_SQL_Running也是單線程的樊展，所以一個DDL卡主了，需要 執(zhí)行10分鐘堆生，那么所有之后的DDL會等待這個DDL執(zhí)行完才會繼續(xù)執(zhí)行专缠，這就導致了延時。有朋友會問：“主庫上那個相同的DDL也需要執(zhí)行10分淑仆，為什 么slave會延時涝婉？”，答案是master可以并發(fā)蔗怠，Slave_SQL_Running線程卻不可以墩弯。

主從同步延遲的產(chǎn)生：
當主庫的TPS并發(fā)較高時，產(chǎn)生的DDL數(shù)量超過slave一個sql線程所能承受的范圍寞射，那么延時就產(chǎn)生了渔工，當然還有就是可能與slave的大型query語句產(chǎn)生了鎖等待。

延遲同步的解決發(fā)方案：
最簡單的減少slave同步延時的方案就是在架構(gòu)上做優(yōu)化桥温，盡量讓主庫的DDL快速執(zhí)行引矩。還有就是主庫是寫，對數(shù)據(jù)安全性較高，比如 sync_binlog=1旺韭，innodb_flush_log_at_trx_commit = 1 之類的設(shè)置氛谜，而slave則不需要這么高的數(shù)據(jù)安全，完全可以講sync_binlog設(shè)置為0或者關(guān)閉binlog区端，innodb_flushlog也 可以設(shè)置為0來提高sql的執(zhí)行效率混蔼。另外就是使用比主庫更好的硬件設(shè)備作為slave。

同步延遲的原因詳解

NFS（rsync）

NFS是Network File System的縮寫及網(wǎng)絡(luò)文件系統(tǒng)珊燎。
主要功能是通過局域網(wǎng)絡(luò)讓不同的主機系統(tǒng)之間可以共享文件或目錄

NFS的優(yōu)點：
1.NFS文件系統(tǒng)簡單易用、方便部署遵湖、數(shù)據(jù)可靠悔政、服務(wù)穩(wěn)定、滿足中小企業(yè)需求延旧。
2.NFS文件系統(tǒng)內(nèi)存放的數(shù)據(jù)都在文件系統(tǒng)之上谋国，所有數(shù)據(jù)都是能看得見。

NFS的缺點：
1.存在單點故障, 如果構(gòu)建高可用維護麻煩迁沫。(web-》nfs()-》backup)
2.NFS數(shù)據(jù)明文, 并不對數(shù)據(jù)做任何校驗芦瘾。
3.客戶端掛載無需賬戶密碼, 安全性一般(內(nèi)網(wǎng)使用)

rsync：
rsync命令是一個遠程數(shù)據(jù)同步工具，集畅。rsync使用所謂的“rsync算法”來使本地和遠程兩個主機之間的文件達到同步近弟，這個算法只傳送兩個文件的不同部分，而不是每次都整份傳送挺智，因此速度相當快

rsync同步：
rsync main.c machineB:/home/userB
若目的沒有該文件祷愉，那么新創(chuàng)建的文件權(quán)限為源文件的權(quán)限。若果有目標文件赦颇，那目標文件的權(quán)限不會發(fā)生改變

消峰

在短期內(nèi)有大量用戶進行訪問時二鳄，回增加數(shù)據(jù)庫的壓力，當?shù)竭_閾值時會出現(xiàn)問題媒怯。
服務(wù)器的處理資源是恒定的订讼，用或者不用它的處理能力都是一樣的，所以出現(xiàn)峰值的話扇苞，很容易導致忙到處理不過來欺殿，閑的時候卻又沒有什么要處理。但是由于要保證服務(wù)質(zhì)量鳖敷，我們的很多處理資源只能按照忙的時候來預(yù)估祈餐，而這會導致資源的一個浪費。

image.png

因此哄陶，需要對用戶的訪問進行過濾帆阳，以緩解這種問題。
方案一：使用消息隊列，當然消息隊列的也會出現(xiàn)閾值

image.png

方案二：分層過濾蜒谤。
假如請求分別經(jīng)過 CDN山宾、前臺讀系統(tǒng)（如商品詳情系統(tǒng)）、后臺系統(tǒng)（如交易系統(tǒng)）和數(shù)據(jù)庫這幾層鳍徽，那么：

• 大部分數(shù)據(jù)和流量在用戶瀏覽器或者 CDN 上獲取资锰，這一層可以攔截大部分數(shù)據(jù)的讀取阶祭；
• 經(jīng)過第二層（即前臺系統(tǒng)）時數(shù)據(jù)（包括強一致性的數(shù)據(jù)）盡量得走 Cache绷杜，過濾一些無效的請求；
• 再到第三層后臺系統(tǒng)濒募，主要做數(shù)據(jù)的二次檢驗鞭盟，對系統(tǒng)做好保護和限流，這樣數(shù)據(jù)量和請求就進一步減少瑰剃；

• 最后在數(shù)據(jù)層完成數(shù)據(jù)的強一致性校驗齿诉。

  
  
  image.png
  
  

  分層過濾的核心思想是：在不同的層次盡可能地過濾掉無效請求，讓“漏斗”最末端的才是有效請求晌姚。而要達到這種效果粤剧，我們就必須對數(shù)據(jù)做分層的校驗。

分層校驗的基本原則是：

1. 將動態(tài)請求的讀數(shù)據(jù)緩存在 Web 端挥唠，過濾掉無效的數(shù)據(jù)讀抵恋；
   2.對讀數(shù)據(jù)不做強一致性校驗，減少因為一致性校驗產(chǎn)生瓶頸的問題宝磨；
   3.對寫數(shù)據(jù)進行基于時間的合理分片馋记，過濾掉過期的失效請求；
   4.對寫請求做限流保護懊烤，將超出系統(tǒng)承載能力的請求過濾掉梯醒；
   5.對寫數(shù)據(jù)進行強一致性校驗，只保留最后有效的數(shù)據(jù)腌紧。

微服務(wù)

spring cloud

Spring Cloud茸习，它我們提供了一整套的微服務(wù)解決方案，大大的降低了微服務(wù)開發(fā)的門檻壁肋，同時也減少了開發(fā)成本号胚。

image.png

組件：

• 服務(wù)注冊與發(fā)現(xiàn)：是 Spring Cloud 中最核心的組件之一，整個系統(tǒng)中所有的服務(wù)都可以注冊到注冊中心浸遗，然后由注冊中心進行統(tǒng)一調(diào)度猫胁，方便后續(xù)的水平擴展以及故障轉(zhuǎn)移等。
• 配置中心：隨著服務(wù)的不斷增多跛锌，同時每個服務(wù)也會有多個環(huán)境（開發(fā)環(huán)境弃秆、測試環(huán)境、生產(chǎn)環(huán)境等），每個環(huán)境的配置文件又會有所不同菠赚，但是其中又有許多配置是可以共用的脑豹，如果每個服務(wù)自己去管理這些配置，會給維護帶來很大的麻煩衡查，這時候瘩欺，我們就需要引入配置中心去統(tǒng)一管理這些配置。Spring Cloud 還提供了 Spring Cloud Bus 組件拌牲，來進行服務(wù)間的通訊俱饿。用來通知服務(wù)配置文件的更新
• 服務(wù)消費者：既然是微服務(wù)架構(gòu)，那服務(wù)間的調(diào)用肯定是無法避免的塌忽，Spring Cloud 提供了 Ribbon 組件拍埠，它可以用來進行服務(wù)間的調(diào)用，同時砚婆，它還支持客戶端的負載均衡。但是突勇，直接使用 Ribbon 不是很方便装盯，所以，Spring Cloud 基于 Netflix Feign 甲馋，并整合了 Ribbon埂奈，這就有了 Spring Cloud OpenFeign，它實現(xiàn)了聲明式的服務(wù)調(diào)用客戶端定躏，
• 服務(wù)器容錯：在微服務(wù)架構(gòu)中账磺，通常會有多個服務(wù)之間相互調(diào)用的情況，一旦某些基礎(chǔ)服務(wù)出現(xiàn)故障痊远，則可能造成整個系統(tǒng)的不可用垮抗，稱之為服務(wù)雪崩，為了避免這種情況的發(fā)生碧聪，我們需要在服務(wù)出現(xiàn)故障時實現(xiàn)故障隔離和服務(wù)降級冒版。針對這種情況，Spring Cloud 使用了 Hystrix 來實現(xiàn)服務(wù)的容錯逞姿。
• 網(wǎng)關(guān)：網(wǎng)關(guān)為系統(tǒng)提供了路由辞嗡、鑒權(quán)、監(jiān)控滞造、負載均衡等功能续室。Spring Cloud 為此提供了兩個解決方案：Zuul 以及 Spring Cloud Gateway。

Eureka：Eureka 由 Netflix 開發(fā)谒养，是一種基于REST（Representational State Transfer）的服務(wù)挺狰，用于定位與發(fā)現(xiàn)服務(wù)，以實現(xiàn)中間層服務(wù)的負載均衡和故障轉(zhuǎn)移。
Eureka的工作原理：

• 由服務(wù)提供方將服務(wù)注冊到 Eureka Server
• 服務(wù)消費者通過 Eureka Server 獲取服務(wù)提供方的真實地址
• 服務(wù)消費者通過真實的地址調(diào)用服務(wù)

image.png

在服務(wù)提供者注冊到 Eureka Server 的過程中她渴，它會將自身的元數(shù)據(jù)（包括主機达址、端口等以及其他自定義的信息）都注冊到 Eureka Server 中，服務(wù)消費者通過 Eureka Server 即可獲取這些信息趁耗，所以對于 Eureka 來說沉唠，它不會限定服務(wù)消費者與服務(wù)提供者之間的具體該如何通訊，這些都是由服務(wù)消費者與服務(wù)提供者決定苛败，你可以自行選擇任意你喜歡的方式满葛，如 HTTP、RPC罢屈、Thrift 等

Eureka的自我保護機制：
默認情況下嘀韧，Eureka Server 在一定時間內(nèi)如果沒有接收到某個實例的心跳，就會移除該實例缠捌。但是可能會有這種情況：當網(wǎng)絡(luò)分區(qū)故障時锄贷，服務(wù)與 Eureka Server 無法正常通信，但是服務(wù)本身是正常的曼月，此時就不該移除該服務(wù)谊却，所以 Eureka 就引入了自我保護機制。當 Eureka 進入此機制時哑芹，它將不再移除任何服務(wù)炎辨，哪怕服務(wù)不可用。

微服務(wù)詳解
·