上一篇我們介紹了系統日誌與測試相關的內容並添加了相關的功能；本章我們將介紹跨域與程序部署相關的內容

一、跨域

1、跨域的概念

1、什麼是跨域？

一個請求的URL由協議，域名，端口號組成，以百度的https://www.baidu.com為例，協議為https，域名由子域名www和主域名baidu組成，端口號若為80會自動隱藏(也可以配置為其它端口，通過代理服務器將80端口請求轉發給實際的端口號)。而當請求的URL的協議，域名，端口號任意一個於當前頁面的URL不同即為跨域

2、什麼是同源策略？

瀏覽器存在一個同源策略，即為了防範跨站腳本的攻擊，出現跨域請求時瀏覽器會限制自身不能執行其它網站的腳本(如JavaScript)。所以說當我們把項目部署到Web服務器后，通過瀏覽器進行請求時就會出現同源策略問題；而像PostMan軟件因其是客戶端形式的，所以不存在此類問題

3、跨域會導致什麼問題？

同源策略會限制以下行為：

• Cookie、LocalStorage和IndexDb的讀取
• DOM和JS對象的獲取
• Ajax請求的發送

2、常用的解決方法

這裏我們將簡單介紹針對跨域問題常用的幾種解決辦法，並就其中的Cors方法進行配置，若對其它方式感興趣，可參照老張的哲學的文章，⅖ 種方法實現完美跨域

2.1、JsonP

1、原理

上面有提到瀏覽器基於其同源策略會限制部分行為，但對於Script標籤是沒有限制的，而JsonP就是基於這一點，它會在頁面種動態的插入Script標籤，其Src屬性對應的就是api接口的地址，前端會以Get方式將處理函數以回調的形式傳遞給後端，後端響應後會再以回調的方式傳遞給前端，最終頁面得以显示

2、優缺點

JsonP出現時間較早，所以對舊版本瀏覽器支持性較好；但自身只支持Get請求，無法確認請求是否成功

2.2、 CORS

1、原理

CORS的全稱是Corss Origin Resource Sharing，即跨域資源共享，它允許將當前域下的資源被其它域的腳本請求訪問。其實現原理就是在響應的head中添加Access-Control-Allow-Origin，只要有該字段就支持跨域請求

2、優缺點

Cors支持所有Http方法，不用考慮接口規則，使用簡單；但是對一些舊版本的瀏覽器支持性欠佳

3、使用

其使用非常簡單，以我們的項目為例，在BlogSystem.Core項目的Startup類的ConfigureServices方法中進行如下配置

同時需要開啟使用中間件，如下：

2.3、Nginx

1、原理

跨域問題是指在一個地址中發起另一個地址的請求，而Nginx可以利用其反向代理的功能，接受請求后直接請求該地址，類似打開了一個新的頁面，所以可以避開跨域的問題

2、優缺點

配置簡單，可以降低開發成本，方便配置負載均衡；靈活性差，每個環境都需要進行不同的配置

二、程序部署

1、部署模式

在.NET Core中，有兩種部署模式，分別為FDD(Framework-dependent)框架依賴發布模式和SCD(Self-contained)自包含獨立發布模式

• FDD：此類部署需要服務器安裝.NET Core SDK環境，部署的包容量會比較小，但可能因SDK版本存在兼容性問題；
• SCD：此類部署自包含.NET Core SDK的環境，不同.NET Core版本可以共存，其部署包容量會較大，且需要對服務器進行相關配置

2、常用部署方式

以下內容均參考老張的哲學的文章最全的部署方案 & 最豐富的錯誤分析，有興趣的朋友可以參考原文

2.1、Windows平台

• 直接運行：發布目標選擇windows時會在文件夾中生成一個exe文件，我們可以直接執行exe文件或使用CLI命令調用dll運行；這種方式雖然方便，卻存在一些弊端，比如說部署多個的情況下會存在很多控制台窗口，如誤操作會導致窗口關閉等；
• 部署服務：除了上述直接運行的方式外，我們還可以將程序發布為服務，發布后我們可以像控制系統服務一樣控製程序的啟動和關閉

需要注意的是上述兩類方法都需要藉助IIS或者是代理服務器進行服務的轉發，否則只能在本地進行訪問；

2.2、Linux平台

Linux平台常用的部署方式即為程序+代理服務器，但是當我們配置完成后運行程序時，該運行命令會一直佔用操作窗口，所以我們需要使用“守護進程”來解決這個問題，簡單來說就是將程序放到後台運行，不影響我們進行其他操作

綜上，部署模式、部署方式及部署平台有多種組合方式，接下來我們挑選下述3種方法進行演示：

方案	依賴運行時/宿主機	依賴代理服務器	其它配置
Windows程序(SCD)+Nginx	否	是	無
Windows服務(FDD)+IIS	是	否	設置為服務
Linux程序(FDD)+Nginx	是	是	守護進程

3、程序發布

1、這裏我們右擊BlogSystem.Core項目，選擇發布，選擇文件夾后，點擊高級

2、為了演示後面的發布實例，這裏我們分別選擇3種組合模式，①獨立+win-x64；②框架依賴+win-x64；③框架依賴+linux-x64

3、將發布實例拷貝到單獨的文件夾種，這裏我們使用SCD-Window驗證下程序能否直接運行，運行BlogSystem.Core.exe，報錯：

原來還是老問題，BLL沒有添加到發布文件中，我們到項目的bin文件夾下將BLL和DAL的dll文件分別拷貝至3個文件夾，再次運行，出現404錯誤，經過確認發現，首頁對應的是Swagger文檔頁面，而在配置中間件時我們有添加開發環境才配置swagger的邏輯，所以這裏我們可以根據個人需求決定是否添加。

這裏我為了方便確認發布是否成功，所以將其從判斷邏輯中取出了。重新生成發布文件，拷貝BLL和DAL的dll文件，再次運行，還是報錯。原來時Swagger的XML文件缺失，從bin文件夾下拷貝添加至發布文件，運行后成功显示頁面

4、有的朋友會說了，每次都要拷貝這兩個dll和這兩個xml文件，太麻煩了。其實也是有對應的解決辦法的，我們可以使用dotnet的CLI命令進行發布，選擇引用的發布文件夾為bin文件夾，拷貝至發布文件夾即可，有興趣的朋友可以自行研究

三、服務器發布

這裏我用的是阿里雲服務器，Window系統版本是Window Server2012 R2，Linux系統版本是CentOS 8.0；在操作前記得確認拷貝的發布文件能否在本地正常運行

1、Windows程序(SCD)+Nginx

1、解壓后雙擊exe文件網站可以正常運行，如下：

2、這個時候我們發現了一個問題，服務器上沒有數據庫，所以無法確認功能是否正常，這裏我們先下載安裝一個Microsoft SQL Server 2012 Express數據庫（建項目時沒有考慮到發布后測試的問題，實際上像SQLite數據庫是非常符合這類場景的）

安裝完成后我們新建一個BlogSystem的數據庫，通過Sql文件的形式將數據庫結構和數據導入至服務器數據庫，這時候又發現一個問題，由於我們連接數據庫的邏輯放置在model層的BlogSystemContext文件夾下，所以需要將連接中的DataSource更改為Express數據庫，重新發布后覆蓋舊的發布文件（系統設計有缺陷，可以將EF上下文文件放在應用程序層或單獨一層），再次運行，成功執行查詢，如下：

3、這個時候本地已經可以進行正常的訪問了，但是外部網絡是無法訪問調用接口的，這裏我們藉助Nginx進行服務的轉發。下載Nginx后解壓對conf文件夾下的nginx.conf文件進行如下配置：

4、在nginx.exe文件所在目錄的文件路徑輸入cmd，鍵入nginx啟動服務訪問8081端口，成功显示頁面（確保core程序正常運行）如下：

5、這個時候我們使用其它電腦訪問接口，發現還是無法訪問，經過查詢是阿里雲服務器進行了相關的限制，在阿里雲控制台配置安全組規則后即可正常訪問，如下：

6、配置完成后運行，成功訪問該網站且功能正常。這類方法不需要藉助Core的運行時環境，可以說十分便捷

2、Windows服務(FDD)+IIS

