面试总结（一）mysql+redis+mybatis+tcp

大聪明」

已于 2024-01-16 21:30:32 修改

阅读量934

点赞数 14

文章标签： spring java 后端

于 2024-01-16 21:29:48 首次发布

本文链接：https://blog.csdn.net/m0_57764322/article/details/135546361

版权

mybatis

简述一下mybatis的工作原理

mybatis的一级缓存和二级缓存

数据库修改了之后，怎么保证缓存和数据库数据的一致性

只开启一级缓存的情况下，数据库发生了改变，怎么保证数据一致性

mysql中的多表关联查询怎么优化，如果不使用关联查询有没有想过其他的方式去处理

选择MyBatis的理由：

为什么选择MyBatis而不是Hibernate：

为什么tcp建立连接需要三次握手，断开连接需要四次握手

mybatis

简述一下mybatis的工作原理

答：

MyBatis是一种持久层框架，它的工作原理基于将Java对象与数据库中的数据进行映射。简而言之，MyBatis通过以下步骤实现工作：

配置文件： 用户需要配置MyBatis的XML配置文件，其中包含数据库连接信息、SQL映射等配置。

映射文件： MyBatis使用映射文件将Java对象和数据库表进行映射。这个文件定义了SQL语句、参数映射以及结果集映射。

SqlSessionFactory： MyBatis通过SqlSessionFactory创建SqlSession对象。SqlSessionFactory是一个线程安全的类，用于创建SqlSession。

SqlSession： SqlSession是MyBatis的主要执行器，它负责与数据库交互。用户通过SqlSession执行SQL语句，进行数据库的增删改查操作。

Executor： SqlSession内部使用Executor执行SQL语句，Executor负责处理Statement的创建、参数设置、SQL语句的执行等。

Statement： MyBatis使用Statement对象表示SQL语句，它可以是预编译的PreparedStatement或者普通的Statement。

参数映射： MyBatis会将Java对象中的属性值与SQL语句中的参数进行映射，确保正确的数据传递。

结果映射： 查询结果会被映射到Java对象上，确保数据库返回的数据与Java对象的属性正确对应。

通过这些步骤，MyBatis实现了Java对象与数据库之间的无缝映射，提供了一种方便的方式来进行数据库操作。

用自己的话来说：

"MyBatis是一个持久层框架，它的核心思想是通过配置文件和映射文件，将Java对象和数据库表进行关联。首先，我们需要配置连接信息等基本设置，然后定义映射文件，指明SQL语句、参数映射和结果集映射。

一旦配置好，MyBatis通过SqlSessionFactory创建SqlSession，这个对象是我们与数据库交互的入口。SqlSession内部使用Executor执行SQL语句，它负责处理参数设置、SQL语句执行等底层细节。

在执行SQL语句时，MyBatis会将Java对象中的属性值与SQL语句中的参数进行匹配，确保数据正确传递。而在查询的时候，MyBatis会将数据库返回的结果映射到相应的Java对象上，这样我们就能方便地在代码中使用对象来处理数据。

总的来说，MyBatis通过配置和映射，提供了一种简单而强大的方式来操作数据库，使得Java对象和数据库表之间的交互变得更加容易理解和管理。"

mybatis的一级缓存和二级缓存

一级缓存（Local Cache）： 一级缓存是SqlSession级别的缓存，它默认是开启的，存储了在同一个SqlSession中执行的查询结果。这意味着如果执行相同的SQL语句，MyBatis会首先查看一级缓存，如果缓存中存在相同的查询，直接返回缓存结果，而不去数据库执行查询。
// 示例中的代码片段 
SqlSession sqlSession = sqlSessionFactory.openSession(); 
User user1 = sqlSession.selectOne("getUser", 1); // 查询并将结果存入一级缓存
User user2 = sqlSession.selectOne("getUser", 1); // 直接从一级缓存中获取结果，而不去执行查询
注意：一级缓存是SqlSession级别的，当SqlSession关闭时，缓存也会被清空。
二级缓存（Global Cache）： 二级缓存是Mapper级别的缓存，它可以跨SqlSession共享缓存数据。配置二级缓存后，如果不同的SqlSession执行相同的查询，查询结果会被存储在二级缓存中，从而实现跨会话的缓存共享。
 
<settings> 
    <setting name="cacheEnabled" value="true"/> 
</settings>


