線程和進程的區(qū)別是什么？進程狀態(tài)之間如何相互轉(zhuǎn)化？

大家好，我是小林。

針對校招同學(xué)，我是推薦在秋招之前多積累實習(xí)經(jīng)歷，或者多做一些有含金量的項目，除了能增加簡歷競爭之外，還有一個好處，就是能減少面試八股文題量。

因為面試的時間基本都是固定的，一般互聯(lián)網(wǎng)公司是 40-60 分鐘，如果這個時間里，問了你很多實習(xí)經(jīng)歷和項目經(jīng)歷方面的問題，那么所剩的時間就不多了，這樣面試官索性就隨便問幾個八股文，來結(jié)束這次面試了，這種面試相當(dāng)于在你的主場進行面試，準備起來的壓力也不會太大。

相反，如果無實習(xí)經(jīng)歷， 項目也是比較爛大街了，面試官對簡歷上的內(nèi)容沒什么興趣的，那整場面試只能圍繞八股文來問了，這時候主場就是在面試官那，他問什么你回答什么，面試官容易問到你沒學(xué)過的內(nèi)容。

比如，這位同學(xué)字節(jié)面經(jīng)，全程基本上就是八股文的拷打，范圍就是操作系統(tǒng)、網(wǎng)絡(luò)協(xié)議、mysql、redis、編程語言、算法、場景題。

操作系統(tǒng)

線程和進程的區(qū)別？

老八股文，這個都不會，說不過去了。從定義、地址空間、通信、安全性這幾個方面對比回答。

調(diào)度和資源：進程是操作系統(tǒng)進行資源分配和調(diào)度的基本單位，而線程是進程的執(zhí)行單元，共享進程的資源。

地址空間：每個進程都有獨立的地址空間，而線程共享所屬進程的地址空間，包括代碼段、數(shù)據(jù)段、堆。

通信：進程間通信需要額外的機制，如管道、消息隊列、共享內(nèi)存等，而線程間通信可以直接共享全局變量等數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)。

安全性：多線程編程需要更小心地處理共享資源，避免出現(xiàn)競態(tài)條件和死鎖等問題，而多進程編程由于各進程有獨立的地址空間，相對更容易實現(xiàn)并發(fā)安全性，一個進程崩潰不會影響其他進程而一個線程崩潰可能影響整個進程。

進程狀態(tài)之間的相互轉(zhuǎn)化？

一個完整的進程狀態(tài)的變遷如下圖：

進程五種狀態(tài)的變遷

再來詳細說明一下進程的狀態(tài)變遷：

NULL -> 創(chuàng)建狀態(tài)：一個新進程被創(chuàng)建時的第一個狀態(tài)；

創(chuàng)建狀態(tài) -> 就緒狀態(tài)：當(dāng)進程被創(chuàng)建完成并初始化后，一切就緒準備運行時，變?yōu)榫途w狀態(tài)，這個過程是很快的；

就緒態(tài) -> 運行狀態(tài)：處于就緒狀態(tài)的進程被操作系統(tǒng)的進程調(diào)度器選中后，就分配給 CPU 正式運行該進程；

運行狀態(tài) -> 結(jié)束狀態(tài)：當(dāng)進程已經(jīng)運行完成或出錯時，會被操作系統(tǒng)作結(jié)束狀態(tài)處理；

運行狀態(tài) -> 就緒狀態(tài)：處于運行狀態(tài)的進程在運行過程中，由于分配給它的運行時間片用完，操作系統(tǒng)會把該進程變?yōu)榫途w態(tài)，接著從就緒態(tài)選中另外一個進程運行；

運行狀態(tài) -> 阻塞狀態(tài)：當(dāng)進程請求某個事件且必須等待時，例如請求 I/O 事件；

阻塞狀態(tài) -> 就緒狀態(tài)：當(dāng)進程要等待的事件完成時，它從阻塞狀態(tài)變到就緒狀態(tài)；

你了解過哪些io模型？

阻塞I/O模型：應(yīng)用程序發(fā)起I/O操作后會被阻塞，直到操作完成才返回結(jié)果。適用于對實時性要求不高的場景。

非阻塞I/O模型：應(yīng)用程序發(fā)起I/O操作后立即返回，不會被阻塞，但需要不斷輪詢或者使用select/poll/epoll等系統(tǒng)調(diào)用來檢查I/O操作是否完成。適合于需要進行多路復(fù)用的場景，例如需要同時處理多個socket連接的服務(wù)器程序。

I/O復(fù)用模型：通過select、poll、epoll等系統(tǒng)調(diào)用，應(yīng)用程序可以同時等待多個I/O操作，當(dāng)其中任何一個I/O操作準備就緒時，應(yīng)用程序會被通知。適合于需要同時處理多個I/O操作的場景，比如高并發(fā)的服務(wù)端程序。

信號驅(qū)動I/O模型：應(yīng)用程序發(fā)起I/O操作后，可以繼續(xù)做其他事情，當(dāng)I/O操作完成時，操作系統(tǒng)會向應(yīng)用程序發(fā)送信號來通知其完成。適合于需要異步I/O通知的場景，可以提高系統(tǒng)的并發(fā)能力。

異步I/O模型：應(yīng)用程序發(fā)起I/O操作后可以立即做其他事情，當(dāng)I/O操作完成時，應(yīng)用程序會得到通知。異步I/O模型由操作系統(tǒng)內(nèi)核完成I/O操作，應(yīng)用程序只需等待通知即可。適合于需要大量并發(fā)連接和高性能的場景，能夠減少系統(tǒng)調(diào)用次數(shù)，提高系統(tǒng)效率。

有了解過io多路復(fù)用嗎？

select 實現(xiàn)多路復(fù)用的方式是，將已連接的 Socket 都放到一個文件描述符集合，然后調(diào)用 select 函數(shù)將文件描述符集合拷貝到內(nèi)核里，讓內(nèi)核來檢查是否有網(wǎng)絡(luò)事件產(chǎn)生，檢查的方式很粗暴，就是通過遍歷文件描述符集合的方式，當(dāng)檢查到有事件產(chǎn)生后，將此 Socket 標記為可讀或可寫， 接著再把整個文件描述符集合拷貝回用戶態(tài)里，然后用戶態(tài)還需要再通過遍歷的方法找到可讀或可寫的 Socket，然后再對其處理。

