一份熱乎乎的騰訊后端面試真題

作者：佚名 2020-05-11 15:15:24

運(yùn)維數(shù)據(jù)庫運(yùn)維

最近有個(gè)好朋友換工作了，面了騰訊后端，跟他要了份面試真題，大家一起來探討一下，哈哈~

前言

最近有個(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ù)測垃圾回收的停頓時(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ù)勀銓厥盏牧私猓裁磿r(shí)候發(fā)生垃圾回收，回收過程

可以講JVM中一次完整的GC流程是怎樣的，對象如何晉升到老年代，如Minor GC，Major GC，full GC這幾個(gè)講清楚，還有對象存活判斷方法，還有垃圾回收算法，復(fù)制算法等等

這個(gè)點(diǎn)也是可以看《深入理解Java虛擬機(jī)》第三章，垃圾收集器與內(nèi)存分配策略哈

4.對于數(shù)據(jù)的一致性是怎么保證的

這個(gè)如果是我的思路的話，我會談緩存與數(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，你們使用的是哪種存儲引擎，為什么？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ī)會比較大的情況。

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ù)載均衡一些想法？哈哈，親愛的讀者，如果你會的話，可不可以告訴我呢

騰訊后端二面

1.有沒有了解過網(wǎng)絡(luò)安全問題，常見的網(wǎng)絡(luò)攻擊有哪些，原理是什么，可以怎么解決

XSS，跨站腳本攻擊？CSRF,跨站請求偽造？DDOS，分布式拒絕服務(wù)攻擊？SQL注入？

對于SQL注入，可以進(jìn)行后臺處理，比如，使用預(yù)編譯語句PreparedStatement進(jìn)行預(yù)處理，又比如Mybatis映射語句中，用#{xxx}而不是${}

2.平時(shí)在開發(fā)接口或者設(shè)計(jì)項(xiàng)目的時(shí)候如何保證安全性的

簽名
加密
ip檢測限流？
接口冪等
特殊字符實(shí)現(xiàn)過濾防止xss、sql注入的攻擊？

3.使用Redis集群時(shí)可能會存在什么問題

數(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)，對于用戶的每一個(gè)操作請求總是能夠在有限的時(shí)間內(nèi)返回結(jié)果。這里的重點(diǎn)是"有限時(shí)間內(nèi)"和"返回結(jié)果"。

分區(qū)容錯(cuò)性（P:Partition tolerance）:

分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然需要能夠保證對外提供滿足一致性和可用性的服務(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ò)問題會直接讓整個(gè)系統(tǒng)不可用

BASE 理論

BASE 理論，是對CAP中AP的一個(gè)擴(kuò)展，對于我們的業(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ù)庫的故障只影響這臺特定主機(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ì)列，集群、限流、降級這些都可以搬出來啦~

7.有沒有了解過緩存策略有哪些