海康威視，開了體面的薪資!

程序員庫森

大家好，我是庫森。
5 q, L$ w2 j1 \; m9 ^/ g9 X�？低�視作為一家體面廠，我們來看看今年�？低�視的校招薪資開了多少？
我根據(jù)一些同學(xué)的反饋，整理了海康威視軟件開發(fā)崗位的校招薪資，在目前的就業(yè)背景下，海康威視的校招薪資還是很體面的。

14k x 15 = 21w（本科 985，武漢）

15k x 15 =  22.5w（碩士雙一流，杭州）

16 x 15 =  24w （本碩 211，杭州）

19 x 15 = 28.5w （本碩 211，杭州）那�？低�視的面試難度如何呢？
我也找了一位今年秋招面�？低�視同學(xué)的面經(jīng)，給大家做做參考參考，總共 1 輪技術(shù)面 + 1 輪 HR 面，3-5 個(gè)工作日出結(jié)果。
一面是技術(shù)面，問的問題不算多，主要拷打了 Java、MySQL、Redis 方面的八股文，都屬于經(jīng)典的面試問題，不算難。
  t# E' W) s, a2 d
" H% S- y1 L! R4 ZJava 介紹一下 Spring Boot 整體的啟動(dòng)流程？

首先從main找到run()方法，在執(zhí)行run()方法之前new一個(gè)SpringApplication對(duì)象

進(jìn)入run()方法，創(chuàng)建應(yīng)用監(jiān)聽器SpringApplicationRunListeners開始監(jiān)聽

然后加載SpringBoot配置環(huán)境(ConfigurableEnvironment)，然后把配置環(huán)境(Environment)加入監(jiān)聽對(duì)象中

然后加載應(yīng)用上下文(ConfigurableApplicationContext)，當(dāng)做run方法的返回對(duì)象