1、首先我們將FDD發布文件壓縮后拷貝至Window Server主機，因FDD的部署方法需要藉助.NET Core運行時環境，所以這裏我們首先到官網https://dotnet.microsoft.com/download/dotnet-core/current/runtime下載安裝.NET Core運行時，這裏我們選擇的是右邊這個，安裝完需要重新啟動

2、上一個方法中桌面显示控制台窗口顯然不是一個較佳的方案，所以這裏我們將其註冊為服務。官方提供了ASP.NET Core服務託管的方法，但使用較為複雜，這裏我們藉助一個名為nssm的工具來達到同樣的目的。我們下載nssm后，在其exe路徑運行cmd命令，執行nssm install，在彈出的窗口中進行如下配置：

3、我們在系統服務中開啟BlogSytem.Core_Server，在控制面版中選擇安裝IIS服務，併發布對應的項目，安裝完成后，添加部署為8082端口，將應用程序池修改為無託管，如下：

4、運行網站，成功显示頁面，但是進行功能試用時發現報錯；經過確認是由於IIS應用程序池的用戶驗證模式和sqlserver的驗證模式不同，解決辦法有三種①修改應用程序池高級設置中的進程模型中的標識②將連接數據庫字符串中的Integrated Security=True去除，並添加數據庫連接對應的賬號密碼③在數據庫的“安全性”>“登錄名”裏面，添加對應IIS程序池的名稱，並在這個用戶的“服務器角色”和“用戶映射”中給他對應的權限

後續嘗試方案一失敗，嘗試方案二成功，方案三由於要安裝SSMS所以沒有嘗試，有遇到相同問題的朋友可以自己試下

3、Linux程序(FDD)+Nginx

1、首先我們使用MobaXterm工具登錄至Linux主機(選擇此工具是由於其)同時支持文件傳送和命令行操作)，這裏使用的Linux版本是CentOS 8.0；藉助MobaXterm工具在home文件夾下創建WebSite文件夾，並在其內部創建BlogSystem文件夾，將我們準備好的FDD部署方式的發布文件上傳至此文件夾后，使用命令sudo dnf install dotnet-sdk-3.1安裝.net core sdk，如下圖

2、輸入cd /home/WebSite/BlogSystem切換至項目文件夾后，使用dotnet BlogSystem.Core.dll運行程序，成功執行，但是由於我們沒有數據庫，且未配置代理服務器，所以無法驗證服務是否正常運行；所以這裏我們先參照微軟doc快速入門：在 Red Hat 上安裝 SQL Server 並創建數據庫安裝Sql Server數據庫（阿里雲默認安裝了python3作為解釋器所以無需重複安裝），安裝完成后我們開放在阿里雲實例中開放1433端口，使用可視化工具導入表結構和數據

3、完成上述操作后我們需要配置守護進程，將程序放在後台運行。首先我們在/etc/systemd/system下新建守護進程文件，文件名以.service結尾，這裏我們新建名為BlogSystem.service文件，使用MobaXterm自帶的編輯器打開文件後進行如下配置，注意後面的中文備註需要去除否則會報錯

[Unit]
Description=BlogSystem    #服務描述，隨便填就好

[Service]
WorkingDirectory=/home/WebSite/BlogSystem/   #工作目錄，填你應用的絕對路徑
ExecStart=/usr/bin/dotnet /home/WebSite/BlogSystem/BlogSystem.Core.dll    #啟動：前半截是你dotnet的位置（一般都在這個位置），後半部分是你程序入口的dll，中間用空格隔開
Restart=always  
RestartSec=25 #如果服務出現問題會在25秒后重啟，數值可自己設置
SyslogIdentifier=BlogSystem  #設置日誌標識，此行可以沒有
User=root   #配置服務用戶，越高越好
Environment=ASPNETCORE_ENVIRONMENT=Production
[Install]
WantedBy=multi-user.target

我們使用cd /etc/systemd/system/切換至BlogSystem.service對應的目錄，使用systemctl enable BlogSystem.service設置為開機運行后，再使用systemctl start BlogSystem.service啟動服務，另外可以使用systemctl status BlogSystem確認服務狀態

4、接下來我們安裝代理Nginx代理默認的5000端口，使用sudo yum install nginx安裝nginx后，我們到\etc\nginx文件夾下打開nginx.conf文件進行如下配置：

配置完成我們進入\etc\nginx文件夾下，使用systemctl enable nginx將nginx設置為開機啟動，並使用systemctl start nginx啟用服務，同樣可以使用systemctl status nginx確認其狀態。確認無誤后在阿里雲中開放8081端口，外網可正常訪問，但功能試用時報錯，原來是數據庫連接錯誤，重新設置后即可正常訪問

本章完~

本人知識點有限，若文中有錯誤的地方請及時指正，方便大家更好的學習和交流。

本文部分內容參考了網絡上的視頻內容和文章，僅為學習和交流，地址如下：

老張的哲學，系列一、ASP.NET Core 學習視頻教程

solenovex，ASP.NET Core 3.x 入門視頻

聲明

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧

※聚甘新

一. 頁式內存管理介紹

　　80386能夠將內存分為不同屬性的段，並通過段描述符、段表以及段選擇子等機制，通過段基址和段內偏移量計算出線性地址進行訪問，這一內存管理方式被稱為段式內存管理。

　　這裏要介紹的是另一種內存管理的方式：80386在開啟了分頁機制后，便能夠將物理內存劃分為一個個大小相同且連續的物理內存頁，訪問時通過物理內存頁號和頁內偏移計算出最終需要訪問的線性地址進行訪問，由於內存管理單元由段變成了頁，因此這一內存管理方式被稱為頁式內存管理。

　　80386的分頁機制只能在保護模式下開啟。

為什麼需要頁式內存管理？

　　在介紹80386分頁機制前，需要先理解為什麼CPU在管理內存時，要在段式內存管理的基礎上再引入一種有很大差異的頁式內存管理方式？頁式內存管理與純段式內存管理相比到底具有哪些優點？

　　一個很重要的原因是為了解決多任務環境下，段式內存管理中多任務的創建與終止時會產生較多內存碎片，使得內存空間使用率不高的問題。

　　內存碎片分為外碎片和內碎片兩種。

外碎片

　　對於指令和數據的訪問通常都是連續的，所以需要為一個任務分配連續的內存空間。在段式內存管理中，通常為任務分配一個完整的內存段，或是按照任務內段功能的不同，分配包括代碼段、數據段和堆棧段在內的多個完整連續段空間。支持多道任務的系統分配的內存空間，會在某些任務退出並釋放內存時，產生外部內存碎片。

　　舉個例子，假設當前存在10MB的內存空間，存在A/B/C/D四個任務，併為每個任務分配一整塊的內存空間，其所佔用的內存空間分別為3MB/2MB/4MB/1MB，如下圖所示(一個格子代表1MB內存)。

　　當任務B和任務D執行完成后，所佔用的內存空間被釋放，10MB的內存空間中出現了3MB大小的空閑內存。如果此時出現了一個任務E，需要為其分配3MB的內存空間，此時內存雖然存在3MB的內存空間，卻由於空閑內存的不連續，碎片化，導致無法直接分配給任務E使用。而這裏任務B、任務D結束后釋放的空餘內存空間就被視為外碎片。

　　這裏的例子任務數量少且內存空間也很小。而在實際的32位甚至64位的系統中，物理內存空間少則4GB，多則幾十甚至上百GB，由於任務內存的反覆分配和釋放，導致出現的外碎片的數量及浪費的內存空間會很多，很大程度上降低了內存空間的利用率。

　　雖然理論上能夠通過操作系統小心翼翼的挪動內存，使得外碎片能夠拼接為連續的大塊，得以被有效利用(內存緊縮)。但是操作系統挪動、複製內存本身很佔用CPU資源，且存在對指令進行地址重定位、暫時暫停對所挪動內存區域的訪問等附加問題，造成的效率降低程度幾乎是不可忍受的，因此這一解決方案並沒有被廣泛使用。

　　

內碎片

　　外碎片指的是不同任務內存之間的碎片，而內碎片指的是一個任務內產生的內存碎片。

　　通常操作系統為了管理多任務環境下的物理內存，會將內存分隔為固定大小的分區，使用系統表記錄對應分區內存的使用情況(如是否已分配等)。分區的大小必須適當，如果分區過小，則相同物理內存大小下，系統表項過多使得所佔用的空間過大；可如果分區過大，則會產生過大的內碎片，造成不必要的內存空間浪費。

