口试常问标题

1、Mysql

1.1、存储引擎

InnoDB 与MyISAM 有什么区别?
1、事件支持不同，InnoDB 支持事件处理处罚，而 MyISAM 不支持。
2、并发处理处罚不同：InnoDB 支持行级锁，而 MyISAM 支持表级锁
3、外键支持不同：InnoDB 支持外键约束，而 MyISAM 不支持
4、性能上存在差别：MyISAM 的读取速度比 InnoDB 快，但是在高并发情况下，InnoDB 的性能更好。这是由于 InnoDB 支持行级锁和事件处理处罚，而 MyISAM 不支持。
所以，如果是读多写少的情况下，利用MyISAM引擎会更合适
5、据安全不同：InnoDB 支持崩溃规复和数据规复，而 MyISAM 不支持。如果 MySQL 崩溃了或者发生意业务外故障，InnoDB 可以通过规复日志来规复数据。
MEMORY存储引擎是基于内存的，利用场景：数据不落磁盘，只在内存中存在。好比一些重要数据不让在外网留盘，传入到内网才可以留磁盘。
1.2、如何选择合适的分布式主键方案呢?

IdUtil.getSnowflake().nextId()。
IdUtil是hutool包下的。
1.3、索引

最左前缀原则：
“最左前缀原则” 联合索引中，如果最左边的索引字段没有生效，那么其他索引字段作条件，索引也不会生效。好比table表有a,b,c,d,e个字段，其中a是主键，别的有一联合索引idx_bcd (b,c,d)，其实等效于创建了(b),(b,c),(b,c,d)三个索引。
索引下推：
“索引下推”: 好比table表有a,b,c,d,e个字段，其中a是主键，别的有一联合索引idx_bcd (b,c,d)，然后查询select * from table where b=3 and d =5;
没有索引下推之前，存储引擎根据b=3检索到数据返回给MySQL的server层，在server层再通过d=5进行过滤，比力费时费性能
MySQL 5.6 之后，便支持索引下推，存储引擎通过b=3，d=5直接检索符合条件的数据，不需要再在server层过滤
所谓下推，就是将条件过滤下推到server层的“下级”存储引擎来进行
回表：
"回表"指的是查询过程在利用索引获取一部分信息后，还需要到主表（数据表）中再次查找数据。一样平常来说，回表查询的发生是由于索引中并不包含全部需要的字段。
覆盖索引：
"覆盖索引"指的是索引中已经包含了查询需要的全部字段，所以不需要回表。覆盖索引查询可以直接从索引中获取全部数据，大大提高查询效率。
1.4、索引什么时间失效？

1.在索引列上做运算，好比利用函数，Mysql在生成实行计划的时间，它是根据统计信息来判断是否要利用索引的。
而在索引列上加函数运算，导致Mysql无法识别索引列，也就不会再走索引了。
不过从Mysql8开始，增长了函数索引可以办理这个标题。
2.在一个由多列构成的组合索引中，需要按照最左匹配法则，也就是从索引的最左列开始顺序检索，否则不会走索引。
在组合索引中，索引的存储结构是按照索引列的顺序来存储的，因此在sql中也需要按照这个顺序才能进行逐一匹配。
否则InnoDB无法识别索引导致索引失效。
3.当索引列存在隐式转化的时间， 好比索引列是字符串类型，但是在sql查询中没有利用引号。
那么Mysql会主动进行类型转化，从而导致索引失效
4.在索引列利用不等于号、not查询的时间，由于索引数据的检索效率非常低，因此Mysql引擎会判断不走索引。
5.利用like通配符匹配后缀%xxx的时间，由于这种方式不符合索引的最左匹配原则，所以也不会走索引。
但是反过来，如果通配符匹配的是前缀xxx%，符合最左匹配，也会走索引。
6.利用or毗连查询的时间，or语句前后没有同时利用索引，那么索引会失效。只有or左右查询字段都是索引列的时间，才会生效。
除了这些场景以外，对于多表毗连查询的场景中，毗连顺序也会影响索引的利用。
不过最终是否走索引，我们可以利用explain命令来检察sql的实行计划，然后针对性的进行调优即可。
1.5、sql优化

