騰訊音樂面經(jīng)

一面

多級緩存下，它的這個跟數(shù)據(jù)庫一致性它怎么做去保證的？
（關于 mget 改成 get 的優(yōu)化）那其實我這里有點好奇是說，因為其實 mget 是一個批處理的獲取命令。它如果在全部改成 get 的話，現(xiàn)在網(wǎng)絡開銷會增加不少。那為什么的 RT 時間會減少呢？
（針對簡歷描述“減少每日 53K 批量操作”）減少每日 53K，其實我感覺好像這個 KP(QPS?) 的不是很高... 這個 S 的這個操作好像也對不上。（質(zhì)疑/要求澄清優(yōu)化效果與描述的關聯(lián)）
那權益卡那邊有做一些，比如說超發(fā)了一些防護嗎？就是一些問題嗎？
對于你負責的那個業(yè)務模塊里面，有沒有遇到什么一些服務問題？就你遇到這個問題到當時是怎么解決的？（要求舉例說明遇到的棘手問題及解決方案）
有遇到一些緩存的一些集中性的一些問題嗎？... 熱 key 的一些問題有沒有遇到過？
原本有考慮過用布隆過濾器那些東西嗎？

系統(tǒng)運維 & 監(jiān)控 & 壓測

你寫的服務有對自己服務進行一個壓測嗎？
（服務）有做一些監(jiān)控嗎？就是怎么發(fā)現(xiàn)一些異常。

數(shù)據(jù)庫 (MySQL)

假設某一天... mysql... 它的負載變高了，你覺得它可能是什么問題引起的？
（針對 MySQL 負載高）讓你的排查的一個思路跟流程... 你會怎么去去定位這種問題，然后去解決這種問題。
（MySQL CPU 升高）怎么看呢？（指用什么命令或工具）
慢查詢，你覺得有可能有些什么情況會導致一些索引失效，這種情況？
假設我要減少一些回表的話，我所以（索引）應該怎么設計？（覆蓋索引相關）
你剛說的 B 加數(shù)，它跟 B 數(shù)的區(qū)別在哪里？
B 數(shù)它的有什么適用的一種場景嗎？（相對 B+樹）
日常有用到（的）數(shù)據(jù)庫是用到 B 樹了嗎？（確認 MongoDB 是否使用 B 樹）
怎么避免長事務呢？
（關于事務開始時間）但一個事物真正開始可能不是 start 這句話就開始。（暗示/引導思考）

緩存 (Redis)

（項目里有提到）防止緩存雪崩的一些問題嗎？
你能講一講 redis 那個數(shù)據(jù)淘汰的一些策略嗎？
（項目里）有用到一個 sorted set 的一個 set 結構嗎？你知道它底層數(shù)據(jù)結構是什么這種結構嗎？（跳表/壓縮列表）

Linux & 網(wǎng)絡

假設我要向（想）看一下網(wǎng)絡端口的一個占用情況的話，你會下什么命令。
假設我想看一下端口那個網(wǎng)絡狀態(tài)... 到底處于比如說 TCP 哪種階段。
假設我看到通過 netstat 那個命令，看到很多端口處于那種 time_wait 的那種狀態(tài)，你覺得是什么問題引起的？
怎么怎么避免這種情況（大量 TIME_WAIT）？
有了解過 TCP 里面的一個快速重傳機制嗎？
有了解 TCP 粘包的一些問題嗎？

Go 語言

（項目里有用 Go 嗎？）能能解說一下夠（Go）的那個（GC）的一個雞翅（機制）嗎？

算法 & 數(shù)據(jù)結構

比如說我有一個 10 億個整數(shù)，對我要快速找到最大 100 個。對你怎么做？（Top K 問題）
你能說一下快速排序跟歸并排序的它的一個時間復雜度嗎？
這兩者（快速排序和歸并排序）的區(qū)別在哪里？

二面

