阿里巴巴一面 ：十道经典面试题解析
1. 用到分布式事務(wù)嘛?為什么用這種方案,有其他方案嘛?
什么是分布式事務(wù)
談到事務(wù)，我們就會(huì)想到數(shù)據(jù)庫(kù)事務(wù)，很容易就想到原子性、一致性、持久性、隔離性。
分布式事務(wù)跟數(shù)據(jù)庫(kù)事務(wù)有點(diǎn)不一樣，它是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。簡(jiǎn)單來(lái)說(shuō)，分布式事務(wù)指的就是分布式系統(tǒng)中的事務(wù)，它的存在就是為了保證不同數(shù)據(jù)庫(kù)節(jié)點(diǎn)的數(shù)據(jù)一致性。
分布式事務(wù)基礎(chǔ)
分布式事務(wù)需要需要知道CAP理論和BASE理論。
CAP理論
- 一致性(C：Consistency)：一致性是指數(shù)據(jù)在多個(gè)副本之間能否保持一致的特性。例如一個(gè)數(shù)據(jù)在某個(gè)分區(qū)節(jié)點(diǎn)更新之后，在其他分區(qū)節(jié)點(diǎn)讀出來(lái)的數(shù)據(jù)也是更新之后的數(shù)據(jù)。
- 可用性(A：Availability)：可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對(duì)于用戶(hù)的每一個(gè)操作請(qǐng)求總是能夠在有限的時(shí)間內(nèi)返回結(jié)果。這里的重點(diǎn)是"有限時(shí)間內(nèi)"和"返回結(jié)果"。
- 分區(qū)容錯(cuò)性（P:Partition tolerance）:分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然需要能夠保證對(duì)外提供滿(mǎn)足一致性和可用性的服務(wù)。
一個(gè)分布式系統(tǒng)中，CAP理論它只能同時(shí)滿(mǎn)足（一致性、可用性、分區(qū)容錯(cuò)性）中的兩點(diǎn)。
BASE 理論
BASE 理論， 是對(duì)CAP中AP的一個(gè)擴(kuò)展，對(duì)于我們的業(yè)務(wù)系統(tǒng)，我們考慮犧牲一致性來(lái)?yè)Q取系統(tǒng)的可用性和分區(qū)容錯(cuò)性。BASE是Basically Available(基本可用)，Soft state（軟狀態(tài)）,和 Eventually consistent（最終一致性）三個(gè)短語(yǔ)的縮寫(xiě)。
- 基本可用是指，通過(guò)支持局部故障而不是系統(tǒng)全局故障來(lái)實(shí)現(xiàn)的；
- Soft State表示狀態(tài)可以有一段時(shí)間不同步；
- 最終一致，最終數(shù)據(jù)是一致的就可以了，而不是實(shí)時(shí)保持強(qiáng)一致。
分布式事務(wù)的幾種解決方案
- 2PC(二階段提交)方案，事務(wù)的提交分為兩個(gè)階段：準(zhǔn)備階段和提交執(zhí)行方案。
- TCC（即Try、Confirm、Cancel），它采用了補(bǔ)償機(jī)制，核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷(xiāo)）操作。
- 本地消息表，它的核心思想就是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理。
- 最大努力通知，實(shí)現(xiàn)最大努力通知，可以采用MQ的ack機(jī)制。
- Saga事務(wù)，它的核心思想是將長(zhǎng)事務(wù)拆分為多個(gè)本地短事務(wù)，由Saga事務(wù)協(xié)調(diào)器協(xié)調(diào)，如果正常結(jié)束那就正常完成，如果某個(gè)步驟失敗，則根據(jù)相反順序一次調(diào)用補(bǔ)償操作。
業(yè)界目前使用本地消息表這種方案是比較多的，它的核心思想就是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理?？梢钥匆幌禄镜膶?shí)現(xiàn)流程圖吧：
對(duì)于消息發(fā)送方：
- 首先需要有一個(gè)消息表，記錄著消息狀態(tài)相關(guān)信息。
- 業(yè)務(wù)數(shù)據(jù)和消息表在同一個(gè)數(shù)據(jù)庫(kù)，即要保證它倆在同一個(gè)本地事務(wù)。
- 在本地事務(wù)中處理完業(yè)務(wù)數(shù)據(jù)和寫(xiě)消息表操作后，通過(guò)寫(xiě)消息到MQ消息隊(duì)列。
- 消息會(huì)發(fā)到消息消費(fèi)方，如果發(fā)送失敗，即進(jìn)行重試。
消息消費(fèi)方：
- 處理消息隊(duì)列中的消息，完成自己的業(yè)務(wù)邏輯。
- 此時(shí)如果本地事務(wù)處理成功，則表明已經(jīng)處理成功了。
- 如果本地事務(wù)處理失敗，那么就會(huì)重試執(zhí)行。
- 如果是業(yè)務(wù)上面的失敗，給消息生產(chǎn)方發(fā)送一個(gè)業(yè)務(wù)補(bǔ)償消息，通知進(jìn)行回滾等操作。
生產(chǎn)方和消費(fèi)方定時(shí)掃描本地消息表，把還沒(méi)處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動(dòng)對(duì)賬補(bǔ)賬邏輯，這種方案還是非常實(shí)用的。
2.JDK6、7、8分別提供了哪些新特性
JDK 6 新特性
- Desktop類(lèi)（它允許一個(gè)Java應(yīng)用程序啟動(dòng)本地的另一個(gè)應(yīng)用程序去處理URI或文件請(qǐng)求）
- 使用JAXB2來(lái)實(shí)現(xiàn)對(duì)象與XML之間的映射
- 輕量級(jí) Http Server API
- 插入式注解處理API（lombok框架基于這個(gè)特性實(shí)現(xiàn)）
- STAX（是JDK6中一種處理XML文檔的API）
JDK 7的新特性
- switch 支持String字符串類(lèi)型
- try-with-resources，資源自動(dòng)關(guān)閉
- 整數(shù)類(lèi)型如（byte，short，int，long）能夠用二進(jìn)制來(lái)表示
- 數(shù)字常量支持下劃線
- 泛型實(shí)例化類(lèi)型自動(dòng)推斷,即”<>”
- 一個(gè)catch中捕獲多個(gè)異常類(lèi)型，用（|）分隔開(kāi)
- 增強(qiáng)的文件系統(tǒng)
- Fork/join 框架
JDK8 的新特性
- lambada表達(dá)式
- 函數(shù)式接口
- 方法引用
- 默認(rèn)方法
- Stream API
- Optional
- Date Time API（如LocalDate）
- 重復(fù)注解
- Base64
- JVM的新特性（如元空間Metaspace代替持久代）
3. https原理，工作流程
- HTTPS = HTTP + SSL/TLS，即用SSL/TLS對(duì)數(shù)據(jù)進(jìn)行加密和解密，Http進(jìn)行傳輸。
- SSL，即Secure Sockets Layer（安全套接層協(xié)議），是網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。
- TLS，即Transport Layer Security(安全傳輸層協(xié)議)，它是SSL3.0的后續(xù)版本。
4. 講講java jmm volatile的實(shí)現(xiàn)原理
volatile關(guān)鍵字是Java虛擬機(jī)提供的的最輕量級(jí)的同步機(jī)制，它作為一個(gè)修飾符，用來(lái)修飾變量。它保證變量對(duì)所有線程可見(jiàn)性，禁止指令重排，但是不保證原子性。
volatile是如何保證可見(jiàn)性的呢？我們先來(lái)看下java內(nèi)存模型（jmm）
- Java虛擬機(jī)規(guī)范試圖定義一種Java內(nèi)存模型,來(lái)屏蔽掉各種硬件和操作系統(tǒng)的內(nèi)存訪問(wèn)差異，以實(shí)現(xiàn)讓Java程序在各種平臺(tái)上都能達(dá)到一致的內(nèi)存訪問(wèn)效果。
- 為了更好的執(zhí)行性能，java內(nèi)存模型并沒(méi)有限制執(zhí)行引擎使用處理器的特定寄存器或緩存來(lái)和主內(nèi)存打交道，也沒(méi)有限制編譯器進(jìn)行調(diào)整代碼順序優(yōu)化。所以Java內(nèi)存模型會(huì)存在緩存一致性問(wèn)題和指令重排序問(wèn)題的。
- Java內(nèi)存模型規(guī)定所有的變量都是存在主內(nèi)存當(dāng)中，每個(gè)線程都有自己的工作內(nèi)存。這里的變量包括實(shí)例變量和靜態(tài)變量，但是不包括局部變量，因?yàn)榫植孔兞渴蔷€程私有的。
- 線程的工作內(nèi)存保存了被該線程使用的變量的主內(nèi)存副本，線程對(duì)變量的所有操作都必須在工作內(nèi)存中進(jìn)行，而不能直接操作操作主內(nèi)存。并且每個(gè)線程不能訪問(wèn)其他線程的工作內(nèi)存。
volatile變量，保證新值能立即同步回主內(nèi)存，以及每次使用前立即從主內(nèi)存刷新，所以我們說(shuō)volatile保證了多線程操作變量的可見(jiàn)性。
指令重排是指在程序執(zhí)行過(guò)程中,為了提高性能, 編譯器和CPU可能會(huì)對(duì)指令進(jìn)行重新排序。volatile是如何禁止指令重排的？在Java語(yǔ)言中，有一個(gè)先行發(fā)生原則（happens-before）
- 程序次序規(guī)則：在一個(gè)線程內(nèi)，按照控制流順序，書(shū)寫(xiě)在前面的操作先行發(fā)生于書(shū)寫(xiě)在后面的操作。
- 管程鎖定規(guī)則：一個(gè)unLock操作先行發(fā)生于后面對(duì)同一個(gè)鎖額lock操作
- volatile變量規(guī)則：對(duì)一個(gè)變量的寫(xiě)操作先行發(fā)生于后面對(duì)這個(gè)變量的讀操作
- 線程啟動(dòng)規(guī)則：Thread對(duì)象的start()方法先行發(fā)生于此線程的每個(gè)一個(gè)動(dòng)作
- 線程終止規(guī)則：線程中所有的操作都先行發(fā)生于線程的終止檢測(cè)，我們可以通過(guò)Thread.join()方法結(jié)束、Thread.isAlive()的返回值手段檢測(cè)到線程已經(jīng)終止執(zhí)行
- 線程中斷規(guī)則：對(duì)線程interrupt()方法的調(diào)用先行發(fā)生于被中斷線程的代碼檢測(cè)到中斷事件的發(fā)生
- 對(duì)象終結(jié)規(guī)則：一個(gè)對(duì)象的初始化完成先行發(fā)生于他的finalize()方法的開(kāi)始
- 傳遞性：如果操作A先行發(fā)生于操作B，而操作B又先行發(fā)生于操作C，則可以得出操作A先行發(fā)生于操作C
實(shí)際上volatile保證可見(jiàn)性和禁止指令重排都跟內(nèi)存屏障有關(guān)。我們來(lái)看一段volatile使用的demo代碼
public class Singleton { private volatile static Singleton instance; private Singleton (){} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } } 復(fù)制代碼編譯后，對(duì)比有volatile關(guān)鍵字和沒(méi)有volatile關(guān)鍵字時(shí)所生成的匯編代碼，發(fā)現(xiàn)有volatile關(guān)鍵字修飾時(shí)，會(huì)多出一個(gè)lock addl $0x0,(%esp)，即多出一個(gè)lock前綴指令，lock指令相當(dāng)于一個(gè)「內(nèi)存屏障」
lock指令相當(dāng)于一個(gè)內(nèi)存屏障，它保證以下這幾點(diǎn)：
- 1.重排序時(shí)不能把后面的指令重排序到內(nèi)存屏障之前的位置
- 2.將本處理器的緩存寫(xiě)入內(nèi)存
- 3.如果是寫(xiě)入動(dòng)作，會(huì)導(dǎo)致其他處理器中對(duì)應(yīng)的緩存無(wú)效。
第2點(diǎn)和第3點(diǎn)就是保證volatile保證可見(jiàn)性的體現(xiàn)嘛，第1點(diǎn)就是禁止指令重排列的體現(xiàn)。內(nèi)存屏障又是什么呢？
內(nèi)存屏障四大分類(lèi)：（Load 代表讀取指令，Store代表寫(xiě)入指令）
| LoadLoad屏障 | Load1; LoadLoad; Load2 | 在Load2要讀取的數(shù)據(jù)被訪問(wèn)前，保證Load1要讀取的數(shù)據(jù)被讀取完畢。 |
| StoreStore屏障 | Store1; StoreStore; Store2 | 在Store2寫(xiě)入執(zhí)行前，保證Store1的寫(xiě)入操作對(duì)其它處理器可見(jiàn) |
| LoadStore屏障 | Load1; LoadStore; Store2 | 在Store2被寫(xiě)入前，保證Load1要讀取的數(shù)據(jù)被讀取完畢。 |
| StoreLoad屏障 | Store1; StoreLoad; Load2 | 在Load2讀取操作執(zhí)行前，保證Store1的寫(xiě)入對(duì)所有處理器可見(jiàn)。 |
為了實(shí)現(xiàn)volatile的內(nèi)存語(yǔ)義，Java內(nèi)存模型采取以下的保守策略
- 在每個(gè)volatile寫(xiě)操作的前面插入一個(gè)StoreStore屏障。
- 在每個(gè)volatile寫(xiě)操作的后面插入一個(gè)StoreLoad屏障。
- 在每個(gè)volatile讀操作的后面插入一個(gè)LoadLoad屏障。
- 在每個(gè)volatile讀操作的后面插入一個(gè)LoadStore屏障。
有些小伙伴，可能對(duì)這個(gè)還是有點(diǎn)疑惑，內(nèi)存屏障這玩意太抽象了。我們照著代碼看下吧：
內(nèi)存屏障保證前面的指令先執(zhí)行，所以這就保證了禁止了指令重排啦，同時(shí)內(nèi)存屏障保證緩存寫(xiě)入內(nèi)存和其他處理器緩存失效，這也就保證了可見(jiàn)性，哈哈~
5. 講一講7層網(wǎng)絡(luò)模型，tcp的為什么要三次握手
計(jì)算機(jī)網(wǎng)路體系結(jié)構(gòu)有三層：OSI七層模型、TCP/IP四層模型、五層體系結(jié)構(gòu),如圖：
七層模型，亦稱(chēng)OSI（Open System Interconnection），國(guó)際標(biāo)準(zhǔn)化組織（International Organization for Standardization）制定的一個(gè)用于計(jì)算機(jī)或通信系統(tǒng)間互聯(lián)的標(biāo)準(zhǔn)體系。
- 應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶(hù)的一個(gè)接口，常見(jiàn)的協(xié)議有：HTTP FTP SMTP SNMP DNS.
- 表示層：數(shù)據(jù)的表示、安全、壓縮。，確保一個(gè)系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取。
- 會(huì)話層：建立、管理、終止會(huì)話,對(duì)應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會(huì)話.
- 傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號(hào)，以及流控和差錯(cuò)校驗(yàn),協(xié)議有TCP UDP.
- 網(wǎng)絡(luò)層：進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇,協(xié)議有ICMP IGMP IP等.
- 數(shù)據(jù)鏈路層：在物理層提供比特流服務(wù)的基礎(chǔ)上，建立相鄰結(jié)點(diǎn)之間的數(shù)據(jù)鏈路。
- 物理層：建立、維護(hù)、斷開(kāi)物理連接。
6.說(shuō)說(shuō)線程池的工作原理
面試官如果要我們講下線程池工作原理的話，大家講下以下這個(gè)流程圖就可以啦：
為了形象描述線程池執(zhí)行，加深大家的理解，我打個(gè)比喻：
- 核心線程比作公司正式員工
- 非核心線程比作外包員工
- 阻塞隊(duì)列比作需求池
- 提交任務(wù)比作提需求
- 當(dāng)產(chǎn)品提個(gè)需求，正式員工（核心線程）先接需求（執(zhí)行任務(wù)）
- 如果正式員工都有需求在做，即核心線程數(shù)已滿(mǎn)），產(chǎn)品就把需求先放需求池（阻塞隊(duì)列）。
- 如果需求池(阻塞隊(duì)列)也滿(mǎn)了，但是這時(shí)候產(chǎn)品繼續(xù)提需求,怎么辦呢？那就請(qǐng)外包（非核心線程）來(lái)做。
- 如果所有員工（最大線程數(shù)也滿(mǎn)了）都有需求在做了，那就執(zhí)行拒絕策略。
- 如果外包員工把需求做完了，它經(jīng)過(guò)一段（keepAliveTime）空閑時(shí)間，就離開(kāi)公司了。
7.你們數(shù)據(jù)庫(kù)的高可用是怎么實(shí)現(xiàn)的?
高可用，即High Availability，是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一，它通常是指，通過(guò)設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間。單機(jī)部署談不上高可用，因?yàn)?strong>單點(diǎn)故障問(wèn)題。高可用都是多個(gè)節(jié)點(diǎn)的，我們?cè)诳紤]MySQL數(shù)據(jù)庫(kù)的高可用的架構(gòu)時(shí)，需要考慮這幾個(gè)方面：
- 如果數(shù)據(jù)庫(kù)節(jié)點(diǎn)宕機(jī)，需要盡快回復(fù)，保證業(yè)務(wù)不受宕機(jī)影響。
- 從數(shù)據(jù)庫(kù)節(jié)點(diǎn)的數(shù)據(jù)，盡可能跟主節(jié)點(diǎn)數(shù)據(jù)實(shí)時(shí)保持一致，至少保證最終一致性。
- 數(shù)據(jù)庫(kù)節(jié)點(diǎn)切換時(shí)，數(shù)據(jù)不能缺失。
7.1 主從或主主半同步復(fù)制
用雙節(jié)點(diǎn)數(shù)據(jù)庫(kù)，搭建單向或者雙向的半同步復(fù)制。架構(gòu)如下：
通常會(huì)和proxy、keepalived等第三方軟件同時(shí)使用，即可以用來(lái)監(jiān)控?cái)?shù)據(jù)庫(kù)的健康，又可以執(zhí)行一系列管理命令。如果主庫(kù)發(fā)生故障，切換到備庫(kù)后仍然可以繼續(xù)使用數(shù)據(jù)庫(kù)。
這種方案優(yōu)點(diǎn)是架構(gòu)、部署比較簡(jiǎn)單，主機(jī)宕機(jī)直接切換即可。缺點(diǎn)是完全依賴(lài)于半同步復(fù)制，半同步復(fù)制退化為異步復(fù)制，無(wú)法保證數(shù)據(jù)一致性；另外，還需要額外考慮haproxy、keepalived的高可用機(jī)制。
7.2 半同步復(fù)制優(yōu)化
半同步復(fù)制機(jī)制是可靠的，可以保證數(shù)據(jù)一致性的。但是如果網(wǎng)絡(luò)發(fā)生波動(dòng)，半同步復(fù)制發(fā)生超時(shí)會(huì)切換為異步復(fù)制，異復(fù)制是無(wú)法保證數(shù)據(jù)的一致性的。因此，可以在半同復(fù)制的基礎(chǔ)上優(yōu)化一下，盡可能保證半同復(fù)制。如雙通道復(fù)制方案
- 優(yōu)點(diǎn)：這種方案架構(gòu)、部署也比較簡(jiǎn)單，主機(jī)宕機(jī)也是直接切換即可。比方案1的半同步復(fù)制，更能保證數(shù)據(jù)的一致性。
- 缺點(diǎn)：需要修改內(nèi)核源碼或者使用mysql通信協(xié)議，沒(méi)有從根本上解決數(shù)據(jù)一致性問(wèn)題。
7.3 高可用架構(gòu)優(yōu)化
保證高可用，可以把主從雙節(jié)點(diǎn)數(shù)據(jù)庫(kù)擴(kuò)展為數(shù)據(jù)庫(kù)集群。Zookeeper可以作為集群管理，它使用分布式算法保證集群數(shù)據(jù)的一致性，可以較好的避免網(wǎng)絡(luò)分區(qū)現(xiàn)象的產(chǎn)生。
- 優(yōu)點(diǎn)：保證了整個(gè)系統(tǒng)的高可用性，擴(kuò)展性也較好，可以擴(kuò)展為大規(guī)模集群。
- 缺點(diǎn)：數(shù)據(jù)一致性仍然依賴(lài)于原生的mysql半同步復(fù)制；引入Zookeeper使系統(tǒng)邏輯更復(fù)雜。
7.4 共享存儲(chǔ)
共享存儲(chǔ)實(shí)現(xiàn)了數(shù)據(jù)庫(kù)服務(wù)器和存儲(chǔ)設(shè)備的解耦，不同數(shù)據(jù)庫(kù)之間的數(shù)據(jù)同步不再依賴(lài)于MySQL的原生復(fù)制功能，而是通過(guò)磁盤(pán)數(shù)據(jù)同步的手段，來(lái)保證數(shù)據(jù)的一致性。
DRBD磁盤(pán)復(fù)制
DRBD是一個(gè)用軟件實(shí)現(xiàn)的、無(wú)共享的、服務(wù)器之間鏡像塊設(shè)備內(nèi)容的存儲(chǔ)復(fù)制解決方案。主要用于對(duì)服務(wù)器之間的磁盤(pán)、分區(qū)、邏輯卷等進(jìn)行數(shù)據(jù)鏡像，當(dāng)用戶(hù)將數(shù)據(jù)寫(xiě)入本地磁盤(pán)時(shí)，還會(huì)將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺(tái)主機(jī)的磁盤(pán)上，這樣的本地主機(jī)(主節(jié)點(diǎn))與遠(yuǎn)程主機(jī)(備節(jié)點(diǎn))的數(shù)據(jù)就可以保證實(shí)時(shí)同步。常用架構(gòu)如下：
當(dāng)本地主機(jī)出現(xiàn)問(wèn)題，遠(yuǎn)程主機(jī)上還保留著一份相同的數(shù)據(jù)，即可以繼續(xù)使用，保證了數(shù)據(jù)的安全。
- 優(yōu)點(diǎn)：部署簡(jiǎn)單，價(jià)格合適，保證數(shù)據(jù)的強(qiáng)一致性
- 缺點(diǎn)：對(duì)IO性能影響較大，從庫(kù)不提供讀操作
7.5 分布式協(xié)議
分布式協(xié)議可以很好解決數(shù)據(jù)一致性問(wèn)題。常見(jiàn)的部署方案就是MySQL cluster，它是官方集群的部署方案，通過(guò)使用NDB存儲(chǔ)引擎實(shí)時(shí)備份冗余數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)庫(kù)的高可用性和數(shù)據(jù)一致性。如下：
- 優(yōu)點(diǎn)：不依賴(lài)于第三方軟件，可以實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致性；
- 缺點(diǎn)：配置較復(fù)雜；需要使用NDB儲(chǔ)存引擎；至少三節(jié)點(diǎn)；
8. 讀寫(xiě)分離的場(chǎng)景下,怎么保證從數(shù)據(jù)庫(kù)讀到最新的數(shù)據(jù)?
數(shù)據(jù)庫(kù)讀寫(xiě)分離，主要解決高并發(fā)時(shí)，提高系統(tǒng)的吞吐量。來(lái)看下讀寫(xiě)分離數(shù)據(jù)庫(kù)模型：
- 寫(xiě)請(qǐng)求是直接寫(xiě)主庫(kù)，然后同步數(shù)據(jù)到從庫(kù)
- 讀請(qǐng)求一般直接讀從庫(kù)，除飛強(qiáng)制讀主庫(kù)
在高并發(fā)場(chǎng)景或者網(wǎng)絡(luò)不佳的場(chǎng)景，如果存在較大的主從同步數(shù)據(jù)延遲，這時(shí)候讀請(qǐng)求去讀從庫(kù)，就會(huì)讀到舊數(shù)據(jù)。這時(shí)候最簡(jiǎn)單暴力的方法，就是強(qiáng)制讀主庫(kù)。實(shí)際上可以使用緩存標(biāo)記法。
- A發(fā)起寫(xiě)請(qǐng)求，更新主庫(kù)數(shù)據(jù)，并在緩存中設(shè)置一個(gè)標(biāo)記，表示數(shù)據(jù)已更新，標(biāo)記格式為：userId+業(yè)務(wù)Id。
- 設(shè)置此標(biāo)記，設(shè)置過(guò)期時(shí)間（估值為主庫(kù)和從庫(kù)同步延遲的時(shí)間）
- B發(fā)起讀請(qǐng)求，先判斷此請(qǐng)求，在緩存中有沒(méi)有更新標(biāo)記。
- 如果存在標(biāo)記，走主庫(kù)；如果沒(méi)有，請(qǐng)求走從庫(kù)。
這個(gè)方案，解決了數(shù)據(jù)不一致問(wèn)題，但是每次請(qǐng)求都要先跟緩存打交道，會(huì)影響系統(tǒng)吞吐。
9. 如何保證MySQL數(shù)據(jù)不丟？
MySQL這種關(guān)系型數(shù)據(jù)庫(kù)，是日志先行策略（Write-Ahead Logging），只要binlog和redo log日志能保證持久化到磁盤(pán)，我們就能確保MySQL異常重啟后，數(shù)據(jù)不丟失。
binlog日志
binlog，又稱(chēng)為二進(jìn)制日志，它會(huì)記錄數(shù)據(jù)庫(kù)執(zhí)行更改的所有操作，但是不包括查詢(xún)select等操作。一般用于恢復(fù)、復(fù)制等功能。它的格式有三種：statement、mixed和row。
- statement：每一條會(huì)修改數(shù)據(jù)的sql都會(huì)記錄到binlog中，不建議使用。
- row：基于行的變更情況記錄，會(huì)記錄行更改前后的內(nèi)容，推薦使用。
- mixed：混合statement和row兩個(gè)模式，不建議使用。
binlog 的寫(xiě)入機(jī)制是怎樣的呢？
事務(wù)執(zhí)行過(guò)程中，先把日志寫(xiě)到 binlog cache，事務(wù)提交的時(shí)候，再把binlog cache寫(xiě)到binlog文件中 。
系統(tǒng)為每個(gè)客戶(hù)端線程分配一個(gè)binlog cache，其大小值控制參數(shù)是binlog_cache_size。如果binlog cache的值超過(guò)閥值，就會(huì)臨時(shí)持久化到磁盤(pán)。當(dāng)事務(wù)提交的時(shí)候，再將 binlog cache中完整的事務(wù)持久化到磁盤(pán)中，并且清空binlog cache。
binlog寫(xiě)文件分write和fsync兩個(gè)過(guò)程：
- write：指把日志寫(xiě)到文件系統(tǒng)的page cache，并沒(méi)有把數(shù)據(jù)持久化到磁盤(pán)，因此速度較快。
- fsync，實(shí)際的寫(xiě)盤(pán)操作，即把數(shù)據(jù)持久化到磁盤(pán)。
write和fsync的寫(xiě)入時(shí)機(jī)，是由變量sync_binlog控制的：
如果IO出現(xiàn)性能瓶頸，可以將sync_binlog設(shè)置成一個(gè)較大的值。比如設(shè)置為（100~1000）。但是，會(huì)存在數(shù)據(jù)丟失的風(fēng)險(xiǎn)，當(dāng)主機(jī)異常重啟時(shí)，會(huì)丟失N個(gè)最近提交的事務(wù)binlog。
redo log日志
redo log，又稱(chēng)為重做日志文件，只記錄事務(wù)對(duì)數(shù)據(jù)頁(yè)做了哪些修改，它記錄的是數(shù)據(jù)修改之后的值。redo 有三種狀態(tài)
- 物理上是在MySQL進(jìn)程內(nèi)存中，存在redo log buffer中，
- 物理上在文件系統(tǒng)的page cache里，寫(xiě)到磁盤(pán) (write)，但是還沒(méi)有持久化（fsync)。
- 存在hard disk，已經(jīng)持久化到磁盤(pán)。
日志寫(xiě)到redo log buffer是很快的；wirte到page cache也很快，但是持久化到磁盤(pán)的速度就慢多了。
為了控制redo log的寫(xiě)入策略，Innodb根據(jù)innodb_flush_log_at_trx_commit參數(shù)不同的取值采用不同的策略，它有三種不同的取值：
- 設(shè)置為0時(shí)，表示每次事務(wù)提交時(shí)都只是把redo log留在redo log buffer 中 ;
- 設(shè)置為1時(shí)，表示每次事務(wù)提交時(shí)都將 redo log 直接持久化到磁盤(pán)；
- 設(shè)置為2時(shí)，表示每次事務(wù)提交時(shí)都只是把redo log 寫(xiě)到page cache。
三種模式下，0的性能最好，但是不安全，MySQL進(jìn)程一旦崩潰會(huì)導(dǎo)致丟失一秒的數(shù)據(jù)。1的安全性最高，但是對(duì)性能影響最大，2的話主要由操作系統(tǒng)自行控制刷磁盤(pán)的時(shí)間，如果僅僅是MySQL宕機(jī)，對(duì)數(shù)據(jù)不會(huì)產(chǎn)生影響，如果是主機(jī)異常宕機(jī)了，同樣會(huì)丟失數(shù)據(jù)。
10. 高并發(fā)下如何設(shè)計(jì)秒殺系統(tǒng)？
設(shè)計(jì)一個(gè)秒殺系統(tǒng)，需要考慮這些問(wèn)題：
如何解決這些問(wèn)題呢？
- 頁(yè)面靜態(tài)化
- 按鈕至灰控制
- 服務(wù)單一職責(zé)
- 秒殺鏈接加鹽
- 限流
- 分布式鎖
- MQ異步處理
- 限流&降級(jí)&熔斷
頁(yè)面靜態(tài)化
秒殺活動(dòng)的頁(yè)面，大多數(shù)內(nèi)容都是固定不變的，如商品名稱(chēng)，商品圖片等等，可以對(duì)活動(dòng)頁(yè)面做靜態(tài)化處理，減少訪問(wèn)服務(wù)端的請(qǐng)求。秒殺用戶(hù)會(huì)分布在全國(guó)各地，有的在上海，有的在深圳，地域相差很遠(yuǎn)，網(wǎng)速也各不相同。為了讓用戶(hù)最快訪問(wèn)到活動(dòng)頁(yè)面，可以使用CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）。CDN可以讓用戶(hù)就近獲取所需內(nèi)容。
按鈕至灰控制
秒殺活動(dòng)開(kāi)始前，按鈕一般需要置灰的。只有時(shí)間到了，才能變得可以點(diǎn)擊。這是防止，秒殺用戶(hù)在時(shí)間快到的前幾秒，瘋狂請(qǐng)求服務(wù)器，然后秒殺時(shí)間點(diǎn)還沒(méi)到，服務(wù)器就自己掛了。
服務(wù)單一職責(zé)
我們都知道微服務(wù)設(shè)計(jì)思想，也就是把各個(gè)功能模塊拆分，功能那個(gè)類(lèi)似的放一起，再用分布式的部署方式。
如用戶(hù)登錄相關(guān)的，就設(shè)計(jì)個(gè)用戶(hù)服務(wù)，訂單相關(guān)的就搞個(gè)訂單服務(wù)，再到禮物相關(guān)的就搞個(gè)禮物服務(wù)等等。那么，秒殺相關(guān)的業(yè)務(wù)邏輯也可以放到一起，搞個(gè)秒殺服務(wù)，單獨(dú)給它搞個(gè)秒殺數(shù)據(jù)庫(kù)。
服務(wù)單一職責(zé)有個(gè)好處：如果秒殺沒(méi)抗住高并發(fā)的壓力，秒殺庫(kù)崩了，服務(wù)掛了，也不會(huì)影響到系統(tǒng)的其他服務(wù)。
秒殺鏈接加鹽
鏈接如果明文暴露的話，會(huì)有人獲取到請(qǐng)求Url，提前秒殺了。因此，需要給秒殺鏈接加鹽?？梢园裊RL動(dòng)態(tài)化，如通過(guò)MD5加密算法加密隨機(jī)的字符串去做url。
限流
一般有兩種方式限流：nginx限流和redis限流。
- 為了防止某個(gè)用戶(hù)請(qǐng)求過(guò)于頻繁，我們可以對(duì)同一用戶(hù)限流；
- 為了防止黃牛模擬幾個(gè)用戶(hù)請(qǐng)求，我們可以對(duì)某個(gè)IP進(jìn)行限流；
- 為了防止有人使用代理，每次請(qǐng)求都更換IP請(qǐng)求，我們可以對(duì)接口進(jìn)行限流。
- 為了防止瞬時(shí)過(guò)大的流量壓垮系統(tǒng)，還可以使用阿里的Sentinel、Hystrix組件進(jìn)行限流。
分布式鎖
可以使用redis分布式鎖解決超賣(mài)問(wèn)題。
使用Redis的SET EX PX NX + 校驗(yàn)唯一隨機(jī)值,再刪除釋放鎖。
if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加鎖try {do something //業(yè)務(wù)處理}catch(){}finally {//判斷是不是當(dāng)前線程加的鎖,是才釋放if (uni_request_id.equals(jedis.get(key_resource_id))) {jedis.del(lockKey); //釋放鎖}} } 復(fù)制代碼在這里，判斷是不是當(dāng)前線程加的鎖和釋放鎖不是一個(gè)原子操作。如果調(diào)用jedis.del()釋放鎖的時(shí)候，可能這把鎖已經(jīng)不屬于當(dāng)前客戶(hù)端，會(huì)解除他人加的鎖。
為了更嚴(yán)謹(jǐn)，一般也是用lua腳本代替。lua腳本如下：
if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) elsereturn 0 end; 復(fù)制代碼MQ異步處理
如果瞬間流量特別大，可以使用消息隊(duì)列削峰，異步處理。用戶(hù)請(qǐng)求過(guò)來(lái)的時(shí)候，先放到消息隊(duì)列，再拿出來(lái)消費(fèi)。
限流&降級(jí)&熔斷
- 限流，就是限制請(qǐng)求，防止過(guò)大的請(qǐng)求壓垮服務(wù)器；
- 降級(jí)，就是秒殺服務(wù)有問(wèn)題了，就降級(jí)處理，不要影響別的服務(wù)；
- 熔斷，服務(wù)有問(wèn)題就熔斷，一般熔斷降級(jí)是一起出現(xiàn)。
更多大廠面試資料及答案可關(guān)注下方公公眾號(hào)【不脫發(fā)有志青年】即可免費(fèi)獲取
?
總結(jié)
以上是生活随笔為你收集整理的阿里巴巴一面 ：十道经典面试题解析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： .Net Core 为 x86 和 x6
- 下一篇： 历年阿里面试题汇总