// 示例中的代码片段 SqlSession sqlSession1 = sqlSessionFactory.openSession(); 
User user1 = sqlSession1.selectOne("getUser", 1); // 查询并将结果存入二级缓存 SqlSession sqlSession2 = sqlSessionFactory.openSession(); 
User user2 = sqlSession2.selectOne("getUser", 1); // 从二级缓存中获取结果，而不去执行查询
注意：二级缓存是跨SqlSession的，但需要注意在进行数据更新、插入、删除等操作时，会清空相应的缓存，以保证缓存数据的一致性。
一级缓存和二级缓存的使用需要谨慎，因为缓存可能导致数据不一致性的问题，特别是在多线程、多事务环境中。在实际应用中，需要根据具体的业务场景和性能需求来决定是否开启以及如何使用缓存。

数据库修改了之后，怎么保证缓存和数据库数据的一致性

清空缓存： 在数据发生变更（更新、插入、删除）时，及时清空相关的缓存。MyBatis提供了 clearCache() 方法来手动清空一级缓存，而对于二级缓存，当进行数据更新操作时，MyBatis会自动清空相关的缓存。
// 示例中的代码片段
sqlSession.update("updateUser", updatedUser); // 数据库更新操作
sqlSession.clearCache(); // 清空一级缓存
使用缓存注解： MyBatis提供了 @CacheNamespace 注解，可以用于配置缓存的相关属性，例如刷新间隔、缓存策略等。通过合理配置缓存注解，可以在一定程度上控制缓存的刷新行为。
// 示例中的代码片段，@CacheNamespace注解用于配置缓存
@CacheNamespace(flushInterval = 60000) // 刷新间隔为60秒
public interface UserMapper {
    User getUser(int userId);
}
手动刷新二级缓存： 在需要时，可以手动刷新二级缓存。MyBatis提供了 clearCache() 方法用于清空所有缓存，包括一级和二级缓存。
// 示例中的代码片段
sqlSession.clearCache(); // 清空所有缓存
需要根据具体的业务场景和性能需求选择适当的缓存策略。在高并发或者要求实时性较高的系统中，可能需要更主动地清空缓存来保证数据的一致性。

只开启一级缓存的情况下，数据库发生了改变，怎么保证数据一致性

手动清空缓存： 在发生数据库更新、插入或删除操作时，手动清空相应的一级缓存，以确保下一次查询时从数据库中获取最新的数据。
// 示例中的代码片段
sqlSession.update("updateUser", updatedUser); // 数据库更新操作
sqlSession.clearCache(); // 清空一级缓存
注意：手动清空缓存可能会带来性能开销，因此需要根据具体情况权衡。
使用select标签的flushCache属性： 在执行涉及到数据变更的查询时，可以使用select标签，并设置flushCache属性为true，以在执行该查询时清空一级缓存。

<select id="getUser" parameterType="int" resultType="User" flushCache="true">
    SELECT * FROM users WHERE id = #{id}
</select>
这样，在执行带有flushCache="true"的查询时，MyBatis会在执行前清空一级缓存。
需要根据具体的业务需求和性能要求，选择合适的策略。手动清空缓存是一种可行的方式，但需要注意潜在的性能开销。使用flushCache属性是更细粒度的控制方式，可以根据具体的查询需求来决定是否清空缓存。

MyBatis 中的默认行为是，对于涉及数据更新、插入、删除等操作的方法，默认会清空一级缓存。这确保了在同一个 SqlSession 中，后续的查询操作可以从数据库中获取最新的数据。

在 MyBatis 中，例如执行 updateById 方法后，默认会清空一级缓存。如果你的应用使用了一级缓存，并在同一个 SqlSession 中执行了更新操作，后续的查询会重新从数据库中加载数据，而不是从缓存中获取。

请注意，这仅适用于一级缓存。对于二级缓存，情况会略有不同，需要根据配置和具体的 Mapper 来决定是否清空二级缓存。

如果你的场景不需要清空一级缓存，或者想要更精细地控制缓存的清空行为，可以使用 @Options 注解或在 XML 配置文件中配置 flushCache 选项，具体根据业务需求来调整。

mysql以及sql查询优化

mysql底层有哪些锁，应用场景都有哪些

MySQL在底层实现了多种类型的锁，这些锁在处理并发访问时起着关键的作用。以下是MySQL中常见的锁及其应用场景：

