【每日八股】淘天一面

在这里插入图片描述

🔥 个人主页: 黑洞晓威
😀你不必等到非常厉害，才敢开始，你需要开始，才会变的非常厉害

rocketmq的消息重复发送问题？如何保证幂等？

如何保证幂等性：
消息 Key 设置：不建议以 Message ID 作为处理依据，而是使用业务唯一标识作为幂等处理的关键依据。例如，在支付场景中，可以将消息的 Key 设置为订单号。
业务逻辑自我实现幂等：消费逻辑需要自行实现幂等性。例如，通过数据库事务、乐观锁等方式，确保同一条消息的消费结果只能在业务系统中生效一次。
注意并发场景：在高并发场景下，要注意并发重复消息的问题。例如，使用 select for update 语句锁定记录，以避免并发问题。

讲一下乐观锁和悲观锁的一些区别吗？

乐观锁：
思想：乐观锁对数据操作持乐观态度，认为其他线程不会同时修改数据。
实现方式：乐观锁不会上锁，而是在执行更新操作时检查其他线程是否修改了数据。如果有其他修改，放弃操作；否则执行操作。
常见实现：使用 CAS（Compare And Swap） 机制或版本号机制。
适用场景：适用于并发写入较少的情况。

悲观锁：
思想：悲观锁对数据操作持悲观态度，认为其他线程可能同时修改数据。
实现方式：悲观锁在操作数据时直接将数据锁住，直到操作完成后才释放锁。其他线程在锁定期间无法修改数据。
常见实现：使用代码块锁（如 Java 的 synchronized 关键字）或数据库中的排它锁。
适用场景：适用于并发写入较多的情况。

CAS 机制：
CAS（Compare And Swap） 是乐观锁的一种实现方式。
CAS 操作包括三个操作数：需要读写的内存位置、进行比较的预期值、拟写入的新值。
CAS 是由 CPU 支持的原子操作，在硬件层面保证原子性。

版本号机制：
乐观锁的另一种实现方式。
在数据表中添加一个版本号字段，每次更新时增加版本号。
更新时检查版本号，如果版本号匹配，执行操作；否则放弃。

适用场景：
乐观锁：适用于读多写少的场景，如缓存、分布式锁。
悲观锁：适用于写多的场景，如数据库事务。

保证幂等中的幂等键是如何设计的？

在设计幂等性时，选择合适的幂等键（也称为幂等标识）是至关重要的。幂等键用于唯一标识一次请求，确保同一操作的多次请求具有相同的结果。以下是一些常见的幂等键设计方法：

业务唯一标识：
使用业务相关的唯一标识作为幂等键。例如，在订单系统中，可以使用订单号作为幂等键。
这样，无论客户端发送多少次相同的请求，只要订单号相同，服务端都会保证处理结果一致。

Token 机制：
在接口调用前，先获取一个全局唯一的 Token。
将 Token 作为请求的一部分，服务端根据 Token 判断是否已处理过相同的请求。
如果已处理，直接返回之前的结果；如果未处理，执行业务逻辑并保存 Token。

版本号机制：
在数据库表中增加一个版本号字段（或者时间戳字段）。
在更新数据之前，先查询数据的版本号。
更新数据时，使用版本号作为查询条件，确保只有相同版本号的请求才能修改数据。

悲观锁：
在高并发场景下，使用数据库的悲观锁来保证幂等性。
通过 SELECT ... FOR UPDATE 查询语句锁定数据行，确保同一时刻只有一个请求能修改数据。

唯一索引：
在数据库表中添加唯一索引，确保某些字段的唯一性。
如果插入重复数据，数据库会报唯一性约束错误，此时可以捕获异常并返回成功。

防重表：
针对特定场景，不允许产生重复数据的情况，可以创建一个防重表。
防重表只包含必要的字段，例如业务标识和唯一索引。
在插入数据时，先查询防重表，如果存在相同的标识，说明是重复请求，直接返回成功。

总之，选择合适的幂等键取决于具体业务场景。根据业务需求、性能要求和数据一致性，选用适当的方案来保证接口的幂等性。

讲一下get reset 跟 git reverse有什么区别？

当涉及到版本控制时，git reset 和 git revert 是两个常用的 Git 命令，它们用于处理提交历史的不同方面。让我们来详细比较一下它们的区别：

git reset：

作用：git reset 用于将 HEAD 指向指定的提交，从而重置分支的历史。
效果：执行 git reset 后，会丢弃指定提交之后的所有提交，这些提交将不再出现在分支历史中。
常见用法：git reset --hard <commit> 可以将 HEAD 和工作目录回退到指定提交。

git revert：

作用：git revert 用于撤销某个提交的更改，创建一个新的提交来还原之前的更改。
效果：执行 git revert 后，会在分支上创建一个新的提交，该提交的内容与要还原的提交相反。
常见用法：git revert <commit> 可以撤销指定提交的更改。

区别总结：