所以，對于 select 這種方式，需要進行 2 次「遍歷」文件描述符集合，一次是在內(nèi)核態(tài)里，一個次是在用戶態(tài)里 ，而且還會發(fā)生 2 次「拷貝」文件描述符集合，先從用戶空間傳入內(nèi)核空間，由內(nèi)核修改后，再傳出到用戶空間中。

select 使用固定長度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的個數(shù)是有限制的，在 Linux 系統(tǒng)中，由內(nèi)核中的 FD_SETSIZE 限制， 默認最大值為 1024，只能監(jiān)聽 0~1023 的文件描述符。

poll 不再用 BitsMap 來存儲所關(guān)注的文件描述符，取而代之用動態(tài)數(shù)組，以鏈表形式來組織，突破了 select 的文件描述符個數(shù)限制，當(dāng)然還會受到系統(tǒng)文件描述符限制。

但是 poll 和 select 并沒有太大的本質(zhì)區(qū)別，都是使用「線性結(jié)構(gòu)」存儲進程關(guān)注的 Socket 集合，因此都需要遍歷文件描述符集合來找到可讀或可寫的 Socket，時間復(fù)雜度為 O(n)，而且也需要在用戶態(tài)與內(nèi)核態(tài)之間拷貝文件描述符集合，這種方式隨著并發(fā)數(shù)上來，性能的損耗會呈指數(shù)級增長。

poll 通過兩個方面，很好解決了 select/poll 的問題。

第一點，epoll 在內(nèi)核里使用紅黑樹來跟蹤進程所有待檢測的文件描述字，把需要監(jiān)控的 socket 通過 epoll_ctl() 函數(shù)加入內(nèi)核中的紅黑樹里，紅黑樹是個高效的數(shù)據(jù)結(jié)構(gòu)，增刪改一般時間復(fù)雜度是 O(logn)。而 select/poll 內(nèi)核里沒有類似 epoll 紅黑樹這種保存所有待檢測的 socket 的數(shù)據(jù)結(jié)構(gòu)，所以 select/poll 每次操作時都傳入整個 socket 集合給內(nèi)核，而 epoll 因為在內(nèi)核維護了紅黑樹，可以保存所有待檢測的 socket ，所以只需要傳入一個待檢測的 socket，減少了內(nèi)核和用戶空間大量的數(shù)據(jù)拷貝和內(nèi)存分配。

第二點， epoll 使用事件驅(qū)動的機制，內(nèi)核里維護了一個鏈表來記錄就緒事件，當(dāng)某個 socket 有事件發(fā)生時，通過回調(diào)函數(shù)內(nèi)核會將其加入到這個就緒事件列表中，當(dāng)用戶調(diào)用 epoll_wait() 函數(shù)時，只會返回有事件發(fā)生的文件描述符的個數(shù)，不需要像 select/poll 那樣輪詢掃描整個 socket 集合，大大提高了檢測的效率。

從下圖你可以看到 epoll 相關(guān)的接口作用：

epoll 的方式即使監(jiān)聽的 Socket 數(shù)量越多的時候，效率不會大幅度降低，能夠同時監(jiān)聽的 Socket 的數(shù)目也非常的多了，上限就為系統(tǒng)定義的進程打開的最大文件描述符個數(shù)。因而，epoll 被稱為解決 C10K 問題的利器。

管道有幾種方式？

管道在Linux中有兩種方式：匿名管道和命名管道。

匿名管道：是一種在父子進程或者兄弟進程之間進行通信的機制，只能用于具有親緣關(guān)系的進程間通信，通常通過pipe系統(tǒng)調(diào)用創(chuàng)建。

命名管道：是一種允許無關(guān)的進程間進行通信的機制，基于文件系統(tǒng)，可以在不相關(guān)的進程之間進行通信。

網(wǎng)絡(luò)

網(wǎng)絡(luò)模型每一層作用是什么？

img

OSI 網(wǎng)絡(luò)模型，該模型主要有 7 層，分別是應(yīng)用層、表示層、會話層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層以及物理層。

應(yīng)用層，負責(zé)給應(yīng)用程序提供統(tǒng)一的接口；

表示層，負責(zé)把數(shù)據(jù)轉(zhuǎn)換成兼容另一個系統(tǒng)能識別的格式；

會話層，負責(zé)建立、管理和終止表示層實體之間的通信會話；

傳輸層，負責(zé)端到端的數(shù)據(jù)傳輸；

網(wǎng)絡(luò)層，負責(zé)數(shù)據(jù)的路由、轉(zhuǎn)發(fā)、分片；

數(shù)據(jù)鏈路層，負責(zé)數(shù)據(jù)的封幀和差錯檢測，以及 MAC 尋址；

物理層，負責(zé)在物理網(wǎng)絡(luò)中傳輸數(shù)據(jù)幀；

TCP/IP 網(wǎng)絡(luò)模型共有 4 層，分別是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和網(wǎng)絡(luò)接口層，每一層負責(zé)的職能如下：

應(yīng)用層，負責(zé)向用戶提供一組應(yīng)用程序，比如 HTTP、DNS、FTP 等;

傳輸層，負責(zé)端到端的通信，比如 TCP、UDP 等；

網(wǎng)絡(luò)層，負責(zé)網(wǎng)絡(luò)包的封裝、分片、路由、轉(zhuǎn)發(fā)，比如 IP、ICMP 等；

網(wǎng)絡(luò)接口層，負責(zé)網(wǎng)絡(luò)包在物理網(wǎng)絡(luò)中的傳輸，比如網(wǎng)絡(luò)包的封幀、 MAC 尋址、差錯檢測，以及通過網(wǎng)卡傳輸網(wǎng)絡(luò)幀等；