　　以上述介紹外碎片的數據為例，系統中的內存分區固定大小為1MB，其中為任務C分配了4個內存分區，共4MB大小。可實際上任務C實際只需要3.5MB的空間即可滿足需求，但由於分區是內存管理的最小單元，只能為任務分配整數個的內存分區。3個分區3MB並不滿足任務C的3.5MB的內存需求，因此只能分配4個分區給任務C。而這裏任務C額外多佔用的0.5MB內存就是內碎片。　

　　內碎片就是已經被分配出去，卻不能被有效利用的內存空間。

80386是如何解決內存碎片問題的？

外碎片的解決

　　外碎片問題產生的主要原因是程序所需要分配的內存空間是連續的。為此，80386提供了分頁機制，使得最終分配給任務的物理內存空間可以不連續。如果任務所使用的內存不必連續，前面外碎片例子中提到的任務E就能夠在1MB+2MB的離散物理內存上正常運行，外碎片問題自然就得到了解決。

內碎片的解決

　　內碎片從本質上來說是很難完全避免的(內存管理最小單元不能過小)，主要的問題在於前面提到的內存分區管理單元大小的較優值不好確定。開啟了分頁管理的80386，允許將物理內存分割最小為4KB固定大小的管理單元，這個固定大小的內存管理單元被稱為頁，並由專門的被稱為頁表的數據結構來追蹤內存頁的使用情況。

　　對於頁表項過多的問題，80386的設計者提供了多級頁表機制，減少了頁表所佔用的空間。

　　對於內碎片過大的問題，由於80386所運行的任務所佔用的內存段一般遠大於一個內存頁的大小，因此頁機制下所產生的內部碎片是十分有限的，可以達到一個令人滿意的內存使用率。

二. 虛擬內存簡單介紹　

　　為了解決應用程序高速增長的內存需求與物理內存增加緩慢的矛盾，計算機科學家們提供了虛擬內存的概念。使用了虛擬內存的系統，可以使得系統內運行的程序所佔用的內存空間總量，遠大於實際物理內存的容量。

　　能夠實現虛擬內存的關鍵在於程序在特定時刻所需要訪問的內存地址是符合局部性原理的。通過操作系統和硬件的緊密配合，能夠將任務暫時不需要訪問的內存交換到外部硬盤中，而將物理內存留給真正需要訪問的那部分內存(工作集內存)。

　　虛擬內存和分頁機制是一對好搭檔，分頁機制提供了管理內存的基本單位：頁，80386的頁式虛擬內存實現在工作集內存調度時也依賴分頁機制提供的頁來進行。隨着程序的執行，程序的工作集內存在動態變化，當CPU檢測到當前所訪問的內存頁不在物理內存中時，便會通知操作系統(內存缺頁異常)，操作系統的缺頁異常處理程序會將硬盤交換區中的對應內存頁數據寫回物理內存。如果物理內存頁已經滿了的情況下，則還需要根據某種算法將另一個物理內存頁替換，來容納這一換入的內存頁。

三. 80386分頁機制原理

　　在介紹分頁機制原理之前，需要先理解關於80386保護模式下32位內存尋址時幾種地址的概念。

物理地址(Physical Address)：

　　物理地址就是32位的地址總線所對應的真實的硬件存儲空間。對於物理內存的訪問，無論中間會經過多少次轉換，最終必須轉換為最終的物理地址進行訪問。

邏輯地址(Logical Address)：

　　在80386保護模式的程序指令中，對內存的訪問是由段選擇子和段內偏移決定的。段選擇子+段內偏移 –> 邏輯地址。

線性地址(Linear Address)：

　　CPU在內存尋址時，從指令中獲得段選擇子和段內偏移，即邏輯地址。由段選擇子在段表(GDT或LDT)中找到對應的段描述符，獲取段基址。段基址+段內偏移決定線性地址。

　　如果沒有開啟分頁，CPU就使用生成的線性地址直接作為最終的物理地址進行訪問；如果開啟了分頁，則還需要通過頁表等機制，將線性地址進一步處理才能生成物理地址進行訪問。

頁式虛擬內存實現原理

　　程序要求訪問一個段時，其線性地址必須是連續的。在純粹的段式內存管理中，線性地址等於物理地址的情況下，就會出現外碎片的問題。而在段式內存管理的基礎上，80386如果還開啟了頁機制，就能通過抽象出一層線性地址到物理地址的映射，使得最終分配給程序的物理內存段不必連續。

　　80386中的內存頁大小為4KB，在32位的內存尋址空間中(4GB)，存在着0x10000 = 1048576個頁。每個頁對應的起始地址低12位都為0，第一個物理內存頁的物理地址為0x00000000，第二個物理內存頁的物理地址為0x00001000，依此類推，最後一個物理頁的物理地址是0xFFFFF000。

頁表

　　在80386的分頁機制的實現中，是通過頁表來實現線性地址到物理地址映射轉換的。每個任務都有一個自己的頁表，記錄著任務的線性地址到物理地址的映射關係。

　　開啟了頁機制后的線性地址也被稱為虛擬地址，這是因為線性地址已經不再直接對應真實的物理地址，而是一個不承載真實數據的虛擬內存地址。開啟了分頁機制后，一個任務的虛擬地址空間依然是連續的，但所佔用的物理地址空間卻可以不連續。

　　頁表保存着被稱為頁表項的數據結構集合，每一個頁表項都記載着一個虛擬內存頁到物理內存頁的映射關係。開啟了頁機制之後，CPU在內存尋址時，在通過段表計算出了線性地址(虛擬地址)后，便可以在連續排布的虛擬地址空間中找到對應的頁表項，通過頁表項獲取虛擬內存頁所對應的物理內存頁地址，進行物理內存的訪問。虛擬地址到物理地址映射的細節會在後面進行展開。

　　由於是將不斷變化的虛擬內存頁裝載進相對不變的物理內存頁中，就像畫廊中展示的畫會不斷的更替，但畫框基本不變一樣。為了更好的區分這兩者，頁通常特指虛擬內存頁，而物理內存頁則被稱為頁框。

頁表項介紹

　　頁表項是32位的，其結構如下圖所示。

　　

P位：

　　P(Present)位，存在位。標識當前虛擬內存頁是否存在於物理內存頁中。當P位為1時，表示當前虛擬內存頁存在於物理內存中，可以直接進行訪問。當P位為0時，表示對應的物理內存頁不存在，需要新分配物理內存頁或是從磁盤中將其調度回物理內存。

　　分頁模式下的內存尋址，如果CPU發現對應的頁表項P位為0，會引發缺頁異常中斷，操作系統在缺頁異常處理程序中進行對應的處理，以實現虛擬內存。

RW位：

　　RW(Read/Write)位，讀寫位。標識當前頁是否能夠寫入。當RW為1時，代表當前頁可讀可寫；當RW為0時，代表當前頁是只讀的。

US位：

　　US(User/Supervisor)位，用戶/管理位。當US為1時，標識當前頁是用戶級別的，允許所有當前特權級的任務進行訪問。當US為0時，表示當前頁是屬於管理員級別的，只允許當前特權級為0、1、2的任務進行訪問，而當前特權級為3的用戶態任務無法進行訪問。

PWT位/PCD位：

　　PWT(Page-level Write Through)位，頁級通寫位。PWT為1時，表示當前物理頁的高速緩存採用通寫法；PWT為0時，表示當前物理頁的高速緩存採用回寫法。

　　PCD(Page-level Cache Disable)位，頁級高速緩存禁止位。PCD為1時，表示訪問當前物理頁禁用高速緩存；PCD為0時，表示訪問當前物理頁時允許使用高速緩存。

　　PWT與PCD位的使用，涉及到了80386高速緩存的工作原理與內存一致性問題，限於篇幅不在這裏展開。

A位：

　　A(Access)位，訪問位。A位為1時，代表當前頁曾經被訪問過；A位為0時，代表當前頁沒有被訪問過。

　　A位的設置由CPU固件在對應內存頁訪問時自動設置為1，且可以由操作系統在適當的時候通過程序指令重置為0，用以計算內存頁的訪問頻率。通過訪問頻率，操作系統能夠以此作為虛擬內存調度算法中評估的依據，在物理內存緊張的情況下，可以選擇將最少使用的內存頁換出，以減少不必要的虛擬內存頁調度時的磁盤I/O，提高虛擬內存的效率。