共享锁（Shared Locks）：

类型： 共享锁是一种读锁，多个事务可以同时持有共享锁。
应用场景： 当一个事务需要读取数据时，可以使用共享锁。多个事务可以同时持有共享锁，不会互相阻塞。适用于读多写少的场景。

排它锁（Exclusive Locks）：

类型： 排它锁是一种写锁，一个事务持有排它锁时，其他事务不能同时持有共享锁或排它锁。
应用场景： 当一个事务需要修改数据时，可以使用排它锁。排它锁确保在任何时候只有一个事务能够修改数据，防止并发写冲突。

行级锁（Row-level Locks）：

类型： 行级锁是对表中某一行或某些行进行锁定，而不是整个表。
应用场景： 当并发事务只需要锁定部分数据行时，可以使用行级锁。这有助于提高并发性，减小锁的粒度，减少锁冲突的可能性。

表级锁（Table-level Locks）：

类型： 表级锁是对整个表进行锁定。
应用场景： 在一些特定情况下，可能需要对整个表进行锁定，例如对表进行结构修改（ALTER TABLE）时。但是表级锁可能导致并发性较差，应慎重使用。

意向共享锁（Intention Shared Locks）和意向排它锁（Intention Exclusive Locks）：

类型： 这些锁并不直接在行或表上加锁，而是在事务级别上表示意向，用于协调多个事务的行级锁和表级锁。
应用场景： 在获取行级锁或表级锁之前，事务通常会先获取相应的意向锁，以表示其对资源的意向，避免死锁等问题。

总体而言，合理的锁的选择和使用，根据具体的业务需求和并发访问模式，有助于提高数据库的性能和并发控制。在设计数据库和应用程序时，需要综合考虑事务的隔离级别、锁的粒度以及锁的使用方式，以最大程度地保持数据的一致性和避免性能问题。

行锁怎么去设置，并且有哪些注意事项

在MySQL中，行级锁是通过事务中的SELECT、UPDATE、DELETE等语句的FOR UPDATE或FOR SHARE子句来设置的。这些子句用于在事务中明确指定对数据行的锁定方式。

1. 读锁 - FOR SHARE：
SELECT * FROM your_table_name WHERE your_condition FOR SHARE;
上述语句将在事务中为匹配条件的行设置共享锁。其他事务也可以获取相同的共享锁，而且这些事务之间不会发生冲突。适用于读多写少的场景。

2. 写锁 - FOR UPDATE：
SELECT * FROM your_table_name WHERE your_condition FOR UPDATE;
上述语句将在事务中为匹配条件的行设置排它锁，确保在事务中只有一个事务能够对这些行进行修改。适用于需要修改数据的场景。

如果使用的是框架，例如mybatis
import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import org.apache.ibatis.annotations.Mapper;
import org.apache.ibatis.annotations.Select;

@Mapper
public interface YourMapper extends BaseMapper<YourEntity> {

    @Select("SELECT * FROM your_table_name WHERE id = #{id} FOR UPDATE")
    YourEntity selectForUpdateById(Long id);

    // 其他方法...
}
3. 事务中的锁释放：

在使用行级锁的事务中，锁是在事务提交或回滚时释放的。如果事务成功提交，那么行级锁将被释放，允许其他事务继续操作这些行。如果事务回滚，那么行级锁也会被释放，恢复到事务开始前的状态。

4. 避免死锁：

在使用行级锁时，要注意避免死锁的情况。为了减少死锁的可能性，可以按照相同的顺序获取行锁，或者尽量减小事务中持有锁的时间。

示例：
-- 避免死锁的示例
-- 事务1
START TRANSACTION;
SELECT * FROM your_table_name WHERE id = 1 FOR UPDATE;

-- 事务2
START TRANSACTION;
SELECT * FROM your_table_name WHERE id = 2 FOR UPDATE;

-- 避免死锁的方式是按照相同的顺序获取锁
-- 例如，将两个事务中的SELECT语句按照id的顺序执行
需要注意，使用行级锁需要考虑业务的并发情况，谨慎选择合适的锁定策略。在设计数据库时，也可以考虑合适的索引来提高行级锁的性能。

行锁设置了之后怎么去释放

在MySQL中，行级锁是在事务提交或回滚时自动释放的。因此，一旦事务执行了 COMMIT 或 ROLLBACK 操作，MySQL 将会释放该事务持有的行级锁。