tcp 和 udp區(qū)別？

連接：TCP 是面向連接的傳輸層協(xié)議，傳輸數(shù)據(jù)前先要建立連接；UDP 是不需要連接，即刻傳輸數(shù)據(jù)。

服務(wù)對象：TCP 是一對一的兩點服務(wù)，即一條連接只有兩個端點。UDP 支持一對一、一對多、多對多的交互通信

可靠性：TCP 是可靠交付數(shù)據(jù)的，數(shù)據(jù)可以無差錯、不丟失、不重復(fù)、按序到達。UDP 是盡最大努力交付，不保證可靠交付數(shù)據(jù)。但是我們可以基于 UDP 傳輸協(xié)議實現(xiàn)一個可靠的傳輸協(xié)議，比如 QUIC 協(xié)議

擁塞控制、流量控制：TCP 有擁塞控制和流量控制機制，保證數(shù)據(jù)傳輸?shù)陌踩?。UDP 則沒有，即使網(wǎng)絡(luò)非常擁堵了，也不會影響 UDP 的發(fā)送速率。

首部開銷：TCP 首部長度較長，會有一定的開銷，首部在沒有使用「選項」字段時是 20 個字節(jié)，如果使用了「選項」字段則會變長的。UDP 首部只有 8 個字節(jié)，并且是固定不變的，開銷較小。

傳輸方式：TCP 是流式傳輸，沒有邊界，但保證順序和可靠。UDP 是一個包一個包的發(fā)送，是有邊界的，但可能會丟包和亂序。

應(yīng)用場景：TCP 是面向連接，能保證數(shù)據(jù)的可靠性交付，因此經(jīng)常用于：FTP、HTTP/HTTPS協(xié)議。UDP 面向無連接，它可以隨時發(fā)送數(shù)據(jù)，再加上 UDP 本身的處理既簡單又高效，經(jīng)常用于視頻、音頻等多媒體通信等。

怎么用udp實現(xiàn)http？

HTTP/1 ~ HTTP/3

UDP 是不可靠傳輸?shù)模?UDP 的 QUIC 協(xié)議 可以實現(xiàn)類似 TCP 的可靠性傳輸，在http3 就用了 quic 協(xié)議。

連接遷移：QUIC支持在網(wǎng)絡(luò)變化時快速遷移連接，例如從WiFi切換到移動數(shù)據(jù)網(wǎng)絡(luò)，以保持連接的可靠性。

重傳機制：QUIC使用重傳機制來確保丟失的數(shù)據(jù)包能夠被重新發(fā)送，從而提高數(shù)據(jù)傳輸?shù)目煽啃浴?/p>

前向糾錯：QUIC可以使用前向糾錯技術(shù)，在接收端修復(fù)部分丟失的數(shù)據(jù)，降低重傳的需求，提高可靠性和傳輸效率。

擁塞控制：QUIC內(nèi)置了擁塞控制機制，可以根據(jù)網(wǎng)絡(luò)狀況動態(tài)調(diào)整數(shù)據(jù)傳輸速率，以避免網(wǎng)絡(luò)擁塞和丟包，提高可靠性。

http長連接是什么？

使用同一個 TCP 連接來發(fā)送和接收多個 HTTP 請求/應(yīng)答，避免了連接建立和釋放的開銷，這個方法稱為 HTTP 長連接。

HTTP 長連接

HTTP 長連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。

MySQL數(shù)據(jù)庫

mysql為什么選擇b+樹？

MySQL 是會將數(shù)據(jù)持久化在硬盤，而存儲功能是由 MySQL 存儲引擎實現(xiàn)的，所以討論 MySQL 使用哪種數(shù)據(jù)結(jié)構(gòu)作為索引，實際上是在討論存儲引使用哪種數(shù)據(jù)結(jié)構(gòu)作為索引，InnoDB 是 MySQL 默認的存儲引擎，它就是采用了 B+ 樹作為索引的數(shù)據(jù)結(jié)構(gòu)。

要設(shè)計一個 MySQL 的索引數(shù)據(jù)結(jié)構(gòu)，不僅僅考慮數(shù)據(jù)結(jié)構(gòu)增刪改的時間復(fù)雜度，更重要的是要考慮磁盤 I/0 的操作次數(shù)。因為索引和記錄都是存放在硬盤，硬盤是一個非常慢的存儲設(shè)備，我們在查詢數(shù)據(jù)的時候，最好能在盡可能少的磁盤 I/0 的操作次數(shù)內(nèi)完成。

二分查找樹雖然是一個天然的二分結(jié)構(gòu)，能很好的利用二分查找快速定位數(shù)據(jù)，但是它存在一種極端的情況，每當(dāng)插入的元素都是樹內(nèi)最大的元素，就會導(dǎo)致二分查找樹退化成一個鏈表，此時查詢復(fù)雜度就會從 O(logn)降低為 O(n)。

為了解決二分查找樹退化成鏈表的問題，就出現(xiàn)了自平衡二叉樹，保證了查詢操作的時間復(fù)雜度就會一直維持在 O(logn) 。但是它本質(zhì)上還是一個二叉樹，每個節(jié)點只能有 2 個子節(jié)點，隨著元素的增多，樹的高度會越來越高。

而樹的高度決定于磁盤 I/O 操作的次數(shù)，因為樹是存儲在磁盤中的，訪問每個節(jié)點，都對應(yīng)一次磁盤 I/O 操作，也就是說樹的高度就等于每次查詢數(shù)據(jù)時磁盤 IO 操作的次數(shù)，所以樹的高度越高，就會影響查詢性能。

B 樹和 B+ 都是通過多叉樹的方式，會將樹的高度變矮，所以這兩個數(shù)據(jù)結(jié)構(gòu)非常適合檢索存于磁盤中的數(shù)據(jù)。

但是 MySQL 默認的存儲引擎 InnoDB 采用的是 B+ 作為索引的數(shù)據(jù)結(jié)構(gòu)。原因有：