D位：

　　D(Dirty)位，臟位。當D位為1時，表示當前頁被寫入修改過；D位為0時，代表當前頁沒有被寫入修改過。

　　臟位由CPU在對應內存頁被寫入時自動設置為1。操作系統在進行內存頁調度時，如果發現需要被換出的內存頁D位為1時，則需要將對應物理內存頁數據寫回虛擬頁對應的磁盤交換區，保證磁盤/內存數據的一致性；當發現需要被換出的物理內存頁的D位為0時，表示當前頁自從換入物理內存以來沒有被修改過，和磁盤交換區中的數據一致，便直接將其覆蓋，而不進行磁盤的寫回，減少不必要的I/O以提高效率。

PAT位：

　　PAT(Page Attribute Table)，頁屬性表支持位。PAT位的存在使得CPU能夠支持更複雜的，不同頁大小的分頁管理。當PAT=0時，每一頁的大小為4KB；當PAT=1時，每一頁的大小是4MB，或是其它大小(分CPU的情況而定)。

G位:

　　G(Global)，全局位。表示當前頁是否是全局的，而不是屬於某一特定任務的。G=1時，表示當前頁是全局的；G=0時，表示當前頁是屬於特定任務的。

　　為了加速頁表項的訪問，80386提供了TLB快表，作為頁表訪問的高速緩存。當任務切換時，TLB內所有G=0的非全局頁將會被清除，G=1的全局頁將會被保留。將操作系統內核中關鍵的，頻繁訪問的頁設置為全局頁，使得其能夠一直保存在TLB快表中，加速對其的訪問速度，提高效率。

AVL位：

　　AVL(Avaliable)，可用位。和段描述符中的AVL位功能類似，CPU並不使用它，而是提供給操作系統軟件自定義使用。

頁物理基地址字段：　　 　　

　　頁物理基地址字段用於標識對應的物理頁，共20位。

　　由於32位的80386的頁最小是4KB，而4GB的物理內存被分解為了最多0x10000個4KB的物理頁。20位的頁物理基地址字段作為物理頁的索引標號與每一個具體的物理頁一一對應。通過頁物理基地址字段，便能找到唯一對應的物理內存頁。

多級頁表

　　在32位的CPU中，操作系統可以給每個程序分配至多4GB的虛擬內存空間，如果一個內存頁佔4KB，那麼對應的每個程序的頁表中最多需要存放着0x10000個頁表項來進行映射。即使每個頁表項只佔小小的32位共4個字節(4Byte)，這依然是一個不小的內存開銷(0x10000個頁表項的大小為4MB)。

　　一個應用程序雖然可以被分配4GB的虛擬內存空間，但實際上可能只使用其中的一小部分，例如40MB的大小。通常程序的堆棧段和數據段都分別位於虛擬內存空間的高低兩端，並隨着程序的執行慢慢的向中間擴展，由於頁表項對應與虛擬地址空間的連續性，這就要求任務在執行時必須完整的定義整張頁表。

　　可以看到，一級的平面頁表結構存在着明顯的頁表空間浪費的問題。雖然可以要求應用程序不要一下子就以4GB的內存規格進行編程，而是一開始用較小的內存，並在需要更大內存時梯度的申請更大的內存空間，並重新構造數據段和堆棧段以減少每個任務的無用頁表項空間的浪費。但這將頁表空間優化的繁重任務強加給了應用程序，並不是一個好的解決辦法。

　　為此，計算機科學家們提出了多級頁表的方案來解決頁表項過多的問題。多級頁表顧名思義，頁表的結構不再是一個一級的平面結構(一級頁表)，而是像一顆樹一樣，由頁目錄項節點和頁表項節點組成。目錄節點中保存着下一級節點的物理頁地址等信息，恭弘=叶 恭弘子節點中則包含着真正的頁表項信息。查詢頁表項時，從一級頁目錄節點(根目錄)出發，按照一定的規則可以找到對應的下一級子目錄節點，直到查詢出對應的恭弘=叶 恭弘子節點為止。

　　

80386頁目錄項介紹

　　80386採用的是二級頁表的設計，二級頁表由頁目錄表和頁表共同組成。頁目錄表中存放的是頁目錄項，頁目錄項的大小和頁表項一致，為4字節。

　　通過80386指令得到的32位線性地址，其中高20位作為頁表項索引，低12位作為頁內偏移地址(4KB大小的物理頁)。如果採用的是一級頁表結構，20位的頁表項索引能直接找到4MB頁表中的對應頁表項。

　　而對於80386二級頁表的設計來說，由於一個物理頁大小為4KB，最多可以容納1024(2^10)個頁表項或者頁目錄項，所以將頁表項索引的高10位作為根目錄頁中頁目錄項的索引值，通過頁目錄項中的頁表項物理頁號可以找到對應的頁表物理頁；再根據頁表項索引的后10位找到頁表中對應的頁表項。

　　

80386頁目錄項結構圖

 　　80386的二級頁表的頁目錄項佔32位，其低12位的含義與頁表項一致。主要區別在於其高20位存放的是下一級頁表的物理頁索引，而不是虛擬地址映射的物理內存頁地址。

　　

頁表基址寄存器

　　前面提到過，和LDT一樣，每個任務都擁有着自己獨立的頁表。為此80386CPU提供了一個專門的寄存器用於追蹤定位任務自己的頁表，這個寄存器的名稱叫做頁表基址寄存器(Page Directory Base Register，PDBR)，也就是控制寄存器CR3。

　　由於80386分頁機制使用的是二級頁表，因此PDBR指向的是二級頁表結構中的頁目錄，通過頁目錄表便能夠間接的訪問整個二級頁表。為了效率其中存放的直接就是頁目錄表的32位物理地址，一般由操作系統負責在任務切換時將新任務對應的頁目錄表預先加載進物理內存。

　　由於PDBR是和當前任務有關的，在任務切換時會被新任務TSS中的PDBR字段值所替換，指向新任務的頁目錄表，而舊任務的PDBR的值則在保護現場時被存入對應的TSS中。

多級頁表是如何解決頁表項浪費問題的？

　　以80386的二級頁表設計為例，最大4GB的虛擬內存空間下，無論如何一級頁目錄表是必須存在的。當不需要為應用程序分配過多的內存時，頁目錄表中的頁目錄項所指向的對應頁表可以不存在，即頁目錄項的P位為0，實際不使用的虛擬內存空間將沒有對應的二級頁表節點，相比一級頁表的設計其浪費的內存會少很多。

　　假設需要為一個虛擬地址首尾各需要分配20MB，共佔用40MB內存的任務構建對應的頁表。

　　1. 如果使用一級頁表，4GB的虛擬內存空間下需要提供0x10000個頁表項，共4MB，頁表的體積達到了任務自身所需40MB內存的10%，但其中絕大多數的頁表項都是沒用的(P位為0)，不會對應實際的物理內存，空間效率很低。

　　2. 如果使用二級頁表，除了佔一個物理頁4KB大小的頁目錄表是必須存在的外，其頁目錄表中只有首尾兩項的P位為1，分別指向一個實際存在的頁表(二級節點)，頁目錄表中間其它的頁目錄項P位都為0，不需要為這些不會使用到的虛擬地址分配頁表。對於這個40MB的程序來說，其頁表只佔了3個物理頁面，共12KB，空間效率相比一級頁表高很多。

TLB快表

　　前面提到了多級頁表所帶來的好處：通過頁表分層，可以減少順序排列的無效頁表項數量，節約內存空間；頁表的層級越多，空間效率也越高。

　　計算機領域中，通常並沒有免費的午餐，一個問題的解決，往往會帶來新的問題：多級頁表本質上是一個樹狀結構，每一個節點頁都是離散的，因此每一層級訪問都需要進行一次內存尋址操作，頁表的層級越多，訪問的次數也就越多，虛擬頁地址映射過程也越慢。在32位的80386中，2級頁表下問題還不算特別嚴重；但64位CPU的出現帶來了更大的尋址空間，也需要更多的頁表項，頁表的層級也漸漸的從2級變成了3級、4級甚至更多。頁機制開啟之後，所有的內存尋址都需要經過CPU的頁部件進行轉化才能獲得最終的物理地址，因此這一過程必須要快，不能因為頁表的離散層次訪問就嚴重影響虛擬地址空間到物理地址空間的轉換速度。

