4，1025 面试题目汇总

1，快排，冒泡，插入

    java 常用排序算法

2， mysql 三大日志打印顺序？

     mysql 三大日志分别是  redolog(重做日志)  undolog（回滚日志）binlog(二进制日志）打印顺序如下：
1，首先，当事务开始对数据进行修改时，会将修改前的数据写入undolog 回滚日志，这样可以在事务需要回滚时，能够根据undolog 恢复到事务开始前的状态。

   2，接着  每堆数据进行一次修改，就会产生一条 redo log 重做日志 记录并写入redo log buffer  从做日志缓冲区， 当满足一定条件时刷新到磁盘上的redo log 文件中。

   3，最后， 当事务提交时， 会将事务的修改记录以二进制的形式写入binlog 文件中，binlog z主要用于数据备份和主从复制等场景。

日志详解

一、redo log（重做日志）

1. 作用：

   • 确保事务的持久性。当数据库发生故障时，通过 redo log 可以恢复未写入数据文件但已经提交的事务。
   • 在事务执行过程中，会先将数据的修改写入 redo log，然后再适时地将修改持久化到数据文件中。

2. 写入过程：

   • 事务在执行过程中，每对数据进行一次修改，就会产生一条 redo log 记录，这些记录会先写入到 redo log buffer（重做日志缓冲区）中。
   • 当满足一定条件时（如 redo log buffer 写满、事务提交等），会将 redo log buffer 中的内容刷新到磁盘上的 redo log 文件中。

二、undo log（回滚日志）

1. 作用：

   • 实现事务的原子性。当事务回滚时，通过 undo log 可以将数据恢复到事务开始之前的状态。
   • 为 MVCC（多版本并发控制）提供支持，通过保存数据的历史版本，实现不同事务对同一数据的并发访问。

2. 写入过程：

   • 在事务对数据进行修改之前，会先将修改前的数据写入 undo log 中。
   • 当事务需要回滚时，可以根据 undo log 中的记录将数据恢复到事务开始之前的状态。

三、binlog（二进制日志）

1. 作用：

   • 用于数据备份和恢复。可以通过 binlog 对数据库进行增量备份，在需要恢复数据时，可以根据 binlog 中的记录进行恢复。
   • 主从复制。在主从复制架构中，主数据库将事务的修改记录写入 binlog，从数据库通过读取主数据库的 binlog 并执行其中的事务，实现数据的同步。

2. 写入过程：

   • 事务提交时，会将事务的修改记录以二进制的形式写入 binlog 文件中。
   • 从数据库通过连接主数据库并读取其 binlog 文件，然后在本地执行相同的事务，实现数据同步。  

3,   进行数据同步为什么监听binlog?

在 MySQL 中进行数据同步时监听二进制日志（binlog）主要有以下几个重要原因：

一、记录数据库更改

1. 全面记录：

   • Binlog 记录了数据库中所有的更改操作，包括数据的插入、更新、删除，以及数据库结构的更改等。这使得在进行数据同步时，可以准确地了解数据库中发生的所有变化。
   • 例如，当一个事务对表中的数据进行修改并提交时，这些修改操作会被记录到 binlog 中。这样，无论是在主从复制还是其他数据同步场景中，都可以通过读取 binlog 来获取这些更改信息。

2. 顺序性：

   • Binlog 中的操作是按照时间顺序记录的，这对于保证数据同步的顺序性非常重要。在数据同步过程中，必须按照相同的顺序应用这些更改，以确保数据的一致性。
   • 例如，在主从复制中，从服务器按照 binlog 中的顺序依次应用主服务器上的更改操作，从而保证从服务器上的数据与主服务器保持一致。

二、实现主从复制

1. 主服务器写入 binlog：

   • 在主从复制架构中，主服务器将所有的数据库更改操作写入 binlog。从服务器通过连接到主服务器并读取 binlog，获取这些更改信息。
   • 主服务器在执行每个事务时，会将事务的更改记录到 binlog 中，并为每个事务分配一个唯一的序列号。从服务器根据这个序列号来确定事务的执行顺序。

2. 从服务器应用更改：

   • 从服务器读取主服务器的 binlog，并将其中的更改操作应用到自己的数据库中。从服务器可以通过多种方式读取 binlog，如使用 MySQL 内置的复制功能或第三方工具。
   • 从服务器在应用更改时，会按照 binlog 中的顺序依次执行每个事务，确保数据的一致性。如果从服务器在应用某个事务时出现错误，它可以停止复制并等待管理员进行故障排除。

三、支持多种数据同步场景

1. 数据库备份和恢复：

   • Binlog 可以用于数据库的备份和恢复。通过定期备份 binlog，可以在数据库发生故障时，使用备份的 binlog 来恢复数据库到故障发生前的状态。
   • 例如，在进行数据库备份时，可以同时备份数据库的数据文件和 binlog。在恢复数据库时，首先恢复数据文件，然后应用备份的 binlog 中的更改操作，以恢复数据库到最新的状态。

2. 数据迁移和同步：

   • 在数据迁移和同步场景中，binlog 可以用于将数据从一个数据库服务器同步到另一个数据库服务器。可以使用工具读取源数据库的 binlog，并将其中的更改操作应用到目标数据库中。
   • 例如，当需要将数据从一个旧的数据库服务器迁移到一个新的服务器时，可以使用 binlog 来实现数据的同步。这样可以确保在迁移过程中，数据的一致性和完整性得到保证。

四、可扩展性和灵活性

1. 支持多种同步方式：

   • Binlog 可以通过多种方式进行读取和应用，这使得它在不同的数据同步场景中具有很高的可扩展性和灵活性。可以使用 MySQL 内置的复制功能、第三方工具或自定义脚本进行数据同步。
   • 例如，可以使用 MySQL 的主从复制功能来实现简单的数据同步，也可以使用第三方工具如 Canal 来实现更复杂的数据同步场景，如将 MySQL 数据同步到其他数据库或消息队列中。

2. 易于配置和管理：

   • Binlog 的配置和管理相对简单，可以通过修改 MySQL 的配置文件来控制 binlog 的记录方式和存储位置。同时，MySQL 提供了一些工具和命令来查看和管理 binlog，方便管理员进行数据同步和故障排除。
   • 例如，可以使用 SHOW BINARY LOGS 命令查看当前服务器上的所有 binlog 文件，使用 PURGE BINARY LOGS 命令删除过期的 binlog 文件，以释放磁盘空间。

4， 二叉树 平衡二叉树，红黑树图的区别， 查询插入速度

1,二叉树：

二叉树是每个节点最多有两个子树的结构。通常字数被称作“左子树” left subtree和右子树 right suntree 

特点： 结构简单，易于实现
没有特定的平衡要求，可能会出现高度不平衡的情况，导致某些操作的时间复杂度变差

2，平衡二叉树： 

 平衡二叉树是一棵空树或它的左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树。

特点：

• 保持平衡的结构，使得查找、插入和删除操作的时间复杂度始终保持在 O (log n)。
• 需要在插入和删除节点时进行平衡调整操作，以确保树的平衡性质。
• 常见的平衡二叉树有 AVL 树等。

3，红黑数图

1. 定义：

   • 红黑树是一种自平衡的二叉查找树，它在每个节点上增加了一个颜色属性（红色或黑色），并通过特定的规则来保持树的平衡。

2. 特点：

   • 也是一种平衡树，但与平衡二叉树相比，红黑树的平衡要求相对较弱。
   • 插入和删除节点时的平衡调整操作相对较少，因此在频繁进行插入和删除操作时性能较好。
   • 规则包括：节点是红色或黑色；根节点是黑色；每个叶子节点（NIL 节点，空节点）是黑色；如果一个节点是红色，则它的两个子节点都是黑色；从任一节点到其每个叶子的所有简单路径都包含相同数目的黑色节点。

5，B树 ，B+树 区别

---

一、结构上的区别

1. B 树：

   • 每个节点可以存储多个关键字和对应的记录指针。
   • 节点内的关键字是有序排列的，并且节点之间通过指针相互连接。
   • 非叶节点的关键字个数 n 满足：ceil (m/2)-1 <= n <= m-1，其中 m 是树的阶数。
   • 所有叶子节点都在同一层上，即具有相同的深度。

2. B + 树：

   • 与 B 树类似，每个节点也可以存储多个关键字和对应的记录指针。
   • 非叶节点只存储关键字信息，不存储具体的记录指针，记录指针只存在于叶子节点中。
   • 叶子节点之间通过指针形成链表，便于进行范围查询。
   • 非叶节点的关键字个数 n 满足：ceil (m/2) <= n <= m，其中 m 是树的阶数。

二、操作上的区别

1. 查找操作：

   • B 树：从根节点开始，根据要查找的关键字与节点中的关键字进行比较，确定进入哪个子节点继续查找。如果在叶子节点中找到了目标关键字，则返回对应的记录指针；如果没有找到，则查找失败。
   • B + 树：查找过程与 B 树类似，但最终在叶子节点中找到目标关键字后，由于叶子节点之间有链表连接，可以方便地进行范围查询。

2. 插入操作：

   • B 树：当插入一个新关键字时，如果节点中的关键字个数超过了上限，则需要进行分裂操作。将中间的关键字提升到父节点中，左右两部分分别成为新的子节点。
   • B + 树：插入过程与 B 树类似，但由于非叶节点不存储记录指针，所以插入操作相对简单一些。当叶子节点中的关键字个数超过上限时，进行分裂操作，并将中间的关键字提升到父节点中。

3. 删除操作：

   • B 树：当删除一个关键字时，如果节点中的关键字个数小于下限，则需要进行合并操作。将相邻的两个节点合并成一个节点，并调整父节点中的关键字。
   • B + 树：删除过程与 B 树类似，但需要注意保持叶子节点之间的链表完整性。

三、应用场景上的区别

1. B 树：

   • 适用于文件系统和数据库索引，尤其是对于随机访问和插入、删除操作比较频繁的场景。
   • 由于节点中存储了记录指针，可以直接访问数据，所以对于单个关键字的查询效率较高。

2. B + 树：

• 更适合用于数据库索引，特别是对于范围查询和顺序访问比较频繁的场景。
• 叶子节点之间的链表连接使得范围查询更加高效，并且可以通过遍历链表来进行顺序访问。

4. 为什么mysql 使用B+树 而不是B树

5. 磁盘 I/O 效率：

   • B + 树的非叶子节点只存储关键字信息，不存储实际的数据记录指针。这样可以使非叶子节点存储更多的关键字，树的高度更低。在进行数据检索时，B + 树需要的磁盘 I/O 次数更少，提高了数据检索的效率。
   • 例如，对于一个较大的数据库表，如果使用 B 树，可能需要多次从磁盘读取节点才能找到目标数据；而使用 B + 树，由于树的高度较低，可能只需要较少的磁盘 I/O 次数就能找到目标数据。

6. 范围查询性能：

   • B + 树的叶子节点之间通过指针形成链表，这使得范围查询非常高效。可以通过遍历叶子节点链表快速获取满足条件的连续数据记录。
   • 例如，在查询某个范围内的记录时，B + 树可以直接从叶子节点链表的起始位置开始遍历，直到找到满足条件的最后一个记录，而 B 树则需要在不同的节点之间跳转，效率较低。

7. 数据存储稳定性：

   • B + 树的所有数据记录都存储在叶子节点中，并且叶子节点之间通过链表连接，这使得数据存储更加稳定。在进行插入、删除操作时，对树的结构调整主要集中在叶子节点上，不会像 B 树那样频繁地影响非叶子节点。
   • 例如，当进行插入操作时，如果导致叶子节点分裂，只会影响到相邻的叶子节点，而不会影响到非叶子节点的结构。

6，redis 缓存 主从同步问题

Redis 的主从同步是实现高可用和数据备份的重要机制，但在实际应用中可能会遇到一些问题。以下是一些常见的主从同步问题及解决方案：

一、主从数据不一致

1. 原因：

   • 网络延迟：主从节点之间的网络延迟可能导致数据同步不及时，从而出现数据不一致的情况。
   • 命令丢失：在主节点执行写操作后，如果在同步到从节点之前主节点发生故障，可能会导致部分命令丢失，从而造成数据不一致。
   • 从节点故障：如果从节点在同步过程中发生故障，重新启动后可能无法完全恢复到与主节点一致的状态。

2. 解决方案：

   • 优化网络环境：尽量减少主从节点之间的网络延迟，可以通过部署在同一局域网内或使用高速网络连接来实现。

   • 配置合适的复制积压缓冲区：Redis 提供了复制积压缓冲区（replication backlog），用于存储主节点最近执行的写命令。当从节点断开连接后重新连接时，可以从复制积压缓冲区中获取丢失的命令，从而保证数据的一致性。可以根据实际情况调整复制积压缓冲区的大小，以适应不同的网络环境和数据量。

   • 监控从节点状态：及时发现从节点的故障，并采取相应的措施进行恢复。可以使用 Redis 的监控工具或第三方监控软件来监控主从节点的状态。

二、主从切换问题

1. 原因：

   • 主节点故障：当主节点发生故障时，需要进行主从切换，将从节点提升为主节点。但是，在切换过程中可能会出现数据丢失或不一致的情况。
   • 切换时间过长：如果主从切换的时间过长，可能会影响系统的可用性。

2. 解决方案：

   • 使用高可用方案：可以使用 Redis Sentinel 或 Redis Cluster 等高可用方案来自动进行主从切换，减少人工干预的时间和风险。
   • 配置合理的故障转移时间：根据实际情况调整 Redis Sentinel 或 Redis Cluster 的故障转移时间，以确保在主节点故障时能够及时进行切换，同时避免频繁的切换。
   • 数据预热：在主从切换后，可以对新的主节点进行数据预热，提前加载一些常用的数据，以提高系统的响应速度。

三、主从同步性能问题

1. 原因：

   • 数据量过大：如果主节点的数据量过大，同步到从节点的时间会很长，从而影响系统的性能。
   • 网络带宽限制：主从节点之间的网络带宽可能会限制数据同步的速度。

2. 解决方案：

   • 数据分片：可以将数据分片存储在多个 Redis 实例中，减少每个实例的数据量，从而提高主从同步的性能。

   • 优化网络环境：增加主从节点之间的网络带宽，或者使用高速网络连接来提高数据同步的速度。

   • 异步复制：Redis 支持异步复制，可以在主节点执行写操作后立即返回，而不等待从节点同步完成。这样可以提高系统的响应速度，但可能会导致数据不一致的风险增加。可以根据实际情况选择合适的复制模式。

Redis 可以通过以下几种方式来保证在主从情况下，数据变更后一定能查到新数据：

一、同步机制

1. 全量同步：

   • 在从节点第一次连接到主节点时，会进行全量同步。主节点会将所有数据生成一个 RDB（Redis Database File）文件，并发送给从节点。从节点接收并加载这个 RDB 文件，从而与主节点的数据保持一致。
   • 全量同步可以确保从节点在初始状态下拥有与主节点完全相同的数据。

2. 增量同步：

   • 在全量同步完成后，主从节点之间会进行增量同步。当主节点有新的写操作时，会将这些写操作记录在复制缓冲区（replication backlog）中。
   • 从节点会不断地从主节点读取复制缓冲区中的内容，并在本地执行这些写操作，从而保持与主节点的数据同步。

二、数据持久化

1. RDB 持久化：

   • Redis 可以定期将内存中的数据生成 RDB 文件，并保存到磁盘上。在主从复制中，如果主节点发生故障，可以通过加载最新的 RDB 文件来恢复数据，并将其同步到从节点上。
   • 这样可以确保在主节点故障恢复后，从节点能够获取到最新的数据。

2. AOF（Append Only File）持久化：

   • AOF 持久化会将 Redis 执行的所有写命令记录到一个日志文件中。在主从复制中，从节点可以通过读取主节点的 AOF 文件来同步数据。
   • 如果主节点发生故障，可以使用 AOF 文件来恢复数据，并将其同步到从节点上。AOF 持久化可以提供更高的数据可靠性，但可能会对性能产生一定的影响。

三、监控和故障转移

1. Redis Sentinel：

   • Redis Sentinel 是一个高可用解决方案，它可以自动监控主节点的状态，并在主节点出现故障时进行故障转移。
   • Sentinel 会选择一个从节点提升为主节点，并通知其他从节点连接到新的主节点。这样可以确保在主节点故障时，系统能够快速恢复，并保证数据的可用性。

2. Redis Cluster：

   • Redis Cluster 是一种分布式数据库解决方案，它将数据分散存储在多个节点上，并自动进行数据的分片和复制。
   • 在 Cluster 模式下，如果某个节点出现故障，Cluster 会自动将其负责的数据迁移到其他节点上，以保证数据的可用性和一致性。

四、客户端缓存

1. 本地缓存：

   • 客户端可以在本地缓存一些经常访问的数据，以减少对 Redis 的访问次数。当数据发生变化时，客户端可以通过监听 Redis 的发布 / 订阅（pub/sub）机制或者使用 Redis 的通知（notification）功能来获取数据变更的通知，并更新本地缓存。
   • 这样可以在一定程度上提高数据的查询性能，并确保客户端能够获取到最新的数据。

2. 分布式缓存：

   • 在分布式系统中，可以使用分布式缓存来缓存 Redis 中的数据。分布式缓存可以将数据缓存在多个节点上，并通过一致性哈希等算法来保证数据的分布和一致性。
   • 当数据发生变化时，可以通过更新分布式缓存来确保客户端能够获取到最新的数据。