讀寫(xiě)分離與分庫(kù)分表，分布式事務(wù)

• MySql存儲(chǔ)引擎，建表規(guī)范，事務(wù)級(jí)別，sql優(yōu)化，讀寫(xiě)分離思想等。
• 了解過(guò)讀寫(xiě)分離嗎？ 你說(shuō)讀的時(shí)候讀從庫(kù)，現(xiàn)在假設(shè)有一張表User做了讀寫(xiě)分離，然后有個(gè)線程在一個(gè)事務(wù)范圍內(nèi)對(duì)User表先做了寫(xiě)的處理，然后又做了讀的處理，這時(shí)候數(shù)據(jù)還沒(méi)同步到從庫(kù)，怎么保證讀的時(shí)候能讀到最新的數(shù)據(jù)呢？
• 你如何保證系統(tǒng)的穩(wěn)定性？ 答：分布式的鏈路一般都很長(zhǎng)，所以我們首先通過(guò)全鏈路壓測(cè)，分析整個(gè)鏈路，到底是哪個(gè)節(jié)點(diǎn)出現(xiàn)瓶頸。如果是數(shù)據(jù)層出現(xiàn)瓶頸，那么可以考慮加緩存，讀寫(xiě)分離等降低數(shù)據(jù)庫(kù)壓力，如果短期流量很大，一天就能打滿一個(gè)庫(kù)，那么要考慮擴(kuò)庫(kù)。數(shù)據(jù)層如果沒(méi)問(wèn)題，瓶頸在應(yīng)用層，那么需要先分析應(yīng)用代碼是否有問(wèn)題，jvm是否可調(diào)優(yōu)，線程池是否可調(diào)優(yōu)，rpc超時(shí)時(shí)間設(shè)置是否正確，如果應(yīng)用代碼沒(méi)問(wèn)題，那么可以加docker，進(jìn)行水平擴(kuò)容。如果問(wèn)題不在己方鏈路，在于依賴服務(wù)，那么要推進(jìn)對(duì)方進(jìn)行性能優(yōu)化，并且最好降級(jí)預(yù)案。如果系統(tǒng)已經(jīng)最優(yōu)，無(wú)法進(jìn)行優(yōu)化仍然承受不了流量，那么只能做限流處理了。然后又介紹了一些流量隔離等等業(yè)內(nèi)解決方案。
• 數(shù)據(jù)庫(kù)插入和刪除一條數(shù)據(jù)的過(guò)程在底層是如何執(zhí)行的，項(xiàng)目里配置了讀寫(xiě)分離，也會(huì)比較深入的就實(shí)現(xiàn)方法和底層邏輯展開(kāi)討論；
• redis是怎么部署的？主從部署？有了解過(guò)redis集群部署嗎？我說(shuō)redis集群部署沒(méi)有了解過(guò)，但是有了解過(guò)mysql的集群部署，有讀寫(xiě)分離部署，主從復(fù)制，分庫(kù)分表等相關(guān)方案
• 在數(shù)據(jù)庫(kù)讀寫(xiě)分離的時(shí)候怎么做，有什么樣的框架；
• MySQL數(shù)據(jù)量太大怎么辦，如何分庫(kù)分表 binlog，讀寫(xiě)分離，主從復(fù)制 MySQL里的鎖了解嗎
• 分庫(kù)分表 聚合查詢 limit怎么實(shí)現(xiàn) top的實(shí)現(xiàn) 不停機(jī)擴(kuò)容？分表避免冷熱？不停機(jī)擴(kuò)庫(kù)？不停機(jī)擴(kuò)表？跨庫(kù)事務(wù)？ 分庫(kù)分表為什么這么設(shè)計(jì)？數(shù)據(jù)增長(zhǎng)怎么做？怎么擴(kuò)容？數(shù)據(jù)不均勻怎么辦？冷熱數(shù)據(jù)怎么分離？聚合怎么做？跨庫(kù)聚合怎么做，查詢?cè)趺醋?？跨?kù)分頁(yè)怎么做？ mysql 線上的組群模式？一主多從？為什么這樣？強(qiáng)一致性如何保證？為了解決讀寫(xiě)分離嗎？是為了一主多備嗎？主庫(kù)crash掉怎么辦？從庫(kù)呢？ 分布式事務(wù)怎么做？什么原理？怎么實(shí)現(xiàn)的？出現(xiàn)過(guò)事務(wù)不一致性嗎？為什么？怎么解決的？ 訪問(wèn)請(qǐng)求暴增怎么做？怎么緩解壓力？
• 如何實(shí)現(xiàn) MySQL，事務(wù)隔離級(jí)別，什么時(shí)候臟讀，什么時(shí)候讀已提交 分布式事務(wù)（經(jīng)常被問(wèn)到） 1、兩階段提交（2PC） 第一階段：事務(wù)協(xié)調(diào)器要求每個(gè)涉及到事務(wù)的數(shù)據(jù)庫(kù)預(yù)提交(precommit)此操作，并反映是否可以提交. 第二階段：事務(wù)協(xié)調(diào)器要求每個(gè)數(shù)據(jù)庫(kù)提交數(shù)據(jù)。 優(yōu)點(diǎn)： 盡量保證了數(shù)據(jù)的強(qiáng)一致，適合對(duì)數(shù)據(jù)強(qiáng)一致要求很高的關(guān)鍵領(lǐng)域。（其實(shí)也不能100%保證強(qiáng)一致） 缺點(diǎn)： 實(shí)現(xiàn)復(fù)雜，犧牲了可用性，對(duì)性能影響較大，不適合高并發(fā)高性能場(chǎng)景 2、補(bǔ)償事務(wù)（TCC） 針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷）。Try、Confirm、Cancel 優(yōu)點(diǎn)： 跟2PC比起來(lái)，實(shí)現(xiàn)以及流程相對(duì)簡(jiǎn)單了一些，但數(shù)據(jù)的一致性比2PC也要差一些 缺點(diǎn)： 缺點(diǎn)還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應(yīng)用層的一種補(bǔ)償方式，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫(xiě)很多補(bǔ)償?shù)拇a，在一些場(chǎng)景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。 3、本地消息表（異步確保） 核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理，消息生產(chǎn)方，需要額外建一個(gè)消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務(wù)數(shù)據(jù)要在一個(gè)事務(wù)里提交，也就是說(shuō)他們要在一個(gè)數(shù)據(jù)庫(kù)里面。然后消息會(huì)經(jīng)過(guò)MQ發(fā)送到消息的消費(fèi)方。如果消息發(fā)送失敗，會(huì)進(jìn)行重試發(fā)送。 優(yōu)點(diǎn)： 一種非常經(jīng)典的實(shí)現(xiàn)，避免了分布式事務(wù)，實(shí)現(xiàn)了最終一致性。 缺點(diǎn)： 消息表會(huì)耦合到業(yè)務(wù)系統(tǒng)中，如果沒(méi)有封裝好的解決方案，會(huì)有很多雜活需要處理。 4、MQ事務(wù)消息 RocketMQ支持，RabbitMQ 和 Kafka 都不支持，一次發(fā)送消息和一次確認(rèn)消息，生產(chǎn)方需要實(shí)現(xiàn)一個(gè)check接口（確認(rèn)消息或者回滾） 優(yōu)點(diǎn)： 實(shí)現(xiàn)了最終一致性，不需要依賴本地?cái)?shù)據(jù)庫(kù)事務(wù)。 缺點(diǎn)： 實(shí)現(xiàn)難度大，主流MQ不支持，沒(méi)有.NET客戶端，RocketMQ事務(wù)消息部分代碼也未開(kāi)源。 5、Sagas事務(wù)模型 長(zhǎng)時(shí)間運(yùn)行的事務(wù)，該模型其核心思想就是拆分分布式系統(tǒng)中的長(zhǎng)事務(wù)為多個(gè)短事務(wù)，或者叫多個(gè)本地事務(wù)，然后由 Sagas 工作流引擎負(fù)責(zé)協(xié)調(diào)，如果整個(gè)流程正常結(jié)束，那么就算是業(yè)務(wù)成功完成，如果在這過(guò)程中實(shí)現(xiàn)失敗，那么Sagas工作流引擎就會(huì)以相反的順序調(diào)用補(bǔ)償操作，重新進(jìn)行業(yè)務(wù)回滾。
• 關(guān)于分布式事務(wù)、以及分布式事務(wù)問(wèn)題------ 關(guān)于分庫(kù)分表（為什么要分庫(kù)分表，用過(guò)哪些分庫(kù)分表中間件）---- 分庫(kù)分表的方法-----------結(jié)合項(xiàng)目，垂直和水平拆分 如何設(shè)計(jì)動(dòng)態(tài)擴(kuò)容縮容的分庫(kù)--- 分庫(kù)分表全局ID如何生成
• 分庫(kù)分表是以什么維度來(lái)劃分的？劃分的算法是怎樣的，會(huì)不會(huì)出現(xiàn)數(shù)據(jù)分配不均衡的情況。 myisam和innodb支持鎖的粒度是怎樣的？
• 5、訂閱分庫(kù)分表的 Binlog 怎么訂閱？ 6、分庫(kù)分表的數(shù)據(jù)源中假如存在主鍵沖突要怎么解決？ 7、怎么保證下游對(duì) Binlog 的消費(fèi)順序？ 8、如何在下游保證消費(fèi)時(shí)的事務(wù)原子性？
• 假如用 id 翻頁(yè)的方式, 數(shù)據(jù)庫(kù)表如何設(shè)計(jì)? 索引如何設(shè)計(jì)? 5. 假如量很大, 你覺(jué)得需要分庫(kù)分表嗎? 怎么分? 6. 分庫(kù)分表后怎么查詢分頁(yè)? 7. 分庫(kù)分表后怎么保證主鍵仍然是遞增的? 8. 現(xiàn)在需要支持深分頁(yè), 頁(yè)碼直接跳轉(zhuǎn), 怎么實(shí)現(xiàn)? 9. 瞬時(shí)寫(xiě)入量很大可能會(huì)打掛存儲(chǔ), 怎么保護(hù)?
• 分庫(kù)分表帶來(lái)的問(wèn)題。
• 分庫(kù)分表怎么做（要方案）
• mysql 怎么做的分庫(kù)分表，有沒(méi)有遇到跨庫(kù)查詢問(wèn)題 某個(gè)分庫(kù)數(shù)據(jù)量特別大的情況，怎么解決 mysql 慢查詢?cè)趺唇鉀Q的，explain怎么使用，重點(diǎn)關(guān)注哪里 分庫(kù)分表，線上數(shù)據(jù)量有多大 數(shù)據(jù)庫(kù)連接池怎么設(shè)計(jì)的 定時(shí)任務(wù)，數(shù)據(jù)量會(huì)不會(huì)特別大
• oracle跟mysql的區(qū)別，隔離級(jí)別 慢查詢?nèi)绾味ㄎ?？如何?yōu)化？遇見(jiàn)過(guò)什么樣的case，怎么解決的？ 項(xiàng)目用到了分庫(kù)分表，分庫(kù)一定會(huì)提升性能呢？什么是冷熱數(shù)據(jù)？?jī)?yōu)化了什么地方？假如出現(xiàn)了數(shù)據(jù)暴增，怎么處理？有什么擴(kuò)容的方法？怎么無(wú)感知擴(kuò)容？怎么做到數(shù)據(jù)實(shí)時(shí)一致性？ 分庫(kù)分表的設(shè)計(jì)？ 分布式事務(wù)出現(xiàn)過(guò)不一致嗎？為什么？怎么解決？有什么方法避免？怎么監(jiān)控？監(jiān)控到怎么處理？什么時(shí)候需要人工接入。分庫(kù)分表 聚合查詢 limit怎么實(shí)現(xiàn) top的實(shí)現(xiàn) 不停機(jī)擴(kuò)容？分表避免冷熱？不停機(jī)擴(kuò)庫(kù)？不停機(jī)擴(kuò)表？跨庫(kù)事務(wù)？ 分庫(kù)分表為什么這么設(shè)計(jì)？數(shù)據(jù)增長(zhǎng)怎么做？怎么擴(kuò)容？數(shù)據(jù)不均勻怎么辦？冷熱數(shù)據(jù)怎么分離？聚合怎么做？跨庫(kù)聚合怎么做，查詢?cè)趺醋?？跨?kù)分頁(yè)怎么做？ mysql 線上的組群模式？一主多從？為什么這樣？強(qiáng)一致性如何保證？為了解決讀寫(xiě)分離嗎？是為了一主多備嗎？主庫(kù)crash掉怎么辦？從庫(kù)呢？ 分布式事務(wù)怎么做？什么原理？怎么實(shí)現(xiàn)的？出現(xiàn)過(guò)事務(wù)不一致性嗎？為什么？怎么解決的？ 訪問(wèn)請(qǐng)求暴增怎么做？怎么緩解壓力？
• mysql唯一索引能加入null嗎（不會(huì)） innodb特性 mysql回表 mysql分庫(kù)分表標(biāo)準(zhǔn)？
• 如何分庫(kù)分表，分頁(yè)查詢，查詢非拆分字段方案； MySql索引結(jié)構(gòu)，為什么用B+樹(shù)（對(duì)比Hash，B+樹(shù)，B樹(shù)，AVL，紅黑樹(shù)）；
• 分庫(kù)分表怎么做？基于什么維度去做？
• 列舉出你能想到的數(shù)據(jù)庫(kù)分庫(kù)分表策略；分庫(kù)分表后，如何解決全表查詢的問(wèn)題
• 聊聊對(duì)事務(wù)的理解（什么是事務(wù)？事務(wù)的特性？） 事務(wù)的隔離級(jí)別 InnoDB 和 MyISAM 的區(qū)別？ 如何優(yōu)化慢 SQL? 一億的表，很多復(fù)雜的查詢條件，查第一萬(wàn)頁(yè)，如何優(yōu)化？分庫(kù)分表查詢過(guò)程？ 二階段、三階段、TCC、seata
• 設(shè)計(jì)一個(gè)系統(tǒng)，每天有100億條數(shù)據(jù)，需要在后臺(tái)做實(shí)時(shí)展示和查找。 我當(dāng)時(shí)回答的大體思路是nginx負(fù)載均衡，消息隊(duì)列存儲(chǔ)，多線程讀取，批量插入，數(shù)據(jù)庫(kù)分庫(kù)分表。 面試官根據(jù)我的回答又衍生出了很多問(wèn)題，如消息隊(duì)列存滿了怎么辦？（也就是消費(fèi)跟不上生產(chǎn)）批量插入時(shí)某一條失敗了有什么影響？怎么解決？分庫(kù)分表應(yīng)該怎么分？怎么解決數(shù)據(jù)遷移的問(wèn)題？
• 分庫(kù)分表的實(shí)現(xiàn)原理是什么，你所在業(yè)務(wù)一般是怎么分庫(kù)分表的？對(duì)應(yīng)邏輯是什么？
• mysql分庫(kù)分表原則，為什么要分這么多庫(kù)這么多表，基于什么考慮？數(shù)據(jù)庫(kù)3、動(dòng)態(tài)擴(kuò)容要如何實(shí)現(xiàn)？
• 問(wèn)分庫(kù)分表優(yōu)化
• ?樂(lè)觀鎖和悲觀鎖的區(qū)別？ ?這兩種鎖在Java和MySQL分別是怎么實(shí)現(xiàn)的？用的什么數(shù)據(jù)庫(kù)？ ?使用什么存儲(chǔ)引擎，為什么使用InnnoDB？ ?訂單表有做拆分么，怎么拆的？ ?水平拆分后查詢過(guò)程描述下 ?如果落到某個(gè)分片的數(shù)據(jù)很大怎么辦？ ?哈希取模會(huì)有什么問(wèn)題么？ ?分庫(kù)分表后怎么解決讀寫(xiě)壓力？ ?拆分后主鍵怎么保證惟一？ ?Snowflake生成的ID是全局遞增唯一么？ ?怎么實(shí)現(xiàn)全局遞增的唯一ID？ ?Mysql的索引結(jié)構(gòu)說(shuō)下 ?主鍵索引和普通索引的區(qū)別？ ?你們系統(tǒng)目前的瓶頸在哪里？ ?你打算怎么優(yōu)化？簡(jiǎn)要說(shuō)下你的優(yōu)化思路 ?有什么想問(wèn)我么？
• 一. 數(shù)據(jù)庫(kù) 1.使用mysq1索引都有哪些原則?索引什么數(shù)據(jù)結(jié)構(gòu)?B+tree和Btree什么區(qū)別? 2.mysq有哪些存儲(chǔ)引擎啊?都有啥區(qū)別? 3.設(shè)計(jì)高并發(fā)系統(tǒng)數(shù)據(jù)庫(kù)層面該怎么設(shè)計(jì)?數(shù)據(jù)庫(kù)鎖有哪些類型?如何實(shí)現(xiàn)呀? 4.數(shù)據(jù)庫(kù)事務(wù)有哪些? 二. 分庫(kù)分表 1.如何設(shè)計(jì)可以動(dòng)態(tài)擴(kuò)容縮容的分庫(kù)分表方案? 2.用過(guò)哪些分庫(kù)分表中間件,有啥優(yōu)點(diǎn)和缺點(diǎn)， 3.講一下你了解的分庫(kù)分表中間件的底層實(shí)現(xiàn)原理? 4.我現(xiàn)在有一個(gè)未分庫(kù)分表的系統(tǒng),以后系統(tǒng)需分庫(kù)分表,如何設(shè)計(jì)， 5.讓未分庫(kù)分表的系統(tǒng)動(dòng)態(tài)切換到分庫(kù)分表的系統(tǒng)上? 6.分布式事務(wù)知道嗎?你們?cè)趺唇鉀Q的?TCC?那若出現(xiàn)網(wǎng)絡(luò)原因,網(wǎng)絡(luò)連不通怎么辦啊 7.為什么要分庫(kù)分表啊? 8.分布式尋址方式都有哪些算法?知道一致性hash嗎? 9.手寫(xiě)一下java實(shí)現(xiàn)代碼?你若userId取摸分片,那我要查段連續(xù)時(shí)間里的數(shù)據(jù)怎么辦? 10.如何解決分庫(kù)分表主鍵問(wèn)題?有什么實(shí)現(xiàn)方案?
• 1、分布式事務(wù) 2、主鍵索引和唯一索引區(qū)別 3、hash索引和B+樹(shù)索引區(qū)別及使用場(chǎng)景 4、單列索引和復(fù)合索引使用場(chǎng)景 5、應(yīng)用內(nèi)存溢出怎么排查 6、MYSQL執(zhí)行計(jì)劃怎么查看，以及應(yīng)該關(guān)注哪些字段 7、分庫(kù)分表時(shí)，怎么實(shí)現(xiàn)多表查詢 8、億級(jí)數(shù)據(jù)怎么存儲(chǔ)
• 分庫(kù)分表如何做的？ 分庫(kù)分表如何不同庫(kù)表間數(shù)據(jù)不重復(fù)。
• 分庫(kù)分表如何選擇分表鍵 分庫(kù)分表的情況下，查詢時(shí)一般是如何做排序的？
• 能否舉個(gè)業(yè)務(wù)上的例子說(shuō)說(shuō)分庫(kù)分表？----------這是針對(duì)并發(fā)量過(guò)大導(dǎo)致單機(jī)存儲(chǔ)容量、連接數(shù)、處理能力瓶頸問(wèn)題。垂直切分也分為分庫(kù)和分表兩種措施，垂直分庫(kù)是根據(jù)業(yè)務(wù)耦合性關(guān)聯(lián)度較低的不同數(shù)據(jù)存儲(chǔ)到不同的數(shù)據(jù)庫(kù)中，比如客戶信息庫(kù)、商品信息庫(kù)……分開(kāi)存放到不同的庫(kù)中。垂直分表是基于原數(shù)據(jù)表的字段太多而拆分的方式，比如客戶表有個(gè)人身份屬性，地址聯(lián)系等屬性……。水平切分分為庫(kù)內(nèi)分表和分庫(kù)分表，將同一個(gè)表的數(shù)據(jù)按照不同的條件分配到多個(gè)表中，比如ID奇偶分表。庫(kù)內(nèi)分表只解決了單一表數(shù)據(jù)過(guò)大的問(wèn)題，沒(méi)有將表分布到不同的機(jī)器上，所以為了避免競(jìng)爭(zhēng)同一臺(tái)機(jī)器的CPU、內(nèi)存、網(wǎng)絡(luò)等可以分布到不同的庫(kù)中。 分庫(kù)分表帶來(lái)的問(wèn)題又是什么？---------事務(wù)一致性的問(wèn)題；跨機(jī)器節(jié)點(diǎn)關(guān)聯(lián)問(wèn)題；跨節(jié)點(diǎn)分頁(yè)排序問(wèn)題；全局主鍵避重問(wèn)題；數(shù)據(jù)遷移擴(kuò)容問(wèn)題
• 分庫(kù)分表應(yīng)該怎么分？怎么解決數(shù)據(jù)遷移的問(wèn)題？
• 關(guān)于分布式事務(wù)、以及分布式事務(wù)問(wèn)題------ 關(guān)于分庫(kù)分表（為什么要分庫(kù)分表，用過(guò)哪些分庫(kù)分表中間件）---- 分庫(kù)分表的方法-----------結(jié)合項(xiàng)目，垂直和水平拆分 如何設(shè)計(jì)動(dòng)態(tài)擴(kuò)容縮容的分庫(kù)--- 分庫(kù)分表全局ID如何生成
• 你們數(shù)據(jù)庫(kù)有沒(méi)有用到分庫(kù)分表，怎么做的？分庫(kù)分表以后全局id怎么生成的？
• 你們公司對(duì)分庫(kù)分表，避免熱點(diǎn)是怎么處理的？----------這涉及到數(shù)據(jù)庫(kù)瓶頸問(wèn)題的解決，所以要結(jié)合項(xiàng)目，對(duì)數(shù)據(jù)進(jìn)行垂直和水平拆分。水平分庫(kù)：（可以手動(dòng)畫(huà)個(gè)草圖來(lái)闡述）當(dāng)用戶通過(guò)userId來(lái)請(qǐng)求數(shù)據(jù)，通過(guò)對(duì)userId的分析得出該去哪個(gè)數(shù)據(jù)庫(kù)進(jìn)行操作（比如：A數(shù)據(jù)庫(kù)是偶數(shù)userId,B數(shù)據(jù)庫(kù)是奇數(shù)userId。不僅僅是通過(guò)userId也有按照其他分庫(kù)的方式，每個(gè)庫(kù)的結(jié)構(gòu)一樣，但數(shù)據(jù)不一樣）。水平分表：做法和分庫(kù)是一樣的。垂直分庫(kù)：依照業(yè)務(wù)的不同，拆分成多個(gè)數(shù)據(jù)庫(kù)（用戶數(shù)據(jù)庫(kù)和產(chǎn)品數(shù)據(jù)庫(kù)……各管各的），垂直分表就是依照uid為核心，將字段分割（比如表一存放個(gè)人身份信息姓名年齡……，表二存放個(gè)人社交信息聯(lián)系方式地址……） 除了分庫(kù)分表，你還了解些MySQL什么優(yōu)化？
• mysql分庫(kù)分表原則 - 為什么要分這么多庫(kù)這么多表 - 基于什么考慮？ - 如何實(shí)現(xiàn)數(shù)據(jù)庫(kù)動(dòng)態(tài)擴(kuò)容？
• 分布式事務(wù)了解嗎？有哪幾種解決方案？
• mysql 幻讀和間隙鎖 分片實(shí)現(xiàn)事務(wù)，mysql原生實(shí)現(xiàn)分布式事務(wù)
• 常見(jiàn)的分布式事務(wù)方案有哪些？ （1）兩階段提交方案 （2）eBay 事件隊(duì)列方案 （3）TCC 補(bǔ)償模式 （4）緩存數(shù)據(jù)最終一致性
• 你的項(xiàng)目中，如何保證分布式事務(wù)的一致性
• 為什么選擇本地消息法做分布式事務(wù)？ 什么是TCC，它的工作過(guò)程？ TCC 和 XA 的區(qū)別？ 如果讓你優(yōu)化XA，你會(huì)如何優(yōu)化？
• 分布式事務(wù)了解嗎？你們項(xiàng)目中都用到了哪些分布式事務(wù)？都有哪些優(yōu)缺點(diǎn)？
• 分布式事務(wù)的原理，如何使用分布式事務(wù)
• 秒殺系統(tǒng)，會(huì)涉及到多個(gè)庫(kù)表的更新，分布式事務(wù)怎么解決，我說(shuō)的消息最終一致性，異步？有沒(méi)有更好的方案？同步TCC方式，TCC方式原理？（三個(gè)階段的具體實(shí)現(xiàn)）
• 從秒殺系統(tǒng)還引申出分布式事務(wù)的幾種實(shí)現(xiàn)，二段式、三段式、補(bǔ)償型(TCC)、基于可靠消息服務(wù)的消息隊(duì)列實(shí)現(xiàn)。重點(diǎn)討論了這幾種的實(shí)現(xiàn)和區(qū)別，要求畫(huà)出基于可靠消息服務(wù)的消息隊(duì)列實(shí)現(xiàn)分布式事務(wù)的架構(gòu)圖，以及上游服務(wù)和下游服務(wù)如何保證消息可靠性和一致性。
• 其實(shí)歸根到底就是分布式事務(wù)的數(shù)據(jù)一致性解決方案，失敗了數(shù)據(jù)怎么回滾
• 分布式事務(wù)如何保證？
• 分布式事務(wù)的原理，如何使用分布式事務(wù)
• 以及分布式事務(wù)理論和解決方案
• MySQL索引原理、聯(lián)合索引、索引注意事項(xiàng)、慢查詢排查 雪花算法原理 MySQL IN的原理，如何優(yōu)化 分庫(kù)分表如何操作 分布式事務(wù)的幾種形式
• 對(duì)分布式事務(wù)的理解
• 一. 數(shù)據(jù)庫(kù) 1.使用mysq1索引都有哪些原則?索引什么數(shù)據(jù)結(jié)構(gòu)?B+tree和Btree什么區(qū)別? 2.mysq有哪些存儲(chǔ)引擎啊?都有啥區(qū)別? 3.設(shè)計(jì)高并發(fā)系統(tǒng)數(shù)據(jù)庫(kù)層面該怎么設(shè)計(jì)?數(shù)據(jù)庫(kù)鎖有哪些類型?如何實(shí)現(xiàn)呀? 4.數(shù)據(jù)庫(kù)事務(wù)有哪些? 二. 分庫(kù)分表 1.如何設(shè)計(jì)可以動(dòng)態(tài)擴(kuò)容縮容的分庫(kù)分表方案? 2.用過(guò)哪些分庫(kù)分表中間件,有啥優(yōu)點(diǎn)和缺點(diǎn)， 3.講一下你了解的分庫(kù)分表中間件的底層實(shí)現(xiàn)原理? 4.我現(xiàn)在有一個(gè)未分庫(kù)分表的系統(tǒng),以后系統(tǒng)需分庫(kù)分表,如何設(shè)計(jì)， 5.讓未分庫(kù)分表的系統(tǒng)動(dòng)態(tài)切換到分庫(kù)分表的系統(tǒng)上? 6.分布式事務(wù)知道嗎?你們?cè)趺唇鉀Q的?TCC?那若出現(xiàn)網(wǎng)絡(luò)原因,網(wǎng)絡(luò)連不通怎么辦啊 7.為什么要分庫(kù)分表啊? 8.分布式尋址方式都有哪些算法?知道一致性hash嗎? 9.手寫(xiě)一下java實(shí)現(xiàn)代碼?你若userId取摸分片,那我要查段連續(xù)時(shí)間里的數(shù)據(jù)怎么辦? 10.如何解決分庫(kù)分表主鍵問(wèn)題?有什么實(shí)現(xiàn)方案?
• 6、分布式事務(wù)的解決方案？ 一、兩階段提交（2PC） 兩階段提交（Two-pha***mit，2PC），通過(guò)引入?yún)f(xié)調(diào)者（Coordinator）來(lái)協(xié)調(diào)參與者的行為，并最終決定這些參與者是否要真正執(zhí)行事務(wù)。 準(zhǔn)備階段：協(xié)調(diào)者詢問(wèn)參與者事務(wù)是否執(zhí)行成功，參與者發(fā)回事務(wù)執(zhí)行結(jié)果。 提交階段：如果事務(wù)在每個(gè)參與者上都執(zhí)行成功，事務(wù)協(xié)調(diào)者發(fā)送通知讓參與者提交事務(wù)；否則，協(xié)調(diào)者發(fā)送通知讓參與者回滾事務(wù)。 二、補(bǔ)償事務(wù)（TCC） TCC 其實(shí)就是采用的補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷）操作。它分為三個(gè)階段： Try 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留 Confirm 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開(kāi)始執(zhí)行 Confirm階段時(shí)，默認(rèn) Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。 Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。 三、本地消息表（異步確保） 本地消息表與業(yè)務(wù)數(shù)據(jù)表處于同一個(gè)數(shù)據(jù)庫(kù)中，這樣就能利用本地事務(wù)來(lái)保證在對(duì)這兩個(gè)表的操作滿足事務(wù)特性，并且使用了消息隊(duì)列來(lái)保證最終一致性。 在分布式事務(wù)操作的一方完成寫(xiě)業(yè)務(wù)數(shù)據(jù)的操作之后向本地消息表發(fā)送一個(gè)消息，本地事務(wù)能保證這個(gè)消息一定會(huì)被寫(xiě)入本地消息表中。 之后將本地消息表中的消息轉(zhuǎn)發(fā)到 Kafka 等消息隊(duì)列中，如果轉(zhuǎn)發(fā)成功則將消息從本地消息表中刪除，否則繼續(xù)重新轉(zhuǎn)發(fā)。 在分布式事務(wù)操作的另一方從消息隊(duì)列中讀取一個(gè)消息，并執(zhí)行消息中的操作。 四、MQ 事務(wù)消息 第一階段Prepared消息，會(huì)拿到消息的地址。 第二階段執(zhí)行本地事務(wù)，第三階段通過(guò)第一階段拿到的地址去訪問(wèn)消息，并修改狀態(tài)。 答案只是個(gè)人的一些觀點(diǎn)，有不對(duì)的歡迎指出來(lái)。
• 分布式事務(wù)的各種方案及你的最佳方案
• 分布式事務(wù)（經(jīng)常被問(wèn)到） 1、兩階段提交（2PC） 第一階段：事務(wù)協(xié)調(diào)器要求每個(gè)涉及到事務(wù)的數(shù)據(jù)庫(kù)預(yù)提交(precommit)此操作，并反映是否可以提交. 第二階段：事務(wù)協(xié)調(diào)器要求每個(gè)數(shù)據(jù)庫(kù)提交數(shù)據(jù)。 優(yōu)點(diǎn)： 盡量保證了數(shù)據(jù)的強(qiáng)一致，適合對(duì)數(shù)據(jù)強(qiáng)一致要求很高的關(guān)鍵領(lǐng)域。（其實(shí)也不能100%保證強(qiáng)一致） 缺點(diǎn)： 實(shí)現(xiàn)復(fù)雜，犧牲了可用性，對(duì)性能影響較大，不適合高并發(fā)高性能場(chǎng)景，如果分布式系統(tǒng)跨接口調(diào)用，目前 .NET 界還沒(méi)有實(shí)現(xiàn)方案。 2、補(bǔ)償事務(wù)（TCC） 針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷）。Try、Confirm、Cancel 優(yōu)點(diǎn)： 跟2PC比起來(lái)，實(shí)現(xiàn)以及流程相對(duì)簡(jiǎn)單了一些，但數(shù)據(jù)的一致性比2PC也要差一些 缺點(diǎn)： 缺點(diǎn)還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應(yīng)用層的一種補(bǔ)償方式，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫(xiě)很多補(bǔ)償?shù)拇a，在一些場(chǎng)景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。 3、本地消息表（異步確保） 核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理，消息生產(chǎn)方，需要額外建一個(gè)消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務(wù)數(shù)據(jù)要在一個(gè)事務(wù)里提交，也就是說(shuō)他們要在一個(gè)數(shù)據(jù)庫(kù)里面。然后消息會(huì)經(jīng)過(guò)MQ發(fā)送到消息的消費(fèi)方。如果消息發(fā)送失敗，會(huì)進(jìn)行重試發(fā)送。 優(yōu)點(diǎn)： 一種非常經(jīng)典的實(shí)現(xiàn)，避免了分布式事務(wù)，實(shí)現(xiàn)了最終一致性。

歡迎關(guān)注和點(diǎn)贊，以及總結(jié)的分類面試題https://github.com/zhendiao/JavaInterview