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

程序員庫森

大家好，我是庫森。
�？低�視作為一家體面廠，我們來看看今年海康威視的校招薪資開了多少？
我根據(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é)果。
) q: l3 J1 B! [' R一面是技術(shù)面，問的問題不算多，主要拷打了 Java、MySQL、Redis 方面的八股文，都屬于經(jīng)典的面試問題，不算難。
( {1 A% f! A1 n3 r. X
# W: V) m- V- \0 ?+ l2 oJava 介紹一下 Spring Boot 整體的啟動(dòng)流程？

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

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

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

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

最后創(chuàng)建Spring容器，refreshContext(context)，實(shí)現(xiàn)starter自動(dòng)化配置和bean的實(shí)例化等工作。[/ol]說一說 Spring MVC 整體的執(zhí)行流程？

流程圖步驟詳解：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

按「字段個(gè)數(shù)」分類：單列索引、聯(lián)合索引。接下來，按照這些角度來說說各類索引的特點(diǎn)。
6 d3 C" _: i( S7 |# p: E+ m按數(shù)據(jù)結(jié)構(gòu)分類
/ ~8 |& Y' G; v4 {% w9 P. q從數(shù)據(jù)結(jié)構(gòu)的角度來看，MySQL 常見索引有 B+Tree 索引、HASH 索引、Full-Text 索引。
: W' k' _; }7 U, u- X, J9 {) q每一種存儲(chǔ)引擎支持的索引類型不一定相同，我在表中總結(jié)了 MySQL 常見的存儲(chǔ)引擎 InnoDB、MyISAM 和 Memory 分別支持的索引類型。
, Z; }/ m8 ~3 ~; w5 p5 U
! Z% o7 Y" J& m9 [8 L$ L2 AInnoDB 是在 MySQL 5.5 之后成為默認(rèn)的 MySQL 存儲(chǔ)引擎，B+Tree 索引類型也是 MySQL 存儲(chǔ)引擎采用最多的索引類型。
, Y7 L1 ?; Q' R1 e  M7 c在創(chuàng)建表時(shí)，InnoDB 存儲(chǔ)引擎會(huì)根據(jù)不同的場景選擇不同的列作為索引：

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

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

在上面兩個(gè)都沒有的情況下，InnoDB 將自動(dòng)生成一個(gè)隱式自增 id 列作為聚簇索引的索引鍵（key）；其它索引都屬于輔助索引（Secondary Index），也被稱為二級索引或非聚簇索引。創(chuàng)建的主鍵索引和二級索引默認(rèn)使用的是 B+Tree 索引。
, k  {: Z  b, S/ F按物理存儲(chǔ)分類
# _' g( `, |% t從物理存儲(chǔ)的角度來看，索引分為聚簇索引（主鍵索引）、二級索引（輔助索引）。
( B3 Y5 Y% _- @9 Q" h7 c  Y& `這兩個(gè)區(qū)別在前面也提到了：
' q) x# g; C. q. _6 X: V5 ?7 z

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

二級索引的 B+Tree 的葉子節(jié)點(diǎn)存放的是主鍵值，而不是實(shí)際數(shù)據(jù)。所以，在查詢時(shí)使用了二級索引，如果查詢的數(shù)據(jù)能在二級索引里查詢的到，那么就不需要回表，這個(gè)過程就是覆蓋索引。如果查詢的數(shù)據(jù)不在二級索引里，就會(huì)先檢索二級索引，找到對應(yīng)的葉子節(jié)點(diǎn)，獲取到主鍵值后，然后再檢索主鍵索引，就能查詢到數(shù)據(jù)了，這個(gè)過程就是回表。
6 r$ z( E; g/ H3 V4 V按字段特性分類
$ v# {+ L2 r; U0 H2 r* m$ K從字段特性的角度來看，索引分為主鍵索引、唯一索引、普通索引、前綴索引。
7 z/ T& j  T; z: W8 a

主鍵索引主鍵索引就是建立在主鍵字段上的索引，通常在創(chuàng)建表的時(shí)候一起創(chuàng)建，一張表最多只有一個(gè)主鍵索引，索引列的值不允許有空值。
+ o: M' a/ y( b! ?% P在創(chuàng)建表時(shí)，創(chuàng)建主鍵索引的方式如下：
CREATE TABLE table_name  (
/ _2 X9 L$ ^$ b( ?0 ?/ J" I  ....
  PRIMARY KEY (index_column_1) USING BTREE
& e5 g% `7 {* _# l);

唯一索引唯一索引建立在 UNIQUE 字段上的索引，一張表可以有多個(gè)唯一索引，索引列的值必須唯一，但是允許有空值。
- g( U' D& }9 d* H$ J! O0 E在創(chuàng)建表時(shí)，創(chuàng)建唯一索引的方式如下：
& s- M  ^; q+ q- g# xCREATE TABLE table_name  (
$ H- V. M# {; @( I% o- M  ....
# m0 r& F( z2 _" M% m3 F& O' R2 O  UNIQUE KEY(index_column_1,index_column_2,...)
6 W$ ]& T! a; H, C4 a5 q);
  \- c4 X5 H, b6 a# _8 s2 N( h( e8 g建表后，如果要?jiǎng)?chuàng)建唯一索引，可以使用這面這條命令：
CREATE UNIQUE INDEX index_name
ON table_name(index_column_1,index_column_2,...);
; w. u8 Z3 ^% F- n2 g

普通索引普通索引就是建立在普通字段上的索引，既不要求字段為主鍵，也不要求字段為 UNIQUE。
在創(chuàng)建表時(shí)，創(chuàng)建普通索引的方式如下：
6 m% M2 z- T0 C; GCREATE TABLE table_name  (
  ....
6 y( O9 A1 f8 I  INDEX(index_column_1,index_column_2,...)
);
, c1 x$ ]4 E) e) m3 @建表后，如果要?jiǎng)?chuàng)建普通索引，可以使用這面這條命令：
CREATE INDEX index_name
ON table_name(index_column_1,index_column_2,...);
% F  c0 C! u1 R! c, m9 m7 c+ V6 I

前綴索引前綴索引是指對字符類型字段的前幾個(gè)字符建立的索引，而不是在整個(gè)字段上建立的索引，前綴索引可以建立在字段類型為 char、 varchar、binary、varbinary 的列上。
4 l0 M4 U) `: b; W! C使用前綴索引的目的是為了減少索引占用的存儲(chǔ)空間，提升查詢效率。
在創(chuàng)建表時(shí)，創(chuàng)建前綴索引的方式如下：
- D8 |: I4 b: Q4 ~CREATE TABLE table_name(
8 S) Y/ M/ e8 R4 \9 p% X# A    column_list,
    INDEX(column_name(length))
# Z2 f1 _8 a) H: y);
建表后，如果要?jiǎng)?chuàng)建前綴索引，可以使用這面這條命令：
6 Y) }0 j- p2 yCREATE INDEX index_name
& h) j& N% {) u; MON table_name(column_name(length));
5 v8 X( W. ^3 C# u9 h按字段個(gè)數(shù)分類
: y2 g4 u" _9 Z% o6 T. `1 [/ U從字段個(gè)數(shù)的角度來看，索引分為單列索引、聯(lián)合索引（復(fù)合索引）。
9 O+ {/ S3 h2 l4 X* {6 z: R

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

建立在多列上的索引稱為聯(lián)合索引；通過將多個(gè)字段組合成一個(gè)索引，該索引就被稱為聯(lián)合索引。
7 ^" E/ U* S! O/ r比如，將商品表中的 product_no 和 name 字段組合成聯(lián)合索引(product_no, name)，創(chuàng)建聯(lián)合索引的方式如下：
CREATE INDEX index_product_no_name ON product(product_no, name);
聯(lián)合索引(product_no, name) 的 B+Tree 示意圖如下（圖中葉子節(jié)點(diǎn)之間我畫了單向鏈表，但是實(shí)際上是雙向鏈表，原圖我找不到了，修改不了，偷個(gè)懶我不重畫了，大家腦補(bǔ)成雙向鏈表就行）。
& d& B: z( Q; H: `1 X* \% X6 T
可以看到，聯(lián)合索引的非葉子節(jié)點(diǎn)用兩個(gè)字段的值作為 B+Tree 的 key 值。當(dāng)在聯(lián)合索引查詢數(shù)據(jù)時(shí)，先按 product_no 字段比較，在 product_no 相同的情況下再按 name 字段比較。
也就是說，聯(lián)合索引查詢的 B+Tree 是先按 product_no 進(jìn)行排序，然后再 product_no 相同的情況再按 name 字段排序。
3 C8 O  O- C( U因此，使用聯(lián)合索引時(shí)，存在最左匹配原則，也就是按照最左優(yōu)先的方式進(jìn)行索引的匹配。在使用聯(lián)合索引進(jìn)行查詢的時(shí)候，如果不遵循「最左匹配原則」，聯(lián)合索引會(huì)失效，這樣就無法利用到索引快速查詢的特性了。
$ R, j/ f- M$ L! ]. Q/ n比如，如果創(chuàng)建了一個(gè) (a, b, c) 聯(lián)合索引，如果查詢條件是以下這幾種，就可以匹配上聯(lián)合索引：
! r, |& C3 }7 m6 \, [

where a=1；

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

where a=1 and b=2；需要注意的是，因?yàn)橛胁樵儍?yōu)化器，所以 a 字段在 where 子句的順序并不重要。
% R4 Q" l3 R% B. R+ d" `1 g但是，如果查詢條件是以下這幾種，因?yàn)椴环�合最左匹配原則，所以就無法匹配上聯(lián)合索引，聯(lián)合索引就會(huì)失效:

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 是全局無序，局部相對有序的，這樣在沒有遵循最左匹配原則的情況下，是無法利用到索引的。
$ g7 S$ G9 M' A聯(lián)合索引有一些特殊情況，并不是查詢過程使用了聯(lián)合索引查詢，就代表聯(lián)合索引中的所有字段都用到了聯(lián)合索引進(jìn)行索引查詢，也就是可能存在部分字段用到聯(lián)合索引的 B+Tree，部分字段沒有用到聯(lián)合索引的 B+Tree 的情況。
這種特殊情況就發(fā)生在范圍查詢。聯(lián)合索引的最左匹配原則會(huì)一直向右匹配直到遇到「范圍查詢」就會(huì)停止匹配。也就是范圍查詢的字段可以用到聯(lián)合索引，但是在范圍查詢字段的后面的字段無法用到聯(lián)合索引。
3 Z6 T! }7 b" y5 k8 P4 i: q6 j有無排查索引失效的經(jīng)驗(yàn)，展開講講？可以使用 EXPLAIN 來查看 SQL 的執(zhí)行計(jì)劃，判斷SQL是否走了索引，如果沒有走索引，就代表索引發(fā)生失效了。
如下圖，就是一個(gè)沒有使用索引，并且是一個(gè)全表掃描的查詢語句。

對于執(zhí)行計(jì)劃，參數(shù)有：
) D) [  B4 Z5 U* ~; v. T) f4 q3 m  b

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>：
% i, [' {8 x9 z

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

range（索引范圍掃描）：range 表示采用了索引范圍掃描，一般在 where 子句中使用 、in、between 等關(guān)鍵詞，只檢索給定范圍的行，屬于范圍查找。從這一級別開始，索引的作用會(huì)越來越明顯，因此我們需要盡量讓 SQL 查詢可以使用到 range 這一級別及以上的 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)查中。比如，對兩張表進(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)：
8 D7 ~; e) ]4 j2 P  @

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

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

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

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

