微服務架構相關
大型網站架構演變過程
網站架構演變演變過程
傳統架構 → 分布式架構 → SOA架構 → 微服務架構
什麼是分布式架構
分布式架構就是将傳統結構按照子產品進行拆分，不同的人負責不同的子產品，不會産生代碼沖突問題，友善開發。
什麼是SOA架構
SOA架構就是将業務邏輯層提取出來，将相似的業務邏輯形成一個服務，提供外部通路接口，服務之間通路通過RPC調用實作。
什麼是微服務架構
微服務類似于SOA架構，但是比SOA架構粒度更細，更輕量。
微服務架構與SOA架構差別
SOA基于WebService和ESP實作，底層基于HTTP協定和使用XML方式傳輸，XML在網絡傳輸過程中會産生大量備援。微服務由SOA架構演變而來，繼承了SOA架構的優點，同時對SOA架構缺點進行改善，資料傳輸采用JSON格式，相比于XML更輕量和快捷，粒度更細，更加便于靈活開發。SOA資料庫會存在共享，微服務提倡每個服務連接配接獨立的資料庫。
微服務架構SpringCloud
什麼是SpringCloud
SpringCloud是微服務的一種解決方案，依賴SpringBoot實作。包含注冊中心(eureka)、用戶端負載均衡(Ribbon)、網關(zull)、分布式鎖、分布式會話等。
為什麼要使用SpringCloud
SpringCloud是一套非常完整的微服務解決方案，俗稱“微服務全家桶”，幾乎内置了微服務所使用的各種技術，可以不必內建第三方依賴。
SpringCloud服務注冊發現原理
每個SpringCloud伺服器啟動後向注冊中心注冊本伺服器資訊，如服務别名、伺服器IP、端口号等，其他服務進行請求時先根據服務别名從注冊中心擷取到目标伺服器IP和端口号，并将擷取到的資訊緩存到本地，然後通過本地使用HttpClient等技術進行遠端調用。
SpringCloud 支援那些注冊中心
Eureka、Consul、Zookeeper
現在Eureka閉源了，可以通過什麼注冊中心替代Eureka呢？
Consul或Zookeeper
談談你對微服務服務治理的思想
Eureka如何實作高可用
啟動多台Eureka伺服器，然後作為SpringCloud服務互相注冊，用戶端從Eureka叢集擷取資訊時，按照注冊的Eureka順序對第一個Eureka進行通路。
@LoadBalanced注解的作用
開啟用戶端負載均衡。
Nginx與Ribbon的差別
Nginx是反向代理同時可以實作負載均衡，nginx攔截用戶端請求采用負載均衡政策根據upstream配置進行轉發，相當于請求通過nginx伺服器進行轉發。Ribbon是用戶端負載均衡，從注冊中心讀取目标伺服器資訊，然後用戶端采用輪詢政策對服務直接通路，全程在用戶端操作。
Ribbon底層實作原理
Ribbon使用discoveryClient從注冊中心讀取目标服務資訊，對同一接口請求進行計數，使用%取餘算法擷取目标服務叢集索引，傳回擷取到的目标服務資訊。
SpringCloud有幾種調用接口方式
使用Feign和RestTemplate
DiscoveryClient的作用
可以從注冊中心中根據服務别名擷取注冊的伺服器資訊。
談談服務雪崩效應
雪崩效應是在大型網際網路項目中，當某個服務發生當機時，調用這個服務的其他服務也會發生當機，大型項目的微服務之間的調用是互通的，這樣就會将服務的不可用逐漸擴大到各個其他服務中，進而使整個項目的服務當機崩潰.發生雪崩效應的原因有以下幾點
1.單個服務的代碼存在bug. 2請求通路量激增導緻服務發生崩潰(如大型商城的槍紅包，秒殺功能). 3.伺服器的硬體故障也會導緻部分服務不可用.
在微服務中，如何保護服務?
一般使用使用Hystrix架構，實作服務隔離來避免出現服務的雪崩效應，進而達到保護服務的效果。當微服務中，高并發的資料庫通路量導緻服務線程阻塞，使單個服務當機，服務的不可用會蔓延到其他服務，引起整體服務災難性後果，使用服務降級能有效為不同的服務配置設定資源,一旦服務不可用則傳回友好提示，不占用其他服務資源，進而避免單個服務崩潰引發整體服務的不可用.
服務雪崩效應産生的原因
因為Tomcat預設情況下隻有一個線程池來維護用戶端發送的所有的請求，這時候某一接口在某一時刻被大量通路就會占據tomcat線程池中的所有線程，其他請求處于等待狀态，無法連接配接到服務接口。
談談Hystrix服務保護的原理
通過服務降級、服務熔斷、服務隔離為高并發服務提供保護。
談談服務降級、熔斷、服務隔離
服務降級：當用戶端請求伺服器端的時候，防止用戶端一直等待，不會處理業務邏輯代碼，直接傳回一個友好的提示給用戶端。
服務熔斷是在服務降級的基礎上更直接的一種保護方式，當在一個統計時間範圍内的請求失敗數量達到設定值（requestVolumeThreshold）或目前的請求錯誤率達到設定的錯誤率門檻值（errorThresholdPercentage）時開啟斷路，之後的請求直接走fallback方法，在設定時間（sleepWindowInMilliseconds）後嘗試恢複。
服務隔離就是Hystrix為隔離的服務開啟一個獨立的線程池，這樣在高并發的情況下不會影響其他服務。服務隔離有線程池和信号量兩種實作方式，一般使用線程池方式。
服務降級底層是如何實作的？
Hystrix實作服務降級的功能是通過重寫HystrixCommand中的getFallback()方法，當Hystrix的run方法或construct執行發生錯誤時轉而執行getFallback()方法。
分布式配置中心有那些架構？
Apollo(阿波羅)、zookeeper、springcloud config。
分布式配置中心的作用？
動态變更項目配置資訊而不必重新部署項目。
SpringCloud Config 可以實作實時重新整理嗎？
springcloud config實時重新整理采用SpringCloud Bus消息總線。
什麼是網關?
網關相當于一個網絡服務架構的入口，所有網絡請求必須通過網關轉發到具體的服務。
網關的作用是什麼
統一管理微服務請求，權限控制、負載均衡、路由轉發、監控、安全控制黑名單和白名單等
網關與過濾器有什麼差別
網關是對所有服務的請求進行分析過濾，過濾器是對單個服務而言。
常用網關架構有那些？
Nginx、Zuul、Gateway
Zuul與Nginx有什麼差別？
Zuul是java語言實作的，主要為java服務提供網關服務，尤其在微服務架構中可以更加靈活的對網關進行操作。Nginx是使用C語言實作，性能高于Zuul，但是實作自定義操作需要熟悉lua語言，對程式員要求較高，可以使用Nginx做Zuul叢集。
既然Nginx可以實作網關？為什麼還需要使用Zuul架構
Zuul是SpringCloud內建的網關，使用Java語言編寫，可以對SpringCloud架構提供更靈活的服務。
如何設計一套API接口
考慮到API接口的分類可以将API接口分為開放API接口和内網API接口，内網API接口用于區域網路，為内部伺服器提供服務。開放API接口用于對外部合作機關提供接口調用，需要遵循Oauth2.0權限認證協定。同時還需要考慮安全性、幂等性等問題。
ZuulFilter常用有那些方法
Run()：過濾器的具體業務邏輯
shouldFilter()：判斷過濾器是否有效
filterOrder()：過濾器執行順序
filterType()：過濾器攔截位置
如何實作動态Zuul網關路由轉發
通過path配置攔截請求，通過ServiceId到配置中心擷取轉發的服務清單，Zuul内部使用Ribbon實作本地負載均衡和轉發。
Zuul網關如何搭建叢集
使用Nginx的upstream設定Zuul服務叢集，通過location攔截請求并轉發到upstream，預設使用輪詢機制對Zuul叢集發送請求。
SpringBoot快速開發架構
什麼是SpringBoot
SpringBoot是快速開發的Spring架構，能夠快速整合主流架構，簡化xml配置，采用全注解化，内置Http伺服器（如tomcat、jetty等），通過java部署運作。
為什麼要用SpringBoot
快速開發，快速整合，配置簡化、内嵌服務容器
SpringBoot啟動方式
主類@SpringBootApplication注解或添加@ComponentScan和@EnableAutoConfiguration注解，使用@SpringBootApplication時注意自動掃描目前包
SpringBoot與SpringMVC 差別
SpringMVC是SpringBoot的Web開發架構
SpringBoot與SpringCloud 差別
SpringBoot是快速開發的Spring架構，SpringCloud是完整的微服務架構， SpringCloud依賴于SpringBoot。
SpringBoot中用那些注解
@EnableAutoConfiguration作用
自動掃描并添加jar包依賴
@SpringBootApplication原理
是一個組合注解，相當于@EnableAutoConfiguration和@ComponentScan
SpringBoot熱部署使用什麼？
devtools
熱部署原理是什麼？
熱部署的實作原理主要依賴java的類加載機制，在實作方式可以概括為在容器啟動的時候起一條背景線程，定時的檢測類檔案的時間戳變化，如果類的時間戳變掉了，則重新加載整個應用的class檔案，同時重新開機服務，重新部署。
熱部署原理與熱加載差別是什麼
熱加載是在運作時重新加載class檔案，不會重新開機服務。
你們項目中異常是如何處理
在web項目中，使用全局捕獲異常傳回統一錯誤資訊。
SpringBoot如何實作異步執行
在啟動類添加@EnableAsync表示開啟對異步任務的支援，在異步服務上添加@Async
SpringBoot多資料源拆分的思路
先在properties配置檔案中配置兩個資料源，建立分包mapper，使用@ConfigurationProperties讀取properties中的配置，使用@MapperScan注冊到對應的mapper包中
SpringBoot多資料源事務如何管理
第一種方式是在service層的@TransactionManager中使用transactionManager指定DataSourceConfig中配置的事務
第二種是使用jta-atomikos實作分布式事務管理
SpringBoot如何實作打包
進入項目目錄在控制台輸入mvn clean package，clean是清空已存在的項目包，package進行打包
SpringBoot性能如何優化
如果項目比較大，類比較多，不使用@SpringBootApplication，采用@Compoment指定掃包範圍
在項目啟動時設定JVM初始記憶體和最大記憶體相同
将springboot内置伺服器由tomcat設定為undertow
SpringBoot執行流程
使用SpringApplication.run()啟動，在該方法所在類添加@SpringBootApplication注解，該注解由@EnableAutoConfiguration和@ComponentScan等注解組成，@EnableAutoConfiguration自動加載SpringBoot配置和依賴包，預設使用@ComponentScan掃描目前包及子包中的所有類，将有spring注解的類交給spring容器管理
SpringBoot底層實作原理
使用maven父子包依賴關系加載相關jar包，使用java操作Spring的初始化過程生成class檔案，然後用java建立tomcat伺服器加載這些class檔案
SpringBoot裝配Bean的原理
通過@EnableAutoConfiguration自動擷取配置類資訊，使用反射執行個體化為spring類，然後加載到spring容器
分布式協調工具
什麼是ZooKeeper
ZooKeeper是Java語言編寫的開源架構，用以協調分布式的一個工具。
ZooKeeper存儲結構與特性
類似于樹形結構，同一層節點名稱不能重複。節點類型分為臨時節點與持久節點
Zookeeper以節點方式進行存儲，類似于xml樹狀結構；
a、 節點又分為節點名稱（全路徑不能重複）和 節點值
節點類型有持久節點（持久化在硬碟上）和臨時節點（會話與臨時節點同死同生）
b、節點功能：每個節點都有通知功能，當這個節點增删改的時候都會有事件通知
Zookeeper主要有一下特性
a、一緻性：資料按照順序分批入庫；
b、原子性：事務要麼成功要麼失敗，不會局部化；
c、單一視圖：用戶端連接配接叢集中任何一個zk節點，資料都是一緻的；
d、可靠性：每次對zk的操作狀态都會儲存在服務端；
e、實時性：用戶端可以讀取到zk伺服器的 新資料；
ZooKeeper中臨時節點與持久節點差別
持久節點是持久化在硬碟上，會話斷開後節點也能查到；
臨時節點與會話保持連接配接，會話在節點在，會話斷開，節點也會删除；
ZooKeeper應用場景
A、 服務注冊與發現的中心
B、利用臨時節點特性解決分布式鎖
C、分布式配置中心
D、基于哨兵機制實作選舉政策
E、實作本地負載均衡
F、基于節點事件通知特性可做消息中間件
G、分布式事務
什麼場景下會導緻ZooKeeper發生延遲通知
watch事件延遲：節點被修改後，會有事件通知發往觀察者，直到接收到watch事件，觀察者才會知道節點被修改了；當管擦着接到watch事件的那一刻，該節點又被其他修改者修改了，而 近的watch事件還沒有通知到觀察者，就會造成延遲通知。
分布式鎖有那些實作方案
a、 基于setNx實作分布式鎖（麻煩，需要考慮死鎖及釋放問題）
b、redission實作分布式鎖
c、zookeeper實作分布式鎖（基于臨時節點，實作簡單，效率高，失效時間容易控制）
ZooKeeper實作分布式鎖的原理
多個jvm在同一個zookeeper上建立同一個節點（臨時節點），哪個jvm能建立成功，就表示它拿到了鎖，剩下的jvm保持對這個節點的監聽，一旦發現這個節點被删除了，那麼剩下的jvm就重新再建立這個節點，誰能建立成功誰能拿到鎖，依次循環下去。
ZooKeeper實作分布式鎖與Redis實作分布式鎖差別
Zookeeper通過建立臨時節點和利用監聽事件實作分布式鎖，Redis使用setnx指令建立相同的key，因為Redis的key保證唯一，先建立的先擷取鎖。
不斷的去嘗試，去擷取鎖，比較耗性能 Zookeeper實作分布式鎖，即使擷取不到鎖，建立對鎖的監聽即可，不需要不斷去嘗試擷取 鎖，性能開銷小
Redis實作分布式鎖，如果用戶端擷取到鎖的時候遇到bug或挂了，還需要等到逾時時間過了以後才能重新擷取鎖
Zookeeper實作分布式鎖，建立的是臨時節點，用戶端挂了，節點自然删除，也就達到了自動釋放鎖的效果
使用Zookeeper實作服務Master選舉原理
多個伺服器在啟動時候，會在Zookeeper上建立相同的臨時節點，誰如果能夠建立成功，誰就為主。如果主伺服器當機，其他備用節點擷取監聽資訊，重新建立節點，選出主伺服器。
ZooKeeper叢集選舉原理
每台Zookeeper伺服器啟動時會發起投票，每次投票後，伺服器統計投票資訊，如果有機器擷取半數以上的投票數則leader産生。
微服務常用解決方案
談談網站跨域解決方案
a、使用jsonp 缺點隻能發送get請求
b、使用httpclient進行轉發，效率低
c、設定響應頭允許跨域
d、使用Nginx搭建api網關
e、使用Zuul微服務搭建api接口網關
分布式Session一緻性問題
a、使用Nginx反向代理，即IP綁定，同一個ip隻能在同一個機器上通路
b、使用資料庫，但性能不高
c、tomcat内置了對session同步的支援，但可能會産生延遲
d、使用Spring-Session架構，相當于把session放到redis中
e、使用token令牌代替session
分布式鎖解決方案
分布式事務解決方案
分布式任務排程平台解決方案
分布式事務解決方案
分布式日志收集解決方案
分布式全局id生成方案
分布式服務追蹤與調用鍊系統解
分布式消息系統與中間件
消息中間件産生的背景
傳統的Web項目采用http協定基于請求和響應傳輸資訊，請求發出後必須等待伺服器端響應，如果伺服器端不會及時響應用戶端會一直等待。
Http協定同步接口調用失敗了怎麼做？
采用消息補償機制重新發送請求。
消息隊列異步通訊與同步通訊差別
同步通訊是用戶端直接将請求發往伺服器，等待伺服器處理完請求并傳回響應資訊後才會繼續向下執行。消息隊列獨立于用戶端和伺服器端，單獨架設消息隊列伺服器，對于不必立即擷取響應和處理過程複雜的請求，用戶端可以将請求發往消息隊列然後立即傳回，指定的消費者處理請求，這樣用戶端不必持續等待。
JMS消息通訊模型有那些
消息隊列：點對點，釋出訂閱
消息中間應用場景
發送郵件或短信的服務、秒殺、運作過程複雜耗時的服務。
釋出訂閱與點對點通訊的差別
釋出訂閱是生産者釋出一個主題，所有訂閱該主題的消費者都會參與消費，消息會被重複消費。點對點通訊是一個消息隻能有一個消費者消費，需要保證資料的幂等性。
如何保證JMS可靠消息
ActiveMQ采用消息簽收機制保證資料的可靠性，消息簽收有三種方式：自動簽收、手動簽收、事務，預設自動簽收。如果是帶事務的消息，事務執行完畢後自動簽收，事務復原則重新發送。
ActiveMQ服務端當機了，消息會丢失嗎？
生産者可以通過setDeliveryMode方法設定消息模式，當設定未非持久化時伺服器當機後消息将銷毀，重新開機伺服器後無法繼續消費。當設定為持久化時伺服器當機後消息将儲存到伺服器中，重新開機後消費者還可以繼續消費未處理完畢的消息。
RabbitMQ與其他MQ有什麼不同？
RabbitMQ是用erlang語言實作，安裝RabbitMQ之前需要先安裝erlang環境。RabbitMQ隻支援AMQP協定，用于對穩定性要求比較高的企業。
RabbitMQvirtualHost的作用
VirtualHost相當于是虛拟的RabbitMQ伺服器，每個VirtualHost都是獨立的，起到隔離交換機、隊列的作用，不同的項目組可以連接配接到不同的VirtualHost不會互相影響。
談談RabbitMQ五種列隊形式
點對點模式：生産者生成的消息由一個消費者消費；
工作模式：在消費者叢集的情況下，可以根據消費者伺服器的性能配置設定消息，即性能好的伺服器多消費，性能次的少消費。
釋出訂閱模式：在生産者和隊列之間插入一個交換機，由交換機轉發到與該交換機綁定的隊列；
路由模式：路由模式是基于釋出訂閱模式，隻是在生産者向交換機生産消息時闆頂一個routingkey，交換機向綁定同一個routingkey的隊列轉發消息；
通配符模式：是對路由模式的補充，使用通配符進行routingkey比對，通配符有#和*，#代表比對多個，*代表比對一個。
RabbitMQ四中交換機類型
Fanout：以這種方式連接配接到交換機的隊列都可以獲得交換機的轉發；
Direct：生産者綁定direct類型的交換機，在向交換機發送消息時綁定routingkey，交換機會将這條消息發送到相同routingkey的隊列。
Topic：和Direct相似，可以在routingKey中使用通配符，#代表多個比對，*代表單個比對，routingkey使用”.”作為分隔符。
Headers：類似Direct，使用多個消息代替路由鍵建立路由規則，通過消息頭比對來轉發消息。
RabbitMQQMAP協定原理
在RabbitMQ中，生産者将消息發送到交換機，交換機将消息根據路由政策将消息發送到綁定的消息隊列，消費者通過消息隊列擷取并消費消息。
高并發解決方案
高性能Nginx+Lua
什麼是DNS解析域名
DNS域名解析就是講域名轉化為不需要顯示端口（二級域名的端口一般為80）的IP位址，域名解析的一般先去本地環境的host檔案讀取配置，解析成對應的IP位址，根據IP位址通路對應的伺服器。若host檔案未配置，則會去網絡營運商擷取對應的IP位址和域名.
你用過那些外網映射工具
花生殼,natapp,ngrok。
什麼是Nginx
Nginx是一個進階的輕量級的web伺服器,由俄羅斯科學家開發的，具有如下優點:
1.占用記憶體少，并發量強，支援多種并發連接配接，效率高.
2.能夠作為負載均衡伺服器和(内部直接支援 Rails 和 PHP)代理伺服器。Nginx用C編寫開銷和CPU占有小.
3.安裝啟動簡單，配置簡潔，bug少，一般幾個月不需要重新啟動且不會當機，穩定性和安全性好. Nginx的作用
反向代理、負載均衡、配置主備tomcat、動靜分離
Nginx 應用場景
做HTTP伺服器、反向代理伺服器、靜态資源伺服器
什麼是反向代理
代替真實伺服器接收網絡請求，然後将請求轉發到真實伺服器
反向代理的作用
隐藏真實伺服器，使真實伺服器隻能通過内網通路，保護了真實伺服器不被攻擊。配置負載均衡，減輕單台真實伺服器的壓力。配置主備伺服器，保持服務穩定運作。
Nginx如何配置反向代理
首先到DNS伺服器做域名解析，如果是區域網路在hosts檔案中配置IP和域名對應關系。編輯nginx的nginx.conf檔案，配置server_name為指向nginx伺服器的域名，location攔截請求，如果是通路nginx本地資源則配置root，如果是反向代理到真實伺服器則配置proxy_pass為伺服器位址
說說常用Nginx的相關配置
upstream 負載均衡配置
server [IP] [weight] [backup] 配置tomcat叢集
proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout 連接配接時間、真實伺服器響應時間、傳回結果時間
location 比對使用者請求的url
root 配置本地資源路徑
proxy_pass 配置真實伺服器位址
請畫圖展示反向代理流程
LVS與Nginx差別
LVS是四層反向代理，基于TCP和UDP協定，可用于管理Nginx叢集，抗負載能力強。Nginx是七層反向代理，基于HTTP協定，用于管理真實伺服器叢集。
location的作用
比對使用者請求url，根據不同請求轉發到不同的伺服器。
Nginx中如何配置負載均衡
在upstream中配置多個server，在location的proxy_pass配置為http://+upstream名稱
四層負載均衡與七層負載均衡差別
四層負載均衡基于TCP和UDP協定，通過IP+端口号接受請求并轉發到伺服器。七層負載均衡基于HTTP協定，通過url或主機名接收請求并轉發到伺服器。
四層負載均衡有那些實作方案
LVS、F5
負載均衡有那些算法
輪詢算法:按照時間順序配置設定到不同的伺服器，當其中一台伺服器當機則被自動剔除，切換到正常的伺服器。
權重算法:按照配置設定給伺服器的權重比例來分發到不同伺服器，權重比例越高，則通路幾率越大。
IP綁定(ip_hash):根據通路的IP的哈希結果來判定，使同一個IP通路一台固定的後端伺服器，同時解決動态頁面的session問題. 伺服器叢集後，會産生了那些問題
分布式鎖
分布式全局ID
分布式Session一緻性問題
分布式事務
分布式任務排程
分布式日志收集
分布式配置中心
什麼是動态負載均衡
一般情況下，使用nginx搭建伺服器叢集，每次修改nginx.conf配置檔案都需要重新開機nginx伺服器。動态負載均衡就是修改nginx.conf配置檔案後不必重新開機nginx而使配置生效。
Nginx如何實作動态負載均衡
搭建Nginx+Consul+Upsycn環境。Nginx實作服務的反向代理和負載均衡。Consul是一個開源的注冊中心和服務發現的架構，通過HTTP API來發現服務，注冊服務。同時支援故障發現，K/V存儲，多資料中心，Raft算法等多中高可用特性。Consul在Nginx動态負載均衡作用是
通過Http api注冊和發現服務.Upsycn是新浪微網誌的開源架構，在Nginx動态負載均衡的作用是Consul的後端的server清單，即擷取Nginx的上遊伺服器(Upstream server）資訊,并動态更新Nginx的路由資訊.
什麼是Http協定
超文本傳輸協定
Http協定組成部分
Http協定是基于TCP協定封裝成超文本傳輸協定，包括請求(request）和響應(response),http協定請求（request）分為請求參數（request params）和方法類型(request method）、請求頭（request hearder）、請求體(request body) ，
響應(response)分為 響應狀态(response state）、響應頭（response header）、響應體(response body）等.
TCP與UDP差別
udp:
a、是面向無連接配接, 将資料及源的封裝成資料包中,不需要建立連接配接
b、每個資料報的大小在限制64k内
c、因無連接配接,是不可靠協定
d、不需要建立連接配接,速度快 tcp：
a、建議連接配接，形成傳輸資料的通道.
b、在連接配接中進行大資料量傳輸，以位元組流方式
c 通過三次握手完成連接配接,是可靠協定
d 必須建立連接配接m效率會稍低 談談七層網絡模型
應用層：用戶端的各種應用、app；
表示層：進行資料的格式區分，如圖檔、編碼；
會話層：本地主機與遠端主機的會話管理；
傳輸層：定義傳輸資料的協定端口号，TCP和UDP是這一層的協定；
網絡層：進行邏輯位址尋址；
資料鍊路層：建立邏輯連接配接，進行硬體位址尋址；
實體層：建立實體連接配接；
Nginx如何實作TCP四層負載均衡
在nginx.conf檔案中配置tcp子產品，在upstream塊中定義socket伺服器負載均衡，其餘與nginx配置七層負載均衡相同。
tcp {
定義多個上遊伺服器
upstream itmayeidu{
### 定義TCP子產品上遊伺服器
server 192.168.5.165:80001; server 192.168.5.165:80002;
}
server {
listen 9999;
server_name 192.168.212.137; 反向代理upstream
proxy_pass itmayeidu;
} }
lvs 與Nginx 差別
lvs工作在網絡第四層，nginx工作在網絡第七層；lvs比nginx抗負載能力強；lvs對網絡依賴性強，nginx對網絡依賴性弱；lvs幾乎可以對所有應用做負載均衡，比如資料庫。
lvs與keepalived差別
Lvs可以實作負載均衡，但是無法實作健康檢查。Keepalived可以進行健康檢查實作高可用。
keepalived 作用
keepalive 軟體可以進行健康檢查，而且能同時實作 LVS 的高可用性，解決 LVS 單點故障的問題
如何實作雙機主從熱備
Nginx+Tomcat：在upstream中配置多台伺服器，從伺服器後加backup
Keepalived+Nginx：在多台nginx伺服器上安裝keepalived，将主伺服器的state設定為MASTER，從伺服器設定為BACKUP，主伺服器的優先級要高于從伺服器
lvs+Keepalived+Nginx架構流程圖
項目釋出如何不影響到正常使用者通路，實作724小時通路
可以兩台機子互為熱備，平時各自負責各自的服務。在做上線更新的時候，關閉一台伺服器的tomcat後，nginx自動把流量切換到另外一台服務的後備機子上，進而實作無痛更新，保持服務的持續性，提高服務的可靠性，進而保證伺服器724小時運作。
項目如何發生故障當機了，如何處理。
使用lvs+keepalived+Nginx做主從熱備，lvs管理nginx叢集，nginx管理伺服器叢集，在伺服器當機的情況下keepalived啟動健康檢測，多次重新開機無果可以短信通知運維人員及時維護。
動态網站與靜态網站差別
在浏覽器中打開一個網站，點選滑鼠右鍵檢視源碼，多次請求後如果源碼不産生變化就是靜态網站，變化就是動态網站。
動态頁面靜态化的作用
便于搜尋引擎抓取和排名
什麼是動靜分離架構模式
靜态頁面與動态頁面分開不同系統通路的架構設計方法，靜态頁面與動态頁面以不同域名區分。
如何搭建動靜分離
以nginx伺服器作為靜态資源伺服器，靜态資源和動态資源通路分開配置，靜态資源在location中使用本地檔案路徑配置方式，動态資源使用proxy_pass配置到背景伺服器。
如：
###靜态資源通路
server {
listen 80;
server_name static.itmayiedu.com;
location /static/imgs {
root F:/;
index index.html index.htm;
}
} ###動态資源通路
server {
listen 80;
server_name www.itmayiedu.com;
location / {
proxy_pass http://127.0.0.1:8080;
index index.html index.htm;
}
} 動靜分離與前後分離差別
動靜分離是将靜态資源和動态資源存放在不同伺服器中，前後分離是将前端和背景分離，前端通過api調用背景接口
如何控制浏覽器靜态資源緩存
靜态資源存在緩存的原因是項目上線時，浏覽器緩存中的靜态資源導緻與伺服器将淘汰資源的代碼發生沖突(或者是頁面通路頻繁通路同一資源，導緻一些浏覽器如IE(本人開發親身經曆過)傳回預設的響應結果，與實際響應結果不符合)，
一般的伺服器是強制F5進行重新整理或者是清除緩存，最有效的解決方法就是在請求資源後面加上變量(如時間戳,随機數)
Http狀态碼304的作用
表示浏覽器存在靜态資源緩存就不從伺服器擷取靜态資源
高并發服務限流特級
高并發服務限流特技有哪些算法?
傳統電腦算法，滑動視窗計數器算法,令牌桶算法和漏桶算法。
傳統計數器限流算法有什麼弊端?
傳統計數器限流方式不支援高并發，存線上程安全問題.若大量通路請求集中在計數器最後時刻，計數器極易發生臨界問題，通路的請求無法完成.
什麼是滑動視窗計數器?
滑動視窗計數器是一種服務限流的算法,相對于計數器方法的實作，滑動視窗實作會更加平滑，并自動消除毛刺。其原理是當有通路進來時，會判斷若幹個機關來的請求是否超過
設定的閥值，并對目前時間片的請求數+1.
令牌桶算法的原理?
向一個存放固定容量令牌的同，以固定速率往桶裡添加令牌，當桶已經裝滿時，新增的令牌會被丢棄或者拒絕,當一個固定數目的資料包到達時，會在
桶中删除同等數量的令牌，資料包會發到網絡上，當這個固定數目超過桶中的令牌數，不會删除桶中的令牌數目，則該資料包會被限流(丢棄或者存入緩沖區等待)
漏桶算法的原理?
向一個存放固定容量的桶，以任意速率滴入水滴(請求)，以固定速率滴出水滴，當滴入水滴量超過桶中設定固定容量，則會發生溢出，溢出的水滴的請求是無法通路的，直接走
服務限流降級，桶中的容量不發生任何變化。
令牌桶與漏桶算法的差別?
令牌桶和漏桶算法的差別是令牌桶會根據請求的令牌數與桶中的令牌數做對比，倘若桶中令牌數小于請求令牌數則多餘的令牌數的請求被拒絕。漏桶算法則是向桶中添加請求，當
請求數大于桶中容量發生溢出，溢出的請求直接被拒絕通路。主要差別是漏桶算法是強行限制資料的傳輸速率，而令牌桶在能夠限制資料的平均傳輸速率外，還允許某種程度的突發傳輸，使用于搶紅包等高并發的場景。
Web前端優化方案
Web前端有哪些優化方案
1.網站架構實行動靜分離，動态資源和和靜态資源部署到不同的伺服器上面，使用nginx通路本地靜态資源，通過nginx代理轉發到tomcate通路動态資源
2.在通路靜态資源時在Url字尾加上時間戳，防止通路資源的與浏覽器本地緩存資源存在沖突.
3.頁面減少HTTP請求，合并靜态資源(如js或者css）并進行壓縮。
4.使用CDN内容分發，緩存靜态資源，讓使用者通路最近的伺服器，減少寬帶之間的傳輸.
什麼是CDN内容分發?
CDN内容轉發是指在使用者和伺服器之間加上一個緩存機制，一組分布在不同的靜态資源伺服器，儲存靜态資源，動态擷取使用者IP，并讓使用者通路最近的靜态資源伺服器,防止出現網絡延遲阻塞，
提高通路速度。CND伺服器部署在網絡營運商的機房，使用者請求首先會通路CND伺服器，如果CND伺服器中沒有緩存會自動把建立緩存，當使用者再次通路時，直接擷取緩存資源，并傳回給前端，提高靜态
資源的通路速度。
CDN内容加速原理?
1)使用者向浏覽器提供要通路的域名.
2)浏覽器從本地host檔案中解析域名,如何host檔案沒有做任何配置，則浏覽器調用域名解析庫對域名進行解析,析函數庫一般得到的是該域名對應的CNAME記錄,從中擷取真正的IP位址,此過程中,根據地理位置資訊解析對應的IP位址，使得使用者能就近通路靜态資源伺服器。
3)此次解析的CDN伺服器的IP位址，浏覽器根據這個位址，向緩存伺服器送出請求。
4)緩存伺服器根究浏覽器通路的域名，通過緩存内部獲得此域名的真實IP位址，再有緩存伺服器送出該IP位址的通路請求。
5)緩存伺服器從伺服器的ip位址擷取内容備用,并将資料傳回給使用者，完成服務過程.
6)用戶端将伺服器傳回的資料展示給前端
網際網路高并發解決方案
首先在談到高并發解決方案的時候，很多學員可能都會想到伺服器應該做叢集、負載均衡。
那麼伺服器叢集，一定能解決高并發嗎？這其實不一定。
首先要厘清楚高并發影響使用者的源頭？是因為帶寬不夠還是服務記憶體不足？
服務帶寬指的是：用戶端與伺服器傳輸的寬度的速度，1m 等于 128kb。
服務記憶體指的是：伺服器端處理業務能力。
那麼解決高并發的入口是用戶端與伺服器端傳輸帶寬速度, 如果帶寬速度不足的情況，可能會導緻用戶端延遲等待。
一個網站核心 分為靜态資源(css、img、js)和動态資源（jsp、ftl）組合，絕大數的情況下靜态資源占了整個網站帶寬傳輸， 這時候應該采用網站動靜分離架構，将動态資源與靜态資源分開伺服器存放，注意：網站跨域問題。
動靜分離可以使用 nginx，或者是使用第三方靜态資源伺服器比如七牛雲、阿裡雲等。
還要對靜态資源實作壓縮、減少帶寬的傳輸，使用 CDN 實作内容分發，從最近伺服器通路。
如何對靜态資源實作壓縮呢？ 使用 nginx 開啟 gzip、maven 打包壓縮 min 格式、或者使用 cdn 自帶壓縮
以上這些屬于 Web 前端優化。
如果用戶端發送請求已經達到伺服器端的話，服務端處理響應産生延遲，那麼開始采用後端優化方案。
.可以對伺服器實作叢集 、加服務配置、采用 MQ 異步傳輸、使用 Redis 做緩存，減輕資料庫通路壓力、代碼優化、資料庫采用:讀寫分離和分表分庫，程式采用多線程、jvm 參數調優，服務實作保護機制（服務降級、服務隔離、服務熔斷、服務限流）等。
Web 前端優化大多數情況下，屬于公司運維幹的事情，後端優化屬于架構師做的事情，如果一個網站中靜态資源非常多的情況下，不要将靜态資源和動态資源在同一個伺服器存放，一定要采用動靜分離架構，提高網站的吞吐量。
最後總結下，如果伺服器帶寬不足的情況下，伺服器接受用戶端請求資源，可能會産生延遲，伺服器做叢集、加配置，效果不會很明顯，因為伺服器叢集隻能提高伺服器的業務處理能力，不能提高伺服器的帶寬傳輸， 是以可以采用以上總結的 Web 前端優化方案，減少用戶端與伺服器端帶寬傳輸。
.如果在帶寬的足夠的情況下，用戶端發送請求已經到達了後端伺服器，伺服器端處理能力産生延遲，那麼采用以上總結 後端優化方案
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)