一份熱乎乎的騰訊后端面試真題
前言
最近有個(gè)好朋友換工作了，面了騰訊后端，跟他要了份面試真題，大家一起來探討一下，哈哈~
騰訊后端一面
1.JVM內(nèi)存模型
這個(gè)可以復(fù)習(xí)一下《深入理解Java虛擬機(jī)》第12章（Java內(nèi)存模型和線程），放錯(cuò)圖了哈~，也可以看看我之前的文章哈~JVM常見面試題解析
2.cms和g1有沒有了解過，它們有什么區(qū)別
- CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用；
- G1收集器收集范圍是老年代和新生代，不需要結(jié)合其他收集器使用；
- CMS收集器以最小的停頓時(shí)間為目標(biāo)的收集器；
- G1收集器可預(yù)測(cè)垃圾回收的停頓時(shí)間
- CMS收集器是使用“標(biāo)記-清除”算法進(jìn)行的垃圾回收，容易產(chǎn)生內(nèi)存碎片
- G1收集器使用的是“標(biāo)記-整理”算法，進(jìn)行了空間整合，降低了內(nèi)存空間碎片。
這個(gè)點(diǎn)是可以看《深入理解Java虛擬機(jī)》第三章，垃圾收集器與內(nèi)存分配策略哈
3.談?wù)勀銓?duì)垃圾回收的了解，什么時(shí)候發(fā)生垃圾回收，回收過程
可以講JVM中一次完整的GC流程是怎樣的，對(duì)象如何晉升到老年代，如Minor GC，Major GC，full GC這幾個(gè)講清楚，還有對(duì)象存活判斷方法，還有垃圾回收算法，復(fù)制算法等等
這個(gè)點(diǎn)也是可以看《深入理解Java虛擬機(jī)》第三章，垃圾收集器與內(nèi)存分配策略哈
4.對(duì)于數(shù)據(jù)的一致性是怎么保證的
- 這個(gè)如果是我的思路的話，我會(huì)談緩存與數(shù)據(jù)庫的一致性，可以看看我之前這篇文章：
并發(fā)環(huán)境下，先操作數(shù)據(jù)庫還是先操作緩存？
- 也可以談?wù)劮植际绞聞?wù)下的數(shù)據(jù)一致性，也可以看看之前我的這篇文章：
后端程序員必備：分布式事務(wù)基礎(chǔ)篇
5.Redis集群有沒有了解過，主從和選舉是怎么樣子的
- 這個(gè)可以回答這些關(guān)鍵詞，主從復(fù)制 ，哨兵機(jī)制等這些~
- 可以看看網(wǎng)上這篇啦，或者親愛的讀者，去網(wǎng)上看一下資料哈~Redis 主從復(fù)制架構(gòu)和Sentinel哨兵機(jī)制（https://aiylqy.com/archives/213.html）
6.看你們公司使用的是MySQL，你們使用的是哪種存儲(chǔ)引擎，為什么？MyISAM和InnoDB的區(qū)別
- MyISAM：如果執(zhí)行大量的SELECT，MyISAM是更好的選擇
- InnoDB：如果你的數(shù)據(jù)執(zhí)行大量的INSERT或UPDATE，出于性能方面的考慮，應(yīng)該使用InnoDB表
- mysiam表不支持外鍵，而InnoDB支持
MyISAM適合：
- 做很多count 的計(jì)算；
- 插入不頻繁，查詢非常頻繁；
- 沒有事務(wù)。
InnoDB適合：
- 列表內(nèi)容 可靠性要求比較高，或者要求事務(wù)；
- 表更新和查詢都相當(dāng)?shù)念l繁，并且行鎖定的機(jī)會(huì)比較大的情況。
7. 索引的底層數(shù)據(jù)結(jié)構(gòu)是什么，為什么選擇這種數(shù)據(jù)結(jié)構(gòu)
可以看看網(wǎng)上的這篇，寫得不錯(cuò)~MySQL索引為什么要用B+樹實(shí)現(xiàn)？
8. SQL優(yōu)化，怎么判斷需要優(yōu)化，從哪些方面著手優(yōu)化
從索引角度出發(fā)，就有很多點(diǎn)可以講，這個(gè)可以看看我的這兩篇文章哈~
- 后端程序員必備：書寫高質(zhì)量SQL的30條建議
- 后端程序員必備：索引失效的十大雜癥
9.手寫代碼：設(shè)計(jì)一個(gè)分布式自增id生成服務(wù)
可以去網(wǎng)上找一下答案哈，這個(gè)我也沒什么思路~參考分庫分表一些想法？nginx負(fù)載均衡一些想法？哈哈，親愛的讀者，如果你會(huì)的話，可不可以告訴我呢
騰訊后端二面
1.有沒有了解過網(wǎng)絡(luò)安全問題，常見的網(wǎng)絡(luò)攻擊有哪些，原理是什么，可以怎么解決
XSS，跨站腳本攻擊？CSRF,跨站請(qǐng)求偽造？DDOS，分布式拒絕服務(wù)攻擊？SQL注入？
對(duì)于SQL注入，可以進(jìn)行后臺(tái)處理，比如，使用預(yù)編譯語句PreparedStatement進(jìn)行預(yù)處理，又比如Mybatis映射語句中，用#{xxx}而不是${}
2.平時(shí)在開發(fā)接口或者設(shè)計(jì)項(xiàng)目的時(shí)候如何保證安全性的
- 簽名
- 加密
- ip檢測(cè)限流？
- 接口冪等
- 特殊字符實(shí)現(xiàn)過濾 防止xss、sql注入的攻擊？
3.使用Redis集群時(shí)可能會(huì)存在什么問題
數(shù)據(jù)一致性問題
4.有沒有了解過cap和base原則
CAP理論
CAP理論作為分布式系統(tǒng)的基礎(chǔ)理論，指的是在一個(gè)分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)。
一致性(C：Consistency)：
一致性是指數(shù)據(jù)在多個(gè)副本之間能否保持一致的特性。例如一個(gè)數(shù)據(jù)在某個(gè)分區(qū)節(jié)點(diǎn)更新之后，在其他分區(qū)節(jié)點(diǎn)讀出來的數(shù)據(jù)也是更新之后的數(shù)據(jù)。
可用性(A：Availability)：
可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對(duì)于用戶的每一個(gè)操作請(qǐng)求總是能夠在有限的時(shí)間內(nèi)返回結(jié)果。這里的重點(diǎn)是"有限時(shí)間內(nèi)"和"返回結(jié)果"。
分區(qū)容錯(cuò)性（P:Partition tolerance）:
分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然需要能夠保證對(duì)外提供滿足一致性和可用性的服務(wù)。
| 選擇 | 說明 |
|---|---|
| CA | 放棄分區(qū)容錯(cuò)性，加強(qiáng)一致性和可用性，其實(shí)就是傳統(tǒng)的單機(jī)數(shù)據(jù)庫的選擇 |
| AP | 放棄一致性，分區(qū)容錯(cuò)性和可用性，這是很多分布式系統(tǒng)設(shè)計(jì)時(shí)的選擇 |
| CP | 放棄可用性，追求一致性和分區(qū)容錯(cuò)性，網(wǎng)絡(luò)問題會(huì)直接讓整個(gè)系統(tǒng)不可用 |
BASE 理論
BASE 理論， 是對(duì)CAP中AP的一個(gè)擴(kuò)展，對(duì)于我們的業(yè)務(wù)系統(tǒng)，我們考慮犧牲一致性來換取系統(tǒng)的可用性和分區(qū)容錯(cuò)性。BASE是Basically Available(基本可用)，Soft state（軟狀態(tài)）,和 Eventually consistent（最終一致性）三個(gè)短語的縮寫。
Basically Available
基本可用：通過支持局部故障而不是系統(tǒng)全局故障來實(shí)現(xiàn)的。如將用戶分區(qū)在 5 個(gè)數(shù)據(jù)庫服務(wù)器上，一個(gè)用戶數(shù)據(jù)庫的故障只影響這臺(tái)特定主機(jī)那 20% 的用戶，其他用戶不受影響。
Soft State
軟狀態(tài)，狀態(tài)可以有一段時(shí)間不同步
Eventually Consistent
最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時(shí)時(shí)保持強(qiáng)一致。
5.zk是如何保證一致性的
可以看這本書哈~《從paxos到Zookeeper分布式一致性原理與實(shí)踐》，
也可以看這篇文章：淺析Zookeeper的一致性原理（https://zhuanlan.zhihu.com/p/25594630）
6.你如何設(shè)計(jì)一個(gè)能抗住大流量的系統(tǒng)，說說設(shè)計(jì)方案
nginx負(fù)載均衡，流量防衛(wèi)兵sentinel，服務(wù)拆分，緩存，消息隊(duì)列，集群、限流、降級(jí)這些都可以搬出來啦~
7.有沒有了解過緩存策略有哪些
- Cache-Aside
- Read-Through
- Write-Through
- Write-Behind
有興趣還是可以看看我這篇文章 : 并發(fā)環(huán)境下，先操作數(shù)據(jù)庫還是先操作緩存？
