項目架構相關問題

時間  2019-11-30
標籤 項目 架構 相關 問題 欄目 系統架構 简体版
原文   原文鏈接

rabitmq的三大做用：
1.同步變異步
2.解耦
3.削峯
javascript

redis 分佈式鎖用的是setnx命令加鎖
JVM爲何須要調優?
php

redis部分支持事務,入隊列不報錯，就能夠運行，執行命令時候的報錯，事務同樣能夠提交
單個redis能夠達到併發量每秒10萬次。
redis是單線程的，命令只能一個個去執行。
css

Rabbitmq自動確認消息問題
autoAck=true. 若是消費者發生異常，則這條消息也被mq丟棄，則消費者消息丟失。
html

Eureka比Zookeeper區別
Zookeeper保證CP
當向註冊中心查詢服務列表時，咱們能夠容忍註冊中心返回的是幾分鐘之前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。可是zk會出現這樣一種狀況，當master節點由於網絡故障與其餘節點失去聯繫時，剩餘節點會從新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就致使在選舉期間註冊服務癱 瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大機率會發生的事，雖然服務可以最終恢復，可是漫長的選舉時間致使的註冊長期不可用是不能容忍的。
前端

Eureka保證AP
Eureka看明白了這一點，所以在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工做，剩餘的節點依然能夠提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時若是發現鏈接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此以外，Eureka還有一種自我保護機制，若是在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現如下幾種狀況：
java

  1. Eureka再也不從註冊列表中移除由於長時間沒收到心跳而應該過時的服務
  2. Eureka仍然可以接受新服務的註冊和查詢請求，可是不會被同步到其它節點上(即保證當前節點依然可用)
  3. 當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中

所以， Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況，而不會像zookeeper那樣使整個註冊服務癱瘓。
web

  1. 總結 Eureka做爲單純的服務註冊中心來講要比zookeeper更加「專業」，由於註冊服務更重要的是可用性，咱們能夠接受短時間內達不到一致性的情況。不過Eureka目前1.X版本的實現是基於servlet的Java web應用，它的極限性能確定會受到影響。期待正在開發之中的2.X版本可以從servlet中獨立出來成爲單獨可部署執行的服務。

SheetJS好像又叫js-xlsx前端導出Excel
首先咱們引入這個腳本文件。
ajax

<html>
<head>
	<style type="text/css">
		.buttonStyle{
			height: 40px;
			width:200px;
			padding: 40px
		}
	</style>
</head>
<body>
	<button class="buttonStyle" onclick="download()">導出</button>
</body>
<script type="text/javascript" src="https://unpkg.com/xlsx@0.14.0/dist/xlsx.full.min.js"></script>  
<script type="text/javascript">

	function download(){
		var filename = "file.xlsx"; //文件名稱
		var data = [[1,2,3],[true, false, null, "sheetjs"],["foo","bar",new Date("2014-02-19T14:30Z"), "0.3"], ["baz", null, "qux"]];  //數據，必定注意須要時二維數組
		var ws_name = "Sheet1"; //Excel第一個sheet的名稱
		var wb = XLSX.utils.book_new(), ws = XLSX.utils.aoa_to_sheet(data);
		XLSX.utils.book_append_sheet(wb, ws, ws_name);  //將數據添加到工做薄
		XLSX.writeFile(wb, filename); //導出Excel
	}
	
</script>
</html>

複製代碼

Sheetjs導出能夠減小服務器的壓力，把生成Excel的工做放在客戶端來處理。redis

3.Redis發佈訂閱
Redis 發佈訂閱(pub/sub)是一種消息通訊模式：發送者(pub)發送消息，訂閱者(sub)接收消息。
下圖展現了頻道 channel1 ， 以及訂閱這個頻道的三個客戶端 —— client2 、 client5 和 client1 之間的關係：
spring

當有新消息經過 PUBLISH 命令發送給頻道 channel1 時， 這個消息就會被髮送給訂閱它的三個客戶端：

1.先向通道發佈消息
redisTemplate.convertAndSend(channel, message);
2.監聽器 