新增：最好就是批量新增
删除：批量删除
改：批量修改
查：
1、多表查询时，小表驱动大表
2、利用索引查询，防止索引失效方式
3、利用索引覆盖
https://blog.csdn.net/wanghailan1818/article/details/121468139
https://blog.csdn.net/m0_74825565/article/details/145195237
1.6、mysql锁机制

1-mysql锁
2-mysql锁
2、RabbitMq

基础概念

• 什么是 RabbitMQ？它的焦点组件是什么？
  RabbitMQ 是一个开源的消息代理（Message Broker），基于 AMQP（Advanced Message Queuing Protocol）协议，用于实现异步通信和解耦系统。
  焦点组件：
  
  
  
  • Producer：消息生产者，发送消息到交换机。
    
  • Exchange：接收消息并根据路由规则分发到队列。
    
  • Queue：存储消息的缓冲区，供消耗者订阅。
    
  • Consumer：消息消耗者，从队列获取消息处理处罚。
    
  • Binding：定义交换机和队列之间的路由规则。
    
  
  
• RabbitMQ 的交换机（Exchange）类型及区别？
  
  
  
  • Direct Exchange：准确匹配路由键（Routing Key）分发消息。
    
  • Topic Exchange：通过通配符（*匹配一个词，#匹配多个词）匹配路由键。
    
  • Fanout Exchange：广播模式，忽略路由键，全部绑定队列都收到消息。
    
  • Headers Exchange：通过消息头（Headers）而非路由键匹配。
    
  
  
• 如何确保消息不丢失？
  
  
  
  • 生产者确认模式（Publisher Confirm）：确保消息成功到达 Broker。
    
  • 恒久化：交换机、队列和消息设置为恒久化（durable=true）。
    
  • 消耗者手动确认（Manual Ack）：消耗者处理处罚完消息后发送确认，制止消息丢失。
    
  
  
• 什么是死信队列（Dead Letter Queue, DLQ）？
  当消息因以下原因无法被消耗时，会被转发到 DLQ：
  
  
  
  • 消息被拒绝（basic.reject 或 basic.nack）且 requeue=false。
    
  • 消息过期（TTL 超时）。
    
  • 队列达到最大长度。
    
  
  

---

高级特性

• 如何实现耽误队列？
  
  
  
  • 方案一：通过消息 TTL（Time-To-Live）和死信队列实现。消息发送到普通队列并设置 TTL，过期后转发到 DLQ。
    
  • 方案二：利用 RabbitMQ 插件 rabbitmq_delayed_message_exchange，支持耽误交换机。
    
  
  
• RabbitMQ 如何包管消息顺序？
  RabbitMQ 默认不包管全局消息顺序，但在单队列单消耗者的场景下可以包管顺序。若需多消耗者顺序处理处罚，需业务层计划（如按消息 ID 分组）。
  
• RabbitMQ 集群如何工作？什么是镜像队列？
  
  
  
  • 集群：多个节点共享元数据（交换机、队列定义），但队列数据默认仅存在于声明它的节点。
    
  • 镜像队列（Mirrored Queue）：队列数据在多个节点间复制，提供高可用性（需设置计谋 ha-mode=all）。
    
  
  
• 如何处理处罚消息重复消耗？
  
  
  
  • 业务层去重：为消息添加唯一 ID，消耗者处理处罚前检查 ID 是否已处理处罚（如数据库或 Redis 记载）。
    
  • 幂等性计划：确保多次处理处罚同一消息的结果与一次处理处罚雷同。
    
  
  

---

实际场景