最后創(chuàng)建Spring容器，refreshContext(context)，實(shí)現(xiàn)starter自動(dòng)化配置和bean的實(shí)例化等工作。[/ol]說一說 Spring MVC 整體的執(zhí)行流程？
5 c, \9 A0 {! M+ z
流程圖步驟詳解：

發(fā)送請(qǐng)求：用戶發(fā)送的所有請(qǐng)求都會(huì)到前端控制器DispatcherServlet

請(qǐng)求查找Handler：DispatcherServlet收到請(qǐng)求會(huì)調(diào)用HandlerMapping（處理器映射器）查找Handler

返回Handler：處理器映射器根據(jù)url返回具體的處理器，生成HandlerExecutionChain對(duì)象，其中包含了目標(biāo)Handler和若干攔截器（可能沒有）

請(qǐng)求調(diào)用Handler：DispatcherServlet通過Handler尋找匹配到HandlerAdapter

執(zhí)行Handler：HandlerAdapter調(diào)用Handler

返回結(jié)果：Handler執(zhí)行完成，返回一個(gè)ModelAndView對(duì)象

返回結(jié)果給DispatcherServlet：HandlerAdapter將Handler執(zhí)行結(jié)果ModelAndView返回給DispatcherServlet

如果Handler返回的View是邏輯視圖名稱而不是真正的View對(duì)象，DispatcherServlet調(diào)用resolveViewName方法在配置的所有視圖解析器(ViewResolver)中，尋找合適的，最終通過ViewResolver將邏輯視圖名解析成真正的View對(duì)象

ViewResolver通過調(diào)用createView方法嘗試將視圖名解析成View，如果無法解析會(huì)返回Null(注: 如果ViewResolver是派生自AbstractCachingViewResolver則在調(diào)用createView方法前會(huì)先嘗試根據(jù)viewName和Iocale從緩存中查找對(duì)應(yīng)的視圖對(duì)象)

DispatcherServlet調(diào)用View的render方法進(jìn)行渲染視圖 (即將模型數(shù)據(jù)填充至request域)

DispatcherServlet響應(yīng)用戶[/ol]MySQL MySQL 索引的機(jī)制，類型有哪些？MySQL可以按照四個(gè)角度來分類索引。

按「數(shù)據(jù)結(jié)構(gòu)」分類：B+tree索引、Hash索引、Full-text索引。

按「物理存儲(chǔ)」分類：聚簇索引（主鍵索引）、二級(jí)索引（輔助索引）。

按「字段特性」分類：主鍵索引、唯一索引、普通索引、前綴索引。

按「字段個(gè)數(shù)」分類：單列索引、聯(lián)合索引。接下來，按照這些角度來說說各類索引的特點(diǎn)。
; }, H. a- A8 e6 x0 Q按數(shù)據(jù)結(jié)構(gòu)分類
從數(shù)據(jù)結(jié)構(gòu)的角度來看，MySQL 常見索引有 B+Tree 索引、HASH 索引、Full-Text 索引。
; m) q/ H9 F* q* @, u4 Q9 G每一種存儲(chǔ)引擎支持的索引類型不一定相同，我在表中總結(jié)了 MySQL 常見的存儲(chǔ)引擎 InnoDB、MyISAM 和 Memory 分別支持的索引類型。
- u5 O6 I! T1 {+ B1 o6 ~
# G  K' u4 \7 y' o3 O3 R! t6 mInnoDB 是在 MySQL 5.5 之后成為默認(rèn)的 MySQL 存儲(chǔ)引擎，B+Tree 索引類型也是 MySQL 存儲(chǔ)引擎采用最多的索引類型。
在創(chuàng)建表時(shí)，InnoDB 存儲(chǔ)引擎會(huì)根據(jù)不同的場(chǎng)景選擇不同的列作為索引：

如果有主鍵，默認(rèn)會(huì)使用主鍵作為聚簇索引的索引鍵（key）；

如果沒有主鍵，就選擇第一個(gè)不包含 NULL 值的唯一列作為聚簇索引的索引鍵（key）；

在上面兩個(gè)都沒有的情況下，InnoDB 將自動(dòng)生成一個(gè)隱式自增 id 列作為聚簇索引的索引鍵（key）；其它索引都屬于輔助索引（Secondary Index），也被稱為二級(jí)索引或非聚簇索引。創(chuàng)建的主鍵索引和二級(jí)索引默認(rèn)使用的是 B+Tree 索引。
按物理存儲(chǔ)分類
* C+ C6 W; I, L% C5 k" K: J' @從物理存儲(chǔ)的角度來看，索引分為聚簇索引（主鍵索引）、二級(jí)索引（輔助索引）。
/ r& p$ }6 A  n這兩個(gè)區(qū)別在前面也提到了：
% D! Y# }; C  i/ y4 `# w

主鍵索引的 B+Tree 的葉子節(jié)點(diǎn)存放的是實(shí)際數(shù)據(jù)，所有完整的用戶記錄都存放在主鍵索引的 B+Tree 的葉子節(jié)點(diǎn)里；

