纪录Java秋招面经（网上找的）
1.Mysql的存储机制，怎么落到库内里的？当数据插入 MySQL 时，首先数据修改会在内存中的 Buffer Pool 中完成，同时纪录写入 Redo Log 以保证事务的持久性。事务提交时，日志会被刷入磁盘，确保数据可以恢复。修改后的数据页暂时不会立刻写入磁盘，而是由后台线程异步将内存中的脏页（已修改但未写回的数据）写入到实际的表空间文件中。这种机制进步了写入性能，同时通过 Redo Log 和数据文件的同步确保数据的划一性和持久性。
1. 存储引擎
MySQL 支持多种存储引擎，差异的存储引擎有差异的存储机制。常见的存储引擎有：
InnoDB： 默认的存储引擎，支持事务，采用行级锁定，具有瓦解恢复功能。
MyISAM： 较老的存储引擎，不支持事务和外键，采用表级锁定，查询速度快，得当只读操纵较多的应用。
2. InnoDB 存储引擎
InnoDB 是 MySQL 的默认存储引擎，它的存储机制比较复杂，涉及以下几个方面：
a. 表空间和数据文件
InnoDB 采用表空间（Tablespace）来管理数据库的数据。数据被存储在数据文件中，常见的有：
系统表空间： 这是一个共享的表空间，包罗了所有 InnoDB 表和索引的数据，存储在 MySQL 数据目录中的 ibdata1 文件中。
独立表空间： InnoDB 可以为每个表创建独立的表空间（如果启用了 innodb_file_per_table），每个表的数据存储在单独的 .ibd 文件中。每个表的表空间包罗表数据、索引等内容。
b. 数据页和索引页
InnoDB 将数据存储在页（Page）中，默认页大小为 16KB。表中的每一行都存储在这些页中，页是存储的根本单位。
数据页： 存储表的行数据，每一页包罗多个行。
索引页： 存储表的索引信息。
c. 聚簇索引（Clustered Index）
InnoDB 利用聚簇索引来存储数据表的行。聚簇索引按主键顺序存储行数据，这意味着行数据实际上存储在 B+ 树结构中，树的叶子节点包罗实际的数据行。每个表都必须有一个主键，如果没有显式定义主键，InnoDB 会选择一个唯一的非空索引或主动天生一个隐藏的列作为主键。
d. Redo Log 和 Undo Log
Redo Log（重做日志）： InnoDB 为了保证事务的持久性，在事务提交前，先将修改写入重做日志（ib_logfile 文件），即使发生瓦解，也可以通过重做日志恢复数据。
Undo Log（回滚日志）： 为了支持事务的原子性和划一性，InnoDB 在事务实行过程中会纪录 Undo Log，允许事务在出错时回滚到之前的状态。
e. 数据落盘过程
InnoDB 利用缓冲池（Buffer Pool）来缓存数据页和索引页，数据的修改首先发生在缓冲池中，随后通过以下步骤将数据持久化到磁盘：
修改页： 当事务对表的数据进行修改时，这些修改会先在缓冲池中的页上进行。
写入重做日志： 事务提交时，InnoDB 会将修改先写入重做日志，保证数据可以在瓦解时恢复。
刷新脏页： InnoDB 会定期或在内存不敷时将修改后的脏页从缓冲池刷新到磁盘上的数据文件中。
3. MyISAM 存储引擎
MyISAM 相对较为简朴，它的数据存储方式如下：
数据文件： 每个表有两个文件，一个是 .MYD 文件，用于存储表的数据，另一个是 .MYI 文件，用于存储索引。
存储形式： MyISAM 的表数据按照表结构定义存储，表的数据和索引是分开存储的，索引黑白聚簇索引。
4. 文件系统和磁盘
MySQL 终极将数据以文件的形式存储在操纵系统的文件系统中。MySQL 支持多种文件系统（如 EXT4、NTFS、XFS 等），差异文件系统对文件的构造和管理方式差异，可能会影响 MySQL 数据库的性能。
5. 数据库缓冲机制
MySQL 通过缓存机制来进步性能：
查询缓存： MySQL 会缓存查询效果，当有相同的查询哀求时，可以直接从缓存中返回效果（InnoDB 不再利用查询缓存，改用 Buffer Pool 来管理缓存）。
Buffer Pool： InnoDB 的缓冲池用于缓存表和索引数据，减少对磁盘的直接访问，进步性能。
6. 数据存储的事务性和划一性
InnoDB 提供 ACID 特性，通过锁机制、事务日志、缓冲池等多种手段来保证数据的划一性和持久性：
原子性：每个事务是一个不可分割的工作单位，要么完全实行，要么完全回滚。
划一性：事务前后，数据库状态必须保持划一。
隔离性：多个事务不会互相干扰，InnoDB 提供了多种隔离级别。
持久性：事务提交后，数据会持久生存到磁盘，即使系统瓦解也可以恢复。
通过这些机制，MySQL 能够高效地将数据写入数据库，并保证数据的安全性和划一性。
当我们将数据插入 MySQL 数据库时，MySQL 会通过一系列的步骤和机制将数据终极存储在磁盘上的数据库文件中。这整个过程涉及到内存、日志文件、缓存等。以 InnoDB 存储引擎为例，具体步骤如下：
1. 客户端发送 SQL 哀求
当客户端发送 INSERT, UPDATE 或 DELETE 等写操纵的 SQL 哀求时，MySQL 的查询解析器会首先对哀求进行解析，天生查询计划。
2. 引擎层处置惩罚
MySQL 的存储引擎负责实际的数据存储工作，差异的存储引擎有差异的实现。以 InnoDB 为例，InnoDB 存储引擎会开始实行写操纵的流程。
3. 检查 Buffer Pool
InnoDB 有一个内存中的缓存区，称为 Buffer Pool，用来缓存数据页（pages）。当我们要修改数据时，首先会检查该数据是否已经在 Buffer Pool 中：
如果数据在 Buffer Pool 中，直接在内存中修改数据；
如果数据不在 Buffer Pool 中，InnoDB 会从磁盘上读取相应的数据页到 Buffer Pool 中，然后再进行修改。
4. 修改数据页（脏页）
数据修改首先在内存中的数据页上进行，这时的页被称为 脏页（dirty page），因为它已经被修改，但还没有写回磁盘。此时数据只是暂存在内存中，还没有永世存储到磁盘上。
5. 写入 Redo Log（重做日志）
为了确保数据的持久性和防止数据丢失，InnoDB 会在修改内存中的数据页的同时，将这次操纵的纪录写入 Redo Log。Redo Log 是一个顺序写入的日志文件，纪录了所有数据的修改操纵。
这个操纵是很快的，因为日志是顺序写入磁盘的，不像随机写数据文件那样慢。
即使数据库瓦解，由于 Redo Log 的存在，InnoDB 能够在重启后通过 Redo Log 恢复数据。
6. 事务提交
在事务实行 COMMIT 时，InnoDB 会将事务相关的 Redo Log 刷入磁盘，保证事务的持久性。这意味着只要 Redo Log 写入成功，即使数据还没有写到表空间的数据文件中，事务也被以为已经提交成功。
7. 数据异步刷新到磁盘
修改的数据页不会立刻写回磁盘，而是由 InnoDB 后台的线程在符合的时候（比方 Buffer Pool 缓存不敷时、数据库空闲时、定时任务等）将这些脏页异步写回磁盘中的数据文件。这称为 刷脏页 操纵。
刷脏页并不是每次修改都立刻进行，而是为了进步性能，在符合的时候批量进行。
8. 写入 Undo Log（回滚日志）
为了支持事务的回滚和划一性读，InnoDB 会在修改数据时天生 Undo Log，纪录数据修改前的状态。Undo Log 生存在磁盘上，它允许事务回滚到实行前的状态，并且在读取数据时，能够提供划一性的快照。
9. 数据文件存储
终极，修改后的数据会被写入到表空间的实际数据文件中。对于 InnoDB 来说，这些数据通常存储在 .ibd 文件中（如果利用独立表空间），或者存储在 ibdata 文件中（如果利用共享表空间）。
10. 刷写到数据文件
InnoDB 的后台线程定期会将脏页刷新到表空间文件中，从而确保内存中的数据与磁盘上的数据同步。这一步是为了进步写性能而计划的，数据写入操纵首先是在内存中完成，最后异步刷写到磁盘。
11. 日志文件和数据文件合并
Redo Log 和 数据文件 保持了差异步的状态，MySQL 通过后台线程定期将脏页和 Redo Log 的内容同步到数据文件中，保证终极划一性。
当发生宕机等故障时，MySQL 可以通过重做日志恢复最新的数据修改。
2.Mysql实行全流程
当 MySQL 接收到客户端的 SQL 哀求后，首先辈行毗连受理和权限验证，确保用户有实行权限。然后，查询会颠末解析器进行词法和语法分析，接着由优化器选择最优的实行计划，比如利用符合的索引或毗连方式。实行器根据天生的计划与存储引擎（如 InnoDB）交互，读取或修改数据。对于写操纵，事务的修改会纪录到日志中确保持久性。终极，查询效果通过 TCP/IP 返回给客户端。
MySQL 实行全流程：
1.客户端哀求： 客户端发送 SQL 查询到 MySQL 服务器，MySQL 通过 TCP/IP 协议接收哀求。
2.毗连受理与权限验证： MySQL 先检查用户权限，确保有实行该查询的权限，如果通过，则分配线程处置惩罚该哀求。
3.查询解析： MySQL 解析器对 SQL 语句进行词法和语法分析，天生解析树，检查语法是否正确。
4.查询优化： 优化器分析解析树，天生最优的实行计划，选择符合的索引和毗连顺序来进步性能。
5.实行计划： 实行器根据优化后的实行计划开始操纵数据库，比如从表中读取数据或更新数据。
6.存储引擎交互： MySQL 通过存储引擎（如 InnoDB）来处置惩罚数据的实际存储和读取操纵，存储引擎负责行级锁、事务处置惩罚等。
7.返回效果： 查询实行器获取数据后，将效果集返回给客户端。
8.事务处置惩罚（针对写操纵）： 对于写操纵，InnoDB 会纪录日志，确保事务的原子性和持久性。
3.索引机制
MySQL 的索引机制重要通过 B+树索引、哈希索引和全文索引来加速查询。B+树索引是最常用的，得当范围查询和排序，哈希索引用于准确查询，而全文索引用于处置惩罚大量文本搜刮。索引可以显著进步查询速度，尤其是在大表中，但会增加插入、更新时的维护开销和存储空间斲丧。因此，在计划索引时必要权衡查询性能和资源成本。
MySQL 的索引机制用于加速数据查询，类似于书的目录，可以资助快速定位数据，而不必逐行扫描整个表。常见的 MySQL 索引类型包括 B+树索引、哈希索引 和 全文索引。以下是各索引的机制及特点：
1. B+树索引（默认类型，实用于 InnoDB 和 MyISAM）
结构：B+树是一种均衡的多叉树结构，叶子节点存储指向实际数据的指针。所有数据节点都在树的叶子节点上，且同一层的叶子节点通过指针相连。
特点：B+树的高度一般很低，通常为 2-4 层，查找、插入、删除等操纵的时间复杂度是 O(log N)，非常得当范围查询和排序查询。
聚簇索引：在 InnoDB 中，主键索引是聚簇索引，数据按主键顺序存储，叶子节点直接存储数据。
非聚簇索引：非主键索引为非聚簇索引，叶子节点存储主键的引用，查询时必要回表。
2. 哈希索引（实用于 Memory 引擎）
结构：哈希索引通过将键值颠末哈希函数处置惩罚后映射到哈希表中，实现 O(1) 时间复杂度的快速定位。
特点：哈希索引非常得当准确查询，但不得当范围查询，因为哈希函数会打乱键值的顺序，无法进行顺序扫描。
3. 全文索引（实用于 MyISAM 和 InnoDB）
结构：全文索引重要用于搜刮大文本字段，它通过创建倒排索引来快速查找包罗某个关键词的纪录。
特点：得当处置惩罚复杂的文本搜刮，比方匹配某个关键词或短语，但不得当准确匹配的场景。
索引的优点：
进步查询速度：通过索引，MySQL 可以跳过大量不相关的数据行，直接定位到所需的数据，尤其是在大表中效果显著。
排序优化：索引可以资助优化 ORDER BY 和 GROUP BY 查询，因为索引列的数据是有序的。
范围查询加速：B+树索引特殊得当范围查询，如 BETWEEN 或 >= 操纵。
索引的缺点：
插入/删除的开销：索引必要维护，当有插入、更新或删除时，MySQL 必要重新均衡索引树或更新哈希表，增加了额外的开销。
占用存储空间：索引会占用额外的存储空间，尤其是对于大表来说，索引文件可能会很大。
总结：
MySQL 的索引机制通过 B+树索引、哈希索引和全文索引等类型，有用地加速了查询操纵，尤其得当大数据量的表。然而，索引的利用也带来了维护开销和存储空间的斲丧，因此必要根据具体的查询需求合理选择和计划索引。
4.AQS
AQS（AbstractQueuedSynchronizer）是 Java 并发包中的一个核心组件，用于实现各种同步器如 ReentrantLock 和 Semaphore。它通过维护一个 FIFO 等待队列和一个状态变量来管理线程对共享资源的访问。AQS 支持独占模式（一个线程独占资源）和共享模式（多个线程可以同时访问资源），通过 CAS 操纵和 CLH 队列高效地处置惩罚线程的同步和唤醒。它为各种同步工具提供了基础，确保了线程管理的高效性和可靠性。
AQS（AbstractQueuedSynchronizer）是 Java 并发包（java.util.concurrent）中的一个基础框架，重要用于构建锁和同步器（如 ReentrantLock, CountDownLatch, Semaphore 等）。它通过维护一个先辈先出（FIFO）的等待队列，来管理多个线程的同步访问。
AQS 工作原理：
状态管理：AQS 通过一个 int 类型的状态变量 state 来表示共享资源的状态。线程通过 CAS（Compare-And-Swap）操纵修改这个状态，用于判断资源是否可以获取。
state = 0 表示资源可用。
state > 0 表示资源已被占用。
独占模式与共享模式：
独占模式：只有一个线程可以获得资源，如 ReentrantLock。在独占模式下，如果某个线程获取资源失败，则会进入等待队列。
共享模式：允许多个线程同时获取资源，如 CountDownLatch 和 Semaphore。多个线程可以并发访问资源。
FIFO 等待队列： 当一个线程尝试获取资源失败时，它会被加入到 AQS 的等待队列中，队列遵循 FIFO 规则。队列中的每个节点代表一个线程，AQS 会管理队列中线程的列队和唤醒。
CLH（Craig, Landin, and Hagersten）队列： AQS 的等待队列基于 CLH 队列，是一种双向链表结构。线程被封装为队列节点，当资源可用时，AQS 会按照队列顺序唤醒等待的线程。
锁的获取与释放：
获取锁：线程通过 acquire() 尝试获取锁，若资源可用则直接成功，否则进入等待队列。
释放锁：锁释放后，AQS 会通过 release() 唤醒等待队列中的下一个线程。
AQS 核心方法：
acquire(int arg)：独占模式下获取锁的方法，若获取失败则进入等待队列。
release(int arg)：独占模式下释放锁的方法，唤醒队列中的下一个线程。
acquireShared(int arg)：共享模式下获取锁，多个线程可以并发获取资源。
releaseShared(int arg)：共享模式下释放锁，通知所有等待线程资源已可用。
AQS 优势：
通用性强：AQS 提供了根本的队列和同步状态管理，允许轻松实现多种同步工具。
高效的线程管理：通过 FIFO 队列有用管理线程的同步操纵，减少竞争和开销。
总结：
AQS 是 Java 并发框架中的基础组件，通过 CAS、CLH 队列等机制管理线程对资源的访问，支持独占和共享两种模式。AQS 为许多高级同步工具（如锁、信号量）提供了核心支撑。
5.volatile和synconized区别以及实现
volatile 和 synchronized 是 Java 中用于处置惩罚并发问题的两种机制。volatile 确保变量的内存可见性和克制指令重排序，实用于简朴的状态变量，但不保证原子性。synchronized 提供了互斥锁、内存可见性和原子性，实用于复杂的同步需求。volatile 通过直接的内存访问实现，而 synchronized 涉及到锁的获取和释放，具有更高的开销。
1. volatile
作用：volatile 关键字用于声明一个变量，以确保该变量的值在所有线程中都是划一的。它重要用来保证内存可见性，即当一个线程修改了被 volatile 修饰的变量时，其他线程能够立刻看到这个修改。
实现：
内存可见性：volatile 变量的读写操纵直接与主内存交互，而不是从线程的缓存中读取或写入数据。这保证了所有线程看到的都是最新的值。
克制指令重排序：编译器和处置惩罚器不会对 volatile 变量的读写操纵进行重排序，这避免了某些操纵顺序差异等的问题。
实用场景：实用于简朴的标志位、状态变量等场景，确保所有线程看到划一的值。它不能保证原子性，因此不得当用于复合操纵（如自增）。
2. synchronized
作用：synchronized 关键字用于在方法或代码块上加锁，以确保同一时刻只有一个线程能够实行被锁定的代码段。它不仅保证了内存的可见性，还提供了原子性和互斥性。
实现：
互斥性：synchronized 确保在同一时刻只有一个线程可以实行被 synchronized 修饰的代码块或方法，防止多个线程同时访问共享资源。
内存可见性：进入 synchronized 代码块时，线程会从主内存中重新加载数据；退出 synchronized 代码块时，线程会将数据刷新到主内存中，确保对共享数据的修改对其他线程立刻可见。
锁对象：每个 synchronized 代码块或方法都有一个锁对象，锁对象是与对象或类实例相关联的。锁的获取和释放操纵必要维护锁的状态，涉及到线程的上下文切换和调理。
实用场景：实用于必要保证线程安全的复杂操纵和临界区，比方对共享资源的访问和修改。
总结
volatile 保证变量的可见性和克制指令重排序，但不保证原子性，得当于简朴的状态标志。它的实现依赖于直接的内存访问和特定的内存屏蔽操纵。
synchronized 提供了互斥锁、原子性和可见性，实用于复杂的同步场景。它的实现涉及到锁的获取和释放、上下文切换等开销。
6.kafka实现原理
Kafka 是一个高吞吐量的分布式流平台，它通过将数据分为多个分区，并在差异的代理节点上存储副本来实现高可靠性和可扩展性。数据顺序写入到分区的日志文件中，保证了数据的划一性和持久性。生产者将数据写入主题，消费者从主题中拉取数据，支持高效的数据传输和处置惩罚。通过分区、副本机制和消费者组，Kafka 能够实现负载均衡、高可用性以及大规模的数据处置惩罚。
Kafka 是一个分布式流平台，用于处置惩罚高吞吐量的实时数据流。它的实现原理涉及多个关键组件和技术，包括生产者、消费者、代理、主题、分区和日志。以下是 Kafka 的重要实现原理：
1. 核心组件
生产者 (Producer)：负责将数据发送到 Kafka 集群中的一个或多个主题。生产者将数据写入到主题的分区中，并可以选择利用差异的分区战略来优化数据分布和负载均衡。
消费者 (Consumer)：从 Kafka 中读取数据。消费者从一个或多个主题的分区中消费数据，并且可以通过消费者组来实现负载均衡和高可用性。
代理 (Broker)：Kafka 集群中的每个节点称为代理。代理负责接收来自生产者的数据，将其写入磁盘，并向消费者提供数据。每个代理可以处置惩罚多个主题和分区。
主题 (Topic)：数据的逻辑分类。每个主题可以有多个分区，生产者将数据写入到主题中的分区，消费者从主题的分区中读取数据。
分区 (Partition)：主题的子集，用于进步并发处置惩罚能力和扩展性。每个分区是一个有序的、不可变的消息序列，数据按追加的顺序写入。
日志 (Log)：每个分区的数据存储在日志文件中，日志文件是一个有序的、不可变的消息序列。数据追加到日志的末尾，消费者可以从日志中按顺序读取数据。
2. 数据存储与管理
消息持久化：Kafka 将消息写入磁盘并进行持久化，以确保数据的可靠性。每个分区的日志是一个有序的文件集合，数据按顺序追加到日志末尾。
副本机制：为了进步数据的可靠性和可用性，Kafka 利用副本机制。每个分区可以有多个副本，副本在差异的代理上进行存储。一个副本是主副本（Leader），其他副本是从副本（Follower）。生产者将数据写入主副本，从副本从主副本同步数据。
数据删除：Kafka 利用配置的保留战略（基于时间或大小）来控制数据的保留和删除。过期的数据会被删除，以释放存储空间。
3. 消息传递机制
顺序写入：Kafka 将数据顺序写入到分区的日志文件中，确保数据的顺序性。这种顺序写入可以进步写入性能并简化数据恢复。
消费者偏移量：消费者读取数据时会纪录偏移量（offset），以跟踪读取的位置。偏移量是分区内消息的唯一标识。消费者可以根据自己的需求选择何时提交偏移量，从而实现数据的准确消费和重复消费的控制。
拉取式模型：消费者通过拉取的方式从 Kafka 中读取数据。消费者定期向 Kafka 哀求数据，Kafka 将数据发送给消费者。这种模型使得消费者可以控制数据的处置惩罚速度和流量。
4. 负载均衡与扩展
分区与副本：通过将主题分别为多个分区，并将副天职布在差异的代理上，Kafka 可以实现负载均衡和扩展。生产者和消费者可以并行处置惩罚多个分区的数据，从而进步吞吐量和处置惩罚能力。
消费者组：消费者组可以实现负载均衡，一个消费者组内的消费者共同消费主题中的所有分区，每个分区只能由一个消费者处置惩罚，从而实现数据的并行处置惩罚和容错。
总结
Kafka 是一个高吞吐量、分布式的流平台，通过将数据分区和副天职布在差异的代理上，实现了高可靠性和扩展性。数据在分区的日志文件中顺序写入，并通过副本机制确保数据的可靠性。消费者通过拉取的方式读取数据，消费者组实现了负载均衡和高可用性。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]