以下是释放行级锁的一些示例情况：
事务提交：
START TRANSACTION;

-- 一些操作，例如 SELECT ... FOR UPDATE、UPDATE、DELETE 等

COMMIT;
在上述例子中，当事务执行 COMMIT 操作时，持有的行级锁将会被释放。
事务回滚：
START TRANSACTION;

-- 一些操作，例如 SELECT ... FOR UPDATE、UPDATE、DELETE 等

ROLLBACK;
如果事务发生错误或者执行 ROLLBACK 操作，持有的行级锁也会被释放。
会话结束： 如果一个数据库会话（session）关闭或结束，该会话持有的行级锁也会被释放。这包括正常关闭连接、异常终止连接等情况。
需要注意的是，行级锁的释放是隐式的，不需要显式地执行解锁操作。MySQL会在事务提交或回滚时自动处理。

确保在使用行级锁时，你的事务逻辑是正确的，并在合适的地方执行 COMMIT 或 ROLLBACK 操作，以及在发生异常时处理回滚。这有助于确保锁的正确释放，避免可能的死锁和性能问题。

mysql索引和性能调优

索引的类型和具体的使用场景有哪些

在数据库中，常见的索引类型包括主键索引、唯一索引、普通索引、全文索引等。不同类型的索引适用于不同的使用场景。以下是一些常见的索引类型及其使用场景：

1. 主键索引（Primary Key Index）：

类型： 主键索引是唯一性索引的特例，用于唯一标识表中的每一行。
使用场景： 主键索引适用于经常用于标识和检索唯一行的列，通常是表的主键列。主键索引通常会在创建表时自动生成。

2. 唯一索引（Unique Index）：

类型： 唯一索引确保列中的所有值都是唯一的。
使用场景： 适用于经常需要进行唯一性检查的列，如用户名、电子邮件等。避免重复值的插入和提高查询性能。

3. 普通索引（Non-Unique Index）：

类型： 普通索引用于提高查询性能，但允许列中有重复的值。
使用场景： 适用于经常用于查询条件的列，以提高检索速度。例如，经常用于WHERE子句的列。

4. 联合索引（Composite Index）：

类型： 联合索引涉及多个列，可以包含多个列的组合。
使用场景： 适用于经常以多个列作为查询条件的情况。但要注意，联合索引的顺序非常重要，因为数据库查询优化器通常只能使用索引的前缀部分。

5. 全文索引（Full-Text Index）：

类型： 全文索引用于对文本数据进行全文本搜索。
使用场景： 适用于包含大量文本数据（如文章、评论）的列，可以进行全文本搜索和匹配。不同数据库系统的实现方式可能有所不同。

6. 空间索引（Spatial Index）：

类型： 空间索引用于对空间数据（如地理信息、几何图形）进行高效检索。
使用场景： 适用于包含空间数据的列，如地理坐标、区域等。

7. 覆盖索引（Covering Index）：

类型： 覆盖索引包含了所有查询所需的数据，无需回表到数据表。
使用场景： 适用于经常进行查询的列，尤其是对大表的查询，可以减少IO操作，提高查询性能。

8. 前缀索引（Prefix Index）：

类型： 前缀索引只索引列值的一部分。
使用场景： 适用于某些大文本列，只需索引文本的一部分，以减小索引的大小。

9. 哈希索引（Hash Index）：

类型： 哈希索引使用哈希算法存储键值对。
使用场景： 适用于等值查询，但不适用于范围查询。常见于一些内存数据库。

注意事项：

每种索引类型都有其优劣和适用场景，选择索引类型时要考虑实际业务需求和查询模式。
索引的维护会增加写入操作的成本，因此过多或不必要的索引可能导致性能问题。
监控和定期维护索引是保持数据库性能的关键一环。

在设计数据库时，根据具体的业务需求和查询模式选择合适的索引类型，有助于提高查询性能和减少IO操作。

建立索引应该遵守的规则

建立索引是数据库性能优化的关键一环，但同时要注意一些规则和最佳实践，以确保索引的有效性和性能提升。以下是一些建立索引时应该遵守的规则：

1. 选择适当的列：

索引的选择应该基于查询的需求。通常，经常用于查询条件和连接操作的列是优先选择的。

2. 选择唯一性高的列：

对于具有高选择性的列，即不同值的数量较大的列，建立索引更为有效。例如，主键、唯一键等。