二級(jí)索引的 B+Tree 的葉子節(jié)點(diǎn)存放的是主鍵值，而不是實(shí)際數(shù)據(jù)。所以，在查詢時(shí)使用了二級(jí)索引，如果查詢的數(shù)據(jù)能在二級(jí)索引里查詢的到，那么就不需要回表，這個(gè)過程就是覆蓋索引。如果查詢的數(shù)據(jù)不在二級(jí)索引里，就會(huì)先檢索二級(jí)索引，找到對(duì)應(yīng)的葉子節(jié)點(diǎn)，獲取到主鍵值后，然后再檢索主鍵索引，就能查詢到數(shù)據(jù)了，這個(gè)過程就是回表。
0 H+ j8 k! \2 V& Y! r! `! h4 U7 U按字段特性分類
從字段特性的角度來看，索引分為主鍵索引、唯一索引、普通索引、前綴索引。

主鍵索引主鍵索引就是建立在主鍵字段上的索引，通常在創(chuàng)建表的時(shí)候一起創(chuàng)建，一張表最多只有一個(gè)主鍵索引，索引列的值不允許有空值。
+ f3 X7 I# }& T$ r0 ?$ q在創(chuàng)建表時(shí)，創(chuàng)建主鍵索引的方式如下：
CREATE TABLE table_name  (
  ....
  PRIMARY KEY (index_column_1) USING BTREE
# y5 I1 M9 f5 l4 F' Z: W);
, N0 u$ _, r# A  B& J

唯一索引唯一索引建立在 UNIQUE 字段上的索引，一張表可以有多個(gè)唯一索引，索引列的值必須唯一，但是允許有空值。
- j  {; G# O3 c( L* w4 f- s7 J5 c- \在創(chuàng)建表時(shí)，創(chuàng)建唯一索引的方式如下：
CREATE TABLE table_name  (
  ....
  UNIQUE KEY(index_column_1,index_column_2,...)
* q5 ]/ J0 }. p! h1 D);
建表后，如果要?jiǎng)?chuàng)建唯一索引，可以使用這面這條命令：
9 \: y% O: x; WCREATE UNIQUE INDEX index_name
9 {- H- R1 C- b/ W) E/ lON table_name(index_column_1,index_column_2,...);
. w, O# H( N- k6 c( J

普通索引普通索引就是建立在普通字段上的索引，既不要求字段為主鍵，也不要求字段為 UNIQUE。
$ x* |6 }9 ?* g9 i在創(chuàng)建表時(shí)，創(chuàng)建普通索引的方式如下：
CREATE TABLE table_name  (
+ \  C6 {* N7 d1 ^  ....
( u/ t7 j, Z( O$ X# q* k  INDEX(index_column_1,index_column_2,...)
);
" i4 Q5 j+ @3 n; V  o建表后，如果要?jiǎng)?chuàng)建普通索引，可以使用這面這條命令：
CREATE INDEX index_name
4 b# E2 o9 F# ], k3 [' I- ION table_name(index_column_1,index_column_2,...);

前綴索引前綴索引是指對(duì)字符類型字段的前幾個(gè)字符建立的索引，而不是在整個(gè)字段上建立的索引，前綴索引可以建立在字段類型為 char、 varchar、binary、varbinary 的列上。
使用前綴索引的目的是為了減少索引占用的存儲(chǔ)空間，提升查詢效率。
2 h& R2 B1 {3 U1 G2 `8 b& a4 q在創(chuàng)建表時(shí)，創(chuàng)建前綴索引的方式如下：
2 _' s* ?% ~) ~CREATE TABLE table_name(
    column_list,
