快手二面准备【面试准备】

前言

2023-8-1 17:33:53

公开发布于
2024-5-21 13:07:32

以下内容源自《【面试准备】》
仅供学习交流使用

版权

禁止其他平台发布时删除以下此话
本文首次发布于CSDN平台
作者是CSDN@日星月云
博客主页是https://blog.csdn.net/qq_51625007
禁止其他平台发布时删除以上此话

快手二面准备

秋招一面中的问题

rpc

远程过程调用

kafka为啥会丢消息

rocketmq怎么保证不丢消息

RocketMQ通过以下几种机制来保证消息不丢失：消息持久化：RocketMQ将消息写入磁盘中进行持久化存储，即使在发生系统故障或重启时，消息也能够被恢复。内存双写：RocketMQ在将消息持久化到磁盘之前，先将消息写入内存中的PageCache中。这种方式可以提高写入速度，并且在发生宕机时，可以通过从磁盘中加载消息来进行快速恢复。同步刷盘：RocketMQ提供了同步刷盘机制，即在消息写入磁盘之前，会等待消息被写入磁盘后才返回发送成功的响应。这样可以确保消息被持久化到磁盘中，避免消息丢失。主从同步：RocketMQ支持主从模式，即一个主节点和多个从节点。主节点负责将消息发送给消费者，从节点负责备份主节点的消息。当主节点宕机时，可以通过从节点快速切换来提供高可用性，并避免消息丢失。高可靠性队列：RocketMQ提供了高可靠性的队列机制，确保消息的可靠传输。通过设置消息的发送模式为同步模式，发送方在消息发送完成之前会等待Broker的确认响应，确保消息可靠传输。消息重试机制：RocketMQ提供了消息重试机制，当消息发送失败时，会自动进行重试。可以通过设置重试次数和重试间隔来控制重试的策略，确保消息最终被正确处理。综上所述，RocketMQ通过持久化、内存双写、同步刷盘、主从同步、高可靠性队列和消息重试机制等多种机制来保证消息不丢失。开发人员也可以根据自己的需求和业务场景，选择适当的配置和策略来保证消息的可靠性。

Rocketmq中Broker的刷盘策略有哪些？同步刷盘
SYNC_FLUSH（同步刷盘）：生产者发送的每一条消息都在保存到磁盘成功后才返回告诉生产者成功。这种方式不会存在消息丢失的问题，但是有很大的磁盘IO开销，性能有一定影响。
异步刷盘
ASYNC_FLUSH（异步刷盘）：生产者发送的每一条消息并不是立即保存到磁盘，而是暂时缓存起来，然后就返回生产者成功。随后再异步的将缓存数据保存到磁盘，有两种情况：1是定期将缓存中更新的数据进行刷盘，2是当缓存中更新的数据条数达到某一设定值后进行刷盘。这种异步的方式会存在消息丢失（在还未来得及同步到磁盘的时候宕机），但是性能很好。默认是这种模式。

秒杀为什么选择rocketmq

rocketmq支持发布事务性消息

实习一面中的问题

es与数据库之间的同步

使用的是kafka来实现的redis是在刷新帖子分数时
点赞评论之后，记录需要刷新的帖子id
供Quartz定时计算帖子分数，然后刷新到数据库

动态代理

基于接口的代理：jdk
基于类的代理：cglib

了解过监听binlog吗

计算机网络和操作系统

http

https

tcp和upd

dns

论坛项目登录注册

一个问题，验证邮箱丢失问题

提供重新发送激活邮箱的服务

ThreadLocal代替session存储用户

拦截器

@preHandle
获取登录凭证@postHandle
前端添加loginUser@afterCompletion
清除HostHold

四种对象引用

本地线程存储

内存泄漏问题

秒杀项目登录注册->阿里验证码->rpc

原来验证码输出到控制台里

session为什么改为token实现，redis存储用户信息

由binlog的用法->缓存和数据库的一致性

数据库和缓存如何保证一致性？

它的用法：
主从复制
数据库恢复

还有一个，订阅binlog解决缓存和数据库的一致性

缓存和数据库一致性：
先更新数据库，后删除缓存。

可能还会有问题

延迟双删

但是更新数据库和删除缓存是两个操作

万一删除失败了，怎么办？

• 重试，消息队列
• 订阅binlog

3种缓存更新策略是怎样的?

面试官:3种缓存更新策略是怎样的?

Cache Aside（旁路缓存）策略是最常用的，应用程序直接与「数据库、缓存」交互，并负责对缓存的维护，该策略又可以细分为「读策略」和「写策略」。

Read/Write Through（读穿 / 写穿）策略原则是应用程序只和缓存交互，不再和数据库交互，而是由缓存和数据库交互，相当于更新数据库的操作由缓存自己代理了。

