前言

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

騰訊后端一面

1.JVM內(nèi)存模型

這個可以復(fù)習(xí)一下《深入理解Java虛擬機(jī)》第12章（Java內(nèi)存模型和線程），放錯圖了哈~，也可以看看我之前的文章哈~JVM常見面試題解析

2.cms和g1有沒有了解過，它們有什么區(qū)別

•  CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用；
•  G1收集器收集范圍是老年代和新生代，不需要結(jié)合其他收集器使用；
•  CMS收集器以最小的停頓時間為目標(biāo)的收集器；
•  G1收集器可預(yù)測垃圾回收的停頓時間
•  CMS收集器是使用“標(biāo)記-清除”算法進(jìn)行的垃圾回收，容易產(chǎn)生內(nèi)存碎片
•  G1收集器使用的是“標(biāo)記-整理”算法，進(jìn)行了空間整合，降低了內(nèi)存空間碎片。

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

3.談?wù)勀銓厥盏牧私猓裁磿r候發(fā)生垃圾回收，回收過程

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

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

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

•  這個如果是我的思路的話，我會談緩存與數(shù)據(jù)庫的一致性，可以看看我之前這篇文章：

        并發(fā)環(huán)境下，先操作數(shù)據(jù)庫還是先操作緩存？

•  也可以談?wù)劮植际绞聞?wù)下的數(shù)據(jù)一致性，也可以看看之前我的這篇文章：

        后端程序員必備：分布式事務(wù)基礎(chǔ)篇

5.Redis集群有沒有了解過，主從和選舉是怎么樣子的

•  這個可以回答這些關(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適合：

1.  做很多count 的計算；
2.  插入不頻繁，查詢非常頻繁；
3.  沒有事務(wù)。

InnoDB適合：

1.  列表內(nèi)容 可靠性要求比較高，或者要求事務(wù)；
2.  表更新和查詢都相當(dāng)?shù)念l繁，并且行鎖定的機(jī)會比較大的情況。

7. 索引的底層數(shù)據(jù)結(jié)構(gòu)是什么，為什么選擇這種數(shù)據(jù)結(jié)構(gòu)

可以看看網(wǎng)上的這篇，寫得不錯~MySQL索引為什么要用B+樹實現(xiàn)？

8. SQL優(yōu)化，怎么判斷需要優(yōu)化，從哪些方面著手優(yōu)化

從索引角度出發(fā)，就有很多點可以講，這個可以看看我的這兩篇文章哈~

•  后端程序員必備：書寫高質(zhì)量SQL的30條建議
•  后端程序員必備：索引失效的十大雜癥

9.手寫代碼：設(shè)計一個分布式自增id生成服務(wù)

可以去網(wǎng)上找一下答案哈，這個我也沒什么思路~參考分庫分表一些想法？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.平時在開發(fā)接口或者設(shè)計項目的時候如何保證安全性的

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

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

數(shù)據(jù)一致性問題

4.有沒有了解過cap和base原則

CAP理論

CAP理論作為分布式系統(tǒng)的基礎(chǔ)理論，指的是在一個分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯性），這三個要素最多只能同時實現(xiàn)兩點。

一致性(C：Consistency)：

一致性是指數(shù)據(jù)在多個副本之間能否保持一致的特性。例如一個數(shù)據(jù)在某個分區(qū)節(jié)點更新之后，在其他分區(qū)節(jié)點讀出來的數(shù)據(jù)也是更新之后的數(shù)據(jù)。

可用性(A：Availability)：

可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內(nèi)返回結(jié)果。這里的重點是"有限時間內(nèi)"和"返回結(jié)果"。

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

分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務(wù)。

選擇	說明
CA	放棄分區(qū)容錯性，加強一致性和可用性，其實就是傳統(tǒng)的單機(jī)數(shù)據(jù)庫的選擇
AP	放棄一致性，分區(qū)容錯性和可用性，這是很多分布式系統(tǒng)設(shè)計時的選擇
CP	放棄可用性，追求一致性和分區(qū)容錯性，網(wǎng)絡(luò)問題會直接讓整個系統(tǒng)不可用

BASE 理論

BASE 理論， 是對CAP中AP的一個擴(kuò)展，對于我們的業(yè)務(wù)系統(tǒng)，我們考慮犧牲一致性來換取系統(tǒng)的可用性和分區(qū)容錯性。BASE是Basically Available(基本可用)，Soft state（軟狀態(tài)）,和 Eventually consistent（最終一致性）三個短語的縮寫。

Basically Available

基本可用：通過支持局部故障而不是系統(tǒng)全局故障來實現(xiàn)的。如將用戶分區(qū)在 5 個數(shù)據(jù)庫服務(wù)器上，一個用戶數(shù)據(jù)庫的故障只影響這臺特定主機(jī)那 20% 的用戶，其他用戶不受影響。

Soft State

軟狀態(tài)，狀態(tài)可以有一段時間不同步

Eventually Consistent

最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時時保持強一致。

5.zk是如何保證一致性的

可以看這本書哈~《從paxos到Zookeeper分布式一致性原理與實踐》，

也可以看這篇文章：淺析Zookeeper的一致性原理（https://zhuanlan.zhihu.com/p/25594630）

6.你如何設(shè)計一個能抗住大流量的系統(tǒng)，說說設(shè)計方案

nginx負(fù)載均衡，流量防衛(wèi)兵sentinel，服務(wù)拆分，緩存，消息隊列，集群、限流、降級這些都可以搬出來啦~

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

•  Cache-Aside
•  Read-Through
•  Write-Through
•  Write-Behind

有興趣還是可以看看我這篇文章 : 并發(fā)環(huán)境下，先操作數(shù)據(jù)庫還是先操作緩存？