讀寫分離與分庫分表，分佈式事務
- 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發送到消息的消費方。如果消息發送失敗，會進行重試發送。 優點： 一種非常經典的實現，避免了分佈式事務，實現了最終一致性。