第一題：一條sql執(zhí)行過長的時(shí)間，你如何優(yōu)化，從哪些方面?

答：1、查看sql是否涉及多表的聯(lián)表或者子查詢，如果有，看是否能進(jìn)行業(yè)務(wù)拆分，相關(guān)字段冗余或者合并成臨時(shí)表(業(yè)務(wù)和算法的優(yōu)化)

2、涉及鏈表的查詢，是否能進(jìn)行分表查詢，單表查詢之后的結(jié)果進(jìn)行字段整合

3、如果以上兩種都不能操作，非要鏈表查詢，那么考慮對(duì)相對(duì)應(yīng)的查詢條件做索引。加快查詢速度

4、針對(duì)數(shù)量大的表進(jìn)行歷史表分離(如交易流水表)

5、數(shù)據(jù)庫主從分離，讀寫分離，降低讀寫針對(duì)同一表同時(shí)的壓力，至于主從同步，MySQL有自帶的binlog實(shí)現(xiàn) 主從同步

6、explain分析sql語句，查看執(zhí)行計(jì)劃，分析索引是否用上，分析掃描行數(shù)等等

7、查看mysql執(zhí)行日志，看看是否有其他方面的問題

第二題：深入理解CAP

CAP原則又稱CAP定理，指的是在一個(gè)分布式系統(tǒng)中，一致性(Consistency)、可用性(Availability)、分區(qū)容錯(cuò)性(Partition tolerance)這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。分布式系統(tǒng)肯定優(yōu)先保證P，多數(shù)時(shí)候是在C和A之間做權(quán)衡選擇!

C：各個(gè)節(jié)點(diǎn)查詢的數(shù)據(jù)都一致;

A：所有節(jié)點(diǎn)盡量可用;

P：節(jié)點(diǎn)之間無法通信;

AP架構(gòu)

向一個(gè)節(jié)點(diǎn)A寫入數(shù)據(jù)成功后，立刻給客戶端響應(yīng)寫成功的信號(hào)。

如果此時(shí)集群節(jié)點(diǎn)之間網(wǎng)絡(luò)斷開了，由于其可用性，其他節(jié)點(diǎn)仍然提供服務(wù)，但是A節(jié)點(diǎn)的數(shù)據(jù)還未寫入到其他節(jié)點(diǎn)，當(dāng)訪問除A之外的其他節(jié)點(diǎn)時(shí)，就會(huì)出現(xiàn)數(shù)據(jù)不一致的問題，當(dāng)網(wǎng)絡(luò)恢復(fù)后，才會(huì)通過心跳保證最終一致性!

CP架構(gòu)

在向一個(gè)節(jié)點(diǎn)A寫入數(shù)據(jù)成功后，并不是馬上給客戶端響應(yīng)寫成功的信號(hào)，而是等待數(shù)據(jù)同步到其他節(jié)點(diǎn)后(個(gè)數(shù)取決于配置)，才響應(yīng)客戶端，表示此次寫數(shù)據(jù)成功了!這在一定程度上保證了數(shù)據(jù)一致性。為了防止數(shù)據(jù)混亂，寫數(shù)據(jù)時(shí)只允許往Leader節(jié)點(diǎn)寫，讀數(shù)據(jù)時(shí)可以從所有節(jié)點(diǎn)讀取!

CP架構(gòu)下具有特殊的Leader - Flower機(jī)制，當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)，非Leader分區(qū)下的節(jié)點(diǎn)會(huì)變成不可用，重新進(jìn)入選舉狀態(tài)。

第三題：雙十一秒殺高可靠如何實(shí)現(xiàn)?

Sentinel承接了阿里10年的促銷場景，利用：流量控制(通過設(shè)置QPS來控制)，容錯(cuò)(熔斷就是切斷壞路，讓后續(xù)新流量再走這個(gè)壞路)，降級(jí)(備選B角，走了try-cath的機(jī)制，)，三板斧解決高可靠。熔斷機(jī)制：通過滑動(dòng)時(shí)間窗口實(shí)現(xiàn)的，對(duì)前一段時(shí)間的錯(cuò)誤比例來設(shè)置熔斷點(diǎn)。

第四題：分布式事務(wù)問題如何解決?

Seata：服務(wù)端也是通過安裝和配置來實(shí)現(xiàn)，使用很簡單，實(shí)現(xiàn)了事務(wù)協(xié)調(diào)功能，需要加一個(gè)依賴包，然后加一個(gè)注解@globalTranscational, AT模式，是最推薦的一種，舉例：Seata如何協(xié)調(diào)訂單和庫存?要求同時(shí)成功或者失敗。一階段：訂單和庫存，都先做回滾日志記錄在本地事務(wù)中，二階段：如果有一個(gè)失敗，通過回滾日志來回到回到初始。

第五題：nacos和zookeeper是如何防止腦裂的?

集群的腦裂通常是發(fā)生在集群之間通信不可達(dá)(分區(qū))的情況下，一個(gè)大集群會(huì)分裂成不同的小集群，小集群中又各自選舉出自己的master節(jié)點(diǎn)，導(dǎo)致原先的集群出現(xiàn)多個(gè)master節(jié)點(diǎn)對(duì)外提供服務(wù)的情況!

leader選舉時(shí)，要求節(jié)點(diǎn)獲取到的投票數(shù)量 > 總節(jié)點(diǎn)數(shù)量/2，有了這個(gè)選舉原則，當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)時(shí)，無論如何最多只有一個(gè)小集群選出leader，避免集群發(fā)生腦裂。

第六題：線程間是怎么通信的,通過調(diào)用幾個(gè)方法來交互的?

線程是通過wait , notify等方法相互作用進(jìn)行協(xié)作通信;

wait()方法使得當(dāng)前線程必須要等待，直到到另外一個(gè)線程調(diào)用notify()或者notifyAll()方法喚醒

wait()和notify()方法要求在調(diào)用時(shí)線程已經(jīng)獲得了對(duì)象鎖，因此對(duì)這兩個(gè)方法的調(diào)用需要在 synchronized修飾的方法或代碼塊中。

Wait,notify,notifyAll都必須在synchronized修飾的方法或代碼塊中使用,都屬于Object的方法,可以被所有類繼承,都是final修飾的方法,不能通過子類重寫去改變他們的行為

第七題：SpringMVC工作流程?

1.用戶請(qǐng)求旅程的第一站是DispatcherServlet。

2.收到請(qǐng)求后，DispatcherServlet調(diào)用HandlerMapping，獲取對(duì)應(yīng)的Handler。

3.如果有攔截器一并返回。

4.拿到Handler后，找到HandlerAdapter,通過它來訪問Handler,并執(zhí)行處理器。

5.執(zhí)行Handler的邏輯。

6.Handler會(huì)返回一個(gè)ModelAndView對(duì)象給DispatcherServlet。

7.將獲得到的ModelAndView對(duì)象返回給DispatcherServlet。

8.請(qǐng)求ViewResolver解析視圖，根據(jù)邏輯視圖名解析成真正的View。

9.返回View給DispatcherServlet。

10.DispatcherServlet對(duì)View進(jìn)行渲染視圖。

11.DispatcherServlet響應(yīng)用戶。

以上就是“最新大廠面試總結(jié)，Java架構(gòu)師面試題”，你能回答上來嗎?如果想要了解更多的Java面試題相關(guān)內(nèi)容，可以關(guān)注動(dòng)力節(jié)點(diǎn)Java官網(wǎng)。