　　要加快原本相對耗時的查詢操作，一個常用的辦法便是引入緩存。為了加速通用內存的訪問，80386利用局部性原理提供了高速緩存；為了加速多級頁表的頁表項訪問，80386提供了TLB。

　　TLB(Translation Lookaside Buffer)直譯為地址轉換後援緩衝器，根據其作用也被稱為頁表緩存或是快表(快速頁表)。TLB中存放着一張表，其中的每一項用於緩存當前任務虛擬頁號和對應頁表項中的關鍵信息，被稱為TLB項。

　　TLB的工作原理和高速緩存類似：當CPU訪問某一虛擬頁時，通過虛擬頁號先在TLB中尋找，如果發現對應的TLB項存在，則直接以TLB項中的數據進行物理地址的轉換，這被稱為TLB命中；當發現對應的TLB項不存在時(TLB未命中)，則進行內存的訪問，在獲取內存中頁表項數據的同時，也將對應頁表項緩存入TLB中。如果TLB已滿則需要通過某種置換算法選出一個已存在的TLB項將其替換。

　　TLB的查詢速度比內存快，但容量相對內存小很多，因此只能緩存數量有限的頁表項。但由於內存訪問的局部性，只要通過合理的設計提高TLB的命中率(通常可以達到90%以上)，就能達到很好的效果。　

四. 80386分頁機制下的內存尋址流程

　　下面總結一下開啟了分頁機制的80386是如何進行內存尋址的。

　　1. CPU首先從內存訪問指令中獲取段選擇子和段內偏移地址

　　2. 根據段選擇子從段表(GDT或LDT)中查詢出對應的段描述符

　　3. 根據段描述符中的段基址和指令中的段內偏移地址生成32位的線性地址(頁機制下的虛擬地址)

　　4. 32位的線性地址根據80386二級頁表的設計，拆分成三個部分：高10位作為頁目錄項索引，中間次高10位作為頁表項索引，低12位作為頁內偏移地址。

　　5. 通過高10位的頁目錄項索引從一級頁目錄表中獲取二級頁表的物理頁地址(通過物理頁框號可得)，再根據中間10位的頁表項索引找到對應的物理頁框。根據物理頁框號與頁內偏移地址共同生成最終的物理地址，進行物理內存的訪問。

五. 總結

　　想要通過學習操作系統來更好的理解計算機程序底層的工作原理，基礎的硬件知識是必須要了解的。紙上得來終覺淺，絕知此事要躬行，在理解了基礎原理后，還需要通過實踐來加深對原理知識的理解，而閱讀相關操作系統的實現源碼就是一個很好的將實踐與原理緊密結合的學習方式。

　　希望通過對硬件和操作系統的學習能幫助我打開計算機程序底層運行的神秘黑盒子一窺究竟，在思考問題時能夠換一個角度從底層的視角出發，去更好的理解和掌握上層的應用技術，以避免迷失在快速發展的技術浪潮中。

 　　

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

※聚甘新

　　Hello 大家好，我是TANZAME，我們又見面了。今天我們來聊聊怎麼手擼一個 Redis Cluster 集群客戶端，純手工有乾貨，您細品。

　　隨着業務增長，線上環境的QPS暴增，自然而然將當前的單機 Redis 切換到群集模式。燃鵝，我們悲劇地發現，ServiceStack.Redis這個官方推薦的 .NET 客戶端並沒有支持集群模式。一通度娘翻牆無果后，決定自己強擼一個基於ServiceStack.Redis的Redis集群訪問組件。

　　話不多說，先上運行效果圖：

 

　　Redis-Cluster集群使用 hash slot 算法對每個key計算CRC16值，然後對16383取模，可以獲取key對應的 hash slot。Redis-Cluster中每個master都會持有部分 slot，在訪問key時根據計算出來的hash slot去找到具體的master節點，再由當前找到的節點去執行具體的 Redis 命令（具體可查閱官方說明文檔）。

　　由於 ServiceStack.Redis已經實現了單個實例的Redis命令，因此我們可以將即將要實現的 Redis 集群客戶端當做一個代理，它只負責計算 key 落在哪一個具體節點（尋址）然後將Redis命令轉發給對應的節點執行即可。

　　ServiceStack.Redis的RedisClient是非線程安全的，ServiceStack.Redis 使用緩存客戶端管理器（PooledRedisClientManager）來提高性能和併發能力，我們的Redis Cluster集群客戶端也應集成PooledRedisClientManager來獲取 RedisClient 實例。

　　同時，Redis-Cluster集群支持在線動態擴容和slot遷移，我們的Redis集群客戶端也應具備自動智能發現新節點和自動刷新 slot 分佈的能力。

　　總結起來，要實現一個Redis-Cluster客戶端，需要實現以下幾個要點：

• 根據 key 計算 hash slot
• 自動讀取群集上所有的節點信息
• 為節點分配緩存客戶端管理器
• 將 hash slot 路由到正確的節點
• 自動發現新節點和自動刷新slot分佈

　　如下面類圖所示，接下來我們詳細分析具體的代碼實現。

　　

　　一、CRC16 　

　　CRC即循環冗餘校驗碼，是信息系統中一種常見的檢錯碼。CRC校驗碼不同的機構有不同的標準，這裏Redis遵循的標準是CRC-16-CCITT標準，這也是被XMODEM協議使用的CRC標準，所以也常用XMODEM CRC代指，是比較經典的“基於字節查表法的CRC校驗碼生成算法”。 

 1 /// <summary>
 2 /// 根據 key 計算對應的哈希槽
 3 /// </summary>
 4 public static int GetSlot(string key)
 5 {
 6     key = CRC16.ExtractHashTag(key);
 7     // optimization with modulo operator with power of 2 equivalent to getCRC16(key) % 16384
 8     return GetCRC16(key) & (16384 - 1);
 9 }
10 
11 /// <summary>
12 /// 計算給定字節組的 crc16 檢驗碼
13 /// </summary>
14 public static int GetCRC16(byte[] bytes, int s, int e)
15 {
16     int crc = 0x0000;
17 
18     for (int i = s; i < e; i++)
19     {
20         crc = ((crc << 8) ^ LOOKUP_TABLE[((crc >> 8) ^ (bytes[i] & 0xFF)) & 0xFF]);
21     }
22     return crc & 0xFFFF;
23 }

 

　　二、讀取集群節點

　　從集群中的任意節點使用 CLUSTER NODES 命令可以讀取到集群中所有的節點信息，包括連接狀態，它們的標誌，屬性和分配的槽等等。CLUSTER NODES 以串行格式提供所有這些信息，輸出示例：

d99b65a25ef726c64c565901e345f98c496a1a47 127.0.0.1:7007 master - 0 1592288083308 8 connected
2d71879d6529d1edbfeed546443051986245c58e 127.0.0.1:7003 master - 0 1592288084311 11 connected 10923-16383
654cdc25a5fa11bd44b5b716cdf07d4ce176efcd 127.0.0.1:7005 slave 484e73948d8aacd8327bf90b89469b52bff464c5 0 1592288085313 10 connected
ed65d52dad7ef6854e0e261433b56a551e5e11cb 127.0.0.1:7004 slave 754d0ec7a7f5c7765f784a6a2c370ea38ea0c089 0 1592288081304 9 connected
754d0ec7a7f5c7765f784a6a2c370ea38ea0c089 127.0.0.1:7001 master - 0 1592288080300 9 connected 0-5460
484e73948d8aacd8327bf90b89469b52bff464c5 127.0.0.1:7002 master - 0 1592288082306 10 connected 5461-10922
2223bc6d099bd9838e5d2f1fbd9a758f64c554c4 127.0.0.1:7006 myself,slave 2d71879d6529d1edbfeed546443051986245c58e 0 0 6 connected

　　每個字段的含義如下：

　　1. id：節點 ID，一個40個字符的隨機字符串，當一個節點被創建時不會再發生變化（除非CLUSTER RESET HARD被使用）。

　　2. ip:port：客戶端應該聯繫節點以運行查詢的節點地址。