B+ 樹的非葉子節(jié)點不存放實際的記錄數(shù)據(jù)，僅存放索引，因此數(shù)據(jù)量相同的情況下，相比存儲即存索引又存記錄的 B 樹，B+樹的非葉子節(jié)點可以存放更多的索引，因此 B+ 樹可以比 B 樹更「矮胖」，查詢底層節(jié)點的磁盤 I/O次數(shù)會更少。

B+ 樹有大量的冗余節(jié)點（所有非葉子節(jié)點都是冗余索引），這些冗余索引讓 B+ 樹在插入、刪除的效率都更高，比如刪除根節(jié)點的時候，不會像 B 樹那樣會發(fā)生復(fù)雜的樹的變化；

B+ 樹葉子節(jié)點之間用鏈表連接了起來，有利于范圍查詢，而 B 樹要實現(xiàn)范圍查詢，因此只能通過樹的遍歷來完成范圍查詢，這會涉及多個節(jié)點的磁盤 I/O 操作，范圍查詢效率不如 B+ 樹。

mysql acid 特性

原子性（Atomicity）：一個事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)，而且事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被回滾到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣，就好比買一件商品，購買成功時，則給商家付了錢，商品到手；購買失敗時，則商品在商家手中，消費者的錢也沒花出去。

一致性（Consistency）：是指事務(wù)操作前和操作后，數(shù)據(jù)滿足完整性約束，數(shù)據(jù)庫保持一致性狀態(tài)。比如，用戶 A 和用戶 B 在銀行分別有 800 元和 600 元，總共 1400 元，用戶 A 給用戶 B 轉(zhuǎn)賬 200 元，分為兩個步驟，從 A 的賬戶扣除 200 元和對 B 的賬戶增加 200 元。一致性就是要求上述步驟操作后，最后的結(jié)果是用戶 A 還有 600 元，用戶 B 有 800 元，總共 1400 元，而不會出現(xiàn)用戶 A 扣除了 200 元，但用戶 B 未增加的情況（該情況，用戶 A 和 B 均為 600 元，總共 1200 元）。

隔離性（Isolation）：數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進行讀寫和修改的能力，隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致，因為多個事務(wù)同時使用相同的數(shù)據(jù)時，不會相互干擾，每個事務(wù)都有一個完整的數(shù)據(jù)空間，對其他并發(fā)事務(wù)是隔離的。也就是說，消費者購買商品這個事務(wù)，是不影響其他消費者購買的。

持久性（Durability）：事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。

InnoDB 引擎通過什么技術(shù)來保證事務(wù)的這四個特性的呢？

持久性是通過 redo log （重做日志）來保證的；

原子性是通過 undo log（回滾日志） 來保證的；

隔離性是通過 MVCC（多版本并發(fā)控制） 或鎖機制來保證的；

一致性則是通過持久性+原子性+隔離性來保證；

mysql事務(wù)的隔離級別有哪些

四個隔離級別如下：

讀未提交），指一個事務(wù)還沒提交時，它做的變更就能被其他事務(wù)看到；

讀提交，指一個事務(wù)提交之后，它做的變更才能被其他事務(wù)看到；

可重復(fù)讀，指一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù)，一直跟這個事務(wù)啟動時看到的數(shù)據(jù)是一致的，MySQL InnoDB 引擎的默認隔離級別；

串行化；會對記錄加上讀寫鎖，在多個事務(wù)對這條記錄進行讀寫操作時，如果發(fā)生了讀寫沖突的時候，后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成，才能繼續(xù)執(zhí)行；

按隔離水平高低排序如下：

圖片

針對不同的隔離級別，并發(fā)事務(wù)時可能發(fā)生的現(xiàn)象也會不同。

圖片

也就是說：

在「讀未提交」隔離級別下，可能發(fā)生臟讀、不可重復(fù)讀和幻讀現(xiàn)象；

在「讀提交」隔離級別下，可能發(fā)生不可重復(fù)讀和幻讀現(xiàn)象，但是不可能發(fā)生臟讀現(xiàn)象；

在「可重復(fù)讀」隔離級別下，可能發(fā)生幻讀現(xiàn)象，但是不可能臟讀和不可重復(fù)讀現(xiàn)象；

在「串行化」隔離級別下，臟讀、不可重復(fù)讀和幻讀現(xiàn)象都不可能會發(fā)生。

讀已提交和可重復(fù)讀的區(qū)別是什么？

可重復(fù)讀隔離級別是啟動事務(wù)時生成一個 Read View，然后整個事務(wù)期間都在用這個 Read View。這樣就保證了在事務(wù)期間讀到的數(shù)據(jù)都是事務(wù)啟動前的記錄。

讀提交隔離級別是在每次讀取數(shù)據(jù)時，都會生成一個新的 Read View。也意味著，事務(wù)期間的多次讀取同一條數(shù)據(jù)，前后兩次讀的數(shù)據(jù)可能會出現(xiàn)不一致，因為可能這期間另外一個事務(wù)修改了該記錄，并提交了事務(wù)。

mvcc怎么實現(xiàn)的？

MVCC 是多版本并發(fā)控制，MVCC保證了事務(wù)之間的隔離性，事務(wù)只能看到已經(jīng)提交的數(shù)據(jù)版本，從而保證了數(shù)據(jù)的一致性，并且避免了事務(wù)讀寫并發(fā)的問題，因為 select 快照讀是不會加鎖的。

可重復(fù)讀隔離級別是開啟事務(wù)，執(zhí)行第一個 select 查詢的時候，會創(chuàng)建 Read View，然后整個事務(wù)期間都在用這個 Read View。讀提交隔離級別是在每次select 查詢時，都會生成一個新的 Read View。

在創(chuàng)建 Read View 后，我們可以將記錄中的 trx_id 劃分這三種情況：

一個事務(wù)去訪問記錄的時候，除了自己的更新記錄總是可見之外，還有這幾種情況：

如果記錄的 trx_id 值小于 Read View 中的 min_trx_id 值，表示這個版本的記錄是在創(chuàng)建 Read View 前已經(jīng)提交的事務(wù)生成的，所以該版本的記錄對當(dāng)前事務(wù)可見。

