后端开发 on pipo's site

W-TinyLFU

Wed, 10 Dec 2025 00:00:00 +0000

W-TinyLFU

前置理解

SLRU 分段最久未使用

分段的意思是将原来只有一段的队列分成两段，一段为 保护段 另一段为 试用段，其内部逻辑与 LRU 相同。核心流程：

新数据会进入试用段
试用段中的数据再次被访问进入保护段
保护段中被淘汰的数据会回到试用段 SLRU 相比 LRU 的优势 在 LRU 场景下如果短时有大量新的散列的非热点数据访问可能导致缓存中的热点数据被移除替换导致 缓存污染，SLRU 的多级淘汰制可以减少这种情况的发送。

CountMinSketch 近似计数器器

原理与布隆过滤器类似，将输入的元素通过散列函数映射到不同的数组位置，每个位置每被映射一次该处的计数器就加一。当请求结果时就返回散列结果中计数最小的值作为计数结果，所以会导致类似布隆过滤器“假阳性”的问题，也就是返回计数比实际计数偏大。

W-TinyLFU

LRU 窗口缓存 + CountMinSketch + SLRU 核心流程：

新加入的缓存进入 LRU 窗口缓存
被窗口淘汰的缓存如果 SLRU 段未满则直接进入
否则从 SLRU 尾部选出将被淘汰的缓存 PK 最少使用的会被淘汰，胜利的会进入 SLRU

Reference

title: "W-TinyLFU缓存淘汰策略W-TinyLFU是一种非常优秀的缓存淘汰策略，它综合的考虑了现实场景中可能会遇到的各种问 - 掘金"
image: "https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9cb71ed5731e4cddb4c664381140c6f7~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp?"
description: "W-TinyLFU是一种非常优秀的缓存淘汰策略，它综合的考虑了现实场景中可能会遇到的各种问题，具有能够提高缓存命中率的准入策略，带有LFU的基于频率的优点，还具备元素保鲜机制，同时还能保证低空间消耗。"
url: "https://juejin.cn/post/7144327955353698334#heading-6"
favicon: ""
aspectRatio: "22.90249433106576"

Redis 生产问题

Sun, 19 Oct 2025 00:00:00 +0000

缓存穿透

指使用非法 key 进行请求, 这个 key 不存在于 Redis 缓存和数据库中. 导致数据库一直忙于处理非法 key 的查询请求.

1. 缓存空值

使用 Redis 缓存空值,将不存在的 key 加入缓存,之后直接在 Redis 被拦截.

优点 :实现简单,成本低.
缺点 : 大量不同非法 key 访问会占用大量 redis 缓存.
改进: 给空值 key 设置较短的过期时间或者加入布隆过滤器.

2. 布隆过滤器

使用布隆过滤器首先判断当前请求的数据是否存在, 若不存在直接拦截, “存在"后继续交由 redis 进行. 优点: bloomfilter 使用了散列算法"存储”,占用空间极小,速度快. 缺点: bloomfilter 会出现假阳性,同时无法删除数据. 改进: 使用缓存空值兜底,同时定期刷新写入真实的数据.

缓存击穿

1. 分布式锁

通过加入分布式只允许一个线程同时去访问数据库进行缓存重建,其他线程等待缓存好的数据. 步骤: A. redis 缓存未命中,尝试获取锁 B. 获取锁成功,进行双重检查 C. 查询数据库 D.重新加入 Redis 缓存 (若为空则构造空值)

缺点:

导致大量用户被堵塞,体验较差.
锁竞争激烈时，性能下降
如果锁未正确释放（如程序崩溃），可能导致死锁

改进:

使用 Redis 的 SET key value NX PX milliseconds 命令原子操作加锁。
加锁失败时，不要无限等待，可以返回“稍后再试”或“默认值”。

2.逻辑过期 + 异步更新

在非强一致性场景下,缓存数据时加入逻辑过期时间,若发生过期则先返回旧数据,同时获取分布式锁进行异步更新缓存. 步骤: A. redis 缓存命中, 但此时逻辑过期 B. 返回旧数据,同时尝试获取锁. C. 开启子线程,进行双重检查 D. 重构缓存缺点:

