懂他！理解他！

1.分布式事务seata处理流程

（1）发起方 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成唯一的全局事务标识 XID，该 XID 在后续事务的服务调用链路的上下文传播

（2）RM 向 TC 注册分支事务，并与 XID 进行绑定（Branch分支事务指分布式事务中每个独立的本地局部事务）。

（3）RM完成资源操作后，向TC上报事务完成状态。

（4）TC将各个分支事务的执行结果告知TM，TM汇总结果生成决议， 向 TC 发起 XID 下的所有分支事务的全局提交或回滚请求（事务一阶段结束）

（5）TC 根据TM的决议，通知所有 RM 提交/回滚 资源，事务二阶段结束；

2.链路追踪的数据信息存在哪

用SkyWalking存储数据

他是一个开源的分布式追踪、监控和诊断系统，它能够跟踪请求在不同服务和组件之间的流动。

数据存储组件

1. 数据存储后端
   • Elasticsearch: SkyWalking 可以将追踪数据存储到 Elasticsearch 中，作为其默认的存储选项之一。Elasticsearch 是一个分布式搜索和分析引擎，非常适合存储和查询大规模的日志数据和追踪数据。
   • H2: SkyWalking 也可以使用 H2 数据库进行存储，通常用于测试或开发环境，因为 H2 是一个轻量级的嵌入式数据库。
   • MySQL / MariaDB: 在某些配置中，SkyWalking 也支持将数据存储到 MySQL 或 MariaDB 数据库中。
2. 数据模型
   • 追踪数据（Trace Data）: 包含请求的详细信息，例如服务调用链、每个服务的调用时长、错误信息等。这些数据通常以文档的形式存储，允许对请求的完整生命周期进行详细分析。
   • 指标数据（Metrics Data）: 包括系统的性能指标，如吞吐量、响应时间、错误率等。这些数据可以帮助监控和优化系统的性能。
   • 日志数据（Logs Data）: 有些配置可能包括与追踪数据相关的日志信息，用于更详细的故障排查。

3.用OpenFeign如果A服务调用B服务失败怎么办

1. 重试机制：使用 OpenFeign 的重试机制尝试再次调用 B 服务。可以通过 Feign 配置来设置重试次数和间隔。
2. 熔断器：集成 Hystrix 或 Resilience4j 等熔断器库来处理失败，防止失败请求对系统造成更大影响。
3. 降级处理：设置降级策略，在 B 服务不可用时提供备用逻辑或默认值。
4. 异常处理：在 Feign 客户端配置中使用自定义的异常处理器，捕获和处理调用失败的情况，并记录日志。
5. 超时设置：调整请求的超时时间，以避免长时间等待失败的调用。

4.ThreadLocal定义以及作用

ThreadLocal 是 Java 中的一个类，用于创建线程局部变量。它的作用是为每个线程提供独立的变量副本，这样多个线程可以并发访问同一个 ThreadLocal 变量而不会相互干扰。每个线程访问的 ThreadLocal 变量是线程隔离的，彼此之间不会共享。

作用和用途

1. 线程隔离：确保每个线程有自己的变量副本，避免了线程间数据竞争。
2. 状态管理：在复杂的应用中，ThreadLocal 常用于存储与线程相关的状态，例如用户会话信息、数据库连接等。
3. 性能优化：避免了在多线程环境中传递和管理共享数据的复杂性，提高了性能。

ThreadLocal 的常见用例包括数据库连接管理、用户会话管理和线程安全的工具类等。

**ThreadLocalMap** 实际上是 ThreadLocal 的一个实现细节，它将 ThreadLocal 对象与线程局部变量的值关联起来，每个线程持有一个独立的 ThreadLocalMap 实例。

5.什么情况下会导致索引失效

1. 查询条件不匹配：使用不等于（!=）、LIKE 操作符开头的模糊查询等，可能导致索引无法有效利用。
2. 数据类型不一致：查询条件的数据类型与索引列的数据类型不一致，如字符串和数字混用。
3. 索引未被使用：某些查询优化器可能选择不使用索引，特别是在涉及复杂计算、函数或连接操作时。
4. 表的统计信息不更新：数据库的统计信息过时可能导致查询优化器做出错误的决策，忽略索引。
5. 索引碎片化：频繁的插入、更新和删除操作可能导致索引碎片化，从而影响性能。

6.怎么判断sql语句用到索引

1. 执行计划：使用 EXPLAIN 或 EXPLAIN PLAN 查看 SQL 查询的执行计划。它会显示查询过程中是否使用了索引。
2. 查询性能：观察查询的执行时间和性能。如果索引被有效利用，查询通常会更快。
3. 数据库工具：使用数据库提供的性能分析工具或查询分析器（如 MySQL 的 SHOW INDEX 命令）来查看索引的使用情况。
4. 日志和统计：查看数据库的慢查询日志或性能统计信息，了解哪些查询使用了索引。