<redis:listener-container connection-factory="cacheJedisConnectionFactory">
    <redis:listener ref="redisMessageSwitchListener" topic="channer" />
</redis:listener-container>
複製代碼

http的各個版本
HTTP1.0、HTTP1.1 和 HTTP2.0 的區別
http發展的時間軸

影響一個 HTTP 網絡請求的因素主要有兩個：帶寬和延遲。
1.帶寬:
表示通訊線路所能傳送數據的能力，在單位時間內從網絡中的某一點到另外一點所能經過的「最高數據率」。對於帶寬的概念，比較形象的一個比喻是高速公路。單位時間內可以在線路上傳送的數據量，經常使用的單位是bps(bit per second)。計算機網絡的帶寬是指網絡可經過的最高數據率，即每秒多少比特。

2.延遲:
瀏覽器阻塞（HOL blocking）：瀏覽器會由於一些緣由阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個鏈接（這個根據瀏覽器內核不一樣可能會有所差別），超過瀏覽器最大鏈接數限制，後續請求就會被阻塞。
DNS 查詢（DNS Lookup）：瀏覽器須要知道目標服務器的 IP 才能創建鏈接。將域名解析爲 IP 的這個系統就是 DNS。這個一般能夠利用DNS緩存結果來達到減小這個時間的目的。
創建鏈接（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的創建鏈接，可是這些鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大。

HTTP1.0和HTTP1.1的一些區別
HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。 主要區別主要體如今：

1）緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

2）帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

3）錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。

4）Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。

5）長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

HTTPS與HTTP的一些區別
HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。
HTTP協議運行在TCP之上，全部傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，全部傳輸的內容都通過加密的。
HTTP和HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
HTTPS能夠有效的防止運營商劫持，解決了防劫持的一個大問題。

HTTP2.0性能驚人
HTTP2.0和HTTP1.X相比的新特性
新的二進制格式（Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在自然缺陷，文本的表現形式有多樣性，要作到健壯性考慮的場景必然不少，二進制則不一樣，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。

多路複用（MultiPlexing），即鏈接共享，即每個request都是是用做鏈接共享機制的。一個request對應一個id，這樣一個鏈接上能夠有多個request，每一個鏈接的request能夠隨機的混雜在一塊兒，接收方能夠根據request的 id將request再歸屬到各自不一樣的服務端請求裏面。

header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP2.0使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。

服務端推送（server push），同SPDY同樣，HTTP2.0也具備server push功能。

Websocket協議
首先，Websocket是一個持久化的協議，相對於HTTP這種非持久的協議來講。
在HTTP1.1中進行了改進，使得有一個keep-alive，也就是說，在一個HTTP鏈接中，能夠發送多個Request，接收多個Response。可是請記住 Request = Response，在HTTP中永遠是這樣， 也就是說一個 request只能有一個response。並且這個response也是被動的，不能主動發起。

long poll 其實原理跟 ajax輪詢 差很少，都是採用輪詢的方式，不過採起的是阻塞模型 ，也就是說， 客戶端發起鏈接後，若是沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完以後，客戶端再次創建鏈接，周而復始。

因此在這種狀況下出現了，Websocket出現了。他解決了HTTP的這幾個難題。首先，被動性，當服務器完成協議升級後（HTTP->Websocket），服務端就能夠主動推送信息給客戶端。

可是Websocket只須要一次HTTP握手，因此說整個通信過程是創建在一次鏈接/狀態中，也就避免了HTTP的非狀態性，服務端會一直知道你的信息，直到你關閉請求，這樣就解決了接線員要反覆解析HTTP協議，還要查看identity info的信息。

1)websocket URL模式：
未加密：ws:// 已加密：wss://