& V; F1 H4 h, N" Y8 S$ {    INDEX(column_name(length))
);
建表后，如果要?jiǎng)?chuàng)建前綴索引，可以使用這面這條命令：
3 m( m8 g# {4 x, [3 z8 M: GCREATE INDEX index_name
ON table_name(column_name(length));
6 {. e5 J0 N& B5 J2 z1 a5 d/ U按字段個(gè)數(shù)分類
從字段個(gè)數(shù)的角度來看，索引分為單列索引、聯(lián)合索引（復(fù)合索引）。

建立在單列上的索引稱為單列索引，比如主鍵索引；

建立在多列上的索引稱為聯(lián)合索引；通過將多個(gè)字段組合成一個(gè)索引，該索引就被稱為聯(lián)合索引。
; @, |5 K( L& {比如，將商品表中的 product_no 和 name 字段組合成聯(lián)合索引(product_no, name)，創(chuàng)建聯(lián)合索引的方式如下：
CREATE INDEX index_product_no_name ON product(product_no, name);
: e. |' O1 [7 g) K! n聯(lián)合索引(product_no, name) 的 B+Tree 示意圖如下（圖中葉子節(jié)點(diǎn)之間我畫了單向鏈表，但是實(shí)際上是雙向鏈表，原圖我找不到了，修改不了，偷個(gè)懶我不重畫了，大家腦補(bǔ)成雙向鏈表就行）。

可以看到，聯(lián)合索引的非葉子節(jié)點(diǎn)用兩個(gè)字段的值作為 B+Tree 的 key 值。當(dāng)在聯(lián)合索引查詢數(shù)據(jù)時(shí)，先按 product_no 字段比較，在 product_no 相同的情況下再按 name 字段比較。
# `( c0 Z" K3 S9 ?也就是說，聯(lián)合索引查詢的 B+Tree 是先按 product_no 進(jìn)行排序，然后再 product_no 相同的情況再按 name 字段排序。
因此，使用聯(lián)合索引時(shí)，存在最左匹配原則，也就是按照最左優(yōu)先的方式進(jìn)行索引的匹配。在使用聯(lián)合索引進(jìn)行查詢的時(shí)候，如果不遵循「最左匹配原則」，聯(lián)合索引會(huì)失效，這樣就無法利用到索引快速查詢的特性了。
比如，如果創(chuàng)建了一個(gè) (a, b, c) 聯(lián)合索引，如果查詢條件是以下這幾種，就可以匹配上聯(lián)合索引：

where a=1；

where a=1 and b=2 and c=3；

where a=1 and b=2；需要注意的是，因?yàn)橛胁樵儍?yōu)化器，所以 a 字段在 where 子句的順序并不重要。
; B" e# v# k/ D2 a+ P但是，如果查詢條件是以下這幾種，因?yàn)椴环�合最左匹配原則，所以就無法匹配上聯(lián)合索引，聯(lián)合索引就會(huì)失效:
; g0 Z6 G; I# L

where b=2；

where c=3；

where b=2 and c=3；上面這些查詢條件之所以會(huì)失效，是因?yàn)?a, b, c) 聯(lián)合索引，是先按 a 排序，在 a 相同的情況再按 b 排序，在 b 相同的情況再按 c 排序。所以，b 和 c 是全局無序，局部相對(duì)有序的，這樣在沒有遵循最左匹配原則的情況下，是無法利用到索引的。
聯(lián)合索引有一些特殊情況，并不是查詢過程使用了聯(lián)合索引查詢，就代表聯(lián)合索引中的所有字段都用到了聯(lián)合索引進(jìn)行索引查詢，也就是可能存在部分字段用到聯(lián)合索引的 B+Tree，部分字段沒有用到聯(lián)合索引的 B+Tree 的情況。
8 e, d% s8 h8 A這種特殊情況就發(fā)生在范圍查詢。聯(lián)合索引的最左匹配原則會(huì)一直向右匹配直到遇到「范圍查詢」就會(huì)停止匹配。也就是范圍查詢的字段可以用到聯(lián)合索引，但是在范圍查詢字段的后面的字段無法用到聯(lián)合索引。
! H8 Q1 B. \( D% M0 Q; _有無排查索引失效的經(jīng)驗(yàn)，展開講講？可以使用 EXPLAIN 來查看 SQL 的執(zhí)行計(jì)劃，判斷SQL是否走了索引，如果沒有走索引，就代表索引發(fā)生失效了。
8 l6 z) i/ q6 ^$ m如下圖，就是一個(gè)沒有使用索引，并且是一個(gè)全表掃描的查詢語句。

9 B0 {- Z. r& E4 c5 h+ I對(duì)于執(zhí)行計(jì)劃，參數(shù)有：
. h$ l' T& n$ J. s, A' k' Z

possible_keys 字段表示可能用到的索引；

key 字段表示實(shí)際用的索引，如果這一項(xiàng)為 NULL，說明沒有使用索引；

key_len 表示索引的長度；

rows 表示掃描的數(shù)據(jù)行數(shù)。

type 表示數(shù)據(jù)掃描類型，我們需要重點(diǎn)看這個(gè)。type 字段就是描述了找到所需數(shù)據(jù)時(shí)使用的掃描方式是什么，常見掃描類型的執(zhí)行效率從低到高的順序?yàn)?/strong>：
4 r1 O& d. ^, f' F  q

All（全表掃描）：在這些情況里，all 是最壞的情況，因?yàn)椴捎昧巳�表掃描的方式�?li>index（全索引掃描）：index 和 all 差不多，只不過 index 對(duì)索引表進(jìn)行全掃描，這樣做的好處是不再需要對(duì)數(shù)據(jù)進(jìn)行排序，但是開銷依然很大。所以，要盡量避免全表掃描和全索引掃描。

range（索引范圍掃描）：range 表示采用了索引范圍掃描，一般在 where 子句中使用 、in、between 等關(guān)鍵詞，只檢索給定范圍的行，屬于范圍查找。從這一級(jí)別開始，索引的作用會(huì)越來越明顯，因此我們需要盡量讓 SQL 查詢可以使用到 range 這一級(jí)別及以上的 type 訪問方式。

