-
Websocket协议?
- Websocket协议是一个基于TCP协议的全双工通信协议。
- Websocket协议与HTTP协议的区别:
- 两者的前缀不一样,http是http,websocket是ws
- http是单向传输协议,websocket是双向实时传输协议
- websocket支持扩展
- websocket的头部比较小,而http的头部比较大,因此websocket的网络传输消耗较小
- websocket的传输过程:
- 客户端向服务端发送一个请求,请求头中包含upgrade:websocket和sec-websocket-key等字段
- 服务端返回一个101状态码,标识协议升级到websocket
- 进行双向传输,利用帧进行传输,在发送时,先将数据切分成一个一个的帧,将其发送到对端,然后接收端接收到帧后将帧重新组装成数据
- 项目中的使用:
- SpringBoot集成了完整的websocket的依赖,可以开箱即用,在websocket中的使用,就是在配置类中定义一个topic同于给前端绑定,然后如果要向客户端发送消息的话,利用websocket的对象convertAndSend方法,类似消息队列的使用方式,然后前端绑定这个topic的地方可以接收到这个消息完成实时通信。
-
Spring的定时任务底层是怎么实现的?
- 任务调度是通过TaskScheduler来实现的,在Spring容器启动时,会扫描所有带@Scheduled注解的方法,将其注册到TaskScheduled中
- TaskScheduled根据其注解内部的固定延迟,固定速率或者cron表达式来调度任务
- 当任务被调度,该任务会被交给ScheduledExecutorService来执行,内部使用一个ScheduledThreadPoolExecutor来并发执行这些定时任务
-
Raft协议?
- Raft协议是一种管理复制日志的共识算法。
- 包括三个角色:
- 领导者leader:处理客户端的请求和日志的复制
- 跟随者follower:从leader复制对应的日志
- 候选者Candidate:follower接收来自leader的心跳,在一段时间没有接收到leader的心跳后会转化为Candidate,重新选举leader
- 选举过程:
- 当一个leader挂了之后,会有一个follower转换为Candidate并开始重新选举
- candidate将自己的任期加一
- 对自己投票
- 请求其他candidate给自己投票
- 其他节点接收到请求后,如果投票请求的candidate的任期大于自己的任期,会将自己转为follower,并为对应的candidate投票,直到一个candidate获得了半数的投票,则该candidate成为leader,leader开始发心跳去阻止其他的节点的选举
-
日志复制过程?
- leader接收到客户端请求,生成一条日志
- leader通过rpc,向follower发起追加日志的请求
- follower接收请求后检查接收到的日志条目与前一个日志条目的索引和任期是否一致,如果一致,则能追加,如果不能则拒绝,将对应的结果响应给leader
- leader接收响应,一旦集群中的大部分follower成功存储了日志,则leader认为日志复制完成,将这条日志存放到状态机中,并告知所有的follower
- follower接收到后也将对应的条目加入状态机
-
Raft协议是两次心跳包来实现日志同步的,那么能不能在系统中记录上一次发送的索引数,只用一次心跳包发送数据?
- 不可以
- 因为两次心跳包的作用不同
- 第一次心跳:用于将要复制的日志条目发送给follower
- 第二次心跳:是leader已经确认集群中大部分的follower已经接收了日志,向所有的follower告知该日志条目可以加入状态机
-
Http1.1相对于Http1.0的改进?
- 短连接改为长连接
- 增加大量状态码
- 带宽处理,允许范围请求
- Host头处理
- 缓存控制
-
Http2.0相较于Http1.1的改进?
- 引入了IO多路复用技术
- 利用帧进行数据传递
- 首部压缩
- 服务器推送
-
Http3.0相较于http2.0的改进?
- 底层协议变成了QUIC协议,提供了相较于2.0更高的安全性,因为QUIC协议是基于UDP的,连接建立的过程更快
- 3.0为每个连接建立多个数据流,每个数据流互不影响,防止队头阻塞
- 提供错误恢复机制
-
为什么3.0基于UDP连接仍然能够保证数据的有序性和可靠性?
- 有序性:通过流内数据的有效性来保证
- 可靠性:
- 确认机制
- 前向纠错
- 自拥塞控制:可以通过拥塞情况调整发送速率
-
跳表的底层数据结构?
- 跳表是由多级索引组成的
- 每级索引是一个有序链表,第0级索引包含所有元素,第1级只包含一半元素,第二级只包含1/4元素,从下到上依次递减,那么对元素进行检索的时候从上到下进行检索,每次检索在当前级别的索引中确定元素在下级索引中的范围,然后往下级去继续搜索,每次都进一步缩小范围,直到找到或者到最后一层还没找到,最终的平均时间复杂度为Ologn
-
Redis为什么用跳表,不用AVL,红黑树,B+树?
- 不用AVL和红黑树的原因是,这两种数据结构在插入删除元素时,需要旋转来保持平衡,带来额外的性能开销
- 不用B+树的原因是,相较于数据库来说,redis并不会去存储大量的数据,而B+树相较于跳表来说更加消耗内存,同时B+树在插入删除的过程中会有节点的分裂与合并,带来额外的性能开销。
-
限流算法有哪些?
- 漏桶
- 令牌桶
- 滑动窗口
-
CMS和G1收集器
- CMS:
- 初始标记:STW,单线程
- 并发标记:不STW,单线程
- 重新标记:STW,多线程
- 并发清理:不STW,单线程
- 使用标记清理算法
- G1
- 初始标记:STW,单线程
- 并发标记:不STW,单线程
- 最终标记:STW,多线程
- 筛选清理:STW,多线程
- 使用标记复制算法
- CMS:
-
MyISAM和InnoDB的区别?
- 相比MyISAM,InnoDB支持外键
- 支持事务
- 支持行锁
- 支持MVCC
- 支持数据库崩溃后的恢复
- 索引实现不同,InnoDB的索引和数据是一个文件,而MyISAM是两个文件。
-
TCP和UDP的区别?
- TCP是面向连接的,UDP不是面向连接
- TCP是有状态的,UDP是无状态的
- TCP只支持一对一的传输方式,UDP支持一对一,一对多,多对一,多对多的传输方式
- TCP是面向字节流的,UDP是面向报文的
- TCP的传输效率比UDP要低
-
TCP三次握手过程TCP的ACK包为什么是随机开始?
- 因为ACK的序列号要考虑安全性,防止被攻击
- 同时排除旧数据包的干扰
- 减少序列号空间的重叠,提高数据传输的效率
-
TCP四次挥手,哪一端会进入TIME_WAIT状态,如何解决TIME_WAIT状态过多?
- 发起四次挥手的一端会进入TIME_WAIT状态
- 存在大量TIME_WAIT状态时会导致连接耗尽
- 可以通过修改环境变量中TIME_WAIT的时间,减小这个时间来减少
- 通过修改环境变量,修改可用端口范围
- 通过负载均衡,防止一个实例接收太多的连接
-
TCP滑动窗口的目的?
- 用于限流
- 用于拥塞控制
-
TCP的3次握手?
- 客户端向服务端发送SYN包,进入SYN_SEND状态
- 服务端接收到SYN包,向客户端发送一个ACK包和一个SYN包,服务端进入SYN_RECV状态。
- 客户端接收到SYN包,向服务端发送一个ACK包,双端进入ESTABLISHED状态
-
如果TCP的第三次挥手超时会发生什么?
- 如果第三次挥手超时,服务端会重传ACK-SYN包
- 直到到达重传次数后,连接建立失败
20240815面经背诵
最新推荐文章于 2024-09-16 17:24:25 发布