3. 考虑查询频率：

经常用于查询的列是建立索引的理想选择。避免为很少被查询的列建立索引，因为它可能导致索引的维护成本高于性能提升。

4. 避免过多的索引：

不是所有的列都需要建立索引。过多的索引可能导致性能下降，因为每个索引都需要额外的存储空间和维护成本。

5. 选择合适的索引类型：

根据查询模式选择合适的索引类型，如普通索引、唯一索引、全文索引等。

6. 联合索引的顺序：

联合索引的顺序非常重要。确保联合索引的顺序与查询条件的顺序匹配，以提高性能。

7. 小心使用全文索引：

全文索引适用于对文本数据进行搜索，但并不是所有场景都适用。在大型表上使用全文索引可能会带来性能问题。

8. 不要在短小的表上建立索引：

对于非常小的表，全表扫描可能比使用索引更为高效。在这种情况下，建立索引可能会增加维护成本而带来较小的性能提升。

9. 定期维护和优化索引：

索引的性能可能随着数据的变化而变化。定期维护索引，重新组织或重建索引，以保持其效率。

10. 了解查询优化器的行为：

不同的数据库系统使用不同的查询优化器，了解优化器的行为有助于更好地设计索引。

11. 谨慎使用索引提示：

使用索引提示（Index Hints）时要小心，因为过度使用可能导致不稳定的查询计划。通常应该依赖优化器选择合适的索引。

12. 测试和监控性能：

在生产环境之前测试索引的性能，监控数据库的性能并及时调整索引策略。

建立索引是一个复杂的任务，需要在实践中根据具体业务场景和查询模式进行调整。最佳实践可能因数据库系统的不同而有所变化，因此建议在具体数据库环境中进行性能测试和优化。

导致索引失效的原因有哪些

索引失效通常是由于查询条件、表设计、SQL语句书写等多种因素造成的。以下是一些导致索引失效的常见原因：

未使用索引列进行检索：

如果查询条件中的列没有被索引，数据库无法使用索引来加速查询。
解决方法： 确保查询条件中的列包含在相应的索引中。

使用了函数或运算符：

当在查询条件中使用了函数或运算符时，数据库可能无法使用索引。
解决方法： 尽量避免在索引列上使用函数或运算符，或者考虑创建函数索引。

类型不匹配：

查询条件中使用了与索引列不同类型的值，导致无法使用索引。
解决方法： 确保查询条件的数据类型与索引列的数据类型匹配。

使用NOT操作：

在查询条件中使用了NOT操作，这可能导致索引失效。
解决方法： 尽量避免使用NOT操作，或者考虑通过其他手段优化查询。

模糊查询（LIKE '%...%')：

对于模糊查询中以通配符开头的情况（比如LIKE '%abc'），索引可能无法有效使用。
解决方法： 尽量避免在查询条件中使用以通配符开头的模糊查询，或者考虑使用全文索引等技术。

数据分布不均匀：

如果索引列上的数据分布不均匀，可能导致查询优化器选择不使用索引。
解决方法： 优化表的统计信息，确保数据分布均匀。

索引失效的阈值：

当表的数据量很小，全表扫描可能比使用索引更快，因此查询优化器可能选择不使用索引。
解决方法： 在实际生产环境中测试查询性能，评估是否使用索引更为有效。

查询优化器选择全表扫描：

查询优化器可能因为统计信息不准确或其他原因，选择全表扫描而不是使用索引。
解决方法： 更新统计信息，尽量让优化器做出更合理的执行计划。

多表连接时的索引选择：

当多个表连接时，查询优化器可能无法有效选择适当的索引，导致失效。
解决方法： 确保连接条件的列上有适当的索引，并考虑调整SQL语句或索引设计。

索引选择性过低：

索引选择性指的是索引中不同值的数量与表中行数的比率。如果选择性过低，数据库可能不会使用索引。
解决方法： 创建更具选择性的索引，以提高索引的效果。

在设计数据库和编写SQL查询时，综合考虑这些因素，可以帮助避免或减少索引失效的问题。使用数据库性能分析工具，例如EXPLAIN命令，可以帮助你理解和优化查询计划。

回表是什么意思，什么情况下会造成回表

