Skip to content

Commit d783b2d

Browse files
committed
一些没有答案的添加
1 parent 2f3cb97 commit d783b2d

8 files changed

Lines changed: 192 additions & 21 deletions

File tree

‎README.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,4 +27,6 @@
2727
- [消息队列](./mq/index.md)
2828
- [MQ基础](./mq/basic.md)
2929
- 分布式
30+
- 微服务
3031
- 安全
32+
- 业务

‎business/index.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# 设计能力
2+
3+
## 说说你在项目中使用过的 UML 图
4+
5+
## 你如何考虑组件化
6+
7+
## 你如何考虑服务化
8+
9+
## 你如何进行领域建模
10+
11+
## 你如何划分领域边界
12+
13+
## 说说你项目中的领域建模
14+
15+
## 说说概要设计
16+
17+
## 你系统中的前后端分离是如何做的
18+
19+
## 说说你的开发流程
20+
21+
## 你和团队是如何沟通的
22+
23+
## 你如何进行代码评审
24+
25+
## 说说你对技术与业务的理解
26+
27+
## 说说你在项目中经常遇到的 Exception
28+
29+
## 说说你在项目中遇到感觉最难Bug,怎么解决的
30+
31+
## 说说你在项目中遇到印象最深困难,怎么解决的
32+
33+
## 你觉得你们项目还有哪些不足的地方
34+
35+
## 你是否遇到过 CPU 100% ,如何排查与解决
36+
37+
## 你是否遇到过 内存 OOM ,如何排查与解决
38+
39+
## 说说你对敏捷开发的实践
40+
41+
## 说说你对开发运维的实践
42+
43+
## 介绍下工作中的一个对自己最有价值的项目,以及在这个过程中的角色

‎distributed/index.md‎

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,4 +8,18 @@
88

99
第三种:session共享机制。使用分布式缓存方案比如memcached、Redis,但是要求Memcached或Redis必须是集群。
1010

11-
第四种:session持久化到数据库。
11+
第四种:session持久化到数据库。
12+
13+
## 谈谈业务中使用分布式的场景
14+
15+
## 分布式锁的场景
16+
17+
## 分布是锁的实现方案
18+
19+
## 分布式事务
20+
21+
## 集群与负载均衡的算法与实现
22+
23+
## 说说分库与分表设计
24+
25+
## 分库与分表带来的分布式困境与应对之策

‎java-web/http.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
# HTTP

‎mic-service/index.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# 微服务
2+
3+
## 前后端分离是如何做的
4+
5+
## 如何解决跨域
6+
7+
## 微服务哪些框架
8+
9+
## 你怎么理解 RPC 框架
10+
11+
## 说说 RPC 的实现原理
12+
13+
## 说说 Dubbo 的实现原理
14+
15+
## 你怎么理解 RESTful
16+
17+
# 说说如何设计一个良好的 API
18+
19+
## 如何理解 RESTful API 的幂等性
20+
21+
## 如何保证接口的幂等性
22+
23+
## 说说 CAP 定理、 BASE 理论
24+
25+
## 怎么考虑数据一致性问题
26+
27+
## 说说最终一致性的实现方案
28+
29+
## 你怎么看待微服务
30+
31+
## 微服务与 SOA 的区别
32+
33+
## 如何拆分服务
34+
35+
## 微服务如何进行数据库管理
36+
37+
## 如何应对微服务的链式调用异常
38+
39+
## 对于快速追踪与定位问题
40+
41+
## 微服务的安全
42+
43+
## 说说服务的治理(怎么注册怎么发现)

‎repository/mysql.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ long_query_time的默认值为10,意思是运行10s以上的语句。慢查询
3131
- 优化insert语句:一次插入多值;
3232
- 应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描;
3333
- 应尽量避免在 where 子句中对字段进行null值判断,否则将导致引擎放弃使用索引而进行全表扫描;
34-
- 优化嵌套查询:子查询可以被更有效率的连接(Join)替代;
34+
- 优化嵌套查询:子查询可以被更有效率的连接(Join)替代;
3535
- 很多时候用 exists 代替 in 是一个好的选择。
3636

3737
#### 索引优化

‎repository/redis.md‎

Lines changed: 70 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -23,24 +23,6 @@
2323

2424
这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。
2525

26-
## mySQL里有2000w数据,redis中只存20w的数据,如何保证redis中的数据都是热点数据
27-
28-
相关知识:redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。redis 提供 6种数据淘汰策略:
29-
30-
- volatile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰
31-
- volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰
32-
- volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰
33-
- allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰
34-
- allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰
35-
- no-enviction(驱逐):禁止驱逐数据
36-
37-
## Redis 常见的性能问题都有哪些?如何解决?
38-
39-
1. Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照。
40-
1. Master AOF持久化,如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化,如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。
41-
1. Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致服务load过高,出现短暂服务暂停现象。
42-
1. Redis主从复制的性能问题,为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内
43-
4426
## redis 最适合的场景
4527

4628
Redis最适合所有数据in-momory的场景,虽然Redis也提供持久化功能,但实际更多的是一个disk-backed的功能,跟传统意义上的持久化有比较大的差别,那么可能大家就会有疑问,似乎Redis更像一个加强版的Memcached,那么何时使用Memcached,何时使用Redis呢?
@@ -105,10 +87,79 @@ redis利用队列技术将并发访问变为串行访问,消除了传统数据
10587
1. 如果数据呈现幂律分布,也就是一部分数据访问频率高,一部分数据访问频率低,则使用allkeys-lru
10688
1. 如果数据呈现平等分布,也就是所有的数据访问频率都相同,则使用allkeys-random
10789