　　3. flags：逗號列表分隔的標誌：myself，master，slave，fail?，fail，handshake，noaddr，noflags。標誌在下一節詳細解釋。

　　4. master：如果節點是從屬節點，並且主節點已知，則節點ID為主節點，否則為“ – ”字符。

　　5. ping-sent：以毫秒為單位的當前激活的ping發送的unix時間，如果沒有掛起的ping，則為零。

　　6. pong-recv：毫秒 unix 時間收到最後一個乒乓球。

　　7. config-epoch：當前節點（或當前主節點，如果該節點是從節點）的配置時期（或版本）。每次發生故障切換時，都會創建一個新的，唯一的，單調遞增的配置時期。如果多個節點聲稱服務於相同的哈希槽，則具有較高配置時期的節點將獲勝。

　　8. link-state：用於節點到節點集群總線的鏈路狀態。我們使用此鏈接與節點進行通信。可以是connected或disconnected。

　　9. slot：散列槽號或範圍。從參數9開始，但總共可能有16384個條目（限制從未達到）。這是此節點提供的散列槽列表。如果條目僅僅是一個数字，則被解析為這樣。如果它是一個範圍，它是在形式start-end，並且意味着節點負責所有散列時隙從start到end包括起始和結束值。

標誌的含義（字段編號3）：

• myself：您正在聯繫的節點。

• master：節點是主人。

• slave：節點是從屬的。

• fail?：節點處於PFAIL狀態。對於正在聯繫的節點無法訪問，但仍然可以在邏輯上訪問（不處於FAIL狀態）。

• fail：節點處於FAIL狀態。對於將PFAIL狀態提升為FAIL的多個節點而言，這是無法訪問的。

• handshake：不受信任的節點，我們握手。

• noaddr：此節點沒有已知的地址。

• noflags：根本沒有標誌。

  1 // 讀取集群上的節點信息
  2 static IList<InternalClusterNode> ReadClusterNodes(IEnumerable<ClusterNode> source)
  3 {
  4     RedisClient c = null;
  5     StringReader reader = null;
  6     IList<InternalClusterNode> result = null;
  7 
  8     int index = 0;
  9     int rowCount = source.Count();
 10 
 11     foreach (var node in source)
 12     {
 13         try
 14         {
 15             // 從當前節點讀取REDIS集群節點信息
 16             index += 1;
 17             c = new RedisClient(node.Host, node.Port, node.Password);
 18             RedisData data = c.RawCommand("CLUSTER".ToUtf8Bytes(), "NODES".ToUtf8Bytes());
 19             string info = Encoding.UTF8.GetString(data.Data);
 20 
 21             // 將讀回的字符文本轉成強類型節點實體
 22             reader = new StringReader(info);
 23             string line = reader.ReadLine();
 24             while (line != null)
 25             {
 26                 if (result == null) result = new List<InternalClusterNode>();
 27                 InternalClusterNode n = InternalClusterNode.Parse(line);
 28                 n.Password = node.Password;
 29                 result.Add(n);
 30 
 31                 line = reader.ReadLine();
 32             }
 33 
 34             // 只要任意一個節點拿到集群信息，直接退出
 35             if (result != null && result.Count > 0) break;
 36         }
 37         catch (Exception ex)
 38         {
 39             // 出現異常，如果還沒到最後一個節點，則繼續使用下一下節點讀取集群信息
 40             // 否則拋出異常
 41             if (index < rowCount)
 42                 Thread.Sleep(100);
 43             else
 44                 throw new RedisClusterException(ex.Message, c != null ? c.GetHostString() : string.Empty, ex);
 45         }
 46         finally
 47         {
 48             if (reader != null) reader.Dispose();
 49             if (c != null) c.Dispose();
 50         }
 51     }
 52 
 53 
 54     if (result == null)
 55         result = new List<InternalClusterNode>(0);
 56     return result;
 57 }
 58 
 59 /// <summary>
 60 /// 從 cluster nodes 的每一行命令里讀取出集群節點的相關信息
 61 /// </summary>
 62 /// <param name="line">集群命令</param>
 63 /// <returns></returns>
 64 public static InternalClusterNode Parse(string line)
 65 {
 66     if (string.IsNullOrEmpty(line))
 67         throw new ArgumentException("line");
 68 
 69     InternalClusterNode node = new InternalClusterNode();
 70     node._nodeDescription = line;
 71     string[] segs = line.Split(' ');
 72 
 73     node.NodeId = segs[0];
 74     node.Host = segs[1].Split(':')[0];
 75     node.Port = int.Parse(segs[1].Split(':')[1]);
 76     node.MasterNodeId = segs[3] == "-" ? null : segs[3];
 77     node.PingSent = long.Parse(segs[4]);
 78     node.PongRecv = long.Parse(segs[5]);
 79     node.ConfigEpoch = int.Parse(segs[6]);
 80     node.LinkState = segs[7];
 81 
 82     string[] flags = segs[2].Split(',');
 83     node.IsMater = flags[0] == MYSELF ? flags[1] == MASTER : flags[0] == MASTER;
 84     node.IsSlave = !node.IsMater;
 85     int start = 0;
 86     if (flags[start] == MYSELF)
 87         start = 1;
 88     if (flags[start] == SLAVE || flags[start] == MASTER)
 89         start += 1;
 90     node.NodeFlag = string.Join(",", flags.Skip(start));
 91 
 92     if (segs.Length > 8)
 93     {
 94         string[] slots = segs[8].Split('-');
 95         node.Slot.Start = int.Parse(slots[0]);
 96         if (slots.Length > 1) node.Slot.End = int.Parse(slots[1]);
 97 
 98         for (int index = 9; index < segs.Length; index++)
 99         {
100             if (node.RestSlots == null)
101                 node.RestSlots = new List<HashSlot>();
102 
103             slots = segs[index].Split('-');
104 
105             int s1 = 0;
106             int s2 = 0;
107             bool b1 = int.TryParse(slots[0], out s1);
108             bool b2 = int.TryParse(slots[1], out s2);
109             if (!b1 || !b2)
110                 continue;
111             else
112                 node.RestSlots.Add(new HashSlot(s1, slots.Length > 1 ? new Nullable<int>(s2) : null));
113         }
114     }
115 
116     return node;
117 }

View Code

 

　　三、為節點分配緩存客戶端管理器

　　在單實例的Redis中，我們通過 PooledRedisClientManager 這個管理器來獲取RedisClient。借鑒這個思路，在Redis Cluster集群中，我們為每一個主節點實例化一個 PooledRedisClientManager，並且該主節點持有的 slot 都共享一個 PooledRedisClientManager 實例。以 slot 做為 key 將 slot 與 PooledRedisClientManager 一一映射並緩存起來。

 1 // 初始化集群管理
 2 void Initialize(IList<InternalClusterNode> clusterNodes = null)
 3 {
 4     // 從 redis 讀取集群信息
 5     IList<InternalClusterNode> nodes = clusterNodes == null ? RedisCluster.ReadClusterNodes(_source) : clusterNodes;
 6 
 7     // 生成主節點，每個主節點的 slot 對應一個REDIS客戶端緩衝池管理器
 8     IList<InternalClusterNode> masters = null;
 9     IDictionary<int, PooledRedisClientManager> managers = null;
10     foreach (var n in nodes)
11     {
12         // 節點無效或者
13         if (!(n.IsMater &&
14             !string.IsNullOrEmpty(n.Host) &&
15             string.IsNullOrEmpty(n.NodeFlag) &&
16             (string.IsNullOrEmpty(n.LinkState) || n.LinkState == InternalClusterNode.CONNECTED))) continue;
17 
18         n.SlaveNodes = nodes.Where(x => x.MasterNodeId == n.NodeId);
19         if (masters == null)
20             masters = new List<InternalClusterNode>();
21         masters.Add(n);
22 
23         // 用每一個主節點的哈希槽做鍵，導入REDIS客戶端緩衝池管理器
24         // 然後，方法表指針（又名類型對象指針）上場，佔據 4 個字節。 4 * 16384 / 1024 = 64KB
25         if (managers == null)
26             managers = new Dictionary<int, PooledRedisClientManager>();
27 
28         string[] writeHosts = new[] { n.HostString };
29         string[] readHosts = n.SlaveNodes.Where(n => false).Select(n => n.HostString).ToArray();
30         var pool = new PooledRedisClientManager(writeHosts, readHosts, _config);
31         managers.Add(n.Slot.Start, pool);
32         if (n.Slot.End != null)
33         {
34             // 這個範圍內的哈希槽都用同一個緩衝池
35             for (int s = n.Slot.Start + 1; s <= n.Slot.End.Value; s++)
36                 managers.Add(s, pool);
37         }
38         if (n.RestSlots != null)
39         {
40             foreach (var slot in n.RestSlots)
41             {
42                 managers.Add(slot.Start, pool);
43                 if (slot.End != null)
44                 {
45                     // 這個範圍內的哈希槽都用同一個緩衝池
46                     for (int s = slot.Start + 1; s <= slot.End.Value; s++)
47                         managers.Add(s, pool);
48                 }
49             }
50         }
51     }
52 
53     _masters = masters;
54     _redisClientManagers = managers;
55     _clusterNodes = nodes != null ? nodes : null;
56 
57     if (_masters == null) _masters = new List<InternalClusterNode>(0);
58     if (_clusterNodes == null) _clusterNodes = new List<InternalClusterNode>(0);
59     if (_redisClientManagers == null) _redisClientManagers = new Dictionary<int, PooledRedisClientManager>(0);
60 
61     if (_masters.Count > 0)
62         _source = _masters.Select(n => new ClusterNode(n.Host, n.Port, n.Password)).ToList();
63 }