• 消息堆积（积压）如何处理处罚？
  
  
  
  • 增长消耗者数量（程度扩展）。
    
  • 设置队列最大长度或 TTL，丢弃旧消息。
    
  • 暂时扩容消耗者，批量处理处罚积压消息。
    
  
  
• RabbitMQ 和 Kafka 的主要区别？
     特性RabbitMQKafka协议AMQP自定义协议消息模子队列模子（点对点、发布订阅）流模子（分区日志）吞吐量中等（万级/秒）高（百万级/秒）消息保存消耗后默认删除按时间/大小保存实用场景实时性高、复杂路由高吞吐、日志流处理处罚
  
• 如何监控 RabbitMQ？
  
  
  
  • 利用管理插件（Management Plugin）提供的 Web UI 或 HTTP API。
    
  • 集成 Prometheus + Grafana，通过 rabbitmq_prometheus 插件收罗指标。
    
  • 监控关键指标：毗连数、队列长度、消息吞吐量、内存/磁盘利用率。
    
  
  

---

深入标题

• 消息的传输过程是怎样的？
  Producer → Exchange → Binding → Queue → Consumer。Exchange 根据类型和路由键决定将消息发送到哪些队列。
  
• 如何实现分布式事件（消息最终一致性）？
  结合本地事件表与 RabbitMQ：
  
  
  
  • 业务操纵和消息写入本地数据库事件表在同一个事件中。
    
  • 配景服务轮询事件表，将未发送的消息投递到 RabbitMQ。
    
  • 消耗者处理处罚成功后关照生产者确认。
    
  
  
• RabbitMQ 的性能瓶颈通常在那边？如何优化？
  
  
  
  • 瓶颈：磁盘 I/O（恒久化）、网络耽误、ACK 机制。
    
  • 优化：
    
    
    
    • 利用内存节点（非恒久化场景）。
      
    • 批量确认（basic.ack 多消息合并）。
      
    • 增长 Prefetch Count 提升消耗者吞吐量。
      
    
    
  
  

3、Redis

redis口试
4、Clickhouse

5、HashMap工作原理

二、HashMap 的底层工作原理
    1、哈希函数与哈希值： 每个键都会通过哈希函数盘算出一个哈希值，然后通过哈希值决定数据应该存储在哪个桶（bucket）中。桶是一个数组的存储位置。
    2、哈希函数的主要目的是将数据均匀地分布在不同的桶中，从而淘汰哈希碰撞（即两个不同的键映射到同一个桶中的情况）。
    3、数组和链表： HashMap 的底层是一个数组，每个数组元素存放一个链表或红黑树（在 JDK 1.8 之后，链表过长时会转化为红黑树）。当新元素插入 HashMap 时，它首先根据哈希值找到数组中的某个位置（桶）。如果该位置为空，则直接插入；如果该位置已经存在元素（发生碰撞），则通过链表或红黑树办理冲突。
    4、hash冲突——链表和红黑树：
    如果发生哈希冲突，HashMap 会将雷同哈希值的元素以链表的情势存储在同一个桶中（数组的某个位置）。在 JDK 1.8 之前，链表是唯一的冲突办理方式。当链表长度较长时，时间复杂度变为 O(n)。JDK 1.8 引入了红黑树，当链表长度超过肯定阈值（默认是 8）时，链表会转换为红黑树，从而将时间复杂度从 O(n) 低沉到 O(log n)。
    5、负载因子和扩容： HashMap 有一个重要的参数叫 负载因子 (load factor)，它决定了当数组中元素数量超过数组容量的多大比例时会触发扩容操纵。默认的负载因子是 0.75。当 HashMap 的元素数量达到数组容量的 75% 时，HashMap 会主动进行扩容操纵，通常会将数组容量扩展为原来的 2 倍。
    6、扩容 (Rehashing)： 扩容时，HashMap 会重新分配一个更大的数组，并将原来的元素重新映射到新的数组中，这个过程叫做 rehashing。这个操纵比力耗时，由于要重新盘算每个元素的哈希值并将其放入新的桶中。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。