20240814面经

m0_53219790

已于 2024-08-14 18:29:00 修改

阅读量255

点赞数 3

文章标签： java spring boot 后端数据库

于 2024-08-14 18:14:23 首次发布

本文链接：https://blog.csdn.net/m0_53219790/article/details/141192134

版权

Linux中用户和用户组的区别？
- 用户主要是为了区分不同的个体，不同用户有不同的用户id和密码
- 用户组是为了将用户分组同一发放权限，一个用户组内的用户往往权限一致
- 一个用户属于一个主要用户组，还可以属于多个次要用户组
SpringBoot的启动流程？
- 启动主类，主要就是SpringBootApplication注解的主类中的main方法启动
- 创建SpringApplication实例
- 初始化SpringApplication
  - 设置初始化器和监听器
  - 设置主应用类
  - 设置应用类型
- 运行SpringApplication
  - 加载yml中的环境配置
  - 刷新应用上下文，初始化Spring容器
  - 启动嵌入容器
- 应用运行
  - 接收事件和请求
什么情况下适合加索引？
- 一个表经常访问，被查询，且数据量庞大
- 数据区分度较大的字段创建索引
- 长字符串创建前缀索引
- 经常作为查询条件的字段创建索引
- 经常被查询的字段创建索引
索引优化？
- 创建索引的优化：
  - 避免创建过多索引
  - 尽量在数据量大，访问频繁的表中建立索引
  - 尽量对经常作为查询条件的字段创建索引
  - 尽量对经常作为查询字段的字段创建索引
  - 尽量对区分度较大的字段创建索引
  - 对长字符串可以创建前缀索引
- 查询时是索引优化：
  - 避免索引失效
  - 避免违反最左前缀原则
  - 不要对索引字段进行运算操作
  - 不要对索引字段进行类型转换
  - 不要对索引字段进行判空
  - 避免对联合索引的右边的字段进行范围查询
  - 避免索引字段的前缀的模糊查询
项目中对java的锁是怎么使用的？
- 像我自己的练手的项目，一开始的设计就是分布式锁加上本地synchronized锁来防止限量菜品的超卖，后来接口性能不太好，又学到了可以使用数据库的乐观锁来解决这个问题。
缓存穿透和击穿怎么解决？
- 穿透：数据库中不存在的数据被频繁访问
  - 解决：
    - 缓存null值
    - 利用布隆过滤器，且需要预热数据
- 击穿：在缓存中不存在，但在数据库中存在的数据在短时间内被频繁访问
  - 解决：
    - 数据预热
    - 使用幂等性方式去同步数据，确保在缓存不存在这条数据的时候，只有一个线程去数据库中去同步数据
- 雪崩：大量key同一时间失效，导致大量请求落到数据库
  - 解决：
    - 给所有的key的ttl加上一个随机值防止大量key同一时间失效
    - 集群模式，提高缓存的可用性
    - 多级缓存
    - 降级限流（解决这3个问题的通用方式）
redis缓存和mysql的一致性？
- 延迟双删：
  - 主要是为了防止有两个线程A，B，A线程去修改数据，B数据去查询数据。A线程去修改数据的时候现将缓存删除了，然后切换到B线程，B线程查询缓存，发现没有，然后去数据库中查询数据，并将数据存入缓存，此时切换回A线程，A线程去修改数据库，这样数据库中的数据，与缓存中数据不一致，因此需要再删除一次。
- 幂等性方式：加锁去同步
- 利用中间件：比如canal去监控数据库的binlog文件，一旦发生写操作，异步提醒去删除redis的缓存。（有延迟，但是能保证最终一致性）
Http是有状态的吗？
- 不是，http是无状态的，他不保存状态，只是通过请求得到的响应的状态码来判断本次请求的成功与否以及一些其他控制
Kafka的优点？
- 吞吐率高：
  - 顺序写入磁盘，减少寻道时间
  - 采用零拷贝来减少数据传输开销
  - 批处理：批量发送消息和批量消费消息
  - 消费者组：增加了并发性能
  - 数据压缩：减少网络传输消耗和存储消耗
- 可靠性保证：kafka的所有消息都要持久化到磁盘，即使broker挂了也不会丢失消息
- 扩展性强：可以通过增加更多的broker来提高kafka集群的并发性能
- 可以和大数据框架集成
kafka会压缩数据，那么消费者消费的数据是原始数据还是压缩过后的数据？
- 是原始数据，kafka在将数据发送到消费者端时，压缩后的数据会被解压缩，压缩主要是为了减少消息的存储消耗
红黑树的特点？
- 所有的叶子节点都是黑色的空节点
- 任意一个节点到达其任一叶子节点的路径中，黑色节点数相等
- 如果当前节点为红色节点，那么其子节点一定为黑色节点
- 根节点总是黑色的
Raft协议的选举过程？
- 候选者将任期加一
- 候选者将票投给自己
- 向集群中其他节点发起请求，请求投票给自己
- 每个节点任期内只能投一次票，一般是投给第一个请求的节点
- 当一个节点获取集群半数以上的投票，则立即成为leader，然后向其他节点发送心跳阻止选举。