如果記錄的 trx_id 值大于等于 Read View 中的 max_trx_id 值，表示這個版本的記錄是在創(chuàng)建 Read View 后才啟動的事務(wù)生成的，所以該版本的記錄對當(dāng)前事務(wù)不可見。

如果記錄的 trx_id 值在 Read View 的 min_trx_id 和 max_trx_id之間，需要判斷 trx_id 是否在 m_ids 列表中：

如果記錄的 trx_id 在 m_ids 列表中，表示生成該版本記錄的活躍事務(wù)依然活躍著（還沒提交事務(wù)），所以該版本的記錄對當(dāng)前事務(wù)不可見。

如果記錄的 trx_id 不在 m_ids列表中，表示生成該版本記錄的活躍事務(wù)已經(jīng)被提交，所以該版本的記錄對當(dāng)前事務(wù)可見。

binlog，redolog，undolog有什么區(qū)別？

binlog（二進制日志）：記錄了對數(shù)據(jù)庫的所有更新操作，包括insert、update、delete等，用于數(shù)據(jù)恢復(fù)、主從復(fù)制和數(shù)據(jù)庫的增量備份。

redo log（重做日志）：記錄了數(shù)據(jù)庫引擎對數(shù)據(jù)頁的物理修改操作，用于在數(shù)據(jù)庫發(fā)生異常情況時進行恢復(fù)，保證數(shù)據(jù)庫的一致性。

undo log（撤銷日志）：記錄了事務(wù)執(zhí)行前的數(shù)據(jù)版本，用于事務(wù)的回滾和MVCC（多版本并發(fā)控制），在事務(wù)提交前，可以使用undo log還原數(shù)據(jù)狀態(tài)。

mysql 主從復(fù)制的過程

MySQL 的主從復(fù)制依賴于 binlog ，也就是記錄 MySQL 上的所有變化并以二進制形式保存在磁盤上。復(fù)制的過程就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐稀?/p>

這個過程一般是異步的，也就是主庫上執(zhí)行事務(wù)操作的線程不會等待復(fù)制 binlog 的線程同步完成。

MySQL 主從復(fù)制過程

MySQL 集群的主從復(fù)制過程梳理成 3 個階段：

寫入 Binlog：主庫寫 binlog 日志，提交事務(wù)，并更新本地存儲數(shù)據(jù)。

同步 Binlog：把 binlog 復(fù)制到所有從庫上，每個從庫把 binlog 寫到暫存日志中。

回放 Binlog：回放 binlog，并更新存儲引擎中的數(shù)據(jù)。

具體詳細過程如下：

MySQL 主庫在收到客戶端提交事務(wù)的請求之后，會先寫入 binlog，再提交事務(wù)，更新存儲引擎中的數(shù)據(jù)，事務(wù)提交完成后，返回給客戶端“操作成功”的響應(yīng)。

從庫會創(chuàng)建一個專門的 I/O 線程，連接主庫的 log dump 線程，來接收主庫的 binlog 日志，再把 binlog 信息寫入 relay log 的中繼日志里，再返回給主庫“復(fù)制成功”的響應(yīng)。

從庫會創(chuàng)建一個用于回放 binlog 的線程，去讀 relay log 中繼日志，然后回放 binlog 更新存儲引擎中的數(shù)據(jù)，最終實現(xiàn)主從的數(shù)據(jù)一致性。

在完成主從復(fù)制之后，你就可以在寫數(shù)據(jù)時只寫主庫，在讀數(shù)據(jù)時只讀從庫，這樣即使寫請求會鎖表或者鎖記錄，也不會影響讀請求的執(zhí)行。

MySQL 主從架構(gòu)

binlog 兩階段提交過程是怎么樣的？

事務(wù)提交后，redo log 和 binlog 都要持久化到磁盤，但是這兩個是獨立的邏輯，可能出現(xiàn)半成功的狀態(tài)，這樣就造成兩份日志之間的邏輯不一致。

在 MySQL 的 InnoDB 存儲引擎中，開啟 binlog 的情況下，MySQL 會同時維護 binlog 日志與 InnoDB 的 redo log，為了保證這兩個日志的一致性，MySQL 使用了內(nèi)部 XA 事務(wù)（是的，也有外部 XA 事務(wù)，跟本文不太相關(guān)，我就不介紹了），內(nèi)部 XA 事務(wù)由 binlog 作為協(xié)調(diào)者，存儲引擎是參與者。

當(dāng)客戶端執(zhí)行 commit 語句或者在自動提交的情況下，MySQL 內(nèi)部開啟一個 XA 事務(wù)，分兩階段來完成 XA 事務(wù)的提交，如下圖：

兩階段提交

從圖中可看出，事務(wù)的提交過程有兩個階段，就是將 redo log 的寫入拆成了兩個步驟：prepare 和 commit，中間再穿插寫入binlog，具體如下：

prepare 階段：將 XID（內(nèi)部 XA 事務(wù)的 ID） 寫入到 redo log，同時將 redo log 對應(yīng)的事務(wù)狀態(tài)設(shè)置為 prepare，然后將 redo log 持久化到磁盤（innodb_flush_log_at_trx_commit = 1 的作用）；

commit 階段：把 XID 寫入到 binlog，然后將 binlog 持久化到磁盤（sync_binlog = 1 的作用），接著調(diào)用引擎的提交事務(wù)接口，將 redo log 狀態(tài)設(shè)置為 commit，此時該狀態(tài)并不需要持久化到磁盤，只需要 write 到文件系統(tǒng)的 page cache 中就夠了，因為只要 binlog 寫磁盤成功，就算 redo log 的狀態(tài)還是 prepare 也沒有關(guān)系，一樣會被認為事務(wù)已經(jīng)執(zhí)行成功；

我們來看看在兩階段提交的不同時刻，MySQL 異常重啟會出現(xiàn)什么現(xiàn)象？下圖中有時刻 A 和時刻 B 都有可能發(fā)生崩潰：