回表（Lookup）是指当数据库引擎使用索引来执行查询，但在索引中找到了满足条件的记录后，仍然需要回到原始数据表中检索其他未包含在索引中的列的过程。这个操作通常是因为索引本身并没有包含所有查询所需的列，所以需要从数据表中获取缺失的列信息。

回表通常会增加I/O操作和查询的开销，因为需要额外的步骤去检索未包含在索引中的列。这一过程可能导致性能下降，特别是在大型表或复杂查询的情况下。

造成回表的情况包括但不限于：
SELECT语句中查询的列不在索引中：
如果你的查询需要返回的列不在索引中，数据库引擎将不得不回表来获取这些列的数据。
-- 假设有一个包含 id 和 name 列的表，其中 id 列上有索引
SELECT name FROM your_table WHERE id = 1;
在这个例子中，如果 id 列上有索引，但查询的是 name 列，就会触发回表操作。
使用了函数或表达式：
当查询中使用了函数、运算符或其他表达式，而这些表达式并不在索引中，就可能导致回表。
-- 假设有一个包含 id 和 timestamp 列的表，其中 id 列上有索引
SELECT MAX(timestamp) FROM your_table WHERE id = 1;
在这个例子中，如果需要获取最大的 timestamp，但索引只包含 id 列，就可能触发回表操作。
使用了不可覆盖的索引：
如果查询使用的是不可覆盖的索引，即索引上包含的列不足以满足查询的所有需求，就可能触发回表。
-- 假设有一个包含 id、name 和 age 列的表，其中 id 列上有索引
SELECT name, age FROM your_table WHERE id = 1;
在这个例子中，如果索引只包含 id 列，而查询需要返回 name 和 age 列，就可能触发回表操作。
避免回表的方法包括：

使用覆盖索引（Covering Index）： 尽量保证索引上包含查询中需要的所有列，这样就能够通过索引直接满足查询的需求，而不需要回表。

优化查询语句： 考虑是否可以调整查询语句，使得所需的列在索引中都有覆盖，从而减少回表的需要。

考虑合适的索引策略： 避免创建过多或不必要的索引，根据实际查询需求和数据分布情况来选择创建合适的索引。

在数据库性能优化的过程中，了解回表的概念并合理设计索引是非常重要的。

redis的优势和用法

Redis（Remote Dictionary Server）是一种基于内存的高性能键值存储系统，它具有以下优势，适用于许多不同的使用场景：

优势：

高性能：

Redis的数据存储在内存中，读写速度非常快，适用于需要低延迟的应用场景。

支持丰富的数据结构：

Redis支持多种丰富的数据结构，包括字符串、哈希表、列表、集合、有序集合等，使得它非常灵活，能够适应不同类型的数据存储需求。

持久化支持：

Redis支持数据持久化，可以将数据保存在磁盘上，确保在重启时数据不会丢失。

复制和高可用：

Redis支持主从复制机制，可以配置多个节点，实现数据的备份和高可用性。

原子性操作：

Redis提供原子性操作，支持事务和各种原子性指令，保证操作的一致性。

丰富的客户端支持：

Redis拥有丰富的官方和第三方客户端库，支持多种编程语言，方便开发者使用。

适用场景：

缓存：

Redis经常被用作缓存层，存储频繁访问的数据，以提高读取性能。

会话存储：

用于存储用户会话信息，实现分布式会话管理。

计数器：

适用于实时计数场景，如网站的点赞数、在线人数等。

队列系统：

通过列表结构，实现高性能的消息队列系统。

发布/订阅系统：

通过发布/订阅功能，实现实时消息推送。

分布式锁：

通过Redis的原子性操作，可以实现分布式锁，确保操作的原子性。

Redis数据类型和用法：

字符串（String）：

存储字符串类型的数据，适用于缓存、计数器等场景。

哈希表（Hash）：

存储字段-值对，适用于存储对象信息。

列表（List）：

双向链表结构，适用于实现消息队列。

集合（Set）：

无序、唯一的元素集合，适用于存储不重复的数据。

有序集合（Sorted Set）：

与集合类似，但每个元素关联一个分数，适用于需要排序的场景，如排行榜。

Redis与关系型数据库结合：

缓存数据库查询结果：

将热点数据缓存到Redis中，减轻关系型数据库的压力。

实现分布式锁：

利用Redis的原子性操作，可以实现分布式锁，防止多个实例同时操作某个资源。

实时计数器：

用于实时统计信息，如网站访问次数、点赞数等。

