> For the complete documentation index, see [llms.txt](https://shniu.gitbook.io/cs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shniu.gitbook.io/cs/middleware/redis/redis-sheng-chan-an-li.md).

# Redis 生产案例

### 案例1

曾经有一个需求，要用 Redis 保存 5000 万个键值对，每个键值对大约是 512B，为了能快速部署并对外提供服务，一开始采用了云主机来运行 Redis 实例，在选择 Redis 云主机实例的内存容量时，通过计算得到大约需要 25 GB，当时使用了一个 32 GB 内存大小的云主机来运行 Redis，这样还有 7 GB 的剩余内存，同时还开启了 RDB，这样 Redis 故障后也可以恢复数据。

但是在实际运行过程中，Redis 的响应有时会非常慢。后来，使用 INFO 命令查看 Redis 的 `latest_fork_usec` 指标值（表示最近一次 fork 的耗时），结果显示这个指标值特别高，快到秒级别了。慢的**原因是 RDB 在持久化时 fork 子进程耗时较高。在使用 RDB 进行持久化时，Redis 会 fork 子进程来完成，fork 操作的用时和 Redis 的数据量是正相关的，而 fork 在执行时会阻塞主线程。数据量越大，fork 操作造成的主线程阻塞的时间越长。所以，在使用 RDB 对 25GB 的数据进行持久化时，数据量较大，后台运行的子进程在 fork 创建时阻塞了主线程，于是就导致 Redis 响应变慢了**。

可见，单机 Redis 存储容量过大时，如果开启了持久化机制，就有可能引发偶尔的响应变慢，会影响 Redis 的整体性能。Redis 的切片集群可以解决内存数据量大的问题，我们可以采取切片集群的方案，把 25 GB 的数据存储到 5 个 Redis 的实例上，这样每个实例上存储 5 GB 的数据，我们可以购买 5 个 8 GB 大小的实例来存储数据。而 5 GB 的数据在 fork 子进程时也会快速很多。

![](https://1617012602-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M5PFXCiDtVclypn0iMK%2F-MOWMf7MnM78T0Qw0eiQ%2F-MOWMhlS7VrBMxHw8H0s%2Fimage.png?alt=media\&token=85a1059a-6f6e-4804-b057-2f1637155f24)