View Code

 

　　四、將 hash slot 路由到正確的節點

　　在訪問一個 key 時，根據第三步緩存起來的 PooledRedisClientManager ，用 key 計算出來的 hash slot 值可以快速找出這個 key 對應的 PooledRedisClientManager 實例，調用 PooledRedisClientManager.GetClient() 即可將 hash slot 路由到正確的主節點。

 1 // 執行指定動作並返回值
 2 private T DoExecute<T>(string key, Func<RedisClient, T> action) => this.DoExecute(() => this.GetRedisClient(key), action);
 3 
 4 // 執行指定動作並返回值
 5 private T DoExecute<T>(Func<RedisClient> slot, Func<RedisClient, T> action, int tryTimes = 1)
 6 {
 7     RedisClient c = null;
 8     try
 9     {
10         c = slot();
11         return action(c);
12     }
13     catch (Exception ex)
14     {
15         // 此處省略 ...
16     }
17     finally
18     {
19         if (c != null)
20             c.Dispose();
21     }
22 }
23 
24 // 獲取指定key對應的主設備節點
25 private RedisClient GetRedisClient(string key)
26 {
27     if (string.IsNullOrEmpty(key))
28         throw new ArgumentNullException("key");
29 
30     int slot = CRC16.GetSlot(key);
31     if (!_redisClientManagers.ContainsKey(slot))
32         throw new SlotNotFoundException(string.Format("No reachable node in cluster for slot {{{0}}}", slot), slot, key);
33 
34     var pool = _redisClientManagers[slot];
35     return (RedisClient)pool.GetClient();
36 }

 　　

　　五、自動發現新節點和自動刷新slot分佈

　　在實際生產環境中，Redis 集群經常會有添加/刪除節點、遷移 slot 、主節點宕機從節點轉主節點等，針對這些情況，我們的 Redis Cluster 組件必須具備自動發現節點和刷新在 第三步  緩存起來的 slot 的能力。在這裏我的實現思路是當節點執行 Redis 命令時返回 RedisException 異常時就強制刷新集群節點信息並重新緩存 slot 與 節點之間的映射。

  1 // 執行指定動作並返回值
  2 private T DoExecute<T>(Func<RedisClient> slot, Func<RedisClient, T> action, int tryTimes = 1)
  3 {
  4     RedisClient c = null;
  5     try
  6     {
  7         c = slot();
  8         return action(c);
  9     }
 10     catch (Exception ex)
 11     {
 12         if (!(ex is RedisException) || tryTimes == 0) throw new RedisClusterException(ex.Message, c != null ? c.GetHostString() : string.Empty, ex);
 13         else
 14         {
 15             tryTimes -= 1;
 16             // 嘗試重新刷新集群信息
 17             bool isRefresh = DiscoveryNodes(_source, _config);
 18             if (isRefresh)
 19                 // 集群節點有更新過，重新執行
 20                 return this.DoExecute(slot, action, tryTimes);
 21             else
 22                 // 集群節點未更新過，直接拋出異常
 23                 throw new RedisClusterException(ex.Message, c != null ? c.GetHostString() : string.Empty, ex);
 24         }
 25     }
 26     finally
 27     {
 28         if (c != null)
 29             c.Dispose();
 30     }
 31 }
 32 
 33 // 重新刷新集群信息
 34 private bool DiscoveryNodes(IEnumerable<ClusterNode> source, RedisClientManagerConfig config)
 35 {
 36     bool lockTaken = false;
 37     try
 38     {
 39         // noop
 40         if (_isDiscoverying) { }
 41 
 42         Monitor.Enter(_objLock, ref lockTaken);
 43 
 44         _source = source;
 45         _config = config;
 46         _isDiscoverying = true;
 47 
 48         // 跟上次同步時間相隔 {MONITORINTERVAL} 秒鐘以上才需要同步
 49         if ((DateTime.Now - _lastDiscoveryTime).TotalMilliseconds >= MONITORINTERVAL)
 50         {
 51             bool isRefresh = false;
 52             IList<InternalClusterNode> newNodes = RedisCluster.ReadClusterNodes(_source);
 53             foreach (var node in newNodes)
 54             {
 55                 var n = _clusterNodes.FirstOrDefault(x => x.HostString == node.HostString);
 56                 isRefresh =
 57                     n == null ||                        // 新節點                                                                
 58                     n.Password != node.Password ||      // 密碼變了                                                                
 59                     n.IsMater != node.IsMater ||        // 主變從或者從變主                                                                
 60                     n.IsSlave != node.IsSlave ||        // 主變從或者從變主                                                                
 61                     n.NodeFlag != node.NodeFlag ||      // 節點標記位變了                                                                
 62                     n.LinkState != node.LinkState ||    // 節點狀態位變了                                                                
 63                     n.Slot.Start != node.Slot.Start ||  // 哈希槽變了                                                                
 64                     n.Slot.End != node.Slot.End ||      // 哈希槽變了
 65                     (n.RestSlots == null && node.RestSlots != null) ||
 66                     (n.RestSlots != null && node.RestSlots == null);
 67                 if (!isRefresh && n.RestSlots != null && node.RestSlots != null)
 68                 {
 69                     var slots1 = n.RestSlots.OrderBy(x => x.Start).ToList();
 70                     var slots2 = node.RestSlots.OrderBy(x => x.Start).ToList();
 71                     for (int index = 0; index < slots1.Count; index++)
 72                     {
 73                         isRefresh =
 74                             slots1[index].Start != slots2[index].Start ||   // 哈希槽變了                                                                
 75                             slots1[index].End != slots2[index].End;         // 哈希槽變了
 76                         if (isRefresh) break;
 77                     }
 78                 }
 79 
 80                 if (isRefresh) break;
 81             }
 82 
 83             if (isRefresh)
 84             {
 85                 // 重新初始化集群
 86                 this.Dispose();
 87                 this.Initialize(newNodes);
 88                 this._lastDiscoveryTime = DateTime.Now;
 89             }
 90         }
 91 
 92         // 最後刷新時間在 {MONITORINTERVAL} 內，表示是最新群集信息 newest
 93         return (DateTime.Now - _lastDiscoveryTime).TotalMilliseconds < MONITORINTERVAL;
 94     }
 95     finally
 96     {
 97         if (lockTaken)
 98         {
 99             _isDiscoverying = false;
100             Monitor.Exit(_objLock);
101         }
102     }
103 }

View Code

 

　　六、配置訪問組件調用入口

　　最後我們需要為組件提供訪問入口，我們用 RedisCluster 類實現 字符串、列表、哈希、集合、有序集合和Keys的基本操作，並且用 RedisClusterFactory 工廠類對外提供單例操作，這樣就可以像單實例 Redis 那樣調用 Redis Cluster 集群。調用示例：