一般這個（活動接口）QPS 會有多高？
你是說 Redis 的 QPS 不是整個業(yè)務的 QPS 是吧？就不是一個接口的 API 的 QPS。
這兩者（API QPS vs Redis QPS）有看過差距會有多大嗎？
當時為什么關注更更關注 Redis QPS，而不是 API 的 QPS？
那 Redis 后面是 7 萬（QPS），然后就要做什么優(yōu)化嗎？
那那本地緩存優(yōu)化之后，Redis 的 QPS 降了多少？
之前是沒有本地緩存是嗎？
然后本地緩存是用什么？也是用什么做的？（確認是 Caffeine）
那這個二級緩存會跟 Redis 的緩存...可能會有在某些瞬間不一致，會有什么業(yè)務損失嗎？
這個就是那這一個維護緩存的是一個獨立的服務嗎？
那有那個比如說那有操作失?。ň彺娓?刪除）的情況嗎？會怎么樣？
然后這個 Redis...本身你是第一級緩存，它底層的數(shù)據(jù)是有 MySQL 的嗎？還是就是靠剛說那個一個服務來更新的。
然后 Redis...假使斷電丟失了會怎么樣？斷電重啟了會怎么樣？
你前面說說從 MySQL 里面找，然后這個找是有現(xiàn)成程序的，還是到時候可能假設發(fā)生情況了，可能是要重新看怎么去重新去 load 數(shù)據(jù)...還是什么。它是自然而然的。（追問緩存加載/恢復機制）
那你前面是說那個可能是運營人員在后臺操作上上下線的時候才會更新 Redis 是吧？還是說就前端有讀取的時候，也會從 MySQL 里面去讀，然后讀到更新到 Redis。（追問緩存更新觸發(fā)機制）
但就像你剛才說的，像 AOF 這些，其實平常都是運維管，你們不管的對嗎？還是你們會參與？
比如說（Redis 抖動）什么意思？（要求解釋技術術語/現(xiàn)象）
然后這種（Redis 抖動）會認為健康還是需要什么處理嗎？（監(jiān)控與應對）
最終在整個活動模塊上...過程中還還你還有碰到什么其他問題，或者覺得比較不合理的地方嗎？哪怕可能還沒來得及做的優(yōu)化的。
比如說一個用戶命中 100 個活動，然后你預期它的這個存儲消耗大概是多大。
那看上去就是可能說這部分，你是認為這部分關聯(lián)關系的存儲成本大，還是那個活動詳情的那部分存儲成本的？
（針對候選人回答活動詳情占用內(nèi)存大）但是那個活動詳情他可能總共也就 100 或者說最多幾百個活動。他可能就在這臺機器上總共也占不了多少空間...總共可能也就只有一兆數(shù)據(jù)。（質(zhì)疑/挑戰(zhàn)候選人關于內(nèi)存消耗的判斷）
怎么會 GC 呢？如果說占的那個內(nèi)存空間不是很大的話，那為什么會 GC 呢？（追問 GC 觸發(fā)原因）

技術棧 & 設計能力

其實像你現(xiàn)在這些技術棧，整個 Spring 或者 MySQL 或者這些...你覺得其實你用哪一個，其實你覺得用的是比較好，比較有優(yōu)勢。
你一般你自己的你習慣性的思考的數(shù)據(jù)的方式，你覺得會偏 Redis 這樣 KV 的還是 MySQL 這種關系型數(shù)據(jù)庫的。
MySQL，那在一些具體的 MySQL 的那些表的設計上，你覺得有哪個案例是你你過去的哪個實習案例是比較能體現(xiàn)這種 MySQL 的一些設計或者理解能力的。
那你一般會怎么去梳理（數(shù)據(jù)庫設計）嗎？是會怎么寫文檔，或者寫一個什么樣的文檔，或者畫一個什么樣的圖。
然后一般實現(xiàn)會按 ER 圖來實現(xiàn)，還是說可能經(jīng)常會有什么樣的妥協(xié)。
（針對 MySQL 存儲 JSON）你是是你會直接存?zhèn)€字符串，還是用它本身現(xiàn)在支持的 JSON 的一個字段能實現(xiàn)。
（針對使用 Text 存 JSON 的妥協(xié)）并（頻繁變更的列）剛才是因為要頻繁讀寫。（確認妥協(xié)原因）