消息队列：

利用Redis的列表结构，实现简单的消息队列，异步处理任务。

会话管理：

将用户会话信息存储在Redis中，实现分布式会话管理。

在结合关系型数据库时，需要谨慎考虑数据的一致性和同步问题。一般情况下，Redis用于读密集型的场景，而关系型数据库用于写入和持久化。使用缓存时，要考虑缓存过期策略，以确保数据的实时性。此外，采用合适的持久化方式，如RDB快照、AOF日志等，以防止数据丢失。

redis怎么实现消息队列

在Spring Boot中，你可以使用Redis实现简单的消息队列。以下是一个基本的Spring Boot项目结合Redis实现消息队列的实例：

首先，确保在pom.xml中引入了Spring Boot和Jedis的依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
</dependency>


<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>


<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
</dependency>
接下来，创建一个简单的消息队列服务：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;

@Service
public class MessageQueueService {

    private final StringRedisTemplate redisTemplate;

    @Autowired
    public MessageQueueService(StringRedisTemplate redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void publishMessage(String channel, String message) {
        redisTemplate.convertAndSend(channel, message);
    }
}
在这个服务中，publishMessage方法使用StringRedisTemplate向指定的频道发布消息。

然后，创建一个订阅者，监听消息：
import org.springframework.data.redis.connection.Message;
import org.springframework.data.redis.connection.MessageListener;
import org.springframework.stereotype.Component;

@Component
public class MessageSubscriber implements MessageListener {

    @Override
    public void onMessage(Message message, byte[] pattern) {
        String channel = new String(message.getChannel());
        String payload = new String(message.getBody());

        System.out.println("Received message from channel " + channel + ": " + payload);
    }
}
上述的MessageSubscriber类实现了MessageListener接口，通过重写onMessage方法来处理接收到的消息。

最后，在Spring Boot应用的主类或配置类中，配置Redis消息监听器：
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.listener.ChannelTopic;
import org.springframework.data.redis.listener.RedisMessageListenerContainer;

@Configuration
public class RedisConfig {

    @Bean
    public RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory,
                                                   MessageSubscriber messageSubscriber) {
        RedisMessageListenerContainer container = new RedisMessageListenerContainer();
        container.setConnectionFactory(connectionFactory);
        container.addMessageListener(messageSubscriber, new ChannelTopic("channel-1"));
        return container;
    }
}
在这个配置类中，创建了一个RedisMessageListenerContainer，并将MessageSubscriber注册到名为"channel-1"的频道上。

现在，你可以在其他服务或控制器中注入MessageQueueService，使用publishMessage方法发布消息，而MessageSubscriber会监听并处理这些消息。

这是一个简单的示例，实际中你可能需要更多的错误处理、消息确认机制等。此外，注意Redis的发布-订阅模式是异步的，发布者发布消息后，订阅者可能不会立即收到消息。

redis的分布式锁怎么用

在Spring Boot中使用Redis的分布式锁可以通过两种方式：使用Spring Data Redis提供的RedisTemplate和使用第三方库Redisson。下面分别介绍这两种方式的简单实现。

使用RedisTemplate：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.data.redis.core.script.RedisScript;
import org.springframework.stereotype.Service;

import java.util.Collections;
import java.util.UUID;
import java.util.concurrent.TimeUnit;

@Service
public class RedisLockService {

    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    public boolean tryLock(String lockKey, String clientId, long expireTime) {
        String lockValue = UUID.randomUUID().toString();
        Boolean result = redisTemplate.opsForValue().setIfAbsent(lockKey, lockValue, expireTime, TimeUnit.MILLISECONDS);
        return result != null && result;
    }

    public boolean releaseLock(String lockKey, String clientId) {
        RedisScript<Long> script = new DefaultRedisScript<>(
                "if redis.call('get', KEYS[1]) == ARGV[1] then " +
                        "return redis.call('del', KEYS[1]) " +
                        "else " +
                        "return 0 " +
                        "end",
                Long.class
        );

        Long result = redisTemplate.execute(script, Collections.singletonList(lockKey), clientId);
        return result != null && result == 1;
    }
}

在上述示例中，tryLock方法尝试获取锁，releaseLock方法释放锁。这里使用了setIfAbsent原子操作来实现尝试获取锁，使用Lua脚本来保证释放锁的原子性。

使用Redisson：

