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