7天八股速记之Java后端——Day 5

本文主要是介绍7天八股速记之Java后端——Day 5，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

平常是用的 MySQL 数据库吗？说一下四个隔离级别。

1. 读未提交（Read Uncommitted）：

   • 在该隔离级别下，事务可以读取其他事务尚未提交的未提交数据。
   • 这意味着一个事务可以看到其他事务所做的修改，即使这些修改还没有被提交。
   • 读未提交是最低级别的隔离级别，也是最不严格的隔离级别。

2. 读已提交（Read Committed）：

   • 在该隔离级别下，事务只能读取已经提交的数据，不能读取其他事务尚未提交的未提交数据。
   • 这意味着一个事务只能看到其他事务已经提交的修改，而看不到其他事务尚未提交的修改。
   • 读已提交解决了读未提交的不一致性问题，但是依然可能出现不可重复读和幻读问题。

3. 可重复读（Repeatable Read）：

   • 在该隔离级别下，事务在执行期间多次读取同一数据集时，会得到相同的结果，即事务始终看到相同的数据。
   • 这意味着其他事务在事务执行期间做的修改对该事务是不可见的，保证了读操作的一致性。
   • 可重复读解决了读已提交的不可重复读问题，但仍可能出现幻读问题。

4. 串行化（Serializable）：

   • 在该隔离级别下，事务被顺序执行，每个事务都相当于在独立运行的数据库中执行。事务之间不存在并发问题。
   • 这意味着并发事务之间不存在任何交错，每个事务都像在一个孤立的环境中运行一样。
   • 串行化提供了最高的隔离级别，可以避免所有的并发问题，但也可能导致系统的性能下降。

这四个隔离级别提供了不同的并发控制机制，可以根据具体的业务需求和性能要求选择合适的隔离级别。默认情况下，MySQL 使用的隔离级别是可重复读（Repeatable Read）。

什么是 MVCC？

MVCC 是多版本并发控制（Multi-Version Concurrency Control）的缩写，是一种用于数据库管理系统中的并发控制机制。MVCC 通过在数据库中维护多个数据版本，允许读取操作可以同时进行，即使在写操作正在进行的情况下也可以。MVCC 主要用于解决数据库读-写操作之间的并发访问问题，常见于一些支持事务的数据库系统，如 MySQL、PostgreSQL 等。

MVCC 的核心思想是为每个数据行维护多个版本，并通过版本号来管理和区分不同版本的数据行。在 MVCC 中，每个事务在读取数据时，会根据事务的启动时间戳（或者说版本号）来选择合适的数据版本。具体来说，MVCC 包含以下几个重要组成部分：

1. 数据版本管理：MVCC 维护了数据库中每个数据行的多个版本，每个版本都有一个唯一的版本号（或者称为时间戳）。当某个事务对数据行进行更新时，会生成一个新的数据版本，并更新版本号。

2. 事务启动时间戳：每个事务在启动时都会被分配一个唯一的时间戳，用于标识该事务的开始时间。这个时间戳通常是事务开始执行的时间或者事务分配的递增序号。

3. 读取操作的版本选择：在读取数据时，事务会根据自己的启动时间戳来选择合适的数据版本。通常情况下，事务只能看到启动时间戳之前已经提交的事务所做的修改。

4. 并发控制：MVCC 通过维护多个数据版本和事务的启动时间戳来实现并发控制，从而保证事务之间的隔离性和一致性。不同的数据库系统可能采用不同的具体实现方式来实现 MVCC。

MVCC 机制具体是怎么样的？

MVCC（多版本并发控制）机制是一种用于数据库管理系统中的并发控制机制，它通过维护数据的多个版本来允许并发事务的读写操作。下面是 MVCC 机制的基本原理和具体实现方式：

1. 数据版本管理：

   • 在 MVCC 中，每个数据行都会维护多个版本，每个版本都有一个唯一的版本号（或者称为时间戳）。通常情况下，一个数据行的多个版本被存储在数据库中的不同地方，例如数据库的 Undo Log 或者版本链中。

2. 事务启动时间戳：

   • 每个事务在启动时都会被分配一个唯一的时间戳，用于标识该事务的开始时间。这个时间戳通常是事务开始执行的时间或者事务分配的递增序号。

3. 读取操作的版本选择：

   • 在执行读操作时，事务会根据自己的启动时间戳来选择合适的数据版本。通常情况下，事务只能看到启动时间戳之前已经提交的事务所做的修改。
   • 如果某个数据行有多个版本，事务会根据自己的启动时间戳选择合适的版本，通常选择最新的未被其他事务修改过的版本。