ref（非唯一索引掃描）：ref 類型表示采用了非唯一索引，或者是唯一索引的非唯一性前綴，返回?cái)?shù)據(jù)返回可能是多條。因?yàn)殡m然使用了索引，但該索引列的值并不唯一，有重復(fù)。這樣即使使用索引快速查找到了第一條數(shù)據(jù)，仍然不能停止，要進(jìn)行目標(biāo)值附近的小范圍掃描。但它的好處是它并不需要掃全表，因?yàn)樗饕�是有序的，即便有重�?fù)值，也是在一個(gè)非常小的范圍內(nèi)掃描。

eq_ref（唯一索引掃描）：eq_ref 類型是使用主鍵或唯一索引時(shí)產(chǎn)生的訪問方式，通常使用在多表聯(lián)查中。比如，對(duì)兩張表進(jìn)行聯(lián)查，關(guān)聯(lián)條件是兩張表的 user_id 相等，且 user_id 是唯一索引，那么使用 EXPLAIN 進(jìn)行執(zhí)行計(jì)劃查看的時(shí)候，type 就會(huì)顯示 eq_ref。

const（結(jié)果只有一條的主鍵或唯一索引掃描）：const 類型表示使用了主鍵或者唯一索引與常量值進(jìn)行比較，比如 select name from product where id=1。需要說明的是 const 類型和 eq_ref 都使用了主鍵或唯一索引，不過這兩個(gè)類型有所區(qū)別，const 是與常量進(jìn)行比較，查詢效率會(huì)更快，而 eq_ref 通常用于多表聯(lián)查中。extra 顯示的結(jié)果，這里說幾個(gè)重要的參考指標(biāo)：
7 z: K. W, W- y* ^, A& v! Z( ~

Using filesort ：當(dāng)查詢語句中包含 group by 操作，而且無法利用索引完成排序操作的時(shí)候， 這時(shí)不得不選擇相應(yīng)的排序算法進(jìn)行，甚至可能會(huì)通過文件排序，效率是很低的，所以要避免這種問題的出現(xiàn)。

Using temporary：使了用臨時(shí)表保存中間結(jié)果，MySQL 在對(duì)查詢結(jié)果排序時(shí)使用臨時(shí)表，常見于排序 order by 和分組查詢 group by。效率低，要避免這種問題的出現(xiàn)。

Using index：所需數(shù)據(jù)只需在索引即可全部獲得，不須要再到表中取數(shù)據(jù)，也就是使用了覆蓋索引，避免了回表操作，效率不錯(cuò)。索引失效的場(chǎng)景有哪些？會(huì)發(fā)生索引失效的情況：
& T- p5 ]  Q; l5 W

當(dāng)我們使用左或者左右模糊匹配的時(shí)候，也就是 like %xx 或者 like %xx%這兩種方式都會(huì)造成索引失效；

當(dāng)我們?cè)诓樵儣l件中對(duì)索引列使用函數(shù)，就會(huì)導(dǎo)致索引失效。

當(dāng)我們?cè)诓樵儣l件中對(duì)索引列進(jìn)行表達(dá)式計(jì)算，也是無法走索引的。

MySQL 在遇到字符串和數(shù)字比較的時(shí)候，會(huì)自動(dòng)把字符串轉(zhuǎn)為數(shù)字，然后再進(jìn)行比較。如果字符串是索引列，而條件語句中的輸入?yún)��?shù)是數(shù)字的話，那么索引列會(huì)發(fā)生隱式類型轉(zhuǎn)換，由于隱式類型轉(zhuǎn)換是通過 CAST 函數(shù)實(shí)現(xiàn)的，等同于對(duì)索引列使用了函數(shù)，所以就會(huì)導(dǎo)致索引失效。

聯(lián)合索引要能正確使用需要遵循最左匹配原則，也就是按照最左優(yōu)先的方式進(jìn)行索引的匹配，否則就會(huì)導(dǎo)致索引失效。

在 WHERE 子句中，如果在 OR 前的條件列是索引列，而在 OR 后的條件列不是索引列，那么索引會(huì)失效。Redis Redis 為什么這么快？官方使用基準(zhǔn)測(cè)試的結(jié)果是，單線程的 Redis 吞吐量可以達(dá)到 10W/每秒，如下圖所示：

+ B+ t9 y. P' w4 I之所以 Redis 采用單線程（網(wǎng)絡(luò) I/O 和執(zhí)行命令）那么快，有如下幾個(gè)原因：

