当前位置：首页 > article >正文

【后端开发面试题】每日 3 题（十）

article 2025/3/13 15:04:16

✍个人博客：Pandaconda-CSDN博客
📣专栏地址：https://blog.csdn.net/newin2020/category_12903849.html
📚专栏简介：在这个专栏中，我将会分享后端开发面试中常见的面试题给大家~
❤️如果有收获的话，欢迎点赞👍收藏📁，您的支持就是我创作的最大动力💪

1. 简述 Redis 持久化的两种方式及其优缺点

Redis 提供了两种持久化方式：RDB（Redis Database）和 AOF（Append - Only File）。

RDB
- 原理：RDB 是 Redis 默认的持久化方式，它会在某个时间点将 Redis 内存中的数据快照保存到磁盘文件中（默认文件名为 dump.rdb）。可以通过配置定期执行快照操作，也可以手动触发。
- 优点
  - 文件紧凑：RDB 文件是一个经过压缩的二进制文件，占用空间小，便于传输和备份。
  - 恢复速度快：在重启 Redis 时，加载 RDB 文件恢复数据的速度比 AOF 方式快，因为只需要一次性加载文件到内存。
  - 对性能影响小：在进行快照操作时，Redis 会创建一个子进程来完成数据的持久化，主进程可以继续处理客户端请求，对 Redis 的性能影响较小。
- 缺点
  - 数据安全性低：由于是定期进行快照，在两次快照之间如果 Redis 发生故障，可能会丢失这段时间内的数据。
  - 快照过程可能阻塞：当数据量较大时，创建子进程和生成 RDB 文件可能会消耗较多的系统资源，并且在 fork 子进程时可能会导致主进程短暂阻塞。
AOF
- 原理：AOF 持久化方式会将 Redis 执行的每一条写命令追加到 AOF 文件的末尾。当 Redis 重启时，会重新执行 AOF 文件中的命令来恢复数据。
- 优点
  - 数据安全性高：可以配置不同的同步策略，如每秒同步（everysec）、每次写操作同步（always）等，能最大程度减少数据丢失的风险。
  - 日志易读：AOF 文件是一个文本文件，包含了 Redis 执行的所有写命令，方便进行分析和修复。
  - 日志可重写：随着时间的推移，AOF 文件会越来越大，Redis 提供了 AOF 重写机制，可以对 AOF文件进行压缩，减少文件大小。
- 缺点
  - 文件体积大：由于 AOF 文件记录了每一条写命令，文件体积通常比 RDB 文件大。
  - 恢复速度慢：在重启 Redis 时，需要重新执行 AOF 文件中的所有命令，恢复数据的速度相对较慢。
  - 性能开销大：如果采用每次写操作同步（always）的策略，会严重影响 Redis 的性能，因为每次写操作都需要将数据写入磁盘。

2. 在 Python 的 FastAPI 框架中，如何进行数据验证？

FastAPI 基于 Pydantic 库进行数据验证，以下是几种常见的数据验证方式：

路径参数和查询参数验证：可以使用 Python 的类型注解来指定路径参数和查询参数的类型，FastAPI 会自动进行类型验证。

from fastapi import FastAPI

app = FastAPI()

@app.get("/items/{item_id}")
def read_item(item_id: int, q: str | None = None):
    return {"item_id": item_id, "q": q}

在上述代码中，item_id 被指定为 int 类型，q 被指定为 str 类型或 None。如果客户端传递的参数类型不符合要求，FastAPI 会返回一个包含错误信息的 HTTP 响应。

请求体验证：使用 Pydantic 的 BaseModel 类来定义请求体的结构，FastAPI 会根据定义的模型进行数据验证。

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float
    is_offer: bool | None = None

@app.post("/items/")
def create_item(item: Item):
    return item

在上述代码中，Item 类继承自 BaseModel，定义了请求体的结构。如果客户端发送的请求体不符合 Item 模型的定义，FastAPI 会返回一个包含错误信息的 HTTP 响应。

自定义验证：可以使用 Pydantic 的 validator 装饰器来定义自定义的验证逻辑。

from fastapi import FastAPI
from pydantic import BaseModel, validator

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

    @validator('price')
    def price_must_be_positive(cls, value):
        if value < 0:
            raise ValueError('Price must be positive')
        return value

@app.post("/items/")
def create_item(item: Item):
    return item

在上述代码中，price_must_be_positive 方法使用 validator 装饰器对 price 字段进行自定义验证，确保价格为正数。

3. 简述如何在 MySQL 中进行数据库性能调优

在 MySQL 中进行数据库性能调优可以从多个方面入手，以下是一些常见的方法：

数据库设计优化
- 表结构优化
  - 合理选择数据类型：根据数据的实际范围选择合适的数据类型，如使用 TINYINT 代替 INT 存储较小的整数，减少存储空间。
  - 避免使用 NULL 值：NULL 值会增加查询和索引的复杂度，尽量为字段设置默认值。
  - 拆分大表：如果表的数据量非常大，可以考虑进行水平拆分（按行拆分）或垂直拆分（按列拆分），提高查询性能。
- 索引优化
  - 创建合适的索引：在经常用于查询条件、排序和连接的字段上创建索引，如在用户表的 username 字段上创建索引，可加快按用户名查询的速度。
  - 避免过多索引：索引会增加写操作的开销，且占用额外的磁盘空间，定期分析查询语句，删除不必要的索引。
  - 使用复合索引：当多个字段经常一起用于查询条件时，创建复合索引可以提高查询效率。例如，对于经常同时根据 user_id 和 create_time 查询订单的场景，创建 (user_id, create_time) 复合索引。
查询语句优化
- 避免使用 SELECT *：只选择需要的列，减少数据传输量。
- 优化子查询：尽量将子查询转换为 JOIN 查询，因为 JOIN 查询通常比子查询性能更好。
- 避免在 WHERE 子句中使用函数或表达式：这会导致索引失效，例如 WHERE YEAR(create_time) = 2024，可以改为 WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31'。
数据库配置优化
- 调整缓冲区大小：根据服务器的硬件资源，调整 innodb_buffer_pool_size、key_buffer_size 等参数，以提高数据库的缓存效率。例如，将 innodb_buffer_pool_size 设置为物理内存的 70% - 80%，可以让更多的数据和索引缓存在内存中，减少磁盘 I/O。
- 优化查询缓存：对于一些不经常变化的数据查询，可以开启查询缓存，但要注意查询缓存可能会带来额外的开销，需要根据实际情况进行调整。
硬件优化
- 升级硬件：如果数据库服务器的硬件资源（如 CPU、内存、磁盘等）成为性能瓶颈，可以考虑升级硬件。例如，使用更快的磁盘（如 SSD）可以显著提高数据库的读写性能。
- 分布式架构：对于高并发、大数据量的场景，可以采用分布式数据库架构，如 MySQL Cluster 或使用分库分表技术，将数据分散存储在多个服务器上，提高系统的并发处理能力。