4. 写操作的版本管理：

   • 在执行写操作时，事务会生成一个新的数据版本，并将新版本的数据写入到数据库中。同时，事务会更新该数据行的版本号或者时间戳为当前事务的启动时间戳。

5. 并发控制：

   • MVCC 通过维护多个数据版本和事务的启动时间戳来实现并发控制，从而保证事务之间的隔离性和一致性。
   • 不同的数据库系统可能采用不同的具体实现方式来实现 MVCC，例如 MySQL 使用的是多版本的快照读，而 PostgreSQL 使用的是多版本的行级锁。

通过以上机制，MVCC 实现了读操作和写操作之间的并发访问，提高了数据库的并发性能和事务的并发性，同时确保了事务的隔离性和一致性。

请简述 Redis 和 MySQL 功能上的区别。

Redis 和 MySQL 是两种不同类型的数据库管理系统，它们在功能上有一些区别：

1. 数据模型：

   • Redis 是一种基于内存的键值存储数据库，支持多种数据结构，如字符串、哈希表、列表、集合、有序集合等。
   • MySQL 是一种关系型数据库管理系统（RDBMS），使用表格来存储数据，并支持 SQL 查询语言。

2. 存储引擎：

   • Redis 的数据存储在内存中，并且可以通过持久化机制将数据写入磁盘，常用的持久化方式包括快照（snapshot）和 AOF（Append Only File）。
   • MySQL 支持多种存储引擎，包括 InnoDB、MyISAM 等，每种存储引擎有不同的特性和适用场景。

3. 查询语言：

   • Redis 并不支持像 MySQL 那样的结构化查询语言（SQL），而是提供了一组命令用于操作不同类型的数据结构。
   • MySQL 使用 SQL 查询语言来执行各种数据操作，包括查询、插入、更新、删除等。

4. 事务支持：

   • Redis 支持事务，可以通过 MULTI 和 EXEC 命令来执行一组操作，保证这组操作的原子性。
   • MySQL 也支持事务，可以使用 BEGIN、COMMIT 和 ROLLBACK 等语句来控制事务的开始、提交和回滚。

5. 分布式特性：

   • Redis 支持主从复制和哨兵机制，可以实现高可用性和数据备份。
   • MySQL 支持主从复制、分片和集群等分布式特性，可以实现数据分布和负载均衡。

6. 适用场景：

   • Redis 适用于需要高性能、低延迟的场景，如缓存、会话存储、消息队列等。
   • MySQL 适用于需要持久化存储和复杂查询的场景，如关系型数据存储、在线交易处理等。

请简述 Redis 和 MongoDB 内存及存储方面的区别。

Redis 和 MongoDB 是两种不同类型的数据库管理系统，它们在内存和存储方面有一些区别：

1. 内存存储：

   • Redis 是一种基于内存的键值存储数据库，所有数据都存储在内存中，因此读取和写入速度非常快。
   • MongoDB 也可以在内存中存储数据，但通常情况下，它是一种磁盘为主的数据库，数据首先存储在磁盘上，然后根据需要被加载到内存中进行操作。

2. 持久化存储：

   • Redis 支持多种持久化方式，包括快照（snapshot）和 Append Only File（AOF）两种方式。快照会定期将内存中的数据写入磁盘，而 AOF 会将每个写操作记录下来，以日志形式写入磁盘。
   • MongoDB 也支持持久化存储，通过将数据写入磁盘文件来确保数据的持久性。它采用了一种称为 WiredTiger 的存储引擎，提供了高效的数据压缩和事务支持。

3. 数据模型：

   • Redis 是一种键值存储数据库，支持多种数据结构，如字符串、哈希表、列表、集合、有序集合等，适用于各种场景的数据存储和处理。
   • MongoDB 是一种文档数据库，使用类似 JSON 格式的 BSON（Binary JSON）文档来存储数据，可以存储复杂的数据结构和嵌套文档。

4. 查询语言：

   • Redis 并不支持像 MongoDB 那样的结构化查询语言（如 SQL），而是提供了一组命令用于操作不同类型的数据结构。
   • MongoDB 使用丰富的查询语言和表达式来执行各种数据操作，支持复杂的查询、聚合操作和地理空间查询等。

5. 适用场景：

   • Redis 适用于需要高性能、低延迟和简单数据结构的场景，如缓存、会话存储、消息队列等。
   • MongoDB 适用于需要存储复杂数据结构、支持复杂查询和分析的场景，如文档存储、日志分析、内容管理等。

redis 的优缺点

Redis 是一种基于内存的键值存储数据库，具有许多优点和一些缺点：

优点：

