Skip to content

Commit b613fe1

Browse files
committed
腾讯面试
1 parent bdf6646 commit b613fe1

3 files changed

Lines changed: 163 additions & 0 deletions

File tree

Lines changed: 163 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,163 @@
1+
## 前言
2+
最近有个好朋友换工作了,面了腾讯后端,跟他要了份面试真题,大家一起来探讨一下,哈哈~
3+
4+
## 腾讯后端一面
5+
### ① JVM内存模型
6+
7+
这个可以复习一下《深入理解Java虚拟机》第12章(Java内存模型和线程)哈~,也可以看看我之前的文章哈~[JVM常见面试题解析](https://juejin.im/post/5d35ca5b518825449c64bc31)
8+
9+
JVM内存结构:
10+
![](https://user-gold-cdn.xitu.io/2020/4/26/171b3b57de3b838c?w=727&h=478&f=png&s=203974)
11+
12+
Java内存模型图:
13+
![](https://user-gold-cdn.xitu.io/2020/4/26/171b3a11106f2cad?w=823&h=759&f=png&s=231498)
14+
15+
### ②cms和g1有没有了解过,它们有什么区别
16+
17+
- CMS收集器是老年代的收集器,可以配合新生代的Serial和ParNew收集器一起使用;
18+
- G1收集器收集范围是老年代和新生代,不需要结合其他收集器使用;
19+
- CMS收集器以最小的停顿时间为目标的收集器;
20+
- G1收集器可预测垃圾回收的停顿时间
21+
- CMS收集器是使用“标记-清除”算法进行的垃圾回收,容易产生内存碎片
22+
- G1收集器使用的是“标记-整理”算法,进行了空间整合,降低了内存空间碎片。
23+
24+
这个点是可以看《深入理解Java虚拟机》第三章,垃圾收集器与内存分配策略哈
25+
26+
### ③谈谈你对垃圾回收的了解,什么时候发生垃圾回收,回收过程
27+
28+
可以讲JVM中一次完整的GC流程是怎样的,对象如何晋升到老年代,如Minor GC,Major GC,full GC这几个讲清楚,还有对象存活判断方法,还有垃圾回收算法,复制算法等等
29+
30+
这个点也是可以看《深入理解Java虚拟机》第三章,垃圾收集器与内存分配策略哈
31+
32+
### ④ 对于数据的一致性是怎么保证的
33+
34+
- 这个如果是我的思路的话,我会谈缓存与数据库的一致性,可以看看我之前这篇文章
35+
36+
[并发环境下,先操作数据库还是先操作缓存?](https://juejin.im/post/5d4a3196f265da03ab423727)
37+
38+
- 也可以谈谈分布式事务下的数据一致性,也可以看看之前我的这篇文章
39+
40+
[后端程序员必备:分布式事务基础篇](https://juejin.im/post/5e47bc14518825491b11bef4)
41+
42+
### ⑤ Redis集群有没有了解过,主从和选举是怎么样子的
43+
这个可以回答这些关键词,主从复制 ,哨兵机制等这些~可以看看网上这篇啦,或者亲爱的读者,去网上看一下资料哈~
44+
[Redis 主从复制架构和Sentinel哨兵机制](https://aiylqy.com/archives/213.html)
45+
46+
### ⑥ 看你们公司使用的是MySQL,你们使用的是哪种存储引擎,为什么?MyISAM和InnoDB的区别
47+
48+
- MyISAM:如果执行大量的SELECT,MyISAM是更好的选择
49+
- InnoDB:如果你的数据执行大量的INSERT或UPDATE,出于性能方面的考虑,应该使用InnoDB表
50+
- mysiam表不支持外键,而InnoDB支持
51+
52+
MyISAM适合:
53+
1. 做很多count 的计算;
54+
2. 插入不频繁,查询非常频繁;
55+
3. 没有事务。
56+
57+
InnoDB适合:
58+
1. 列表内容 可靠性要求比较高,或者要求事务;
59+
2. 表更新和查询都相当的频繁,并且行锁定的机会比较大的情况。
60+
61+
### ⑦ 索引的底层数据结构是什么,为什么选择这种数据结构
62+
63+
可以看看网上的这篇,写得不错~
64+
[MySQL索引为什么要用B+树实现?](https://mp.weixin.qq.com/s?__biz=MzIxMzk3Mjg5MQ==&mid=2247483916&idx=1&sn=bfc33b53f8176e6f4d7e64c087ad36a4&chksm=97afe0f8a0d869eeaa14d8b26eca9d6fa09f9fda4557b40cb22ebe75851aa4dfb67d822233d9&scene=0&subscene=90&sessionid=1539434820&ascene=7&devicetype=andro)
65+
66+
### ⑧SQL优化,怎么判断需要优化,从哪些方面着手优化
67+
68+
从索引角度出发,就很多点可以讲,
69+
这个可以看看我的这两篇文章哈~
70+
71+
- [后端程序员必备:书写高质量SQL的30条建议](https://juejin.im/post/5e624d156fb9a07ca80ab6f2)
72+
- [后端程序员必备:索引失效的十大杂症](https://juejin.im/post/5de99dd2518825125e1ba49d)
73+
74+
### ⑨ 手写代码:设计一个分布式自增id生成服务
75+
76+
可以去网上找一下答案哈,这个我也没什么思路~参考分库分表一些想法?nginx负载均衡一些想法?哈哈,亲爱的读者,如果你会的话,可不可以告诉我呢
77+
78+
## 腾讯后端二面:
79+
### ①有没有了解过网络安全问题,常见的网络攻击有哪些,原理是什么,可以怎么解决
80+
81+
XSS,跨站脚本攻击?CSRF,跨站请求伪造?DDOS,分布式拒绝服务攻击?SQL注入?
82+
83+
对于SQL注入,可以进行后台处理,比如,使用预编译语句PreparedStatement进行预处理,又比如Mybatis映射语句中,用#{xxx}而不是${}
84+
85+
### ②平时在开发接口或者设计项目的时候如何保证安全性的
86+
- 签名
87+
- 加密
88+
- ip检测限流?
89+
- 接口幂等
90+
- 特殊字符实现过滤 防止xss、sql注入的攻击?
91+
92+
### ③使用Redis集群时可能会存在什么问题
93+
数据一致性问题
94+
95+
### ④有没有了解过cap和base原则
96+
97+
#### CAP理论
98+
CAP理论作为分布式系统的基础理论,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),这三个要素最多只能同时实现两点。
99+
![](https://user-gold-cdn.xitu.io/2019/7/20/16c0f6675fee8222?w=302&h=289&f=png&s=25862)
100+
101+
**一致性(C:Consistency):**
102+
103+
一致性是指数据在多个副本之间能否保持一致的特性。例如一个数据在某个分区节点更新之后,在其他分区节点读出来的数据也是更新之后的数据。
104+
105+
**可用性(A:Availability):**
106+
107+
可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。
108+
109+
**分区容错性(P:Partition tolerance):**
110+
111+
分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务。
112+
113+
选择 | 说明 |
114+
-|-|
115+
CA | 放弃分区容错性,加强一致性和可用性,其实就是传统的单机数据库的选择 |
116+
AP | 放弃一致性,分区容错性和可用性,这是很多分布式系统设计时的选择 |
117+
CP | 放弃可用性,追求一致性和分区容错性,网络问题会直接让整个系统不可用 |
118+
119+
#### BASE 理论
120+
121+
BASE 理论, 是对CAP中AP的一个扩展,对于我们的业务系统,我们考虑牺牲一致性来换取系统的可用性和分区容错性。BASE是Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)三个短语的缩写。
122+
123+
**Basically Available**
124+
125+
基本可用:通过支持局部故障而不是系统全局故障来实现的。如将用户分区在 5 个数据库服务器上,一个用户数据库的故障只影响这台特定主机那 20% 的用户,其他用户不受影响。
126+
127+
**Soft State**
128+
129+
软状态,状态可以有一段时间不同步
130+
131+
**Eventually Consistent**
132+
133+
最终一致,最终数据是一致的就可以了,而不是时时保持强一致。
134+
135+
### ⑤zk是如何保证一致性的
136+
可以看这本书哈~
137+
《从paxos到Zookeeper分布式一致性原理与实践》,
138+
139+
也可以看这篇文章:
140+
[浅析Zookeeper的一致性原理](https://zhuanlan.zhihu.com/p/25594630)
141+
142+
### ⑥你如何设计一个能抗住大流量的系统,说说设计方案
143+
144+
nginx负载均衡,流量防卫兵sentinel,服务拆分,缓存,消息队列,集群、限流、降级这些都可以搬出来啦~
145+
146+
### ⑦有没有了解过缓存策略有哪些
147+
148+
- Cache-Aside
149+
- Read-Through
150+
- Write-Through
151+
- Write-Behind
152+
153+
有兴趣还是可以看看我这篇文章,哈哈
154+
155+
[并发环境下,先操作数据库还是先操作缓存?](https://juejin.im/post/5d4a3196f265da03ab423727)
156+
157+
158+
## 个人公众号
159+
160+
![](https://user-gold-cdn.xitu.io/2019/7/28/16c381c89b127bbb?w=344&h=344&f=jpeg&s=8943)
161+
162+
- 如果你是个爱学习的好孩子,可以关注我公众号,一起学习讨论。
163+
- 如果你觉得本文有哪些不正确的地方,可以评论,也可以关注我公众号,私聊我,大家一起学习进步哈。

0 commit comments

Comments
 (0)