下面是 Read Through/Write Through 策略的示意图：

Write Back（写回）策略在更新数据的时候，只更新缓存，同时将缓存数据设置为脏的，然后立马返回，并不会更新数据库。对于数据库的更新，会通过批量异步更新的方式进行。

实际上，Write Back（写回）策略也不能应用到我们常用的数据库和缓存的场景中，因为 Redis 并没有异步更新数据库的功能。

ES搜索->Mysql全文索引

MySQL全文检索临时代替ES实现快速搜索

模糊查询：like '%关键词'

MySQL 中使用全局变量ngram_token_size来配置ngram中n的大小，它的取值范围是1到10，默认值是2。通常ngram_token_size设置为要查询的单词的最小字数。如果需要搜索单字，就要把ngram_token_size设置为1。在默认值是2的情况下，搜索单字是得不到任何结果的。因为中文单词最少是两个汉字，推荐使用默认值2。

CREATE FULLTEXT INDEX idx_名 ON 表(字段) WITH PARSER ngram;
select - from  -
where MATCH (columnName) AGAINST ('keywords')

MySQL8的索引新特性

降序索引

隐藏索引

redis的高级数据结构

拦截器：记录uv，dau访问过一次判断其为活跃

hyperLogLog
统计uv
key：uv_日期
value：ip
add()
指定日期范围统计union()之后再size返回

bitmap
统计dau
key：dau_日期
value：userId
setBit()
统计指定日期范围内的DAU OR运算 bitCount()

代理模式->设计模式

单例模式

工厂模式

为什么使用mq

解耦 异步 削峰

比如：论坛项目中的，关注，点赞或评论帖子，做系统通知

如果写出一个方法的话，还需要保证事务，设置事务的传播行为

但是别人点赞了，和你收到系统通知，其实是两个业务

别人点赞了，系统通知的业务执行失败，你也不能回滚

这两个操作也是异步的

削峰，秒杀项目的

mq

【消息队列】五个问题详解消息中间件

【RocketMQ】原理分析：消息存储机制

【RocketMQ】消息可靠性保证

【Kafka】原理分析：消息的文件存储机制

【Kafka】消息可靠性保证

同步刷盘

es的构成

Elasticsearch由以下几个主要组件构成：

• 节点（Nodes）：节点是Elasticsearch的基本组成单位，每个节点代表一个运行的实例。一个Elasticsearch集群可以由多个节点组成，每个节点都有自己的名称和唯一的ID。节点之间可以通过集群通信进行相互发现、数据同步和协作。

• 索引（Indexes）：索引是一种用于组织和存储数据的逻辑容器。它类似于数据库中的表，可以包含多个文档（documents）。每个索引都具有唯一的名称，用于标识它所包含的数据类型或内容。

• 类型（Types）：在早期版本的Elasticsearch（5.x及以前的版本），索引可以包含多个类型。类型是索引中的一个逻辑类别，用于区分不同类型的文档。然而，在5.x以后的版本中，Elasticsearch不再推荐使用多个类型，建议将不同类型的数据拆分为独立的索引。

• 文档（Documents）：文档是Elasticsearch中的基本数据单元。它可以是任意结构的JSON对象，类似于数据库中的记录。每个文档都有一个唯一的ID，用于标识它在索引中的位置。文档可以被索引、搜索和修改。

• 分片和副本（Shards and Replicas）：为了实现高可用性和扩展性，Elasticsearch将索引分割成多个分片（shards），每个分片可以在集群中的不同节点上进行分布。分片允许索引数据被并行处理和存储。为了提高数据的冗余性和可靠性，每个分片可以有多个副本（replicas），副本是分片的精确拷贝。

以上是Elasticsearch的基本构成，它们一起工作来提供高效的分布式搜索和分析功能。

倒排索引的理解：

倒排索引（Inverted Index）是一种用于快速定位文档的索引结构。在倒排索引中，每个关键词都维护了一个包含包含该关键词的文档列表。通过倒排索引，可以快速地找到包含特定关键词的文档，而无需遍历所有文档。

倒排索引的构建过程包括以下几个步骤：

文档分词：将每个文档拆分为一个个的词语（或称为术语，terms），这通常是通过分词器（tokenizer）来实现的。分词器可以根据各种规则和算法将文本切分为合适的词语。

构建倒排索引：对于每个词语，将它出现的文档ID记录到倒排索引中。倒排索引的数据结构通常是一个关联数组（Associative Array），其中词语作为键，文档ID的列表作为值。

优化倒排索引：为了提高查询性能和减少索引的大小，通常还会对倒排索引进行优化。例如，可以使用压缩算法对文档ID列表进行压缩，或者使用数据结构如跳表（Skip List）来加速查找过程。