1. 高性能：Redis 所有数据都存储在内存中，因此读写速度非常快，适用于对响应时间有较高要求的场景。
2. 丰富的数据结构：Redis 支持多种数据结构，包括字符串、哈希表、列表、集合、有序集合等，能够满足各种场景的数据存储和处理需求。
3. 持久化支持：Redis 支持多种持久化方式，包括快照（snapshot）和 Append Only File（AOF）两种方式，能够保证数据的持久性。
4. 高可用性：Redis 支持主从复制和哨兵机制，可以实现高可用性和数据备份，保证系统的稳定性和可靠性。
5. 丰富的功能：Redis 提供了丰富的功能和特性，如事务支持、发布订阅机制、Lua 脚本执行等，能够满足各种复杂的业务需求。
6. 轻量级：Redis 采用 C 语言开发，代码简洁高效，占用资源较少，适合部署在各种环境下。

缺点：

1. 数据量受限：由于数据存储在内存中，Redis 的数据量受到物理内存的限制，对于大规模数据存储的场景不太适用。
2. 持久化性能开销：持久化操作会对 Redis 的性能产生一定影响，特别是在 AOF 持久化模式下，每个写操作都需要记录到日志文件中，会增加磁盘 I/O 开销。
3. 单线程模型：Redis 使用单线程模型处理客户端请求，虽然能够减少线程切换开销，但在高并发场景下可能成为性能瓶颈。
4. 不支持复杂查询：Redis 并不支持像关系型数据库那样复杂的查询语言，只能通过一组命令来操作数据，对于复杂的数据分析和查询较为不便。
5. 数据一致性：由于 Redis 的主从复制是异步的，可能存在数据同步延迟的情况，导致主从节点之间的数据不一致。
6. 有限的持久化策略：Redis 的持久化策略相对简单，虽然提供了多种方式，但并不能满足所有场景的需求，特别是在对数据一致性要求非常高的场景下。

综上所述，Redis 具有高性能、丰富的功能和简洁的设计，适用于对响应时间要求高、数据量相对较小、读写频繁且数据模式相对简单的场景。但它也存在一些限制，特别是在大规模数据存储和复杂查询方面的应用场景下可能不太适合。

redis 有哪几种数据结构？

Redis 支持多种数据结构，每种数据结构都有特定的用途和操作命令。以下是 Redis 支持的主要数据结构：

1. 字符串（String）：字符串是 Redis 最基本的数据结构，可以存储文本、整数或者二进制数据。常用于缓存、计数器、分布式锁等场景。常见的命令包括 SET、GET、INCR、DECR 等。

2. 哈希表（Hash）：哈希表是一种键值对的无序集合，其中每个键都映射到一个值。常用于存储对象的属性和值，例如用户信息、配置信息等。常见的命令包括 HSET、HGET、HGETALL、HINCRBY 等。

3. 列表（List）：列表是一个有序的字符串列表，允许在列表的两端进行插入和删除操作。常用于实现队列、栈、消息队列等场景。常见的命令包括 LPUSH、RPUSH、LPOP、RPOP、LRANGE 等。

4. 集合（Set）：集合是一个无序的字符串集合，不允许重复元素的存在。常用于存储唯一值、集合运算等场景。常见的命令包括 SADD、SREM、SISMEMBER、SMEMBERS 等。

5. 有序集合（Sorted Set）：有序集合是一个有序的字符串集合，每个成员都关联一个分数，通过分数来对集合中的成员进行排序。常用于排行榜、范围查找等场景。常见的命令包括 ZADD、ZREM、ZRANK、ZRANGE 等。

6. 位图（Bitmap）：位图是一种特殊的字符串，其中的每个位都可以被设置或者清除。常用于统计、布隆过滤器等场景。常见的命令包括 SETBIT、GETBIT、BITCOUNT、BITOP 等。

除了以上几种主要数据结构之外，Redis 还支持一些其他数据结构，如 HyperLogLog、地理位置等。每种数据结构都有自己特定的用途和适用场景，可以根据实际需求选择合适的数据结构。

redis 为什么这么快？

Redis 之所以如此快速，主要归因于以下几个方面的原因：

1. 基于内存存储：Redis 所有数据都存储在内存中，因此读写操作非常快速。相比于磁盘存储的数据库系统，Redis 可以直接在内存中进行数据访问和操作，无需进行磁盘 I/O，从而大大提高了读写性能。

2. 非阻塞式 I/O：Redis 使用了基于事件驱动的 I/O 模型，在处理网络请求时采用非阻塞式的方式。这意味着 Redis 能够在一个线程中同时处理多个客户端连接，有效地利用了系统资源，提高了并发处理能力和响应速度。