var node = new ClusterNode("127.0.0.1", 7001);
var redisCluster = RedisClusterFactory.Configure(node, config);
string key = "B070x14668";
redisCluster.Set(key, key);
string value = redisCluster.Get<string>(key);
redisCluster.Del(key);

 1 /// <summary>
 2 /// REDIS 集群工廠
 3 /// </summary>
 4 public class RedisClusterFactory
 5 {
 6     static RedisClusterFactory _factory = new RedisClusterFactory();
 7     static RedisCluster _cluster = null;
 8 
 9     /// <summary>
10     /// Redis 集群
11     /// </summary>
12     public static RedisCluster Cluster
13     {
14         get
15         {
16             if (_cluster == null)
17                 throw new Exception("You should call RedisClusterFactory.Configure to config cluster first.");
18             else
19                 return _cluster;
20         }
21     }
22 
23     /// <summary>
24     /// 初始化 <see cref="RedisClusterFactory"/> 類的新實例
25     /// </summary>
26     private RedisClusterFactory()
27     {
28     }
29 
30     /// <summary>
31     /// 配置 REDIS 集群
32     /// <para>若群集中有指定 password 的節點，必須使用  IEnumerable&lt;ClusterNode&gt; 重載列舉出這些節點</para>
33     /// </summary>
34     /// <param name="node">集群節點</param>
35     /// <returns></returns>
36     public static RedisCluster Configure(ClusterNode node)
37     {
38         return RedisClusterFactory.Configure(node, null);
39     }
40 
41     /// <summary>
42     /// 配置 REDIS 集群
43     /// <para>若群集中有指定 password 的節點，必須使用  IEnumerable&lt;ClusterNode&gt; 重載列舉出這些節點</para>
44     /// </summary>
45     /// <param name="node">集群節點</param>
46     /// <param name="config"><see cref="RedisClientManagerConfig"/> 客戶端緩衝池配置</param>
47     /// <returns></returns>
48     public static RedisCluster Configure(ClusterNode node, RedisClientManagerConfig config)
49     {
50         return RedisClusterFactory.Configure(new List<ClusterNode> { node }, config);
51     }
52 
53     /// <summary>
54     /// 配置 REDIS 集群
55     /// </summary>
56     /// <param name="nodes">集群節點</param>
57     /// <param name="config"><see cref="RedisClientManagerConfig"/> 客戶端緩衝池配置</param>
58     /// <returns></returns>
59     public static RedisCluster Configure(IEnumerable<ClusterNode> nodes, RedisClientManagerConfig config)
60     {
61         if (nodes == null)
62             throw new ArgumentNullException("nodes");
63 
64         if (nodes == null || nodes.Count() == 0)
65             throw new ArgumentException("There is no nodes to configure cluster.");
66 
67         if (_cluster == null)
68         {
69             lock (_factory)
70             {
71                 if (_cluster == null)
72                 {
73                     RedisCluster c = new RedisCluster(nodes, config);
74                     _cluster = c;
75                 }
76             }
77         }
78 
79         return _cluster;
80     }
81 }

View Code

 

　　總結

　　今天我們詳細介紹了如何從0手寫一個Redis Cluster集群客戶端訪問組件，相信對同樣在尋找類似解決方案的同學們會有一定的啟發，喜歡的同學請點個 star。在沒有相同案例可以參考的情況下筆者通過查閱官方說明文檔和借鑒 Java 的 JedisCluster 的實現思路，雖說磕磕碰碰但最終也初步完成這個組件並投入使用，必須給自己加一個雞腿！！在此我有一個小小的疑問，.NET 的同學們在用 Redis 集群時，你們是用什麼組件耍的，為何網上的相關介紹和現成組件幾乎都沒有？歡迎討論。

　　GitHub 代碼託管：https://github.com/TANZAME/ServiceStack.Redis.Cluster

　　技術交流 QQ 群：816425449

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧

※聚甘新

為了搶攻Tesla帶來的電動車商機，和大工業(1536)董事會昨(14)日通過提前啟動嘉義大埔美二期廠建廠計畫，將打造特斯拉專廠，預定將在2018年8月全面投產；同時和大也通過將辦理現金增資20億元，以因應擴產資金需求。

(Photo Credit:和大工業)

為加速大埔美二期廠建設，和大董事會通過斥資4.27億元，向同集團的高鋒工業(4510)購買緊鄰和大大埔美一期廠的土地廠房，並將斥資12億元，採購4條工業4.0的智能化產線設備。待新產能開出後，公司預期大埔美廠未來將貢獻和大半數產值，也有助於提前達成年營收百億元目標。

而為了因應產能擴張的資金需求，和大董事會也決議將辦理現金增資，預計發行2,000萬股新股，每股面額10元，暫定每股100元溢價發行，總計將籌募20億元資金。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

※聚甘新

電動車新創公司「法拉第未來」（Faraday Future）履行年前承諾，在美國拉斯維加斯舉辦的CES 2017展會上正式推出旗下首款電動車──FF91，即日起接受預約。

樂視控股創辦人暨董事長賈躍亭個人投資法拉第未來超過3億美金，使法拉第未來的電動車被各界暱稱為「樂視電動車」。他於去年12月11日在北京公開，片中直接挑戰特斯拉（Tesla）、法拉利（Ferrari）以及賓利（Bentley）等超跑與電動車龍頭。賈躍亭也同時表示，法拉第未來將在CES 2017正式推出旗下新車。

美西時間1月4日，法拉第未來正式發表首輛量產型電動車FF91。FF91號稱馬力達1,050匹，0~60英里加速僅需2.39秒，比競爭目標Tesla Model S P100D 極速模式下的加速時間2.5秒還短。電池充飽電後，FF91的行駛距離可達378英里（約608公里），足以從矽谷開到洛杉磯。這些規格都凌駕於特斯拉的車款之上。

法拉第未來的工程部門副總裁Peter Savagian在CES 2017的發表會上表示，FF91還將搭配個人化操作介面，也有自動尋找停車位的功能。FF91即日起開放預約，訂金5,000美元，預計在2018年開始交車。不過，法拉第未來並未公布FF91的定價。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

※聚甘新

福特汽車（Ford Motor） 執行長Mark Fields 1月5日投下震撼彈，宣布取消墨西哥設廠計畫，回到美國投資，增加700 個工作機會，市場第一個反應是川普效應，直指福特汽車收起選舉期間與川普的砲火，向權力低頭。但事實上，福特汽車回美國並非為了川普，而是著眼於未來汽車所需要的科技發展，以及自動化考量。

華盛頓郵報（Washington Post） 報導，福特汽車在美國密西哥州Flat Rock 的工廠未來將以生產自動駕駛汽車與電動車為主，需要具有電腦能力以及高中以上學歷的勞工。新的雇用機會，被視為是進入中產階級的門票，已經與過去截然不同。

經濟學家表示，汽車製造以及其他製造業會逐漸增加自動化，需要的人力更少，且都是較高技術性勞工。雖然福特執行長與川普互相讚揚彼此，聲稱是為了保護美國人的工作，但分析師認為，福特回美計畫是基於長遠的目標，而不是奉獻給美國政府與勞工。

福特計劃在2020 年前在電動車領域投資45 億美元，認為未來10 年消費者對電動車的接受度會大幅改變，現在福特在密西根州Dearborn 工廠的工程師就擔負創造模型的工作，他們工作的地點距離Flat Rock 的組裝廠只有20 英里 ，若把組裝廠移到墨西哥的話，會增加研發與製造工作的溝通難度。

汽車研究中心分析師表示，「至少對第一代產品來說，將新科技留在工程師身邊是很重要的事，讓工程師可以掌握與監控系統運作。」福特在密西根的擴廠計畫符合大趨勢走向，而勞工要確保工作機會，必須不斷的學習，分析師說，「現在已經不像以前，擁有一個技術就可以做40 年。」

華盛頓智庫Brookings Institution 研究員也表示，在美國比在墨西哥更容易找到技術勞工。墨西哥提供的勞力是低成本、堪用的勞力，但不適合創新含量高或做新產品開發。福特會保留汽油引擎的Focus 在墨西哥工廠製造。福特執行長也說，他們取消在墨西哥16 億美元的建廠計畫，最主要的原因是小型車的需求愈來愈低。

看來川普喜歡往自己臉上貼金，但生意人算盤打得更精，表面上的花言巧語只是一場政治秀罷了。

（合作媒體：。圖：福特汽車位於密西根的總部 Glass House。）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧

※聚甘新