問題
1、10萬+大數據處理方式、套用場景。
2、redis在計畫中如何使用。
3、訊息佇列使用的四種場景介紹。
4、redis緩存穿透、緩存擊穿、緩存雪崩原因+解決方案。
5、單列模式使用場景。
6、什麽是死結？死結產生的原因？如何避免死結？
7、ElasticSearch使用場景。
8、TiDB使用場景。
9、Redis的優點
支持多種數據結構，如 string（字串）、 list(雙向連結串列)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基數估算）
每個型別使用的場景
10、各個索引套用場景
11、B+樹為什麽快
12、二元樹尋找法。
13、訊息佇列Kafka、RocketMQ、RabbitMQ的優劣勢比較和使用場景
14、redis集群的方式
redis有三種集群方式：主從復制，哨兵模式和集群。
1、主從復制
主從復制原理
從伺服器連線主伺服器，發送SYNC命令；
主伺服器接收到SYNC命名後，開始執行BGSAVE命令生成RDB檔並使用緩沖區記錄此後執行的所有寫命令；
主伺服器BGSAVE執行完後，向所有從伺服器發送快照檔，並在發送期間繼續記錄被執行的寫命令；
從伺服器收到快照檔後丟棄所有舊數據，載入收到的快照；
主伺服器快照發送完畢後開始向從伺服器發送緩沖區中的寫命令；
從伺服器完成對快照的載入，開始接收命令請求，並執行來自主伺服器緩沖區的寫命令（ 從伺服器初始化完成 ）
主伺服器每執行一個寫命令就會向從伺服器發送相同的寫命令，從伺服器接收並執行收到的寫命令（ 從伺服器初始化完成後的操作 ）
主從復制優缺點
優點
支持主從復制，主機會自動將數據同步到從機，可以進行讀寫分離
為了分載Master的讀操作壓力，Slave伺服器可以為客戶端提供唯讀操作的服務，寫服務仍然必須由Master來完成
Slave同樣可以接受其它Slaves的連線和同步請求，這樣可以有效的分載Master的同步壓力。
Master Server是以非阻塞的方式為Slaves提供服務。所以在Master-Slave同步期間，客戶端仍然可以送出查詢或修改請求。
Slave Server同樣是以非阻塞的方式完成數據同步。在同步期間，如果有客戶端送出查詢請求，Redis則返回同步之前的數據
缺點
Redis不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部份讀寫請求失敗，需要等待機器重新開機或者手動切換前端的IP才能恢復。
主機宕機，宕機前有部份數據未能及時同步到從機，切換IP後還會引入數據不一致的問題，降低了系統的可用性。
Redis較難支持線上擴容，在集群容量達到上限時線上擴容會變得很復雜。
2、哨兵模式
當主伺服器中斷服務後，可以將一個從伺服器升級為主伺服器，以便繼續提供服務，但是這個過程需要人工手動來操作。 為此，Redis 2.8中提供了哨兵工具來實作自動化的系統監控和故障恢復功能。
哨兵的作用就是監控Redis系統的執行狀況。它的功能包括以下兩個。
1、監控主伺服器和從伺服器是否正常執行。
2、主伺服器出現故障時自動將從伺服器轉換為主伺服器。
哨兵的工作方式
每個Sentinel（哨兵）行程以每秒鐘一次的頻率向整個集群中的Master主伺服器，Slave從伺服器以及其他Sentinel（哨兵）行程發送一個 PING 命令。
如果一個例項（instance）距離最後一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個例項會被 Sentinel（哨兵）行程標記為主觀下線（SDOWN）
如果一個Master主伺服器被標記為主觀下線（SDOWN），則正在監視這個Master主伺服器的所有 Sentinel（哨兵）行程要以每秒一次的頻率確認Master主伺服器的確進入了主觀下線狀態
當有足夠數量的 Sentinel（哨兵）行程（大於等於配置檔指定的值）在指定的時間範圍內確認Master主伺服器進入了主觀下線狀態（SDOWN）， 則Master主伺服器會被標記為客觀下線（ODOWN）
在一般情況下， 每個 Sentinel（哨兵）行程會以每 10 秒一次的頻率向集群中的所有Master主伺服器、Slave從伺服器發送 INFO 命令。
當Master主伺服器被 Sentinel（哨兵）行程標記為客觀下線（ODOWN）時，Sentinel（哨兵）行程向下線的 Master主伺服器的所有 Slave從伺服器發送 INFO 命令的頻率會從 10 秒一次改為每秒一次。
若沒有足夠數量的 Sentinel（哨兵）行程同意 Master主伺服器下線， Master主伺服器的客觀下線狀態就會被移除。若 Master主伺服器重新向 Sentinel（哨兵）行程發送 PING 命令返回有效回復，Master主伺服器的主觀下線狀態就會被移除。
哨兵模式的優缺點
優點
哨兵模式是基於主從模式的，所有主從的優點，哨兵模式都具有。
主從可以自動切換，系統更健壯，可用性更高。
缺點
Redis較難支持線上擴容，在集群容量達到上限時線上擴容會變得很復雜。
3、Redis-Cluster集群
redis的哨兵模式基本已經可以實作高可用，讀寫分離 ，但是在這種模式下每台redis伺服器都儲存相同的數據，很浪費記憶體，所以在redis3.0上加入了cluster模式，實作的redis的分布式儲存，也就是說每台redis節點上儲存不同的內容。
Redis-Cluster采用無中心結構,它的特點如下：
所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協定最佳化傳輸速度和頻寬。
節點的fail是透過集群中超過半數的節點檢測失效時才生效。
客戶端與redis節點直連,不需要中間代理層.客戶端不需要連線集群所有節點,連線集群中任何一個可用節點即可。
工作方式
在redis的每一個節點上，都有這麽兩個東西，一個是插槽（slot），它的的取值範圍是：0-16383。還有一個就是cluster，可以理解為是一個集群管理的外掛程式。
當我們的存取的key到達的時候，redis會根據crc16的演算法得出一個結果，然後把結果對 16384 求余數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，透過這個值，去找到對應的插槽所對應的節點，然後直接自動跳轉到這個對應的節點上進行存取操作。
為了保證高可用，redis-cluster集群引入了主從模式，一個主節點對應一個或者多個從節點，當主節點宕機的時候，就會啟用從節點。當其它主節點ping一個主節點A時，如果半數以上的主節點與A通訊超時，那麽認為主節點A宕機了。如果主節點A和它的從節點A1都宕機了，那麽該集群就無法再提供服務了。
15、如何在ASP.NET Core中啟用Session功能？
首先要添加session包. 其次要在configservice方法裏面添加session。
然後又在configure方法裏面呼叫usesession。
16、ASP.NET Core Filter如何支持依賴註入?
可以透過全域註冊，支持依賴註入
透過TypeFilter(typeof(Filter)) 標記在方法，標記在控制器
透過ServiceType(typeof(Filter))標記在方法，標記在控制器，必須要註冊Filter這類；
TypeFilter和ServiceType的本質是實作了一個IFilterFactory介面
17、ASP.NET Core 如何和讀取配置檔中的內容？
可以有兩種方式，可以透過IConfiguration介面來讀取；
有可以定義根據配置檔結構一致的實體物件，來繫結到物件中去；或者透過1寫入，2註入讀取
必須保證：DBConnectionOption和配置檔的內容結構一致；
services.Configure < DBConnectionOption > (Configuration.Getp("ConnectionStrings")); //註入多個連結
private DBConnectionOption dBConnections = null;
private DbContext _Context = null;
publicDbContextFactory(DbContext context, IOptions < DBConnectionOption > options)
{
_Context = context;
dBConnections = options.Value;
}
18、ASP.NET Core有哪些好的功能？
第一是依賴註入。
第二是日誌系統架構。
第三是引入了一個跨平台的網路伺服器，kestrel。可以沒有iis, apache和nginx就可以單獨執行。
第四是可以使用命令列建立套用。
第五是使用appsettings來配置工程。
第六是使用startup來註冊服務。
第七是更好的支持異步編程。
第八是支持web socket和signal IR。
第九是對於跨網站的請求的預防和保護機制
19、描述一下依賴註入後的服務生命周期?
在ASP.NET Core中，我們不需要關心如何釋放這些服務, 因為系統會幫我們釋放掉。有三種服務的生命
周期。
1、單例項服務， 透過add singleton方法來添加。在註冊時即建立服務, 在隨後的請求中都使用這一個服務。
2、短暫服務, 透過add transient方法來添加。是一種輕量級的服務，用於無狀態服務的操作。
3、作用域服務，一個新的請求會建立一個服務例項。使用add scoped方法來添加。
20、說說RESTful是什麽
在傳統的服務中，比方說WebService,WCF，Remouting，都是透過呼叫方法來做到一個行程去呼叫另外一個行程的服務，在Core WebApi中是把要呼叫的服務資源化，比方說有圖書資源，Books，學生資源Studentlist，每一個資源對應一個控制器，然後對外提供增刪改查等操作；
對外提供統一的Uri, 可以對資源Books，資源Studentlist做增刪改查的操作；存取的是資源，可以根據不同的額存取方式，做不同的事兒；
21、如何解決跨域問題？
三種方式
1、後台模擬Http請求，既然是瀏覽器的行為，就避開瀏覽器，先來一個同源的伺服器去請求，然後由伺服器模擬http請求去請求到Core WebApi的資源，然後響應給前端；
2、JSONP，思路：透過html部份標簽發起請求，比方說 等等，發起請求是可以避開同源策略的，使用這些標簽發起請求，然後帶有一個回呼函式，然後得到請求後，把回呼函式之心一次，把數據解析後使用；
3、伺服端允許跨域，多種方式，可以自己定義中介軟體支持跨域，只要把響應的Response的頭資訊Header中寫入"Access-Control-Allow-Origin"即可支持跨域；
如果需要讓所有的Api都支持跨域，就可以寫一個中介軟體從管道處理模型中去支持跨域，如果要選擇性的支持跨域，可以使用ActionFilter來完成，也可以透過Cors（ASP.NET Core中提供的中介軟體，可以支持配置不同的跨域規則）來配置支持跨域；
22、說說你了解到的鑒權授權技術
1、傳統的授權技術：透過Session、Cookie完成授權；
實作特點:
讓無狀態的http請求，變的有狀態，讓第一次請求和第二次請求之間產生聯系，第一次請求進入伺服器，在伺服器寫入一組session，然後返回sessionId給客戶端存在Cookie,第二次請求，從cookie中渠道SessionId,傳遞給伺服器，伺服器鑒別SessionId,如果是上一次來的SessionId,就認為之前來請求過；
就認為有許可權；
publicvoidConfigure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseSwagger();
app.UseSwaggerUI(c = >c.SwaggerEndpoint("/swagger/v1/swagger.json", "WebApplication1 v1"));
}
2、流行鑒權授權方式：
Token授權，在Core WebApi中主要就是JWT和IdentityServer4;
都是獨立的授權中心，授權後辦法token，然後客戶端帶著token去請求Api,Api方驗證Token，驗證透過就有許可權，驗證不透過就沒有許可權；
23、gRPC有幾種模式？
四種模式
1、簡單模式：簡單模式只是使用參數和返回值作為伺服器與客戶端傳遞數據的方式，最簡單。
2、客戶端流模式：即從客戶端往伺服器端發送數據使用的是流，即伺服器端的參數為流型別，然而在伺服器相應後返還數據給客戶端，使用的也是流的send方法。
一般在伺服器端的程式碼，需要先recv再send，而客戶端與此相反。但是在後面的雙向模式中可以使用go的協程協作。
3、伺服器端流模式：即伺服器端返回結果的時候使用的是流模式，即傳入的數據是透過參數形式傳入的。但是在往客戶端發送數據時使用send方法，與客戶端返回數據的方式大同小異。
4、雙向模式：客戶端如果不適用協程，那麽發送必須在接收之前。如果使用協程，發送與接收並沒有先後順序。為了保證協程的同步，可以使用互斥量進行約束。
24、談談對通訊加密解密的理解
加密解密分為：對稱可逆加密，非對稱可逆加密兩大類；
可逆加密：加密後得到密文，可以透過加密後的密文得到原文；
對稱可逆加密特點：
有一個公開的加密演算法，任何人都知道；
有一組Key，分為加密Key和解密Key，且兩個Key是相同的；
使用當前這個Key加密，可以得到一段密文；
同時如果這段密文想要得到原文，也必須得使用這個Key才能解密；
此類被稱為對稱可逆加密，效能很高，但是安全性較差；
只要是key被泄密了，密文就可以被攻破得到原文；
因為加密演算法是公開的；
非對稱可逆加密特點：
有一個公開的加密演算法，任何人都知道；同時有一對Key,這一組Key是成套的，兩個Key不相同，二者且不能相互推導；
一個Key作為加密Key，一個Key作為解密Key，且加密Key加密 後，只能由這個解密Key才能解開；
此類被稱為非對稱可逆加密；
在非對稱可逆加密的套用中，有一個公鑰和私鑰的概念；
公鑰：把其中的一個Key公開，
私鑰：把其中 的一個Key私有化；
那這樣就有一下場景：
1、公開加密Key，私有解密Key：
那麽任何一個擁有公開加密Key的人給我這個擁有私有解密Key的人發密文，我都能解開，且只有我能解開；
這樣就可以保證在通訊傳輸的時候，保證資訊的安全；
在傳輸的時候不會被泄密，因為就算在傳輸的過程中，密文被攔截了，也無法得到原文；
因為沒有這個解密Key，有密文是無法得到原文的；
2、公開解密Key,私有化加密Key:
那麽任何一個擁有解密Key的人都能夠接收到來自於我這個擁有加密Key的人發送的訊息，只要是我這個私有的加密Key加密後的密文，任何一個擁有解密Key的人都能夠解開密文得到原文；
那這樣就可以實作一個功能：防止抵賴，也就是說，如果我是有解密Key的人，我得到的密文只要能夠解開，那就說明這段密文一定是擁有加密Key的人發出來的；不然我是解不開這段密文的；
轉自：IT_ziliang
連結：blog.csdn.net/IT_ziliang/article/details/113184223
- EOF -
推薦閱讀 點選標題可跳轉
看完本文有收獲？請轉發分享給更多人
推薦關註「DotNet」，提升.Net技能
點贊和在看就是最大的支持❤️
