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