java面試題——中介軟體&&資料庫&&redis（三）
六、中介軟體篇
1.訊息中介軟體如何保證訊息的一致性和如何進行訊息的重試機制？
2.Spring Cloud熔斷機制介紹；
在Spring Cloud框架裡，熔斷機制通過Hystrix實現。Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，預設是5秒內20次呼叫失敗，就會啟動熔斷機制。熔斷機制的註解是@HystrixCommand，Hystrix會找有這個註解的方法，並將這類方法關聯到和熔斷器連在一起的代理上。當前，@HystrixCommand僅當類的註解為@Service或@Component時才會發揮作用。
3.Spring Cloud對比下Dubbo，什麼場景下該使用Spring Cloud？
1.①dubbo由於是二進位制的傳輸，佔用頻寬會更少 ②springCloud是http協議傳輸，頻寬會比較多，同時使用http協議一般會使用JSON報文，消耗會更大 ③dubbo的開發難度較大，原因是dubbo的jar包依賴問題很多大型工程無法解決 ④springcloud的介面協議約定比較自由且鬆散，需要有強有力的行政措施來限制介面無序升級 ⑤dubbo的註冊中心可以選擇zk,redis等多種，springcloud的註冊中心只能用eureka或者自研 2.對於類似於電商等同步呼叫場景多並且能支撐搭建Dubbo 這套比較複雜環境的成本的產品而言，Dubbo 確實是一個可以考慮的選擇。但如果產品業務中由於後臺業務邏輯複雜、時間長而導致非同步邏輯比較多的話，可能Dubbo 並不合適。同時，對於人手不足的初創產品而言，這麼重的架構維護起來也不是很方便 參考連結：https://blog.csdn.net/u010664947/article/details/80007767
七、資料庫篇
4.鎖機制介紹：行鎖、表鎖、排他鎖、共享鎖；
①表鎖和行鎖鎖的粒度不一樣，表鎖鎖住的是一整張表，行鎖鎖住的是表中的一行資料。InnoDB使用的是行級鎖，MyISAM使用的是表級鎖。 ②共享鎖又稱讀鎖（S鎖），一個事務獲取了共享鎖，其他事務可以獲取共享鎖，不能獲取排他鎖，其他事務可以進行讀操作，不能進行寫操作。 ③排他鎖又稱寫鎖（X鎖），如果事務T對資料A加上排他鎖後，則其他事務不能再對A加任任何型別的封鎖。獲准排他鎖的事務既能讀資料，又能修改資料。 對於insert、update、delete，InnoDB會自動給涉及的資料加排他鎖（X）；
5.樂觀鎖的業務場景及實現方式；
1.①悲觀鎖（Pessimistic Lock）： 每次獲取資料的時候，都會擔心資料被修改，所以每次獲取資料的時候都會進行加鎖，確保在自己使用的過程中資料不會被別人修改，使用完成後進行資料解鎖。由於資料進行加鎖，期間對該資料進行讀寫的其他執行緒都會進行等待。 ②樂觀鎖（Optimistic Lock）：每次獲取資料的時候，都不會擔心資料被修改，所以每次獲取資料的時候都不會進行加鎖，但是在更新資料的時候需要判斷該資料是否被別人修改過。如果資料被其他執行緒修改，則不進行資料更新，如果資料沒有被其他執行緒修改，則進行資料更新。由於資料沒有進行加鎖，期間該資料可以被其他執行緒進行讀寫操作。 2.適用場景：
①悲觀鎖：比較適合寫入操作比較頻繁的場景，如果出現大量的讀取操作，每次讀取的時候都會進行加鎖，這樣會增加大量的鎖的開銷，降低了系統的吞吐量。 ②樂觀鎖：比較適合讀取操作比較頻繁的場景，如果出現大量的寫入操作，資料發生衝突的可能性就會增大，為了保證資料的一致性，應用層需要不斷的重新獲取資料，這樣會增加大量的查詢操作，降低了系統的吞吐量。 總結：兩種所各有優缺點，讀取頻繁使用樂觀鎖，寫入頻繁使用悲觀鎖。
6.事務介紹，分散式事物的理解，常見的解決方案有哪些，什麼事兩階段提交、三階段提交；
1.事務：事務是使用者定義的一個數據庫操作序列，這些操作要麼全做，要麼全不做，是一個不可分割的工作單位。 2.①分散式事務：用需要操作的資源位於多個資源伺服器上，而應用需要保證對於多個資源伺服器的資料的操作，要麼全部成功，要麼全部失敗。本質上來說，分散式事務就是為了保證不同資源伺服器的資料一致性。 3.解決方案： ①兩階段提交； ②補償事務：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作； ③本地訊息表（非同步確保）：訊息生產方，需要額外建一個訊息表，並記錄訊息傳送狀態。訊息表和業務資料要在一個事務裡提交，也就是說他們要在一個數據庫裡面。然後訊息會經過MQ傳送到訊息的消費方。如果訊息傳送失敗，會進行重試傳送 4.兩階段提交：①TM通知各個RM準備提交它們的事務分支。如果RM判斷自己進行的工作可以被提交，那就就對工作內容進行持久化，再給TM肯定答覆；要是發生了其他情況，那給TM的都是否定答覆。在傳送了否定答覆並回滾了已經的工作後，RM就可以丟棄這個事務分支資訊。②TM根據階段1各個RM prepare的結果，決定是提交還是回滾事務。如果所有的RM都prepare成功，那麼TM通知所有的RM進行提交；如果有RM prepare失敗的話，則TM通知所有RM回滾自己的事務分支。 三階段提交：①CanCommit階段：3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者傳送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
②PreCommit階段： 協調者根據參與者的反應情況來決定是否可以記性事務的PreCommit操作。根據響應情況，有以下兩種可能。假如協調者從所有的參與者獲得的反饋都是Yes響應，那麼就會執行事務的預執行。
③doCommit階段， 該階段進行真正的事務提交，也可以分為以下兩種情況。 Case 1：執行提交 1）.傳送提交請求 協調接收到參與者傳送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送doCommit請求。 2）.事務提交 參與者接收到doCommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。 3）.響應反饋 事務提交完之後，向協調者傳送Ack響應。 4）.完成事務 協調者接收到所有參與者的ack響應之後，完成事務。 Case 2：中斷事務 協調者沒有接收到參與者傳送的ACK響應（可能是接受者傳送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。 1）.傳送中斷請求 協調者向所有參與者傳送abort請求 2).事務回滾 參與者接收到abort請求之後，利用其在階段二記錄的undo資訊來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。 3).反饋結果 參與者完成事務回滾之後，向協調者傳送ACK訊息 4).中斷事務 協調者接收到參與者反饋的ACK訊息之後，執行事務的中斷
參考連結：http://www.tianshouzhi.com/api/tutorials/distributed_transaction
7.MySQL記錄binlog的方式主要包括三種模式？每種模式的優缺點是什麼？
①Row Level行模式：日誌中會記錄每一行資料被修改的形式，然後在slave端再對相同的資料進行修改 優點：在row level模式下，bin-log中可以不記錄執行的sql語句的上下文相關的資訊，僅僅只需要記錄那一條被修改。所以rowlevel的日誌內容會非常清楚的記錄下每一行資料修改的細節。不會出現某些特定的情況下的儲存過程或function，以及trigger的呼叫和觸發無法被正確複製的問題 缺點：row level，所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，會產生大量的日誌內容。 ②Statement Level（預設）：每一條會修改資料的sql都會記錄到master的bin-log中。slave在複製的時候sql程序會解析成和原來master端執行過的相同的sql來再次執行 優點：statement level下的優點首先就是解決了row level下的缺點，不需要記錄每一行資料的變化，減少bin-log日誌量，節約IO，提高效能，因為它只需要在Master上鎖執行的語句的細節，以及執行語句的上下文的資訊。 缺點：由於只記錄語句，所以，在statement level下 已經發現了有不少情況會造成MySQL的複製出現問題，主要是修改資料的時候使用了某些定的函式或者功能的時候會出現。 ③Mixed 自動模式：在Mixed模式下，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌格式，也就是在Statement和Row之間選擇一種。如果sql語句確實就是update或者delete等修改資料的語句，那麼還是會記錄所有行的變更。
8.同步\非同步\阻塞\非阻塞；
1.同步與非同步：獲取完成標誌的方式。如果是採用輪詢的方式監測I/O操作是否完成稱為同步，而以通過回撥通知的方式獲得完成標誌則稱為非同步。 阻塞與非阻塞：在那段時間差的過程中，CPU有沒有處理別的事情，如果處理過別的事情則是非阻塞，如果並沒有處理過別的事情則是阻塞。 2.①同步阻塞：即是在B階段CPU一直採用輪詢的方式直到獲得完成標誌，所以此段時間CPU一直阻塞在此I/O操作上。 ②同步不阻塞：在B階段依然採用輪詢的方式直至獲得完成標誌，但是此輪詢不同於上面的輪詢過程，而是在相鄰的輪詢中完成了上下文切換去處理別的任務的，所以是同步不阻塞 ③非同步阻塞：也就是所沒有上面的①,②過程，當I/O操作完成後回撥通知CPU已完成【即是③過程】，但是此階段CPU處於休眠狀態而不處理別的任務。= ④非同步不阻塞：和上面一樣沒有①,②過程而是通過回撥知道I/O操作已完成，但是並沒有休眠，而是在此階段處理其他任務。 綜上所述：非同步不阻塞是最高效的。
9.資料庫事務隔離級別，MySQL預設的隔離級別；
MySQL資料庫提供四種隔離級別：
① Serializable (序列化)：可避免髒讀、不可重複讀、幻讀的發生。
② Repeatable read (可重複讀)：可避免髒讀、不可重複讀的發生。
③ Read committed (讀已提交)：可避免髒讀的發生。
④ Read uncommitted (讀未提交)：最低級別，任何情況都無法保證
MySQL資料庫中預設的隔離級別為Repeatable read (可重複讀)。
10.Spring如何實現事務、JDBC如何實現事務、巢狀事務實現；
spring事務：①獲取事務屬性。 ②載入配置中配置的TransactionManager。 ③不同的事務處理使用不同的邏輯，第一點區別在事務屬性上，程式設計式事務是不需要有事務屬性的。第二點區別在TransactionManager上，CallbackPreferringPlatformTransactionManager實現了PlatformTransactionManager介面，暴露出一個方法用於執行事務處理中的回撥。所以這兩種方式都可以 用作事務處理方式的判斷。 ④在目標方法執行前獲取事務並收集事務資訊。（事務資訊和事務屬性並不相同） ⑤執行目標方法。 ⑥一旦出現異常，嘗試異常處理。並不是所有異常spring都會回滾，預設只對RuntimeException回滾。 ⑦提交事務前的事務資訊清除。 ⑧提交事務。 jdbc事務：①獲取連線 Connection con = DriverManager.getConnection() ②開啟事務con.setAutoCommit(true/false); ③執行CRUD ④提交事務/回滾事務 con.commit() / con.rollback(); ⑤關閉連線 conn.close(); 巢狀事務：在spring中將事務級別設定為RROPAGATION_REQUIRES_NEW
11.SQL的整個解析、執行過程原理、SQL行轉列；
1.①第一步：客戶端把語句發給伺服器端執行 ②第二步：語句解析 1）查詢快取記憶體（library cache） 2）語句合法性檢查（data dict cache）
3）語言含義檢查（data dict cache）
4）獲得物件解析鎖（control structer）
5）資料訪問許可權的核對（data dict cache）
6）確定最佳執行計劃 ③第三步：繫結變數賦值④第四步：語句執行⑤第五步：提取資料
2.指令碼：
Select st.stuid, st.stunm,
MAX(CASE c.coursenm WHEN '大學語文' THEN s.scores ELSE 0 END ) '大學語文',
MAX(CASE c.coursenm WHEN '新視野英語' THEN ifnull(s.scores,0) ELSE 0 END ) '新視野英語',
MAX(CASE c.coursenm WHEN '離散數學' THEN ifnull(s.scores,0) ELSE 0 END ) '離散數學',
MAX(CASE c.coursenm WHEN '概率論與數理統計' THEN ifnull(s.scores,0) ELSE 0 END ) '概率論與數理統計',
MAX(CASE c.coursenm WHEN '線性代數' THEN ifnull(s.scores,0) ELSE 0 END ) '線性代數',
MAX(CASE c.coursenm WHEN '高等數學(一)' THEN ifnull(s.scores,0) ELSE 0 END ) '高等數學(一)',
MAX(CASE c.coursenm WHEN '高等數學(二)' THEN ifnull(s.scores,0) ELSE 0 END ) '高等數學(二)'
From student st
Left Join score s On st.stuid = s.stuid
Left Join courses c On c.courseno = s.courseno
Group by st.stuid
參考連結：https://blog.csdn.net/wulantian/article/details/52687640
八、Redis
Redis為什麼這麼快？redis採用多執行緒會有哪些問題？
Redis支援哪幾種資料結構；
Redis跳躍表的問題；
Redis單程序單執行緒的Redis如何能夠高併發?
Redis如何使用Redis實現分散式鎖？
Redis分散式鎖操作的原子性，Redis內部是如何實現的？