git reset 直接修改提交历史，可能导致本地仓库和远程仓库不一致，需要谨慎使用。
git revert 创建一个新的提交来撤销特定的提交，不会修改提交历史。

●使用git reset时，你可以修改当前分支的历史，但如果更改已经推送，可能会给团队带来问题。它主要用于本地更改的撤销或重组。
●使用git revert时，你在不更改现有历史的前提下撤销之前的更改，通过添加新的提交来实现。这对于处理已经推送的更改更为安全和推荐。
简单来说，如果你想撤销本地的更改并且不担心改变历史，可以使用git reset。如果需要撤销已经推送的提交，并且希望保持项目历史的完整性，应该使用git revert。

怎么用threadlocal解决用户信息共享的问题嘛（黑马点评）？

ThreadLocal 是 Java 中的一个强大工具，用于解决多线程环境下的数据共享问题。虽然它可以用于处理线程安全问题，但它的资源并不是共享的，而是每个线程独享的。让我们深入了解一下 ThreadLocal 的使用和原理：
ThreadLocal 的使用场景：

每个线程需要一个独享对象：例如，SimpleDateFormat 和 Random 等工具类。每个线程内有自己的实例副本，不共享。类比：教材只有一本，一起做笔记会有线程安全问题。使用 ThreadLocal 相当于复印了教材。
每个线程内需要保存全局变量：例如，在拦截器中获取用户信息，可以让不同方法直接使用，避免参数传递的麻烦。
ThreadLocal 的实践：
场景1：每个线程打印日期：

Java
public class ThreadLocalExample {
    private static ThreadLocal<SimpleDateFormat> dateFormatThreadLocal = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));

    public String formatDate(int seconds) {
        Date date = new Date(1000L * seconds);
        return dateFormatThreadLocal.get().format(date);
    }

    public static void main(String[] args) {
        ThreadLocalExample example = new ThreadLocalExample();
        for (int i = 0; i < 30; i++) {
            int finalI = i;
            new Thread(() -> {
                String formattedDate = example.formatDate(finalI);
                System.out.println(formattedDate);
            }).start();
        }
    }
}
AI 生成的代码。仔细查看和使用。有关常见问题解答的详细信息.

运行结果：多个线程打印自己的时间，每个线程有自己的 SimpleDateFormat 对象，避免了线程安全问题。
场景2：当前用户信息需要被线程内的所有方法共享：

方案1：传递参数。但这样会增加方法参数的复杂度。
方案2：使用 ThreadLocal 存储用户信息，让不同方法直接访问，避免参数传递的麻烦。
ThreadLocal 的注意点：

需要在使用完毕后调用 remove() 方法，以避免内存泄漏。
不要过度使用 ThreadLocal，否则可能导致资源浪费。
总之，ThreadLocal 可以有效地解决多线程环境下的数据共享问题，但要谨慎使用，避免资源泄漏。1234

利用 Redis 实现了点赞和关注功能，那 Redis 跟点赞和关注功能有啥关系？点赞不应该存储在数据库里面的嘛？

Redis 在点赞和关注功能中扮演着重要的角色，尤其是在高并发环境下。让我们详细探讨一下 Redis 与点赞、关注功能之间的关系：

点赞和关注功能的需求：

点赞和关注功能是社交平台和内容应用中常见的交互特性。
关键特性包括唯一性、即时性、可见性和可撤销性。

Redis 在点赞和关注功能中的作用：

缓存点赞数：将文章的点赞数存储在 Redis 中，避免频繁查询数据库，提高性能。
记录用户点赞的文章：使用 Redis 的数据结构（例如 Hash 或 Set）存储用户点赞的文章，以便快速判断用户是否已点赞某篇文章。
定时同步到数据库：通过定时任务，将 Redis 中的点赞数据定期持久化到 MySQL 数据库中。

具体实现步骤：

点赞

：

用户点赞时，将点赞信息存入 Redis：
增加用户总点赞数。
记录用户点赞的文章。
增加文章的点赞数。

定时任务从 Redis 读取数据，将点赞数据持久化到 MySQL。

取消点赞

：

用户取消点赞时，将取消点赞信息从 Redis 中移除：
减少用户总点赞数。
移除用户点赞的文章记录。
减少文章的点赞数。

同样，定时任务将 Redis 中的数据同步到 MySQL。

数据库设计：

主要涉及两张表：
article 表：存储文章信息，包括文章 ID、内容和总点赞数。
user_like_article 表：记录用户点赞的文章，是一张中间表。

总结：

Redis 作为缓存数据库，用于存储点赞数和用户点赞的文章信息，可以有效减轻数据库压力，提高系统性能。
定时任务确保 Redis 中的数据与数据库保持同步，实现数据的持久化存储。

如果你想了解更多关于 Redis 和点赞功能的实现细节，可以参考以下链接：

知乎专栏：Redis 实现点赞功能模块
鱼皮的编程宝典：Redis 实现文章点赞功能

遇到的Java的包冲突，一般怎么排查呢？