复杂度较高, 需要维护逻辑过期字段、异步线程、锁机制
用户可能无法及时获取到最新数据.
内存占用略高,因为缓存不会真正过期，除非手动清理。

改进:

对缓存设置较长的过期时间,大于逻辑过期时间.

3. 缓存预热

针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。

缓存雪崩

指缓存内同时出现大量 key 过期或者 Redis 奔溃重启,没有缓存任何key,导致大量的请求都直接落到了数据库上，对数据库造成了巨大的压力。

1. 随机过期时间

通过在 Redis 重构缓存时在过期时间中加入随机抖动使得过期时间均匀分散,避免了大量 key 同时过期的情况.

2. Redis 集群

通过构建 Redis 主从架构+哨兵机制实现, 当主节点下线后,哨兵会自动把从节点提升为主节点. 多个节点保证了不会出现缓存全部消失的情况.

**服务降级 & 熔断

当数据库压力过大时：

返回默认值（如“系统繁忙，请稍后再试”）。
启用本地缓存（如 Caffeine）作为二级缓存。
使用限流（如 Sentinel、Hystrix）保护数据库。

3.预热数据

Redis RDB & AOF

Fri, 17 Oct 2025 00:00:00 +0000

RDB

RDB是对 Redis 某一瞬间保存的全量快照,本质上是一份二进制文件,用来在 Redis 重启或丢失数据后进行恢复,通常用作数据恢复、主从全量同步以及定期备份.

执行方式

1.手动

可以通过 `SAVE` 与 `BGSAVE` 手动执行 RDB 备份, `SAVE` 命令会在主线程内进行备份操作,此时Redis主线程会被堵塞直到写入 RDB 完成.
使用 `BGSAVE` 时 则是通过 `fork` 一个子线程进行写时复制写入硬盘,不会造成 Redis 主线程堵塞.

Copy-On-Write（写时复制） 是一种 优化内存使用和提升性能的系统级技术，广泛用于操作系统（如 Linux）、数据库、虚拟化等领域。

多个进程/线程共享同一份物理内存，只有当某个进程试图“修改”数据时，才真正复制一份私有副本。

读操作：直接共享原始数据，无需复制；

写操作：触发复制，之后修改的是副本，不影响原数据。

2. 自动(通过配置文件)

Redis 支持通过在 redis.conf 文件中配置 save 选项，让服务器每隔一段时间自动执行一次 BGSAVE 命令。save 选项可以设置多个保存条件，只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令。

【示例】redis.conf 中自动保存配置

# 900 秒内，至少对数据库进行了 1 次修改
save 900 1
# 300 秒内，至少对数据库进行了 10 次修改
save 300 10
# 60 秒内，至少对数据库进行了 10000 次修改
save 60 10000

只要满足以上任意条件，Redis 服务就会执行 BGSAVE 命令。

RDB 优缺点

优点

重启后加载快, 相比 AOF 命令执行式恢复, RDB本质就是压缩过的二进制文件,只需要将其全部读入内存即可.
相比 AOF RDB空间利用率更高.

缺点

备份频率较低,每次只能全量备份,如果在备份开始前发生故障,会导致丢失大量数据,无法满足强一致性.
备份时间长,如果数据量很大，保存快照的时间会很长.

AOF（Append Only File）

AOF 是 Redis 的另一种持久化机制，它通过记录服务器接收到的每一个写命令，以日志形式追加到文件末尾。在 Redis 重启时，通过重新执行 AOF 文件中的命令来恢复数据。AOF 文件是可读的文本格式，通常用于对数据安全性要求较高的场景。

执行方式

1. 手动

开启 AOF：默认关闭，需在 redis.conf 中设置 appendonly yes。
重写 AOF：执行 BGREWRITEAOF 命令，Redis 会 fork 一个子进程，根据当前数据库状态生成一个更紧凑的新 AOF 文件（利用 Copy-On-Write 机制，不阻塞主线程）。

2. 自动（通过配置文件）