時刻 A 與時刻 B

不管是時刻 A（redo log 已經(jīng)寫入磁盤， binlog 還沒寫入磁盤），還是時刻 B （redo log 和 binlog 都已經(jīng)寫入磁盤，還沒寫入 commit 標識）崩潰，此時的 redo log 都處于 prepare 狀態(tài)。

在 MySQL 重啟后會按順序掃描 redo log 文件，碰到處于 prepare 狀態(tài)的 redo log，就拿著 redo log 中的 XID 去 binlog 查看是否存在此 XID：

如果 binlog 中沒有當(dāng)前內(nèi)部 XA 事務(wù)的 XID，說明 redolog 完成刷盤，但是 binlog 還沒有刷盤，則回滾事務(wù)。對應(yīng)時刻 A 崩潰恢復(fù)的情況。

如果 binlog 中有當(dāng)前內(nèi)部 XA 事務(wù)的 XID，說明 redolog 和 binlog 都已經(jīng)完成了刷盤，則提交事務(wù)。對應(yīng)時刻 B 崩潰恢復(fù)的情況。

可以看到，對于處于 prepare 階段的 redo log，即可以提交事務(wù)，也可以回滾事務(wù)，這取決于是否能在 binlog 中查找到與 redo log 相同的 XID，如果有就提交事務(wù)，如果沒有就回滾事務(wù)。這樣就可以保證 redo log 和 binlog 這兩份日志的一致性了。

所以說，兩階段提交是以 binlog 寫成功為事務(wù)提交成功的標識，因為 binlog 寫成功了，就意味著能在 binlog 中查找到與 redo log 相同的 XID。

Redis

redis分布式鎖實現(xiàn)

分布式鎖是用于分布式環(huán)境下并發(fā)控制的一種機制，用于控制某個資源在同一時刻只能被一個應(yīng)用所使用。如下圖所示：

img

Redis 本身可以被多個客戶端共享訪問，正好就是一個共享存儲系統(tǒng)，可以用來保存分布式鎖，而且 Redis 的讀寫性能高，可以應(yīng)對高并發(fā)的鎖操作場景。

Redis 的 SET 命令有個 NX 參數(shù)可以實現(xiàn)「key不存在才插入」，所以可以用它來實現(xiàn)分布式鎖：

如果 key 不存在，則顯示插入成功，可以用來表示加鎖成功；

如果 key 存在，則會顯示插入失敗，可以用來表示加鎖失敗。

基于 Redis 節(jié)點實現(xiàn)分布式鎖時，對于加鎖操作，我們需要滿足三個條件。

加鎖包括了讀取鎖變量、檢查鎖變量值和設(shè)置鎖變量值三個操作，但需要以原子操作的方式完成，所以，我們使用 SET 命令帶上 NX 選項來實現(xiàn)加鎖；

鎖變量需要設(shè)置過期時間，以免客戶端拿到鎖后發(fā)生異常，導(dǎo)致鎖一直無法釋放，所以，我們在 SET 命令執(zhí)行時加上 EX/PX 選項，設(shè)置其過期時間；

鎖變量的值需要能區(qū)分來自不同客戶端的加鎖操作，以免在釋放鎖時，出現(xiàn)誤釋放操作，所以，我們使用 SET 命令設(shè)置鎖變量值時，每個客戶端設(shè)置的值是一個唯一值，用于標識客戶端；

滿足這三個條件的分布式命令如下：

SETlock_keyunique_valueNXPX10000

lock_key 就是 key 鍵；

unique_value 是客戶端生成的唯一的標識，區(qū)分來自不同客戶端的鎖操作；

NX 代表只在 lock_key 不存在時，才對 lock_key 進行設(shè)置操作；

PX 10000 表示設(shè)置 lock_key 的過期時間為 10s，這是為了避免客戶端發(fā)生異常而無法釋放鎖。

而解鎖的過程就是將 lock_key 鍵刪除（del lock_key），但不能亂刪，要保證執(zhí)行操作的客戶端就是加鎖的客戶端。所以，解鎖的時候，我們要先判斷鎖的 unique_value 是否為加鎖客戶端，是的話，才將 lock_key 鍵刪除。

可以看到，解鎖是有兩個操作，這時就需要 Lua 腳本來保證解鎖的原子性，因為 Redis 在執(zhí)行 Lua 腳本時，可以以原子性的方式執(zhí)行，保證了鎖釋放操作的原子性。

//釋放鎖時，先比較unique_value是否相等，避免鎖的誤釋放
ifredis.call("get",KEYS[1])==ARGV[1]then
returnredis.call("del",KEYS[1])
else
return0
end

這樣一來，就通過使用 SET 命令和 Lua 腳本在 Redis 單節(jié)點上完成了分布式鎖的加鎖和解鎖。

redis緩存問題 穿透 雪崩 擊穿?

緩存雪崩：當(dāng)大量緩存數(shù)據(jù)在同一時間過期（失效）或者 Redis 故障宕機時，如果此時有大量的用戶請求，都無法在 Redis 中處理，于是全部請求都直接訪問數(shù)據(jù)庫，從而導(dǎo)致數(shù)據(jù)庫的壓力驟增，嚴重的會造成數(shù)據(jù)庫宕機，從而形成一系列連鎖反應(yīng)，造成整個系統(tǒng)崩潰，這就是緩存雪崩的問題。

image.png

緩存擊穿：如果緩存中的某個熱點數(shù)據(jù)過期了，此時大量的請求訪問了該熱點數(shù)據(jù)，就無法從緩存中讀取，直接訪問數(shù)據(jù)庫，數(shù)據(jù)庫很容易就被高并發(fā)的請求沖垮，這就是緩存擊穿的問題。

image.png

