場景和設計
- 為什么要這樣分表渐扮？跨庫join如何解決论悴？數(shù)據(jù)量突增怎么解決？ 如何解決線上問題墓律？cpu狂飆怎么辦膀估？頻繁minor gc怎么辦？可能造成的原因是什么耻讽？如何避免察纯？ 數(shù)據(jù)庫 隔離級別，怎么實現(xiàn)的针肥？當前讀饼记，快照讀？MVCC慰枕？
- 分庫分表的設計具则？ 分布式事務出現(xiàn)過不一致嗎？為什么具帮？怎么解決博肋？有什么方法避免？怎么監(jiān)控蜂厅？監(jiān)控到怎么處理匪凡？什么時候需要人工接入
- 如何優(yōu)雅的寫代碼？什么代碼算做優(yōu)雅掘猿？什么代碼是規(guī)范病游？你們代碼規(guī)范是什么樣的？ 如何進行code review稠通？
- mysql innodb下衬衬，能不能不設置主鍵？主鍵可以為空嗎采记？可以允許幾個佣耐？主鍵跟非主鍵的區(qū)別？索引存儲形式唧龄？ 聯(lián)合索引失效問題兼砖？索引失效問題奸远？mysql索引，覆蓋索引讽挟？回表懒叛？B+樹葉子節(jié)點存儲什么？為什么不用AVL樹耽梅？ 數(shù)據(jù)庫鎖薛窥，樂觀，悲觀眼姐，record lock诅迷？next-key lock颂鸿？
- 不停機擴容秽晚？分表避免冷熱？不停機擴庫大磺？不停機擴表贡歧？跨庫事務滩租？
- Redis與Mysql雙寫一致性方案
- 微服務需要注意些什么?
- redis并發(fā)競爭key的解決方案
- 高并發(fā)系統(tǒng)的設計與實現(xiàn)
- 高并發(fā)系統(tǒng)的限流如何實現(xiàn)？
- 如何從0到1設計一個類似Dubbo的RPC框架利朵？
- 線上有實際的性能優(yōu)化經(jīng)驗律想？ 3、從SQL绍弟、JVM技即、架構、數(shù)據(jù)庫四個方面講講優(yōu)化思路晌柬，以及如何優(yōu)先排序姥份？
- 如果讓你實現(xiàn)一個mq，怎么樣保證消息不丟失
- 從簡單的生產(chǎn)者消費者模式設計到如何高效健壯實現(xiàn)等等
- 然后根據(jù)一個項目年碘，問如果量級擴大1000倍澈歉，你會怎么做？
- 如果讓你做一個監(jiān)控告警服務屿衅，你怎么設計
- 如果生產(chǎn)者生產(chǎn)的數(shù)據(jù)量很多埃难，消費者來不及消費這些數(shù)據(jù)怎么辦，
- 某一個業(yè)務中現(xiàn)在需要生成全局唯一的遞增 ID, 并發(fā)量非常大, 怎么做
- 考慮一個業(yè)務場景: 頭條的文章的評論量非常大, 比如說一篇熱門文章就有幾百萬的評論, 設計一個后端服務, 實現(xiàn)評論的時序展示與分頁
- 假如用 id 翻頁的方式, 數(shù)據(jù)庫表如何設計涤久？索引如何設計涡尘？ 假如量很大, 你覺得需要分庫分表嗎? 怎么分？ 分庫分表后怎么查詢分頁响迂？ 分庫分表后怎么保證主鍵仍然是遞增的考抄？ 現(xiàn)在需要支持深分頁, 頁碼直接跳轉, 怎么實現(xiàn)？
- 工作當中cpu和內(nèi)存異常排查方法蔗彤；詳細說明分析過程及定位解決方式
- redis問了一個實際問題的解決辦法川梅，如果redis一個value特別大疯兼，有什么解決方案；
- 接口調(diào)用變慢排查
- 解決項目運行時贫途，CPU占用過高的問題
- 死鎖怎么排查吧彪？
- 怎么不斷優(yōu)化項目、架構升級丢早？如果業(yè)務量劇增姨裸，怎么保證系統(tǒng)高可用、擴展性怨酝？
- 系統(tǒng)負載過高怎么辦傀缩、什么問題導致的？怎么排查凫碌？
- JVM調(diào)優(yōu)思路
- redis cluster集群擴容怎么數(shù)據(jù)平滑過度扑毡，從客戶端設計
- 設計一個im系統(tǒng)包括群聊單聊
- 設計數(shù)據(jù)庫連接池
- 秒殺場景的設計
- VM 出現(xiàn) fullGC 很頻繁，怎么去線上排查問題盛险？
- 設計一個系統(tǒng)，每天有100億條數(shù)據(jù)勋又，需要在后臺做實時展示和查找苦掘。 我當時回答的大體思路是nginx負載均衡，消息隊列存儲楔壤，多線程讀取鹤啡，批量插入，數(shù)據(jù)庫分庫分表蹲嚣。 面試官根據(jù)我的回答又衍生出了很多問題递瑰，如消息隊列存滿了怎么辦？（也就是消費跟不上生產(chǎn)）批量插入時某一條失敗了有什么影響隙畜？怎么解決抖部？分庫分表應該怎么分？怎么解決數(shù)據(jù)遷移的問題议惰？
- 內(nèi)存泄露慎颗，內(nèi)存溢出解決方案？
- A系統(tǒng)和B系統(tǒng)需要交互言询，A系統(tǒng)需要更新B系統(tǒng)的大量數(shù)據(jù)俯萎，但是更新失敗了，有什么解決方法运杭。
- 高并發(fā)場景 1夫啊、如何定時得往數(shù)據(jù)庫中插入500萬條數(shù)據(jù)以及刪除，保證數(shù)據(jù)插入正確做到最優(yōu)解辆憔； 2撇眯、在高并發(fā)下如何設計使用Redis谆趾；3、在高并發(fā)場景下如何設計一個接口叛本，保證這個接口高性能高可用沪蓬；
- 如何讀取一個很大得文件里面存入了很多url怎么找到最常用得url；
- 如果頁面點擊反應慢来候，你怎么排查的跷叉？最后怎么優(yōu)化？ 分布式你怎么怎么保持數(shù)據(jù)一致性的 說一下springboot啟動run方法里都干了什么 給你ip1到ip2的一個ip段营搅，再給你一個ip云挟，用程序判斷這個ip屬不屬于這個ip段 講一下zk 你們zk掛了怎么處理的，你們redis掛了用的什么策略解決的
- 兩個10G的文件转质，里面是一些url园欣，內(nèi)存只有1G，如何將這兩個文件合并休蟹，找到相同的url沸枯？
- 100W 的數(shù)據(jù)，需要定時更新赂弓，失敗需要重試绑榴，需要盡快執(zhí)行完成。現(xiàn)在機器數(shù)量不固定盈魁，如何用最少的代碼實現(xiàn)
- 一個任務在平時只需要 5 個線程就可以處理好翔怎，忙的時候需要 100 個線程才能處理完成， 如何設計才能合理利用資源杨耙？
- 規(guī)定給出的并發(fā)量外赤套，如果有額外的流量訪問進來了，如何做熔斷處理珊膜？
- 搜索時延這么高容握，該如何進行優(yōu)化？如何提高響應速度辅搬？如何優(yōu)化以提升用戶體驗度唯沮？
- 如何實現(xiàn)何高并發(fā)下的削峰，限流堪遂？
- 服務器雪崩是怎么造成的介蛉？之前有這樣的經(jīng)歷嗎？怎么防備溶褪？
- 內(nèi)存500M币旧，有個文件存有int類型數(shù)據(jù)1億條，要去讀取猿妈，怎么處理
- 從需求到開發(fā)到上線吹菱。如何對需求進行有效管理巍虫？
- 假設有一個場景，系統(tǒng)需要某個特定時間內(nèi)響應用戶請求鳍刷，比如說100ms內(nèi)完成用戶請求占遥，但是在最高峰的時候每單位時間幾百萬的用戶請求，也就是高并發(fā)输瓜，但我必須要實現(xiàn)系統(tǒng)響應及時瓦胎，而且高可用(不宕機)，假如你是架構師尤揣，你該如何架構這個系統(tǒng)搔啊，聊聊你的方案。
- 如果要對系統(tǒng)進行監(jiān)控北戏，考慮哪些方面负芋，如何實現(xiàn)？
- 如果你現(xiàn)在CPU100%了嗜愈，你如何查詢是哪個進程旧蛾，哪個線程，哪行代碼占用CPU過高芝硬？
- 自己寫程序?qū)崿F(xiàn)MySQL不同實例之間的導表/要求盡量高并發(fā)高效/給出設計
- 前臺訂單數(shù)據(jù)庫如何與倉庫庫存數(shù)據(jù)庫保持同步蚜点？限時搶購如何實現(xiàn)？
- 場景：同時給10萬個人發(fā)工資拌阴，怎么樣設計并發(fā)方案，能確保在1分鐘內(nèi)全部發(fā)完奶镶？
- 設計一個訂餐排隊系統(tǒng)迟赃，底層模型有哪些？(客戶厂镇，商家纤壁，桌型)
- 單臺機器4核，服務A請求時間為5S捺信，但是A調(diào)用的某個服務B耗時4.98S酌媒，A服務超時時間是10S，問100QPS的訪問量迄靠，動態(tài)線程池CoreSize,maxSize,等待隊列怎么指定秒咨？
- 多個平臺（B端C端）有多個支付的接口可利用，如何設計表掌挚；
- 給你100億個賬號和密碼雨席，怎么用純Java自己設計一個緩存系統(tǒng)；
- 問重啟服務的時候吠式，發(fā)現(xiàn)線程數(shù)特別高陡厘，可能是什么問題抽米？
- 秒殺系統(tǒng)如何設計？
- 如何實現(xiàn)1億用戶的消息通知機制糙置？
- 秒殺業(yè)務怎樣防止超賣云茸；
- 怎么搭建一個自動化構建和發(fā)布環(huán)境，怎么從0開始搭建一個測試環(huán)境
- 分布式緩存實現(xiàn)原理谤饭，秒殺業(yè)務怎樣防止超賣标捺；
- 系統(tǒng)在10：05 設置一個值，并給出5分鐘的過期時間网持，系統(tǒng)剛剛set完之后redis集群崩潰宜岛，10：11分系統(tǒng)重啟成功，那么redis中set的值是否還存在功舀？
- 成千上萬個數(shù)據(jù)文件萍倡，每個文件大概2GB數(shù)據(jù)量，只用java基礎實現(xiàn)所有數(shù)據(jù)的讀取辟汰，并按每條數(shù)據(jù)的時間排序列敲；
- 設計十萬并發(fā)級別的網(wǎng)站后臺，如何計算使用的ecs數(shù)目帖汞；
- 10G的整數(shù)中戴而，取出最大的一個；
- 設計一個系統(tǒng)翩蘸，每天有100億條數(shù)據(jù)所意，需要在后臺做實時展示和查找。
歡迎關注和點贊
