無手撕  面試官遲到三分鐘（這應該不算遲到）

以為會問八股，結果全是項目引申的，麻了 有的面試官不問我這玩具項目嗚嗚+在日常實習就沒看，自己介紹都沒講清楚
1. 線程通信方式  oom  線程安全 死鎖
2. 分布式事務 如果c超時沒反應， 咋處理。直接通知回滾的話，可能有c先處理回滾的命令，后面又執(zhí)行了本地事務（c查看本地事務的狀態(tài) 執(zhí)行中就不回滾 還是咋處理）
3. 協(xié)調者掛了 咋辦  
項目: 庫存變化流程 redis回滾庫存為啥會超賣 mq重投db會不會超賣 （冪等判斷和回滾在一個事務中）
4. 分庫和分表的區(qū)別（分庫一般是多個實例解決高并發(fā)，分表是單表數(shù)據(jù)量比較大  分庫和分表很像，都是按分片鍵路由）
基于買家id分表分庫的話，賣家想查詢怎么辦（binlog 賣家id分片）
自己說話要堅定，不能弱弱慫慫的
 晚上一看，掛了
感覺是除了分布式事務那兩問題基本都能回答個大概，可能"大概"這種程度不行吧，太久沒看了，自己的項目都不熟了，分布式事務確實就學了一點   

看見我的項目都想吐，重復看的東西。。#畢業(yè)后不工作的日子里我在做什么#
嗚嗚嗚嗚，好菜，本科學歷不太行感覺銀行國企也不太穩(wěn)麻了

3. 我搜的是1.TCC  2.本地消息表  3.多節(jié)點選舉機制（如Raft協(xié)議）實現(xiàn)高可用，避免單點故障     三階段提交只是緩解了單點故障問題      （TCC和本地消息表根本就沒有協(xié)調者所以沒有單點故障   沒有往這上面想 一直在繞三階段提交）
2. #### 1. 參與者C超時無響應
**解決方案：**
- **事務狀態(tài)查詢機制**：協(xié)調者先發(fā)起事務狀態(tài)查詢（3PC中的CanCommit階段）
- **異步補償機制**：記錄操作日志，超時后通過定時任務重試事務查詢
- **最終一致性兜底**：若長時間無響應，記錄異常事務日志人工介入
- **示例流程**：
  1. 協(xié)調者發(fā)送prepare請求
  2. 參與者C超時未響應
  3. 協(xié)調者發(fā)起事務狀態(tài)查詢請求
  4. 若C本地事務已提交 -> 繼續(xù)提交其他參與者
  5. 若C未提交/回滾 -> 發(fā)起全局回滾
（我前面講的RMQ的事務消息 也是反查本地事務狀態(tài) 這沒回答出來）
4. ### 二、分庫分表核心區(qū)別
|          | 分庫                          | 分表                  |
|----------|-----------------------------|---------------------|
| 拆分維度  | 數(shù)據(jù)庫實例級別                   | 單表結構級別           |
| 核心目標  | 降低單點壓力，提升并發(fā)處理能力        | 解決單表數(shù)據(jù)量過大問題   |
| 典型場景  | 電商系統(tǒng)買家?guī)臁⒂唵螏旆蛛x           | 用戶表按月分表          |
| 實施難度  | 需要處理分布式事務、跨庫join        | 主要處理SQL路由        |