AOF 的同步策略由 appendfsync 配置项控制，决定写命令何时从缓冲区刷入磁盘：

# 每次写操作都同步到磁盘（最安全，性能最差）
appendfsync always

# 每秒同步一次（默认推荐，平衡安全与性能）
appendfsync everysec

# 由操作系统决定何时同步（性能最好，但可能丢失较多数据）
appendfsync no

此外，AOF 重写也可自动触发，通过以下配置：

# 当 AOF 文件大小超过上一次重写后大小的指定百分比时，自动触发重写
auto-aof-rewrite-percentage 100
# AOF 文件至少达到指定大小（字节）才触发自动重写
auto-aof-rewrite-min-size 64mb

AOF 优缺点

优点

数据更安全：everysec 模式下最多丢失 1 秒数据，always 模式可做到几乎零丢失。
可读可编辑：AOF 是纯文本格式，若误操作（如误删 key），可手动修改文件删除对应命令后恢复。
自动压缩：通过重写机制，可将冗余命令（如多次 INCR）合并为一条 SET，减小文件体积。

缺点

文件体积大：相比 RDB，AOF 通常更大（尽管重写可优化）。
恢复速度慢：需逐条重放命令，大数据集下恢复时间远长于 RDB。
性能开销：尤其在 always 模式下，每次写操作都需同步磁盘，影响吞吐量。

RESTful API 设计原则

Fri, 10 Oct 2025 00:00:00 +0000

RESTful API 设计原则

无状态性 (Stateless)

无状态是指客户端和服务器之间的通信不依赖于历史消息，服务器不存储任何会话状态。每个请求都必须包含处理该请求所需的所有信息。

违反无状态原则的例子：

在用户认证中使用服务器端存储的 session，通过 sessionId 来验证用户信息
服务器存储用户的登录状态或上下文信息

正确的做法：

使用 JWT (JSON Web Token) 进行用户认证
在请求头中携带认证信息（如 Authorization: Bearer ）
所有必要的状态信息都应由客户端提供

优势：

提高可扩展性：服务器可以轻松水平扩展
提高可靠性：单个服务器故障不会影响用户会话
简化负载均衡：请求可以被路由到任何服务器

可缓存性 (Cacheability)

服务器的响应必须明确地定义自身是否可缓存，以提高性能并减轻服务器负载。

实现方式：

使用 HTTP 缓存头来控制缓存行为
Cache-Control: 定义缓存策略（max-age, no-cache, no-store 等）
ETag: 资源版本标识符，用于条件请求
Last-Modified: 资源最后修改时间

缓存策略示例：

Cache-Control: max-age=3600  # 缓存1小时
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

优势：

减少服务器负载
提高响应速度
降低带宽消耗

统一接口 (Uniform Interface)

统一接口是 REST 架构的核心约束，确保系统组件之间的标准化通信。

资源标识 (Resource Identification)

每个资源都通过 URI 唯一标识，客户端通过 URI 访问和操作资源。

示例：

GET /api/v1/users/123
GET /api/v1/products/456/reviews

通过表述操作资源 (Manipulation of Resources Through Representations)

客户端通过发送资源的表述（如 JSON）来操作资源，而不是直接操作资源本身。

示例：

{
  "name": "John Doe",
  "email": "john@example.com"
}

自描述消息 (Self-descriptive Messages)

每条消息（请求或响应）都应包含足够的信息来描述如何处理它。

实现方式：

HTTP 方法：GET、POST、PUT、PATCH、DELETE
HTTP 头部：Content-Type、Accept、Authorization
HTTP 状态码：200 OK、404 Not Found 等

API 设计实践

资源命名规范

使用名词而非动词

在 REST 理念下，每个 URL 路径都代表一个资源，通过 HTTP 方法来表示操作动作。

良好示例：

- https://api.example.com/v1/zoos
- https://api.example.com/v1/animals
- https://api.example.com/v1/employees

避免的示例：

- https://api.example.com/v1/getUsers
- https://api.example.com/v1/createOrder
- https://api.example.com/v1/deleteProduct

使用复数名词

这是一个常见的约定，用于表示资源集合。