Redis 的大部分操作都在內(nèi)存中完成，并且采用了高效的數(shù)據(jù)結(jié)構(gòu)，因此 Redis 瓶頸可能是機(jī)器的內(nèi)存或者網(wǎng)絡(luò)帶寬，而并非 CPU，既然 CPU 不是瓶頸，那么自然就采用單線程的解決方案了；

Redis 采用單線程模型可以避免了多線程之間的競爭，省去了多線程切換帶來的時(shí)間和性能上的開銷，而且也不會(huì)導(dǎo)致死鎖問題。

Redis 采用了 I/O 多路復(fù)用機(jī)制處理大量的客戶端 Socket 請(qǐng)求，IO 多路復(fù)用機(jī)制是指一個(gè)線程處理多個(gè) IO 流，就是我們經(jīng)常聽到的 select/epoll 機(jī)制。簡單來說，在 Redis 只運(yùn)行單線程的情況下，該機(jī)制允許內(nèi)核中，同時(shí)存在多個(gè)監(jiān)聽 Socket 和已連接 Socket。內(nèi)核會(huì)一直監(jiān)聽這些 Socket 上的連接請(qǐng)求或數(shù)據(jù)請(qǐng)求。一旦有請(qǐng)求到達(dá)，就會(huì)交給 Redis 線程處理，這就實(shí)現(xiàn)了一個(gè) Redis 線程處理多個(gè) IO 流的效果。Redis 6.0 之后為什么引入了多線程？Redis 單線程指的是「接收客戶端請(qǐng)求->解析請(qǐng)求 ->進(jìn)行數(shù)據(jù)讀寫等操作->發(fā)送數(shù)據(jù)給客戶端」這個(gè)過程是由一個(gè)線程（主線程）來完成的，這也是我們常說 Redis 是單線程的原因。
但是，Redis 程序并不是單線程的，Redis 在啟動(dòng)的時(shí)候，是會(huì)啟動(dòng)后臺(tái)線程（BIO）的：

Redis 在 2.6 版本，會(huì)啟動(dòng) 2 個(gè)后臺(tái)線程，分別處理關(guān)閉文件、AOF 刷盤這兩個(gè)任務(wù)；

Redis 在 4.0 版本之后，新增了一個(gè)新的后臺(tái)線程，用來異步釋放 Redis 內(nèi)存，也就是 lazyfree 線程。例如執(zhí)行 unlink key / flushdb async / flushall async 等命令，會(huì)把這些刪除操作交給后臺(tái)線程來執(zhí)行，好處是不會(huì)導(dǎo)致 Redis 主線程卡頓。因此，當(dāng)我們要?jiǎng)h除一個(gè)大 key 的時(shí)候，不要使用 del 命令刪除，因?yàn)?del 是在主線程處理的，這樣會(huì)導(dǎo)致 Redis 主線程卡頓，因此我們應(yīng)該使用 unlink 命令來異步刪除大key。之所以 Redis 為「關(guān)閉文件、AOF 刷盤、釋放內(nèi)存」這些任務(wù)創(chuàng)建單獨(dú)的線程來處理，是因?yàn)檫@些任務(wù)的操作都是很耗時(shí)的，如果把這些任務(wù)都放在主線程來處理，那么 Redis 主線程就很容易發(fā)生阻塞，這樣就無法處理后續(xù)的請(qǐng)求了。
后臺(tái)線程相當(dāng)于一個(gè)消費(fèi)者，生產(chǎn)者把耗時(shí)任務(wù)丟到任務(wù)隊(duì)列中，消費(fèi)者（BIO）不停輪詢這個(gè)隊(duì)列，拿出任務(wù)就去執(zhí)行對(duì)應(yīng)的方法即可。

