首先

阅读/写作快速，并且能够以各种方式保存数据，因此Redis在作为缓存数据库方面非常受欢迎。然而，如果在实际运营系统中使用时不加考虑，数据可能会因为肥大化而变得非常难处理。

本次讨论将总结与数据肥大化问题紧密相关的挑战以及针对数据肥大化的策略。

在数据膨胀时凸显的问题

对于所装有的键是哪个，我变得不知所措。

由于Redis是一个基于内存的键值存储系统，随着数据量的增加，它开始占用服务器的内存容量。在这种情况下，如果对生产环境执行诸如keys *之类的命令，临时的内存使用量会急剧上升，为了控制内存使用量，Redis可能会删除键或者被OOM KILLER杀死整个Redis服务器，因此这些命令将无法使用。换句话说，无法确认Redis中包含哪些键，这将导致神秘的数据增加。

变得无法轻松添加从节点。

在数据量较少的情况下，可以通过一条命令轻松地添加从节点。然而，当数据量变大时，就需要突然非常小心了。当在Redis中添加从节点时，主节点会先将数据库的数据保存为文件，然后将该文件发送给从节点以供读取。但是，如果主节点的内存不足，保存为文件的过程可能因为内存不足而失败，导致无法添加从节点。

对于数据的快速增长所采取的应对策略

请以有足够空间设置的方式设置maxmemory。(Please set maxmemory with ample space)

在Redis中，您可以在redis.conf文件中设置maxmemory（Redis使用的最大内存量）。当超过设置的内存时，Redis会根据键删除策略（如allkey-lru）自动删除键。通常情况下，建议将maxmemory设置为可用服务器内存的一半左右（即将所需内存的两倍左右的内存配置给服务器）。

设置vm.overcommit_memory

当使用的内存达到一定程度时，可能会因为内存不足而导致BGSAVE失败，最坏情况下，可能会被OOM KILLER杀掉Redis进程。作为对策，可以设置overcommit_memory = 1，使其可以进行swap交换。

请执行以下命令来进行设置。

# sysctl vm.overcommit_memory=1

请在/etc/sysctl.conf文件中添加以下行。

vm.overcommit_memory = 1

避免创建拥有大量数据的密钥

由于Redis可以使用各种数据类型来存储数据，不仅限于常见的KeyValue格式，还包括Hash类型等复杂的数据结构。这些数据类型具有较好的内存利用效率，因此通常会在一个键上存储多个数据。但是，当一个键的分配数据变得过大（超过1GB等）时，当该键被删除时，主从服务器所保存的数据差异会变大，导致通常的同步操作无法进行，而是会进行bgsave操作，这会给Redis施加负载，可能会导致bgsave失败并停止数据同步。在这种情况下，需要通过像LTRIM这样的命令对数据进行修剪，或者将键分成多个键，以确保一个键不会持有过大的数据。

比如，我们考虑管理用户每个页面的访问时间这种情况。

user_page_access_time:
    "user_id:{page_id}": last_access_datetime

如果以这种方式持有，

用户数量乘以页数

每个键保存了一个数据，随着用户和页面数量的增加，数据量呈指数增长。

在这种情况下，我们可以通过将键分开为每个用户ID，以减少在一个键中存储的数据量。

user_page_access_time:{user_id}:
     "{page_id}": last_access_datetime

キーにExpireを設定する

実運用システムでは，放っておくとどんどんキー数は増加していきます．
そのため，データのライフサイクルを考え，可能な限りExpireを設定するようにします．
Expireを設定したキーはその時間がくると自動的に削除されるため，データ量の増加を防ぐことができます．
既にデータがある場合には，一度キー名を取得してから一括でExpireを付けるようなスクリプトを書いたので参考にしていただけたらと思います．

给Redis中的所有键添加过期时间

在这种情况下，如果存在许多不能设置过期时间的键（即需要永久保存的键），我们需要考虑是否适合使用Redis作为缓存。

最后

Redis是一种处理数据方便且易于操作的内存型数据库，它不仅速度快且拥有丰富的数据存储方式，并且还无需费用。因此，它非常受欢迎作为一个缓存数据库。但是由于其高度方便的特性，很容易超出缓存数据库的范畴而存储大量数据。考虑数据的生命周期，为了避免在Redis中保存过多的数据，运营团队需要谨慎操作。

请看这个

Redis文档
使用Redis时，我们需要估计两倍的容量才够用啊，这是怎么回事呢。