108-
## Redis 有哪些类型
90+
## mySQL里有2000w数据,redis中只存20w的数据,如何保证redis中的数据都是热点数据
91+
92+
相关知识:redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。redis提供6种数据淘汰策略见上面一条
93+
94+
## 假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如果将它们全部找出来?
95+
96+
使用keys指令可以扫出指定模式的key列表。
97+
98+
对方接着追问:如果这个redis正在给线上的业务提供服务,那使用keys指令会有什么问题?
99+
100+
这个时候你要回答redis关键的一个特性:redis的单线程的。keys指令会导致线程阻塞一段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。这个时候可以使用scan指令,scan指令可以无阻塞的提取出指定模式的key列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用keys指令长。
101+
102+
## Redis 常见的性能问题都有哪些?如何解决?
103+
104+
1. Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照。
105+
2. Master AOF持久化,如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化,如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。
106+
3. Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致服务load过高,出现短暂服务暂停现象。
107+
4. Redis主从复制的性能问题,为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内
108+
109+
## Redis有哪些数据结构?
110+
111+
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。
112+
113+
如果你是Redis中高级用户,还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。
114+
115+
如果你说还玩过Redis Module,像BloomFilter,RedisSearch,Redis-ML,面试官得眼睛就开始发亮了。
116+
117+
## 使用过Redis分布式锁么,它是什么回事?
118+
119+
先拿setnx来争抢锁,抢到之后,再用expire给锁加一个过期时间防止锁忘记了释放。
120+
121+
这时候对方会告诉你说你回答得不错,然后接着问如果在setnx之后执行expire之前进程意外crash或者要重启维护了,那会怎么样?
122+
123+
这时候你要给予惊讶的反馈:唉,是喔,这个锁就永远得不到释放了。紧接着你需要抓一抓自己得脑袋,故作思考片刻,好像接下来的结果是你主动思考出来的,然后回答:我记得set指令有非常复杂的参数,这个应该是可以同时把setnx和expire合成一条指令来用的!对方这时会显露笑容,心里开始默念:摁,这小子还不错。
124+
125+
## 使用过Redis做异步队列么,你是怎么用的?
126+
127+
一般使用list结构作为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,要适当sleep一会再重试。
128+
129+
如果对方追问可不可以不用sleep呢?list还有个指令叫blpop,在没有消息的时候,它会阻塞住直到消息到来。
130+
131+
如果对方追问能不能生产一次消费多次呢?使用pub/sub主题订阅者模式,可以实现1:N的消息队列。
132+
133+
如果对方追问pub/sub有什么缺点?在消费者下线的情况下,生产的消息会丢失,得使用专业的消息队列如rabbitmq等。
134+
135+
如果对方追问redis如何实现延时队列?我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话,怎么问的这么详细。但是你很克制,然后神态自若的回答道:使用sortedset,拿时间戳作为score,消息内容作为key调用zadd来生产消息,消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。
136+
137+
到这里,面试官暗地里已经对你竖起了大拇指。但是他不知道的是此刻你却竖起了中指,在椅子背后。
138+
139+
## 如果有大量的key需要设置同一时间过期,一般需要注意什么?
140+
141+
如果大量的key过期时间设置的过于集中,到过期的那个时间点,redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值,使得过期时间分散一些。
109142

110143
## Redis 持久化机制
111144

145+
bgsave做镜像全量持久化,aof做增量持久化。因为bgsave会耗费较长时间,不够实时,在停机的时候会导致大量丢失数据,所以需要aof来配合使用。在redis实例重启时,会使用bgsave持久化文件重新构建内存,再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。
146+
147+
对方追问那如果突然机器掉电会怎样?取决于aof日志sync属性的配置,如果不要求性能,在每条写指令时都sync一下磁盘,就不会丢失数据。但是在高性能的要求下每次都sync是不现实的,一般都使用定时sync,比如1s1次,这个时候最多就会丢失1s的数据。
148+
149+
对方追问bgsave的原理是什么?你给出两个词汇就可以了,fork和cow。fork是指redis通过创建子进程来进行bgsave操作,cow指的是copy on write,子进程创建后,父子进程共享数据段,父进程继续提供读写服务,写脏的页面数据会逐渐和子进程分离开来。
150+
151+
## Pipeline有什么好处,为什么要用pipeline?
152+
153+
可以将多次IO往返的时间缩减为一次,前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。
154+
155+
## Redis的同步机制了解么?
156+
157+
Redis可以使用主从同步,从从同步。第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将rdb文件全量同步到复制节点,复制节点接受完成后将rdb镜像加载到内存。加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
158+
112159
## Redis 集群方案与实现
113160

161+
Redis Sentinal着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。
162+
163+
Redis Cluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。
164+
114165
## Redis 为什么是单线程的

‎security/index.md‎

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
# 安全问题
2+
3+
## 安全要素与 STRIDE 威胁
4+
5+
## 防范常见的 Web 攻击
6+
7+
## 服务端通信安全攻防
8+
9+
## HTTPS 原理剖析
10+
11+
## HTTPS 降级攻击
12+
13+
## 授权与认证
14+
15+
## 基于角色的访问控制
16+
17+
## 基于数据的访问控制

0 commit comments

Comments
 (0)