8 @  `. g7 t5 V雖然 Redis 的主要工作（網(wǎng)絡(luò) I/O 和執(zhí)行命令）一直是單線程模型，但是在 Redis 6.0 版本之后，也采用了多個(gè) I/O 線程來處理網(wǎng)絡(luò)請(qǐng)求，這是因?yàn)殡S著網(wǎng)絡(luò)硬件的性能提升，Redis 的性能瓶頸有時(shí)會(huì)出現(xiàn)在網(wǎng)絡(luò) I/O 的處理上。
6 Q5 R- s2 G. S* _; P所以為了提高網(wǎng)絡(luò) I/O 的并行度，Redis 6.0 對(duì)于網(wǎng)絡(luò) I/O 采用多線程來處理。但是對(duì)于命令的執(zhí)行，Redis 仍然使用單線程來處理，所以大家不要誤解Redis 有多線程同時(shí)執(zhí)行命令。
* {* R1 B/ C% M% X  ^  I  o/ ]! YRedis 官方表示，Redis 6.0 版本引入的多線程 I/O 特性對(duì)性能提升至少是一倍以上。
Redis 6.0 版本支持的 I/O 多線程特性，默認(rèn)情況下 I/O 多線程只針對(duì)發(fā)送響應(yīng)數(shù)據(jù)（write client socket），并不會(huì)以多線程的方式處理讀請(qǐng)求（read client socket）。要想開啟多線程處理客戶端讀請(qǐng)求，就需要把 Redis.conf 配置文件中的 io-threads-do-reads 配置項(xiàng)設(shè)為 yes。
//讀請(qǐng)求也使用io多線程
- B- W- B* `4 M2 y8 Uio-threads-do-reads yes
5 n& T8 G% A, v同時(shí)， Redis.conf 配置文件中提供了 IO 多線程個(gè)數(shù)的配置項(xiàng)。
// io-threads N，表示啟用 N-1 個(gè) I/O 多線程（主線程也算一個(gè) I/O 線程）
io-threads 4
% p4 ~+ ?2 [  R# x( @+ C( n2 W關(guān)于線程數(shù)的設(shè)置，官方的建議是如果為 4 核的 CPU，建議線程數(shù)設(shè)置為 2 或 3，如果為 8 核 CPU 建議線程數(shù)設(shè)置為 6，線程數(shù)一定要小于機(jī)器核數(shù)，線程數(shù)并不是越大越好。
因此， Redis 6.0 版本之后，Redis 在啟動(dòng)的時(shí)候，默認(rèn)情況下會(huì)額外創(chuàng)建 6 個(gè)線程（這里的線程數(shù)不包括主線程）：
( X6 r2 P0 Z& n5 F6 i! [2 ^

Redis-server ：Redis的主線程，主要負(fù)責(zé)執(zhí)行命令；

bio_close_file、bio_aof_fsync、bio_lazy_free：三個(gè)后臺(tái)線程，分別異步處理關(guān)閉文件任務(wù)、AOF刷盤任務(wù)、釋放內(nèi)存任務(wù)；

io_thd_1、io_thd_2、io_thd_3：三個(gè) I/O 線程，io-threads 默認(rèn)是 4 ，所以會(huì)啟動(dòng) 3（4-1）個(gè) I/O 多線程，用來分擔(dān) Redis 網(wǎng)絡(luò) I/O 的壓力。Redis 分布式鎖怎么解決超賣問題的？同一個(gè)鎖key，同一時(shí)間只能有一個(gè)客戶端拿到鎖，其他客戶端會(huì)陷入無限的等待來嘗試獲取那個(gè)鎖，只有獲取到鎖的客戶端才能執(zhí)行下面的業(yè)務(wù)邏輯。
比如說，用戶要一次性買 10 臺(tái)手機(jī)，那么避免超賣的流程如下：

只有一個(gè)訂單系統(tǒng)實(shí)例可以成功加分布式鎖，然后只有他一個(gè)實(shí)例可以查庫存、判斷庫存是否充足、下單扣減庫存，接著釋放鎖。

釋放鎖之后，另外一個(gè)訂單系統(tǒng)實(shí)例才能加鎖，接著查庫存，一下發(fā)現(xiàn)庫存只有 2 個(gè)了，庫存不足，無法購買，下單失敗，不會(huì)將庫存扣減為-8的，就避免超賣的問題。這種方案的缺點(diǎn)是同一個(gè)商品在多用戶同時(shí)下單的情況下，會(huì)基于分布式鎖串行化處理，導(dǎo)致沒法同時(shí)處理同一個(gè)商品的大量下單的請(qǐng)求。