1. ?分布式訂單ID生成? 短時(shí)間高并發(fā)下如何保證唯一性？
我先回答了雪花-like, 上段實(shí)習(xí)中, 我們項(xiàng)目的全局GUID生成器是我寫(xiě)的, 考慮了短時(shí)間內(nèi)大量產(chǎn)生的情況, 向后借用, 未考慮時(shí)鐘回?fù)?br />然后想起來(lái)當(dāng)時(shí)和leader討論,  單獨(dú)的GUID生成中心, 分批向各個(gè)ds批發(fā)號(hào)段.. 或者是用tacplus的自增id, 但是這樣效率太低
2. ?CPU 性能瓶頸分析
使用 prof 工具監(jiān)視熱點(diǎn)函數(shù)的性能消耗
3. 上段實(shí)習(xí)工作內(nèi)容? 難點(diǎn)?
    背包/倉(cāng)庫(kù)/道具 ?重構(gòu)模塊
追問(wèn)?：
    在兩周內(nèi)重構(gòu)1萬(wàn)行代碼，如何保證代碼質(zhì)量？是否引入單元測(cè)試或自動(dòng)化驗(yàn)證？
    10天完成15天任務(wù)，如何協(xié)調(diào)開(kāi)發(fā)與測(cè)試資源？是否犧牲技術(shù)債？
4. 問(wèn)了一點(diǎn)網(wǎng)絡(luò): 網(wǎng)絡(luò)通信與實(shí)時(shí)系統(tǒng)
視頻會(huì)議與代碼共享的鏈路設(shè)計(jì)
追問(wèn)?：解釋從你的設(shè)備到面試官屏幕的完整網(wǎng)絡(luò)路徑（如NAT穿透、協(xié)議選擇）

5. 游戲服務(wù)器同步機(jī)制? 和互聯(lián)網(wǎng)開(kāi)發(fā)的區(qū)別
服務(wù)器作為權(quán)威狀態(tài)源，定期向客戶端廣播游戲世界的完整或增量狀態(tài)（如玩家位置、血量）
電商無(wú)狀態(tài)服務(wù)可通過(guò)REST API+RPC橫向擴(kuò)展，而游戲服務(wù)器需維護(hù)長(zhǎng)連接和會(huì)話狀態(tài)。

6. 系統(tǒng)設(shè)計(jì) 分布式事務(wù)與最終一致性?
游戲道具交易涉及多個(gè)系統(tǒng)（背包、倉(cāng)庫(kù)、郵件），如何設(shè)計(jì)分布式事務(wù)？對(duì)比電商訂單支付+庫(kù)存扣減。
?回答方向?：
?Saga模式?：將事務(wù)拆分為多個(gè)可補(bǔ)償步驟（如“扣道具-發(fā)郵件-記錄日志”，失敗則回滾）。
對(duì)比：電商更傾向異步消息隊(duì)列?（如Kafka）實(shí)現(xiàn)最終一致性。
7. 游戲服務(wù)器宕機(jī)后如何快速恢復(fù)玩家狀態(tài)？電商系統(tǒng)如何設(shè)計(jì)類(lèi)似容災(zāi)機(jī)制？
定時(shí)落DB+游戲整體運(yùn)行在共享內(nèi)存, 方便resume

7. 游戲后端請(qǐng)求鏈路分析
采用自定義的可靠UDP協(xié)議?（KCP），平衡延遲與可靠性. 玩家操作（如移動(dòng)、技能釋放）需攜帶時(shí)間戳和操作序列號(hào)，用于服務(wù)端驗(yàn)證順序, 請(qǐng)求直達(dá), 客戶端直接和服務(wù)器

感覺(jué)面試內(nèi)容很不"八股", 答得稀里糊涂的, 上面的順序不是面試提問(wèn)順序, 想起來(lái)什么說(shuō)什么, 大家做個(gè)參考