當(dāng)我們在查詢條件中對索引列使用函數(shù)，就會(huì)導(dǎo)致索引失效。

當(dāng)我們在查詢條件中對索引列進(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)的，等同于對索引列使用了函數(shù)，所以就會(huì)導(dǎo)致索引失效。

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

在 WHERE 子句中，如果在 OR 前的條件列是索引列，而在 OR 后的條件列不是索引列，那么索引會(huì)失效。Redis Redis 為什么這么快？官方使用基準(zhǔn)測試的結(jié)果是，單線程的 Redis 吞吐量可以達(dá)到 10W/每秒，如下圖所示：
8 d; N: S2 A. p4 R6 |
$ c3 n6 F' L) y, F之所以 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 請求，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 上的連接請求或數(shù)據(jù)請求。一旦有請求到達(dá)，就會(huì)交給 Redis 線程處理，這就實(shí)現(xiàn)了一個(gè) Redis 線程處理多個(gè) IO 流的效果。Redis 6.0 之后為什么引入了多線程？Redis 單線程指的是「接收客戶端請求->解析請求 ->進(jìn)行數(shù)據(jù)讀寫等操作->發(fā)送數(shù)據(jù)給客戶端」這個(gè)過程是由一個(gè)線程（主線程）來完成的，這也是我們常說 Redis 是單線程的原因。
1 k9 T! a9 I: h% G3 y; Y( E5 a( k. ^但是，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ù)的請求了。
# @0 {' s" p2 z/ |后臺(tái)線程相當(dāng)于一個(gè)消費(fèi)者，生產(chǎn)者把耗時(shí)任務(wù)丟到任務(wù)隊(duì)列中，消費(fèi)者（BIO）不停輪詢這個(gè)隊(duì)列，拿出任務(wù)就去執(zhí)行對應(yīng)的方法即可。

- ?1 _& M4 y, Q* ^, s) L; r# b雖然 Redis 的主要工作（網(wǎng)絡(luò) I/O 和執(zhí)行命令）一直是單線程模型，但是在 Redis 6.0 版本之后，也采用了多個(gè) I/O 線程來處理網(wǎng)絡(luò)請求，這是因?yàn)殡S著網(wǎng)絡(luò)硬件的性能提升，Redis 的性能瓶頸有時(shí)會(huì)出現(xiàn)在網(wǎng)絡(luò) I/O 的處理上。
所以為了提高網(wǎng)絡(luò) I/O 的并行度，Redis 6.0 對于網(wǎng)絡(luò) I/O 采用多線程來處理。但是對于命令的執(zhí)行，Redis 仍然使用單線程來處理，所以大家不要誤解Redis 有多線程同時(shí)執(zhí)行命令。
: Z5 y7 R7 R# O' N/ D. \8 p& CRedis 官方表示，Redis 6.0 版本引入的多線程 I/O 特性對性能提升至少是一倍以上。
9 v0 Z. s$ |: C$ o8 ZRedis 6.0 版本支持的 I/O 多線程特性，默認(rèn)情況下 I/O 多線程只針對發(fā)送響應(yīng)數(shù)據(jù)（write client socket），并不會(huì)以多線程的方式處理讀請求（read client socket）。要想開啟多線程處理客戶端讀請求，就需要把 Redis.conf 配置文件中的 io-threads-do-reads 配置項(xiàng)設(shè)為 yes。
//讀請求也使用io多線程
io-threads-do-reads yes
同時(shí)， Redis.conf 配置文件中提供了 IO 多線程個(gè)數(shù)的配置項(xiàng)。
// io-threads N，表示啟用 N-1 個(gè) I/O 多線程（主線程也算一個(gè) I/O 線程）
# t: I9 Z% K1 L9 `& d/ Oio-threads 4
關(guān)于線程數(shù)的設(shè)置，官方的建議是如果為 4 核的 CPU，建議線程數(shù)設(shè)置為 2 或 3，如果為 8 核 CPU 建議線程數(shù)設(shè)置為 6，線程數(shù)一定要小于機(jī)器核數(shù)，線程數(shù)并不是越大越好。
1 ^' T0 p  r+ |3 z- Z& X" c2 o因此， Redis 6.0 版本之后，Redis 在啟動(dòng)的時(shí)候，默認(rèn)情況下會(huì)額外創(chuàng)建 6 個(gè)線程（這里的線程數(shù)不包括主線程）：
* c# T' y4 E+ d* z/ M, @

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ù)邏輯。
: ~  Q) E- l) d+ y比如說，用戶要一次性買 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è)商品的大量下單的請求。