緩存穿透：當(dāng)用戶訪問的數(shù)據(jù)，既不在緩存中，也不在數(shù)據(jù)庫中，導(dǎo)致請求在訪問緩存時，發(fā)現(xiàn)緩存缺失，再去訪問數(shù)據(jù)庫時，發(fā)現(xiàn)數(shù)據(jù)庫中也沒有要訪問的數(shù)據(jù)，沒辦法構(gòu)建緩存數(shù)據(jù)，來服務(wù)后續(xù)的請求。那么當(dāng)有大量這樣的請求到來時，數(shù)據(jù)庫的壓力驟增，這就是緩存穿透的問題。

緩存雪崩解決方案：

均勻設(shè)置過期時間：如果要給緩存數(shù)據(jù)設(shè)置過期時間，應(yīng)該避免將大量的數(shù)據(jù)設(shè)置成同一個過期時間。我們可以在對緩存數(shù)據(jù)設(shè)置過期時間時，給這些數(shù)據(jù)的過期時間加上一個隨機數(shù)，這樣就保證數(shù)據(jù)不會在同一時間過期。

互斥鎖：當(dāng)業(yè)務(wù)線程在處理用戶請求時，如果發(fā)現(xiàn)訪問的數(shù)據(jù)不在 Redis 里，就加個互斥鎖，保證同一時間內(nèi)只有一個請求來構(gòu)建緩存（從數(shù)據(jù)庫讀取數(shù)據(jù)，再將數(shù)據(jù)更新到 Redis 里），當(dāng)緩存構(gòu)建完成后，再釋放鎖。未能獲取互斥鎖的請求，要么等待鎖釋放后重新讀取緩存，要么就返回空值或者默認值。實現(xiàn)互斥鎖的時候，最好設(shè)置超時時間，不然第一個請求拿到了鎖，然后這個請求發(fā)生了某種意外而一直阻塞，一直不釋放鎖，這時其他請求也一直拿不到鎖，整個系統(tǒng)就會出現(xiàn)無響應(yīng)的現(xiàn)象。

后臺更新緩存：業(yè)務(wù)線程不再負責(zé)更新緩存，緩存也不設(shè)置有效期，而是讓緩存“永久有效”，并將更新緩存的工作交由后臺線程定時更新。

緩存擊穿解決方案：

互斥鎖方案，保證同一時間只有一個業(yè)務(wù)線程更新緩存，未能獲取互斥鎖的請求，要么等待鎖釋放后重新讀取緩存，要么就返回空值或者默認值。

不給熱點數(shù)據(jù)設(shè)置過期時間，由后臺異步更新緩存，或者在熱點數(shù)據(jù)準備要過期前，提前通知后臺線程更新緩存以及重新設(shè)置過期時間；

緩存穿透解決方案：

非法請求的限制：當(dāng)有大量惡意請求訪問不存在的數(shù)據(jù)的時候，也會發(fā)生緩存穿透，因此在 API 入口處我們要判斷求請求參數(shù)是否合理，請求參數(shù)是否含有非法值、請求字段是否存在，如果判斷出是惡意請求就直接返回錯誤，避免進一步訪問緩存和數(shù)據(jù)庫。

緩存空值或者默認值：當(dāng)我們線上業(yè)務(wù)發(fā)現(xiàn)緩存穿透的現(xiàn)象時，可以針對查詢的數(shù)據(jù)，在緩存中設(shè)置一個空值或者默認值，這樣后續(xù)請求就可以從緩存中讀取到空值或者默認值，返回給應(yīng)用，而不會繼續(xù)查詢數(shù)據(jù)庫。

布隆過濾器：我們可以在寫入數(shù)據(jù)庫數(shù)據(jù)時，使用布隆過濾器做個標記，然后在用戶請求到來時，業(yè)務(wù)線程確認緩存失效后，可以通過查詢布隆過濾器快速判斷數(shù)據(jù)是否存在，如果不存在，就不用通過查詢數(shù)據(jù)庫來判斷數(shù)據(jù)是否存在。即使發(fā)生了緩存穿透，大量請求只會查詢 Redis 和布隆過濾器，而不會查詢數(shù)據(jù)庫，保證了數(shù)據(jù)庫能正常運行，Redis 自身也是支持布隆過濾器的。

redis寫回策略你了解哪些？

常見的緩存更新策略共有3種：

Cache Aside（旁路緩存）策略；

Read/Write Through（讀穿 / 寫穿）策略；

Write Back（寫回）策略；

實際開發(fā)中，Redis 和 MySQL 的更新策略用的是 Cache Aside，另外兩種策略應(yīng)用不了。

Cache Aside（旁路緩存）策略

Cache Aside（旁路緩存）策略是最常用的，應(yīng)用程序直接與「數(shù)據(jù)庫、緩存」交互，并負責(zé)對緩存的維護，該策略又可以細分為「讀策略」和「寫策略」。

寫策略的步驟：

先更新數(shù)據(jù)庫中的數(shù)據(jù)，再刪除緩存中的數(shù)據(jù)。

讀策略的步驟：

如果讀取的數(shù)據(jù)命中了緩存，則直接返回數(shù)據(jù)；

如果讀取的數(shù)據(jù)沒有命中緩存，則從數(shù)據(jù)庫中讀取數(shù)據(jù)，然后將數(shù)據(jù)寫入到緩存，并且返回給用戶。

注意，寫策略的步驟的順序不能倒過來，即不能先刪除緩存再更新數(shù)據(jù)庫，原因是在「讀+寫」并發(fā)的時候，會出現(xiàn)緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致性的問題。

舉個例子，假設(shè)某個用戶的年齡是 20，請求 A 要更新用戶年齡為 21，所以它會刪除緩存中的內(nèi)容。這時，另一個請求 B 要讀取這個用戶的年齡，它查詢緩存發(fā)現(xiàn)未命中后，會從數(shù)據(jù)庫中讀取到年齡為 20，并且寫入到緩存中，然后請求 A 繼續(xù)更改數(shù)據(jù)庫，將用戶的年齡更新為 21。

最終，該用戶年齡在緩存中是 20（舊值），在數(shù)據(jù)庫中是 21（新值），緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致。

為什么「先更新數(shù)據(jù)庫再刪除緩存」不會有數(shù)據(jù)不一致的問題？