通过倒排索引，可以在搜索时快速定位包含特定关键词的文档。比如，当用户在搜索引擎中输入一个关键词时，搜索引擎可以通过倒排索引找到包含该关键词的文档，并返回给用户相关的搜索结果。倒排索引是大部分搜索引擎（包括Elasticsearch）的核心组成部分，它能够提供快速、灵活和准确的搜索功能。

mq的消息类型

缓存相关的问题

缓存和数据库的一致性

先更新数据库再删除缓存

库存的一致性是mq实现事务消息

缓存穿透

场景：
场景查询根本不存在的数据，使得请求直达存储层
导致其负载过大，甚至宕机。

解决方案：
1.缓存空对象存储层未命中后，仍然将空值存入缓存层。再次访问该数据时，缓存层会直接返回空值。
2.布隆过滤器将所有存在的key提前存入布隆过滤器，在访问缓存层之前，先通过过滤器拦截，若请求的是不存在的key，则直接返回空值。

缓存击穿

场景：
一份热点数据，它的访问量非常大。在其缓存失效瞬间，大量请求直达存储层，导致服务崩溃。

解决方案：
1.加互斥锁对数据的访问加互斥锁，当一个线程访问该数据时，其他线程只能等待。这个线程访问过后，缓存中的数据将被重建，届时其他线程就可以直接从缓存取值。
2.永不过期不设置过期时间，所以不会出现上述问题，这是“物理”上的不过期。为每个value设置逻辑过期时间，当发现该值逻辑过期时，使用单独的线程重建缓存。

缓存雪崩
场景：
由于某些原因，缓存层不能提供服务，导致所有的请求直达存储层，造成存储层宕机。
解决方案：
1.避免同时过期设置过期时间时，附加一个随机数，避免大量的key同时过期。
2.构建高可用的Redis缓存部署多个Redis实例，个别节点宕机，依然可以保持服务的整体可用。
3.构建多级缓存增加本地缓存，在存储层前面多加一级屏障，降低请求直达存储层的几率。
4.启用限流和降级措施对存储层增加限流措施，当请求超出限制时，对其提供降级服务。

kafka的角色

Kafka的角色包括以下几个：

• 生产者（Producer）：负责将消息发送到Kafka集群，并且可以选择将消息发送到特定的主题（Topic）。
• 消费者（Consumer）：从Kafka集群中读取消息，并且可以选择订阅一个或多个主题。
• 主题（Topic）：是消息的逻辑容器，可以理解为消息的分类或者主题。
• 分区（Partition）：每个主题可以被分为一个或多个分区，每个分区对应一个日志文件。
• 消费者组（Consumer Group）：消费者可以组成一个或多个消费者组，每个组可以订阅一个或多个主题。
• Kafka集群（Kafka Cluster）：由多个Kafka实例组成的集群，用于存储和处理消息。
• Broker：Kafka集群中的每个节点就是一个Broker，负责存储和处理消息。
• ZooKeeper：Kafka使用ZooKeeper来管理集群的元数据，包括主题、分区等信息。
• 消息（Message）：Kafka中的基本单位，由键（Key）和值（Value）组成。
• 日志（Log）：Kafka使用日志文件来存储消息，每个分区对应一个日志文件。

以上是Kafka的主要角色，每个角色在Kafka中都扮演着不同的角色和功能。

rocketmq的角色

RocketMQ的角色包括以下几个：

• 生产者（Producer）：负责将消息发送到RocketMQ集群，并且可以选择将消息发送到特定的主题（Topic）。
• 消费者（Consumer）：从RocketMQ集群中读取消息，并且可以选择订阅一个或多个主题。
• 主题（Topic）：是消息的逻辑容器，可以理解为消息的分类或者主题。
  消费者组（Consumer Group）：消费者可以组成一个或多个消费者组，每个组可以订阅一个或多个主题。
• Broker：RocketMQ集群中的每个节点就是一个Broker，负责存储和处理消息。
• 消息（Message）：RocketMQ中的基本单位，由键（Key）和值（Value）组成。
• 消息队列（Message Queue）：每个主题可以被分为一个或多个消息队列，每个消息队列对应一个消费者线程。
• 消息存储（Message Store）：RocketMQ使用消息存储来存储消息，包括内存存储和磁盘存储。
• NameServer：RocketMQ使用NameServer来管理集群的元数据，包括主题、消费者组等信息。
• 消息消费进度（Offset）：RocketMQ可以跟踪每个消费者组在每个主题的消费进度，以确保消息的顺序性和可靠性。

以上是RocketMQ的主要角色，每个角色在RocketMQ中都扮演着不同的角色和功能。

最后

2023-8-1 21:18:19

我们都有光明的未来

祝大家考研上岸
祝大家工作顺利
祝大家得偿所愿
祝大家如愿以偿
点赞收藏关注哦