首先，添加Redisson的依赖：

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.16.0</version>
</dependency>

然后，创建一个Redisson配置类：

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379");
        return Redisson.create(config);
    }
}

接下来，使用Redisson的分布式锁：

import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

@Service
public class RedissonLockService {

    @Autowired
    private RedissonClient redissonClient;

    public boolean tryLock(String lockKey, long expireTime) {
        RLock lock = redissonClient.getLock(lockKey);
        try {
            return lock.tryLock(expireTime, TimeUnit.MILLISECONDS);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return false;
        }
    }

    public void releaseLock(String lockKey) {
        RLock lock = redissonClient.getLock(lockKey);
        lock.unlock();
    }
}

在上述示例中，tryLock方法尝试获取锁，releaseLock方法释放锁。Redisson提供了丰富的分布式锁的实现，包括可重入锁、公平锁、读写锁等。

以上两种方式都可以根据业务需求和实际情况进行选择，使用Spring Data Redis的RedisTemplate需要自己处理锁的原子性，而使用Redisson可以方便地使用各种类型的分布式锁。

mysql中的多表关联查询怎么优化，如果不使用关联查询有没有想过其他的方式去处理

使用子查询：

将关联查询拆分成多个子查询，分步执行
SELECT * FROM table1 WHERE id IN (SELECT table1_id FROM table2 WHERE condition);
使用临时表：

将关联查询的结果存储在临时表中，然后在临时表上进行进一步的查询
CREATE TEMPORARY TABLE temp_table AS SELECT * FROM table1 JOIN table2 ON condition;
SELECT * FROM temp_table WHERE condition;
使用存储过程：

将关联查询的逻辑封装在存储过程中，减少客户端和数据库之间的数据传输。

选择MyBatis的理由：

a. 灵活的SQL控制：

MyBatis提供了直接编写SQL语句的能力，可以更精确地控制执行计划。

b. 轻量级框架：

MyBatis是一个轻量级的持久层框架，相对于Hibernate来说，学习曲线较低，更容易上手。

c. 易于集成：

MyBatis可以与各种数据源集成，配置简单，适用于不同的项目需求。

d. 直观的XML映射：

MyBatis使用XML文件配置数据映射，使得数据映射关系直观易懂。

e. 自由度高：

MyBatis提供了很高的自由度，开发者可以根据需要自由地编写SQL语句，更容易做到定制化。

为什么选择MyBatis而不是Hibernate：

a.控制SQL执行计划：

MyBatis允许开发者直接编写SQL语句，可以更精确地控制SQL执行计划，适用于需要优化的场景。

b. 轻量级和简单性：

对于一些简单的项目或者对ORM不依赖过多的场景，MyBatis更轻量、简单，学习成本较低。

c. 灵活性：

MyBatis提供更大的灵活性，可以根据实际需求自由地编写SQL语句，适用于一些需要定制化的场景。

d. 对SQL更直观的控制：

Hibernate是一个全自动的ORM框架，对于某些对SQL控制要求较高的场景，MyBatis提供了更直观的控制方式。

总体而言，选择MyBatis还是Hibernate取决于项目的需求和开发团队的偏好。MyBatis适用于那些需要更直接控制SQL、轻量级、简单易学的场景。

为什么tcp建立连接需要三次握手，断开连接需要四次握手

三次握手

三次握手的目的，是为了防止A端已经失效的连接请求突然又传到B端，被误认为是A端再次发出的一个新的连接请求，如果B端这时又再次向A发出确认报文，表示同意建立连接，就会产生错误。

第一次是A端向B端发送请求，如果是只有一次握手的话，A端不知道B端是不是收到了这个请求。

第二次是B端确认收到A端请求，如果只有两次的话，B端不确定A端是否收到了确认消息，这个确认消息有可能会在半路丢了。

第三次是A端确认收到了B的确认消息，A和B双方都是通的，然后AB就可以建立连接相互通信了。

四次挥手

四次挥手的本质原因是tcp是全双公的，通信是双向的， A到B是一个通道，B到A又是另一个通道。

A端确认没有数据发送后，发出结束报文，此时B端返回确认后，B端也不会接收A端数据。

但是此时B端可能还有数据没有传输完，A端还是可以接收数据。

只有当B端数据发送完之后，才能发出结束报文，并且确认A端接收到的时候，两边才会真正的断开连接，双方的读写分开。