7.关于Redis

Redis支持的数据类型

1. 字符串（String）：最基本的数据类型，可以存储文本、数字等。
2. 哈希（Hash）：键值对集合，适合存储对象及其属性。
3. 列表（List）：有序字符串集合，支持从两端推入和弹出元素。
4. 集合（Set）：无序字符串集合，支持集合操作如交集、并集、差集。
5. 有序集合（Sorted Set）：类似集合，但每个元素都有一个分数用于排序。
6. 位图（Bitmap）：用于高效存储和操作位数据。
7. 超日志（HyperLogLog）：用于估算唯一元素数量，适用于大数据量的去重。
8. 地理位置（Geo）：存储地理位置数据，支持地理位置相关的操作。

Redis在项目中缓存哪些数据

1. 热点数据：频繁访问的数据，如用户资料、热门商品等。
2. 会话信息：用户会话和身份验证信息。
3. 缓存查询结果：数据库查询结果，减少重复的数据库查询。
4. 计数器和统计数据：如网站访问量、用户行为统计等。
5. 临时数据：如验证码、任务队列、会话过期数据等。

Redis中key值过期的处理策略

Redis采用的过期策略是惰性删除+定期删除同时使用

惰性删除：当尝试访问一个过期的键时，Redis 会检查该键是否已经过期。如果是，Redis 会将其从数据库中删除并返回一个空值 这种策略即为惰性删除，它的优点是避免了不必要的计算开销，但缺点是可能会导致一些过期键在访问时才被删除，增加了访问延迟。

定期删除：Redis 会定期扫描数据库中的过期键。默认情况下，Redis 每隔 100 毫秒会随机检查一部分键的过期情况，并删除那些过期的键。

当 Redis 达到内存限制时，除了过期键的删除策略，Redis 还提供了内存淘汰策略，以保证 Redis 继续正常运行

Redis 通过设置键的过期时间和应用多种过期策略来管理数据的生命周期。这些策略帮助 Redis 处理过期数据、优化内存使用，并确保系统高效稳定运行

Redis缓存问题

缓存穿透：

查询一个不存在的数据，由于缓存中没有该数据，导致每次请求都会去数据库查询，数据库压力增大。

解决方案：

• 布隆过滤器：使用布隆过滤器（Bloom Filter）来判断请求的数据是否存在。布隆过滤器是一个高效的概率型数据结构，用于测试某个元素是否在一个集合中。布隆过滤器的误判率较低且空间效率高，可以在缓存层做一次筛查，避免不必要的数据库查询。
• 缓存空值：对于那些查询结果为空的请求，可以将空值也缓存起来，设置一个合理的过期时间。这可以防止相同的不存在的数据频繁请求数据库。
• 请求合并：在高并发情况下，将多个相同的请求合并为一个请求，防止同一时间大量请求直接访问数据库。可以通过请求队列和批量查询来实现。

缓存击穿：

本来缓存中有对应的数据，但是缓存的数据 因为到期，需要去数据库中再次查询数据

解决方案：

• 互斥锁：在缓存数据过期时，可以使用分布式锁（如 Redis 的 SETNX 命令）来保证只有一个线程去加载数据并更新缓存，其他线程等待数据加载完成后再从缓存中读取。
• 提前加载：可以在缓存数据到期之前，提前刷新数据。在数据过期前设置一个较短的预警时间，定期检查并更新缓存中的数据。
• 缓存预热：在系统启动时或数据更新时，预先加载一些热点数据到缓存中，避免缓存刚启动时突然出现大量数据库请求。

缓存雪崩：

当大量缓存数据同时过期或被删除时，大量请求会直接访问数据库，导致数据库压力骤增。

解决方案：

• 随机过期时间：对缓存数据设置随机的过期时间，避免所有缓存数据同时过期。这样可以平摊缓存失效的压力，防止集中在同一时间大量请求击中数据库。
• 缓存预热：定期将缓存中热点数据进行预热，以减少缓存雪崩发生时的影响。
• 降级机制：当缓存雪崩发生时，可以启用降级机制，提供一些默认的数据或服务降级的处理方式，以保证系统的可用性。

缓存倾斜：

某个热点数据被大量请求访问，导致该数据所在的Redis节点压力过大，甚至可能引发宕机。

解决方案：

• 分片：通过分片（sharding）技术，将数据分布到多个 Redis 节点上，以避免单个节点的负载过大。可以使用 Redis Cluster 或其他分布式 Redis 解决方案来实现。

