據說做刷掌核身和支付。要鴿嗎，有沒有懂哥，現(xiàn)在手里有小紅書c端核組，和b站技術架構offer，咋選呀。

2025-04-09 20:57 網申投遞簡歷4-21 一面 http://www.fangfengwang8.cn/feed/main/detail/ffbadb65eb5e47d392e6ea419ad38fcb?sourceSSR=users，其實一直在推進度，只是我還有別的面試流程4-23 二面 http://www.fangfengwang8.cn/feed/main/detail/265157a02c384eb6aef47d2b3d50fed04-24上午 HR面 http://www.fangfengwang8.cn/feed/main/detail/5a16b58cb1cc431b811763a...

無手撕  面試官遲到三分鐘（這應該不算遲到）以為會問八股，結果全是項目引申的，麻了 有的面試官不問我這玩具項目嗚嗚+在日常實習就沒看，自己介紹都沒講清楚1. 線程通信方式  oom  線程安全 死鎖2. 分布式事務 如果c超時沒反應， 咋處理。直接通知回滾的話，可能有c先處理回滾的命令，后面又執(zhí)行了本地事務（c查看本地事務的狀態(tài) 執(zhí)行中就不回滾 還是咋處理）3. 協(xié)調者掛了 咋辦  項目: 庫存變化流程 redis回滾庫存為啥會超賣 mq重投db會不會超賣 （冪等判斷和回滾在一個事務中）4. 分庫和分表的區(qū)別（分庫一般是多個實例解決高并發(fā)，分表是單表數(shù)據量比較大  分庫和分表很像，都是按分片鍵路由）基于買家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ù)據庫實例級別                   | 單表結構級別           || 核心目標  | 降低單點壓力，提升并發(fā)處理能力        | 解決單表數(shù)據量過大問題   || 典型場景  | 電商系統(tǒng)買家?guī)臁⒂唵螏旆蛛x           | 用戶表按月分表          || 實施難度  | 需要處理分布式事務、跨庫join        | 主要處理SQL路由        |

1.自我介紹2.項目中使用緩存情況、緩存一致性問題、項目中使用的哪種3.項目如何使用單元測試的4.手撕leetcode有效ip，SQL超過五個直屬員工的領導5.數(shù)據庫索引類型6.索引失效場景7.concurrent包下的類8.AQS基本原理、實現(xiàn)了AQS的類9.synchronized跟lock區(qū)別10.Jvm對synchronized的優(yōu)化11.垃圾回收算法、以及jvm不同的回收器已掛