Maven Helper

使用IntelliJ IDE的Maven helper插件方便找到和排除冲突的依赖项

【1】command+, 打开工具的设置窗口

【2】设置搜索中输入plugin

【3】在Marketplace table页面中搜索Maven Helper，并安装

【4】重启后即可使用，打开pom文件后，文件下面会多出Dependency Analyzer这一个tab。

进入Dependency Analyzer视图之后有三个查看选项，

Conflicts(冲突)

All Dependencies as List(列表形式查看所有依赖)

All Dependencies as Tree(树结构查看所有依赖)

描述一下类加载的过程？

类加载是 Java 程序运行的关键步骤之一，它负责将编译后的 Java 类文件加载到虚拟机中，使得程序能够正确运行。类加载过程包括以下七个阶段：

加载（Loading）：
加载阶段通过类的全限定名获取类的二进制字节流。
将字节流转换为方法区的运行时数据结构。
在内存中生成一个代表该类的 Class 对象，作为方法区这些数据的访问入口。

验证（Verification）：
验证阶段确保 Class 文件的字节流符合 Java 虚拟机规范的约束要求。
防止恶意代码的执行。

准备（Preparation）：
准备阶段为类变量分配内存并设置初始值。
只包括类变量，不包括实例变量。

解析（Resolution）：
解析阶段将符号引用转换为直接引用。
主要针对类、字段、方法等符号引用。

初始化（Initialization）：
初始化阶段执行类构造器 <clinit> 方法，为类变量赋予正确的初始值。
静态变量和静态代码块的初始化都在这一阶段完成。

使用（Using）：
在类加载完成后，可以使用类的静态变量和静态方法。

卸载（Unloading）：
类的生命周期从加载开始到卸载结束。
类卸载发生在类不再被引用且没有正在执行的线程使用时。

讲一下索引为什么可以提高数据库的查询速度？

索引的优缺点

优势：可以快速检索，减少I/O次数，加快检索速度；根据索引分组和排序，可以加快分组和排序；

劣势：索引本身也是表，因此会占用存储空间，一般来说，索引表占用的空间的数据表的1.5倍；索引表的维护和创建需要时间成本，这个成本随着数据量增大而增大；构建索引会降低数据表的修改操作（删除，添加，修改）的效率，因为在修改数据表的同时还需要修改索引表；

深入理解MySQL索引原理和实现——为什么索引可以加速查询？-腾讯云开发者社区-腾讯云 (tencent.com)

有没有遇到过跨域的问题。你知道跨域是啥意思？

什么是跨域？

跨域指的是在浏览器中，一个网页的脚本试图访问不同源（Origin）的资源（例如不同域名、协议或端口）时，会受到浏览器的限制。
同源策略是浏览器的一种安全机制，它限制了不同源之间的交互。

为什么会出现跨域问题？

浏览器出于安全考虑，限制了不同源之间的资源访问。
如果请求的协议、主机、端口有任何一个不同，就被视为跨域请求。

跨域问题的解决方法：

CORS（跨域资源共享）：在响应头中添加特定的字段，允许不同源的请求访问资源。
JSONP（JSON with Padding）：通过动态创建 <script> 标签，实现跨域数据传输。
代理服务器：在同源服务器上设置代理，将跨域请求转发到目标服务器。

前后端分离项目，如何解决跨域问题？_项目测试环境、生产环境里,前后端跨域是如何解决的-CSDN博客

能讲一下 session 跟 cookie 的区别吗？

当谈到 Web 应用程序的用户身份验证和状态管理时，Session 和 Cookie 是两个常见的概念。让我详细解释一下它们之间的区别：

Cookie：
概念：Cookie 是一种在客户端存储数据的技术，由服务器发送给客户端的小型文本文件。
存储位置：Cookie 存储在客户端的浏览器中。
安全性：相对较低，因为 Cookie 可以被客户端修改和查看。
大小限制：Cookie 大小通常限制在 4KB 左右。
有效期：可以设置较长时间，只要不超过设置的过期时间，可以一直存储。

Session：
概念：Session 是在服务器端创建的会话，用于跟踪用户的状态和数据。
存储位置：Session 数据存储在服务器上。
安全性：相对较高，因为 Session 数据在服务器上，客户端无法直接修改。
有效期：Session 在一定时间内保存在服务器上，通常为 30 分钟左右。

区别总结：
存储位置：Cookie 存储在客户端，Session 存储在服务器端。
安全性：Session 比 Cookie 更安全。
生命周期：Cookie 可以长期存储，Session 有固定的过期时间。
存储大小：Cookie 有大小限制，Session 大小受服务器内存限制。
跨域访问：Cookie 受同源策略限制，Session 不受限制。

总之，Cookie 和 Session 都用于存储用户状态和身份信息，但它们的存储位置、安全性和生命周期等方面存在差异。在实际应用中，通常会结合使用 Cookie 和 Session 来实现用户认证和状态管理。12345