MySQL和Redis的区别？

1. 数据类型：
MySQL是一种关系型数据库，表结构化存储，使用 SQL 查询。支持表、列、行等结构化数据。
Redis是一种基于内存的缓存系统，支持多种数据结构，如字符串、哈希表、列表、集合、有序集合等。
2. 存储方式：
MySQL则将数据存储在磁盘上，读写速度相对较慢，但可以存储更大的数据量。
Redis将所有数据存储在内存中，因此读写速度非常快。
3. 访问模式：
MySQL则使用多线程模型，可以同时处理多个请求。
Redis是单线程模型，所有请求都在一个线程中依次执行，因此可以获得更高的并发性能。
4. 持久化支持：
MySQL提供了多种持久化方式，如InnoDB引擎的redo log和binlog等。
Redis提供了多种持久化方式，如RDB（快照）和 AOF（追加日志）两种持久化方式等。
5.数据一致性
MySQL支持 ACID 事务，可靠性强。
Redis支持部分事务（通过 MULTI、EXEC），但缺乏回滚机制，安全性略逊。
6.数据容量
MySQL适用于大数据集，TB 级别数据处理能力强。支持主从复制、分库分表、集群等扩展方式。
Redis受内存大小限制，适合小而频繁的数据。支持主从复制、Cluster 模式，扩展性强，但需要手动管理。
7.应用场景

场景	MySQL	Redis
数据持久化	核心业务系统（如订单、库存、财务系统等）	适用于对数据完整性要求不高的场景（如日志、缓存等）。
高并发读写	适合中等并发场景。	擅长秒杀、排行榜、实时计数等高并发场景。
临时数据存储	数据需落盘保存，临时数据不推荐。	适用于短暂数据缓存，数据可随时丢弃。
消息队列	不适合。	适用于轻量级消息队列（如 pub/sub）。

 在实际开发中，MySQL + Redis 常被组合使用：

• Redis 作为缓存层，快速返回热点数据。
• MySQL 作为持久化存储层，保证数据完整性。
• Cache Aside 模式（缓存旁路）：
  读取数据时，先查询 Redis，若未命中再查询 MySQL 并将结果写入 Redis。
  写入数据时，同时更新 MySQL 和 Redis（或选择延迟淘汰 Redis 数据）。

Mysql底层数据结构，在磁盘上如何存储的？

MySQL 的底层数据存储结构以其存储引擎为基础，最常用的存储引擎是 InnoDB（默认）和 MyISAM。

InnoDB的底层数据结构

InnoDB 将数据以 表空间 (Tablespace) 的形式组织，并进一步划分为以下层次：

• 表空间（ibd文件）：一个mysql实例可以对应多个表空间，用于存储记录、索引等数据。
• 段：由多个区组成，是 InnoDB 分配和管理数据的基本单位.
  分为
        数据段（Leaf node segment）
        索引段（Non-leaf node segment）
        回滚段（Rollback segment）
  InnoDB是索引组织表，数据段就是B+tree的叶子节点，索引段即为B+tree的非叶子节点。段用来管理多个Extent（区）。
• 区：表空间的单元结构，每个区的大小为1M。默认情况下，InnoDB存储引擎页大小为16K，既一个区中一共有64个连续的页。
• 页：页是 InnoDB 磁盘存储的最小单元，默认大小为 16KB。
  页的类型多样，常见的有：
        数据页 (DATA_PAGE)：存储表的行数据（叶子节点）
        索引页 (INDEX_PAGE)：存储 B+树的非叶子节点
        Undo 页 (UNDO_PAGE)：存储回滚日志
  页的内容以行记录 (Row Record) 为核心，页内数据按主键有序存储，支持范围查询。
• 行：InnoDB存储引擎数据是按行进行存放的。

InnoDB 的磁盘存储结构采用页 (Page) 为核心单元，通过表空间 (Tablespace)、段 (Segment)、区 (Extent) 等机制，有效组织数据并提升性能。其设计充分利用了 B+树、缓冲池、日志等机制，确保数据的高效存储与快速恢复。

InnoDB 的数据组织体现了层次化的设计思路：

✅ B+树 提供快速检索能力，非叶子节点存储指针，叶子节点对应数据页。
✅ 页 (Page) 是磁盘 I/O 的基本单位，直接存储行数据或索引。
✅ 区 (Extent) 和 段 (Segment) 提供更大粒度的内存管理，减少碎片化，提高 I/O 性能。
✅ 表空间 (Tablespace) 则承载整个数据文件，方便管理与扩展。

Redis的持久化机制？

什么是RDB和AOF-CSDN博客
RDB（Redis DataBase）快照 
AOF（Append-Only File）只追加日志文件

RDB 是 Redis 通过创建 数据快照 (snapshot) 来持久化数据的一种机制。它会将某一时刻的内存数据以二进制文件 (.rdb) 形式存储到磁盘中。
AOF 是 Redis 通过将 每次写操作 以日志形式记录下来的持久化机制。

在生产环境中，推荐同时开启 RDB 和 AOF 以结合两者的优点：

✅ RDB 负责快速备份，适合全量恢复。
✅ AOF 负责实时记录，确保数据安全。

Redis的内存淘汰策略都有什么

1. noeviction（默认策略）
描述：当Redis内存不足时，不执行任何淘汰操作，所有的写操作都会返回错误。这种策略可以确保Redis内存不会被其他进程抢占，但会导致Redis进程被强制杀死，数据全部丢失，因此不建议在生产环境中使用。
适用场景：通常不推荐使用，除非对数据的完整性有极高的要求，且能够接受在内存不足时拒绝所有写操作的后果。
2. allkeys-lru
描述：从所有key中使用LRU（最近最少使用）算法进行淘汰。LRU算法通过记录每个key的最近访问时间，淘汰最长时间未被访问的key。
适用场景：适用于缓存场景，可以确保经常被访问的数据保留在内存中，提高缓存命中率。

3. volatile-lru
描述：从设置了过期时间的key中使用LRU算法进行淘汰。这种策略只针对设置了过期时间的key进行操作，优先淘汰那些最近最少使用且已经设置了过期时间的key。
适用场景：适用于需要设置过期时间，同时希望缓存尽可能保留热门数据的场景。

4. allkeys-random
描述：从所有key中随机淘汰数据。这种策略不考虑key的访问频率或过期时间，完全随机选择key进行淘汰。
适用场景：在不确定哪些key是热门数据，或者对淘汰策略没有特殊要求的情况下，可以使用这种简单的随机淘汰策略。

5. volatile-random
描述：从设置了过期时间的key中随机淘汰。与allkeys-random类似，但这种策略只针对设置了过期时间的key进行操作。
适用场景：在需要淘汰过期key，但又不希望完全依赖LRU算法的情况下，可以使用这种随机淘汰策略。

6. volatile-ttl
描述：在设置了过期时间的key中，淘汰过期时间剩余最短的。这种策略优先淘汰那些即将过期的key，确保Redis存储的数据尽可能新鲜。
适用场景：适用于需要快速淘汰即将过期数据的场景，比如缓存即将失效的会话信息等。