3. 单线程模型：Redis 采用单线程模型处理客户端请求，这样可以避免多线程之间的上下文切换开销。虽然单线程模型可能会受到某些特定场景下并发量的限制，但对于大部分场景来说，这种简单的设计能够带来更高的性能。

4. 高效的数据结构：Redis 提供了丰富而高效的数据结构，如字符串、哈希表、列表、集合、有序集合等，这些数据结构都经过优化，能够在内存中高效地存储和操作数据，满足各种业务需求。

5. 多种持久化方式：Redis 提供了多种持久化方式，如快照（snapshot）和 Append Only File（AOF）两种方式，可以根据实际需求选择合适的持久化方式。持久化机制能够保证数据的持久性，同时又不会过多地影响读写性能。

6. 简洁高效的代码实现：Redis 的代码采用 C 语言编写，简洁高效，充分利用了系统资源和操作系统提供的特性。同时 Redis 社区对代码的优化和维护也是非常活跃的，不断地改进和提升系统的性能和稳定性。

综上所述，Redis 之所以如此快速，是由于其基于内存存储、非阻塞式 I/O、单线程模型、高效的数据结构、多种持久化方式以及简洁高效的代码实现等多方面的因素共同作用所致。这些特性使得 Redis 成为一种高性能、低延迟的键值存储数据库，适用于各种需要快速响应和高并发访问的场景。

redis 的缓存淘汰策略？

Redis 提供了多种缓存淘汰策略，用于在内存不足时决定要删除哪些键以释放空间。以下是常见的几种缓存淘汰策略：

1. LRU（Least Recently Used，最近最少使用）：

   • LRU 策略会优先淘汰最近最少被访问的键，即如果一个键在一段时间内没有被访问过，那么就会被淘汰掉。
   • Redis 使用近似 LRU 策略，通过一些采样和近似计算来实现 LRU。

2. LFU（Least Frequently Used，最不经常使用）：

   • LFU 策略会优先淘汰访问频率最低的键，即如果一个键在一段时间内被访问的次数最少，那么就会被淘汰掉。
   • Redis 使用近似 LFU 策略，通过一些采样和近似计算来实现 LFU。

3. TTL（Time To Live，过期时间）：

   • TTL 策略会优先淘汰已经过期的键，即如果一个键设置了过期时间，并且已经过期了，那么就会被淘汰掉。
   • 这种策略适用于缓存数据中有明确的过期时间的场景。

4. 随机淘汰：

   • 随机淘汰策略会随机选择一个键进行淘汰，没有特定的规则或者优先级，只是简单地选择一个键释放空间。

5. 定期淘汰：

   • 定期淘汰策略会定期检查键的空闲时间或者访问时间，并根据一定的规则选择要淘汰的键，以释放空间。

Redis 默认采用的是 LRU 策略，但也可以根据实际需求通过配置文件或者命令来设置其他的淘汰策略。不同的淘汰策略适用于不同的场景，可以根据具体的业务需求选择合适的策略。

redis 如何持久化数据？

Redis 提供了两种主要的持久化方式来保证数据的持久性：

1. 快照（Snapshot）持久化：

   • 快照持久化是将 Redis 在某个时间点的内存数据保存到磁盘上的一种方式。Redis 将内存中的数据以快照的形式写入到一个 RDB 文件中，这个 RDB 文件是一个二进制文件，包含了 Redis 在某个时间点的所有数据。
   • 快照持久化可以通过配置文件中的 save 指令来设置保存快照的条件，比如在指定的时间间隔内如果有指定数量的修改操作，则触发保存快照的操作。
   • Redis 会 fork 出一个子进程来执行快照持久化操作，这样可以避免对主进程的阻塞影响服务的正常运行。

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

   • AOF 持久化是将 Redis 所有的写操作以追加的方式记录到一个日志文件中的一种方式。Redis 会将每个写操作都记录到 AOF 文件中，以文本形式保存命令的序列。
   • AOF 文件保存的是 Redis 服务器接收到的写命令，可以通过 replay AOF 文件来重新构建数据集的状态。AOF 文件可以通过 BGREWRITEAOF 命令来进行重写，从而减小文件大小和加快加载速度。
   • Redis 提供了多种 AOF 持久化的策略，包括 always（每条写命令都追加到 AOF 文件）、everysec（每秒追加一次 AOF 文件）和 no（不使用 AOF 持久化）。

这两种持久化方式可以单独使用，也可以同时使用，以提供更高的数据安全性。用户可以根据具体的需求选择适合的持久化方式，并根据实际情况调整持久化配置参数来平衡数据持久化的安全性和性能。

这篇关于7天八股速记之Java后端——Day 5的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---