2）建立WebSocket:先實例一個WebSocket對象並傳入要鏈接的URL
var socket = new WebSocket("ws://www.example.com/server.php);
socket.close(); // 關閉鏈接

  1. 表示當前狀態的readyState屬性
    WebSocket.OPENING (0):正在創建鏈接
    WebSocket.OPEN (1):已經創建鏈接
    WebSocket.CLOSING (2):正在關閉鏈接
    WebSocket.CLOSE (3):已經關閉鏈接

4）發送數據
var message = { time: new Date(), text: "Hello world!", clientId: "asdfp8734rew" }; socket.send(JSON.stringify(message));// 複雜的數據結構要先進行序列化

5）接收數據
socket.onmessage = function(event){
var data = event.data;// data就是要解析的接收到的JSON字符串
}

6）其餘事件：在鏈接生命週期的不一樣階段觸發
open:在成功創建鏈接時觸發
error:在發生錯誤時觸發

springBoot 支持WebSocket
參見官網： https://docs.spring.io/spring-framework/docs/4.3.x/spring-framework-reference/html/websocket.html <br>
複製代碼

DNS域名解析服務
域名與IP地址之間是多對一的關係，一個ip地址不必定只對應一個域名，且一個域名只能夠對應一個ip地址，它們之間的轉換工做稱爲域名解析。域名解析須要由專門的域名解析服務器來完成，整個過程是自動進行的。
DNS的全稱是（ Domain Name System）是「域名系統」的英文縮寫。

具體過程以下：
①用戶主機上運行着DNS的客戶端，就是咱們的PC機或者手機客戶端運行着DNS客戶端了
②瀏覽器將接收到的url中抽取出域名字段，就是訪問的主機名，好比
www.baidu.com/, 並將這個主機名傳送給DNS應用的客戶端
③DNS客戶機端向DNS服務器端發送一份查詢報文，報文中包含着要訪問的主機名字段（中間包括一些列緩存查詢以及分佈式DNS集羣的工做）
④該DNS客戶機最終會收到一份回答報文，其中包含有該主機名對應的IP地址
⑤一旦該瀏覽器收到來自DNS的IP地址，就能夠向該IP地址定位的HTTP服務器發起TCP鏈接

DNS爲何不採用單點的集中式的設計方式，而是使用分佈式集羣的工做方式？
DNS的一種簡單的設計模式就是在因特網上只使用一個DNS服務器，該服務器包含全部的映射，在這種集中式的設計中，客戶機直接將全部查詢請求發往單一的DNS服務器，同時該DNS服務器直接對全部查詢客戶機作出響應，儘管這種設計方式很是誘人，但他不適用當前的互聯網，由於當今的因特網有着數量巨大而且在持續增加的主機，這種集中式設計會有單點故障（嗝屁一個，全球着急），通訊容量（上億臺主機發送的查詢DNS報文請求，包括但不限於全部的HTTP請求，電子郵件報文服務器，TCP長鏈接服務），遠距離的時間延遲（澳大利亞到紐約的舉例），維護開銷大（由於全部的主機名-ip映射都要在一個服務站點更新）等問題

DNS服務器通常分三種，根DNS服務器，頂級DNS服務器，權威DNS服務器。

一、在瀏覽器中輸入www.qq.com 域名，操做系統會先檢查本身本地的hosts文件是否有這個 網址映射關係，若是有，就先調用這個IP地址映射，完成域名解析。

二、若是hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，若是有，直接返回，完成域名解析。

三、若是hosts與本地DNS解析器緩存都沒有相應的網址映射關係，首先會找TCP/ip參數中設置的首選DNS服務器，在此咱們叫它本地DNS服務器，此服務器收到查詢時，若是要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具備權威性。

四、若是要查詢的域名，不禁本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析，此解析不具備權威性。

五、若是本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，若是未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名(.com)是誰來受權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。這臺負責.com域的服務器收到請求後，若是本身沒法解析，它就會找一個管理.com域的下一級DNS服務器地址(qq.com)給本地DNS服務器。當本地DNS服務器收到這個地址後，就會找http://qq.com域服務器，重複上面的動做，進行查詢，直至找到www . qq .com主機。

六、若是用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器若是不能解析，或找根DNS或把轉請求轉至上上級，以此循環。無論是本地DNS服務器用是是轉發，仍是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。

從客戶端到本地DNS服務器是屬於遞歸查詢，而DNS服務器之間就是的交互查詢就是迭代查詢。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程