• 热点数据分离：将热点数据与普通数据分开存储。对于访问频繁的热点数据，可以使用更高性能的存储方案或不同的缓存策略（如设置更高的缓存容量）。

• 限流：对热点数据的请求进行限流，避免过多的请求集中在一个节点上。可以通过令牌桶算法或漏斗算法来限制请求的速率。

• 缓存更新策略：优化缓存更新策略，比如使用后台异步刷新机制来减少缓存压力。

8.关于Rabbitmq

消息的可靠性（重要）面试

mq如何保证消息的可靠性

1. 持久化：将消息写入磁盘以确保即使系统崩溃也不会丢失。
2. 确认机制：消费者在成功处理消息后发送确认信号，确保消息被正确处理。
3. 重复投递处理：设计系统以处理消息的重复投递，确保业务逻辑的幂等性。
4. 事务：支持消息生产和消费的事务操作，确保消息一致性。
5. 消息备份：使用副本机制，将消息数据备份到多个节点上，增加容错能力。
6. 超时重试：在消息处理失败时设置重试机制，以处理临时错误。

这些策略共同作用，以确保消息在传递和处理过程中不会丢失。

mq如何保证消息不丢失

1. 持久化（Persistence）：
   • 消息持久化：将消息写入磁盘存储，而不是仅保存在内存中。即使系统崩溃，消息也能从磁盘恢复。
   • 日志文件：消息队列通常会将消息记录到日志文件中，以确保在故障恢复时能够恢复消息。
2. 确认机制（Acknowledgements）：
   • 生产者确认：生产者在发送消息时等待确认，确保消息已成功写入消息队列。
   • 消费者确认：消费者在处理完消息后发送确认（ACK），告诉消息队列消息已成功处理。如果消费者未确认，消息队列会重新投递消息。
3. 消息备份（Replication）：
   • 数据副本：在集群模式下，消息队列可以将数据复制到多个节点，确保主节点故障时，副本节点可以接管，避免消息丢失。
4. 事务（Transactions）：
   • 生产者事务：确保消息生产和发送的操作是原子性的，即要么全部成功，要么全部失败，避免半完成的操作。
   • 消息队列事务：有些消息队列支持事务，确保消息从生产到消费的整个过程是一致的。
5. 超时重试（Retry Mechanism）：
   • 重试机制：如果消息处理失败，消息队列可以配置重试策略，将消息重新投递到队列中，确保消息能够被处理。
6. 死信队列（Dead-Letter Queue）：
   • 死信处理：处理失败的消息会被发送到专门的死信队列，方便后续的审查和处理，避免消息丢失。
7. 消息去重（Deduplication）：
   • 去重机制：避免消息重复处理，尤其是在消息队列发生重启或网络异常时。

通过这些机制，消息队列系统可以有效地减少消息丢失

mq如何防止消息的重复消费

消息的幂等性处理 防止因为网络抖动，同一个消息被多次消费

持久化：

• 消息持久化：可以将消息标记为持久化，消息会被写入磁盘。
• 队列持久化：可以将队列标记为持久化，队列的状态会被写入磁盘。
• 交换机持久化：交换机本身的持久化主要体现在持久化绑定关系和路由配置上。

消息的确认机制：

​ 发送消息确认：confirm机制、return机制

​ 消息到交换机过程，confirm机制

​ 消息从交换机到队列，如果队列没有收到消息，触发return机制

​ 消费消息确认：ack机制

​ 手动确认 channel.basicAck() 一般没有异常，确认消息已正常处理

​ channel.basicReject() 一般针对异常，拒绝消息，还可以设置消息是否重新入队

​ channel.basicNack(),拒绝多条消息

死信队列：

没有被及时消费的消息存放在死信队列 中

消息变成死信后，会被重新投递到另一个交换机，这个交换机往往被称为DLX(dead-letter-exchange)“死信交换机”，然后交换机根据绑定规则转发到对应的队列上，监听死信队列就可以对消息进行重新消费

当以下几个事件中任意一个发生时，消息将会被重新发送到死信队列：

1）消息被消费者使用basic.reject或basic.nack方法并且requeue参数值设置为false的方式进行消息确认(negatively acknowledged)；

2）消息由于消息有效期(TTL)过期；

换机根据绑定规则转发到对应的队列上，监听死信队列就可以对消息进行重新消费

[外链图片转存中…(img-G1uF3HyJ-1725546383793)]

当以下几个事件中任意一个发生时，消息将会被重新发送到死信队列：

1）消息被消费者使用basic.reject或basic.nack方法并且requeue参数值设置为false的方式进行消息确认(negatively acknowledged)；

2）消息由于消息有效期(TTL)过期；

3）消息由于队列超过其长度限制而被丢弃