繼續(xù)用「讀 + 寫」請求的并發(fā)的場景來分析。

假如某個用戶數(shù)據(jù)在緩存中不存在，請求 A 讀取數(shù)據(jù)時從數(shù)據(jù)庫中查詢到年齡為 20，在未寫入緩存中時另一個請求 B 更新數(shù)據(jù)。它更新數(shù)據(jù)庫中的年齡為 21，并且清空緩存。這時請求 A 把從數(shù)據(jù)庫中讀到的年齡為 20 的數(shù)據(jù)寫入到緩存中。

最終，該用戶年齡在緩存中是 20（舊值），在數(shù)據(jù)庫中是 21（新值），緩存和數(shù)據(jù)庫數(shù)據(jù)不一致。從上面的理論上分析，先更新數(shù)據(jù)庫，再刪除緩存也是會出現(xiàn)數(shù)據(jù)不一致性的問題，但是在實際中，這個問題出現(xiàn)的概率并不高。

因為緩存的寫入通常要遠遠快于數(shù)據(jù)庫的寫入，所以在實際中很難出現(xiàn)請求 B 已經(jīng)更新了數(shù)據(jù)庫并且刪除了緩存，請求 A 才更新完緩存的情況。而一旦請求 A 早于請求 B 刪除緩存之前更新了緩存，那么接下來的請求就會因為緩存不命中而從數(shù)據(jù)庫中重新讀取數(shù)據(jù)，所以不會出現(xiàn)這種不一致的情況。

Cache Aside 策略適合讀多寫少的場景，不適合寫多的場景，因為當(dāng)寫入比較頻繁時，緩存中的數(shù)據(jù)會被頻繁地清理，這樣會對緩存的命中率有一些影響。如果業(yè)務(wù)對緩存命中率有嚴格的要求，那么可以考慮兩種解決方案：

一種做法是在更新數(shù)據(jù)時也更新緩存，只是在更新緩存前先加一個分布式鎖，因為這樣在同一時間只允許一個線程更新緩存，就不會產(chǎn)生并發(fā)問題了。當(dāng)然這么做對于寫入的性能會有一些影響；

另一種做法同樣也是在更新數(shù)據(jù)時更新緩存，只是給緩存加一個較短的過期時間，這樣即使出現(xiàn)緩存不一致的情況，緩存的數(shù)據(jù)也會很快過期，對業(yè)務(wù)的影響也是可以接受。

Read/Write Through（讀穿 / 寫穿）策略

Read/Write Through（讀穿 / 寫穿）策略原則是應(yīng)用程序只和緩存交互，不再和數(shù)據(jù)庫交互，而是由緩存和數(shù)據(jù)庫交互，相當(dāng)于更新數(shù)據(jù)庫的操作由緩存自己代理了。

1、Read Through 策略

先查詢緩存中數(shù)據(jù)是否存在，如果存在則直接返回，如果不存在，則由緩存組件負責(zé)從數(shù)據(jù)庫查詢數(shù)據(jù)，并將結(jié)果寫入到緩存組件，最后緩存組件將數(shù)據(jù)返回給應(yīng)用。

2、Write Through 策略

當(dāng)有數(shù)據(jù)更新的時候，先查詢要寫入的數(shù)據(jù)在緩存中是否已經(jīng)存在：

如果緩存中數(shù)據(jù)已經(jīng)存在，則更新緩存中的數(shù)據(jù)，并且由緩存組件同步更新到數(shù)據(jù)庫中，然后緩存組件告知應(yīng)用程序更新完成。

如果緩存中數(shù)據(jù)不存在，直接更新數(shù)據(jù)庫，然后返回；

下面是 Read Through/Write Through 策略的示意圖：

img

Read Through/Write Through 策略的特點是由緩存節(jié)點而非應(yīng)用程序來和數(shù)據(jù)庫打交道，在我們開發(fā)過程中相比 Cache Aside 策略要少見一些，原因是我們經(jīng)常使用的分布式緩存組件，無論是 Memcached 還是 Redis 都不提供寫入數(shù)據(jù)庫和自動加載數(shù)據(jù)庫中的數(shù)據(jù)的功能。而我們在使用本地緩存的時候可以考慮使用這種策略。

Write Back（寫回）策略

Write Back（寫回）策略在更新數(shù)據(jù)的時候，只更新緩存，同時將緩存數(shù)據(jù)設(shè)置為臟的，然后立馬返回，并不會更新數(shù)據(jù)庫。對于數(shù)據(jù)庫的更新，會通過批量異步更新的方式進行。

實際上，Write Back（寫回）策略也不能應(yīng)用到我們常用的數(shù)據(jù)庫和緩存的場景中，因為 Redis 并沒有異步更新數(shù)據(jù)庫的功能。

Write Back 是計算機體系結(jié)構(gòu)中的設(shè)計，比如 CPU 的緩存、操作系統(tǒng)中文件系統(tǒng)的緩存都采用了 Write Back（寫回）策略。

Write Back 策略特別適合寫多的場景，因為發(fā)生寫操作的時候， 只需要更新緩存，就立馬返回了。比如，寫文件的時候，實際上是寫入到文件系統(tǒng)的緩存就返回了，并不會寫磁盤。

但是帶來的問題是，數(shù)據(jù)不是強一致性的，而且會有數(shù)據(jù)丟失的風(fēng)險，因為緩存一般使用內(nèi)存，而內(nèi)存是非持久化的，所以一旦緩存機器掉電，就會造成原本緩存中的臟數(shù)據(jù)丟失。所以你會發(fā)現(xiàn)系統(tǒng)在掉電之后，之前寫入的文件會有部分丟失，就是因為 Page Cache 還沒有來得及刷盤造成的。

這里貼一張 CPU 緩存與內(nèi)存使用 Write Back 策略的流程圖：

img

其他

Go：

context是否線程安全？

slice底層實現(xiàn)？

GMP模型介紹一下

場景題：

設(shè)計短鏈系統(tǒng)

算法：

最長公共前綴

三數(shù)之和

審核編輯：湯梓紅