示例：

GET /users          # 获取所有用户
GET /users/123      # 获取特定用户
POST /users         # 创建新用户
PUT /users/123      # 更新用户信息
DELETE /users/123   # 删除用户

使用层级结构

展示资源之间的关系，但避免过深的嵌套。

良好示例：

GET /users/123/orders          # 获取用户 123 的所有订单
GET /users/123/orders/456      # 获取特定用户的特定订单

避免过深嵌套：

# 避免这种过深的嵌套
GET /users/123/orders/456/items/789/reviews/101

HTTP 方法语义

方法	语义	幂等性	安全性
GET	获取资源	是	是
POST	创建资源	否	否
PUT	更新完整资源	是	否
PATCH	部分更新资源	否	否
DELETE	删除资源	是	否

完整示例：

GET    /zoos                    # 列出所有动物园
POST   /zoos                    # 新建一个动物园
GET    /zoos/123                # 获取指定动物园的信息
PUT    /zoos/123                # 更新指定动物园的完整信息
PATCH  /zoos/123                # 更新指定动物园的部分信息
DELETE /zoos/123                # 删除指定动物园
GET    /zoos/123/animals        # 列出指定动物园的所有动物
DELETE /zoos/123/animals/456    # 删除指定动物园的指定动物

版本控制 (Versioning)

在 API 设计中加入版本控制机制，确保向后兼容性和系统的可扩展性。

实现方式：

URL 路径版本控制（推荐）：/api/v1/users
查询参数版本控制：/api/users?version=1
请求头版本控制：Accept: application/vnd.example.v1+json

推荐使用 URL 路径版本控制：

GET /api/v1/users
POST /api/v2/users

优势：

支持并行开发和测试
提供向后兼容性
便于 API 演进和废弃

HTTP 状态码规范

使用标准化的 HTTP 状态码来描述请求的处理结果。

常用状态码

2xx 成功

200 OK - 请求成功
201 Created - 资源创建成功
204 No Content - 请求成功，无返回内容

3xx 重定向

301 Moved Permanently - 资源永久移动
304 Not Modified - 资源未修改（缓存相关）

4xx 客户端错误

400 Bad Request - 请求参数错误
401 Unauthorized - 未认证
403 Forbidden - 无权限
404 Not Found - 资源不存在
409 Conflict - 资源冲突
422 Unprocessable Entity - 请求格式正确但语义错误

5xx 服务器错误

500 Internal Server Error - 服务器内部错误
503 Service Unavailable - 服务不可用

查询参数设计

使用查询参数进行过滤、分页、排序等操作，避免创建复杂的多级 URL。

常用查询参数模式

过滤：

GET /articles?published=true&category=tech
GET /users?status=active&role=admin

分页：

GET /users?page=2&limit=20
GET /products?offset=100&limit=50

排序：

GET /articles?sort=created_at&order=desc
GET /users?sort=name&order=asc

搜索：

GET /products?q=laptop
GET /users?search=john

响应格式标准化

API 响应应该采用结构化的 JSON 格式，保持一致性。

成功响应格式

{
  "status": "success",
  "data": {
    "id": 123,
    "name": "John Doe",
    "email": "john@example.com"
  },
  "meta": {
    "timestamp": "2025-10-10T14:30:00Z",
    "version": "1.0"
  }
}

总结

RESTful API 设计是一个系统性的工程，需要综合考虑架构原则、开发实践和安全性。以下是关键要点：

核心原则

无状态性 - 每个请求独立，不依赖会话状态
可缓存性 - 合理利用缓存提高性能
统一接口 - 标准化通信协议和资源操作

设计要点

使用名词表示资源，HTTP 方法表示操作
采用一致的命名规范和 URL 结构
实现适当的版本控制策略
使用标准的 HTTP 状态码
设计清晰的查询参数模式
保持响应格式的一致性

最佳实践

优先考虑 API 的可发现性和易用性
确保向后兼容性
实施适当的安全措施
提供详细的文档和错误信息

遵循这些原则和实践，可以设计出健壮、可扩展且易于维护的 RESTful API。