经验：
一定要记住不要使用密钥和生产环境。 网友测试：
访问100万条数据，10000条数据，100万条数据一起存储执行。 显示CPU占用率为11.0%，CPU立即大幅上升。
项目指导
列表数据类型
List 元素的数量没有限制。 单个元素的最大值为 512 MB。 建议列表中的元素数量小于 8192，并且值的最大长度不应超过 1 MB。
设置数据类型
套数没有限制。 单个元素的最大值为 512 MB。 建议集合中的元素数量小于8192，并且值的最大长度不超过1MB。
设置数据类型
套数没有限制。 单个元素的最大值为 512 MB。 建议集合中的元素数量小于8192，并且值的最大长度不超过1MB。
哈希数据类型
字段数量没有限制。 单个元素的最大值为 512 MB。 建议元素数量小于 8192。最大值长度不超过 1 MB。
数据库数量限制
每个实例支持256个DB。
Redis命令支持
有关详细信息，请参阅文档。
监控报警
云数据库Redis版本不提供容量报警，用户需要在云监控中进行配置。 配置方法请参考文档。
建议设置以下监控告警：实例故障、实例主备倒换、已使用连接百分比、操作失败次数、已使用容量百分比、写入带宽使用率、读取带宽使用率。
数据过期删除策略
- 主动过期，系统后台会定期检测，当发现过期密钥时，将其删除。
- 被动过期，当用户访问某个密钥时，如果该密钥已过期，则会被删除。
空闲连接回收机制
服务器不会主动回收Redis空闲连接，由用户管理。
数据持久化策略
使用模式，每秒 fysnc。
内存管理优化
Redis Hash 内部有一个值。 如果Map的成员数量比较少，会采用类似一维线性的紧凑格式来存储Map，这样可以节省大量指针的内存开销。 该参数控制对应 redis.conf 配置文件中的以下2项：
hash-max-zipmap-entries 64 hash-max-zipmap-value 512
当值Map中的成员不超过几个时，将以线性紧凑格式存储。 默认为64，即如果value的成员数少于64，将使用线性紧凑存储。 如果数值超过这个值，就会自动转为实数。
hash-max--value的含义是当值Map中每个成员值的长度不超过一定字节数时，将采用线性紧凑存储来节省空间。
如果以上两个条件中的任何一个超过设定值，就会转换为true，并且不再节省内存。 那么这个值是不是越大越好呢？ 答案当然是否定的。 优点是搜索和操作。 时间复杂度是O(1)，但是放弃Hash而使用一维存储，时间复杂度会是O(n)。 如果
如果成员数量少，影响就小，否则会严重影响性能，所以这个值的设置必须权衡。 一般来说，是时间成本和空间成本之间最根本的权衡。
list-max-ziplist-value 64 list-max-ziplist-entries 512
如果列表数据类型节点值小于字节数，则将使用紧凑存储格式。 如果列表数据类型节点值小于字节数，则将使用无指针紧凑存储格式。
内存预分配：
Redis的内部实现在内存分配方面并没有做太多的优化（比较）。 内存碎片在一定程度上会存在，但大多数情况下这不会成为Redis的性能瓶颈。 但是，如果 Redis 内部存储的大部分数据是数值类型的话，Redis 内部会采用一种方法来节省分配内存的开销，即系统启动时，首先分配 1 到 n 的多个数值对象并将它们放入池中。 如果存储的数据恰好是这个数值范围内的数据，则直接从池中取出对象，并通过引用计数来共享。 这样，当系统存储大量数值时，也可以在一定程度上节省内存并提高性能。 该参数值n的设置需要修改源代码中的一行宏定义S。 默认值为10000，您可以根据自己的需要进行修改。 修改后重新编译即可。
持久化机制：
定期快照法()：
这种持久化方式其实就是Redis内部的一个定时器事件。 每隔固定时间检查当前数据的变化次数和变化时间是否满足配置的持久化触发条件。 如果是，则通过操作系统创建 fork 调用。 子进程，这个子进程默认会和父进程共享相同的地址空间。 这时，子进程就可以遍历整个内存进行存储操作，而主进程仍然可以提供服务。 当有写入时，操作系统以内存页为单位进行Copy-on-write，以保证父子进程不会互相影响。
这种持久化的主要缺点是，计划的快照仅代表一段时间内的内存映像，因此系统重新启动将丢失上次快照和重新启动之间的所有数据。
基于语句方法（aof）：
aof方法其实和mysql的基于语句的方法类似，即每一条改变Redis内存数据的命令都会追加到一个日志文件中，也就是说这个日志文件就是Redis的持久化数据。
aof方法的主要缺点是附加日志文件可能会导致大小过大。 当系统重启恢复数据时，如果使用aof方式，数据加载会非常慢。 加载几十GB的数据可能需要几个小时。 当然，这是很耗时的。 这并不是因为磁盘文件读取速度慢，而是因为所有读取的命令都必须在内存中执行。 另外，由于每个命令都需要写入一条日志redis主要消耗什么物理资源，因此使用aof时Redis的读写性能也会有所降低。
您可以考虑将数据保存到不同的Redis实例中。 每个实例的内存大小约为2G。 这样就避免了把鸡蛋放在一个篮子里，不仅可以减少缓存故障对系统的影响，还可以加快数据恢复速度。 ，但也给系统设计带来了一定的复杂度。
Redis持久化崩溃问题：
有Redis在线运维经验的人会发现，Redis使用了大量的物理内存，但在不超过实际总物理内存容量时就会变得不稳定甚至崩溃。 有人认为它是一个基于快照持久化的分叉系统。 这种观点是不准确的，因为fork调用的copy-on-write机制是基于操作系统页单位的，即只有写入的脏页才会被复制，但一般来说，你的系统不会在短时间内写入所有页时间，导致复制。 那么是什么原因导致Redis崩溃呢？
答案是Redis持久化使用IO。 所谓IO是指Redis使用物理内存Page Cache对持久化文件进行写入和读取操作，而大多数数据库系统使用IO来绕过这层Page。 Cache 自行维护数据缓存。 当Redis持久化文件（尤其是快照文件）过大时，在读写时，磁盘文件中的数据会像操作系统一样加载到物理内存中。 文件的一层Cache，而这层Cache的数据和Redis内存中管理的数据实际上是重复存储的。 虽然在物理内存紧张的时候内核会淘汰Page Cache，但是内核可能会认为某个Page Cache更重要，而让你的进程启动Swap，那么你的系统就会开始变得不稳定或者崩溃。 我们的经验是，当你的Redis物理内存使用量超过总内存容量的3/5时，就会变得更加危险。
总结：
根据业务需求选择合适的数据类型，针对不同的应用场景设置相应的紧凑存储参数。
当业务场景不需要数据持久化时，关闭所有持久化方法可以达到最好的性能和最大的内存使用率。
如果需要使用持久性，请根据是否可以容忍重启时丢失部分数据来选择快照模式和语句追加模式。 不要使用虚拟内存和模式。
不要让你的Redis所在机器的物理内存使用超过总实际内存的3/5。
redis.conf 中的选项告诉 Redis 在使用了多少物理内存后开始拒绝后续的写入请求。 该参数可以保护您的 Redis 不使用过多的物理内存。 导致swap，最终严重影响性能甚至崩溃。
redis.conf文件中的vm-没有
常用内存优化方法及参数
通过我们上面的实现分析，我们可以看到redis实际的内存管理成本是非常高的，也就是占用了太多的内存。 作者对此也很清楚，所以他提供了一系列的参数和手段来控制和节省内存。
首先也是最重要的一点就是不要开启Redis的VM选项，即虚拟内存功能。 这原本是Redis的一种持久化策略，用于存储物理内存之外的数据，并将其换入换出内存和磁盘。 但是，它的内存管理成本也非常高，而且后面我们会分析这种持久化策略还不成熟，所以要关闭VM功能，请检查你的redis.conf文件中的vm-是否为否。
其次，最好在redis.conf中设置该选项。 该选项告诉 Redis 在使用了多少物理内存后开始拒绝后续的写入请求。 这个参数可以很好的保护你的Redis不被过度使用。 物理内存过多会导致swap，最终会严重影响性能甚至崩溃。
此外，Redis针对不同的数据类型提供了一组参数来控制内存的使用。 之前我们详细分析过，Redis Hash 里面有一个值。 如果Map的成员数量比较少，会使用类似于一维线性的紧凑格式。 存储Map，节省了大量指针的内存开销。 该参数控制对应redis.conf配置文件中的以下两项：
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
hash-max-zipmap-entries
意思是当数值不超过Map中的成员个数时，会以线性紧凑格式存储。 默认为64，即如果value的成员数少于64，将使用线性紧凑存储。 如果数值超过这个值，就会自动转为实数。
hash-max--value的含义是当值Map中每个成员值的长度不超过一定字节数时，将采用线性紧凑存储来节省空间。
如果以上两个条件中的任何一个超过设定值，就会转换为true，并且不再节省内存。 那么这个值是不是越大越好呢？ 答案当然是否定的。 优点是搜索和操作。 时间复杂度是O(1)，但是放弃Hash而使用一维存储，时间复杂度会是O(n)。 如果
如果成员数量少，影响就小，否则会严重影响性能，所以这个值的设置必须权衡。 一般来说，是时间成本和空间成本之间最根本的权衡。
类似的参数包括：
list-max-ziplist-entries 512
注意：列表数据类型将在节点数以下使用无指针紧凑存储格式。
list-max-ziplist-value 64
注意：如果列表数据类型节点值大小小于字节数，则将使用紧凑存储格式。
set-max-intset-entries 512
注意：如果set数据类型的内部数据都是数值型且包含的节点数不超过节点数，则会以紧凑格式存储。
最后想说的是，Redis的内部实现并没有对内存分配做太多的优化。 内存碎片在一定程度上会存在，但大多数情况下这不会成为Redis的性能瓶颈。 但是，如果Redis内部存储的数据量很大，部分数据是数值的话，Redis内部会使用一种方法来节省分配内存的开销。 即系统启动时，首先分配1到n若干个数值对象，放入池中。 如果存储的数据恰好在这个数值范围内，则直接从池中取出对象，并通过引用计数来共享。 这样，当系统存储大量值时，也可以在一定程度上节省内存并提高性能。 这个参数值n的设置需要修改源代码中的一行宏定义S。 默认值为10000，您可以根据自己的需要进行修改。 修改后重新编译即可。
Redis持久化机制
由于Redis支持非常丰富的内存数据结构类型，如何将这些复杂的内存组织方式持久化到磁盘上是一个难题。 因此，Redis的持久化方式与传统数据库有很大不同。 Redis总共支持四种类型。 持久化方法有：
从设计思路上来说，前两种方法是基于所有数据都在内存的情况下，即数据量较小时提供磁盘登陆功能，而后两种方法是作者尝试的时候存储超出物理内存的数据，即大量数据的数据存储，截至本文，后两种持久化方式还处于实验阶段，vm方式基本已经被作者放弃，所以实际上只有前两个可以在生产环境中使用。 也就是说，Redis只能用于小数据。 海量存储（所有数据都可以加载到内存中），海量数据存储并不是Redis擅长的领域。 下面介绍这些持久化方法：
定期快照法()：
这种持久化方式其实就是Redis内部的一个定时器事件。 每隔固定时间检查当前数据的变化次数和变化时间是否满足配置的持久化触发条件。 如果是，则通过操作系统创建 fork 调用。 子进程，这个子进程默认会和父进程共享相同的地址空间。 这时，子进程就可以遍历整个内存进行存储操作，而主进程仍然可以提供服务。 当有写入时，操作系统以内存页为单位进行Copy-on-write，以保证父子进程不会互相影响。
这种持久化的主要缺点是，计划的快照仅代表一段时间内的内存映像，因此系统重新启动将丢失上次快照和重新启动之间的所有数据。
基于语句方法（aof）：
aof方法其实和mysql的基于语句的方法类似，即每一条改变Redis内存数据的命令都会追加到一个日志文件中，也就是说这个日志文件就是Redis的持久化数据。
aof方法的主要缺点是附加日志文件可能会导致大小过大。 当系统重启恢复数据时，如果使用aof方式，数据加载会非常慢。 加载几十GB的数据可能需要几个小时。 当然，这是很耗时的。 这并不是因为磁盘文件读取速度慢，而是因为所有读取的命令都必须在内存中执行。 另外，由于每个命令都需要写入一条日志，因此使用aof时Redis的读写性能也会有所降低。
虚拟内存模式：
虚拟内存方法是Redis用来将数据交换进和交换出用户空间的策略。 该方法实施效果较差。 主要问题是代码复杂、重启慢、复制慢等，已被作者放弃。
方式：
该方法是作者放弃虚拟内存方法（即传统的B树方法）后选择的新的实现方法。 目前仍处于实验阶段。 我们可以拭目以待，看看未来是否会推出。
Redis持久盘IO方式及其带来的问题
有Redis在线运维经验的人会发现，Redis使用了大量的物理内存，但在不超过实际总物理内存容量时就会变得不稳定甚至崩溃。 有人认为它是一个基于快照持久化的分叉系统。 这种观点是不准确的，因为fork调用的copy-on-write机制是基于操作系统页单位的，即只有写入的脏页才会被复制，但一般来说，你的系统不会在短时间内写入所有页时间，导致复制。 那么是什么原因导致Redis崩溃呢？
答案是Redis持久化使用IO。 所谓IO是指Redis使用物理内存Page Cache对持久化文件进行写入和读取操作，而大多数数据库系统使用IO来绕过这层Page。 Cache 自行维护数据缓存。 当Redis持久化文件（尤其是快照文件）过大时，在读写时，磁盘文件中的数据会像操作系统一样加载到物理内存中。 文件的一层Cache，而这层Cache的数据和Redis内存中管理的数据实际上是重复存储的。 虽然在物理内存紧张的时候内核会淘汰Page Cache，但是内核可能会认为某个Page Cache更重要，而让你的进程启动Swap，那么你的系统就会开始变得不稳定或者崩溃。 我们的经验是，当你的Redis物理内存使用量超过总内存容量的3/5时，就会变得更加危险。
下图是Redis读取或写入快照文件dump.rdb后的内存数据图：
总结：
根据业务需求选择合适的数据类型，针对不同的应用场景设置相应的紧凑存储参数。
当业务场景不需要数据持久化时，关闭所有持久化方法可以达到最好的性能和最大的内存使用率。
如果需要使用持久性，请根据是否可以容忍重启时丢失部分数据来选择快照模式和语句追加模式。 不要使用虚拟内存和模式。
不要让你的Redis所在机器的物理内存使用超过总实际内存的3/5。
===================================================
使用Redis时需要注意以下几点：
1.控制Redis中存储的所有密钥
数据库的主要功能是存储数据，但是开发者由于应用需求或者数据使用情况的变化而忽略数据库中存储的一些数据是很正常的，在Redis中也是如此。 您可能会忽略使某些密钥过期，或者您可能会因为应用程序的某个模块已被弃用而忘记数据。
无论哪种情况，Redis 都会存储一些不再使用的数据，无故占用一些空间。 Redis 的弱结构化数据模型使得很难破译集中存储的内容，除非您对键使用非常复杂的命名约定。 使用正确的命名将简化您的数据库管理。 当您通过应用程序或服务命名键时（通常使用冒号分隔键名称），您可以迁移、转换或删除数据。 易于识别。
Redis 的另一个常见用例是作为热门数据项目的辅助数据存储，其中大部分数据存储在其他数据库中，例如 Redis 或 Redis。 在这些用例中，当数据从主存储中删除时，开发人员经常忘记删除 Redis 中的相应数据。 在这种存在数据交叉存储的情况下，通常需要进行级联删除。 在这种情况下，可以通过在Redis配置中保存特定数据项的所有标识符来实现，以确保主数据库中的数据被删除后，系统会调用清理程序来删除所有相关的副本和信息。
2.控制所有键名的长度
上面我们说过应该使用适当的命名规则并添加前缀来标识数据方向，所以这一点似乎与此相悖。 但是，请不要忘记，Redis 是一个内存数据库，键越短，需要的空间就越少。 当然，当数据库中有数百万或数十亿个键时，键名的长度就会产生很大的影响。
例如：在32位的Redis服务器上，如果存储一百万个键，每个值的长度为32-，那么当使用6长度的键名时，大约会消耗96MB的空间，但是如果使用12长度的密钥名，空间消耗将增加到约111MB。 随着键数量的增加，15%的额外开销将会产生显着的影响。
3. 使用适当的数据结构
无论是内存使用还是性能，有时候数据结构都会产生很大的影响。 以下是一些您可以参考的最佳实践：
不要将数据存储为数千（或数百万）个单独的字符串，而是考虑使用哈希数据结构对相关数据进行分组。 哈希表非常高效，可以减少你的内存使用； 同时，哈希也更有利于细节抽象和代码可读性。
在适当的时候，使用列表而不是集合。 如果不需要使用set功能，List可以提供比set更快的速度，同时使用更少的内存。
无论是在内存消耗还是基本操作的复杂性方面，集合都是最昂贵的数据结构。 如果你只需要一种查询记录的方式，而不关心排序等属性，那么建议使用哈希表。
Redis 中一个经常被忽视的功能是 or （V2.2 之后）。 允许您对 Redis 值执行多个位级操作，例如一些轻量级分析。
4.使用SCAN时不要使用按键
从 Redis v2.8 开始，SCAN 命令已经可用，它允许使用游标从中检索键。 与KEYS命令相比，SCAN虽然无法一次性返回所有匹配结果，但避免了系统阻塞的高风险，允许部分操作在主节点上执行。
应该注意的是，SCAN 命令是基于游标的迭代器。 每次调用 SCAN 命令时redis主要消耗什么物理资源，都会向用户返回一个新的光标。 用户需要在下一次迭代中使用这个新的游标作为SCAN命令的游标参数来继续之前的迭代过程。 同时，使用SCAN，用户还可以使用模式和计数选项来调整命令。
SCAN相关命令还包括SSCAN命令、HSCAN命令和ZSCAN命令，分别用于集合、散列键和续集。
5. 使用服务器端Lua脚本
在Redis的使用过程中，Lua脚本的支持无疑为开发者提供了非常友好的开发环境，从而极大地解放了用户的创造力。 如果使用得当，Lua脚本可以给性能和资源消耗带来很大的提升。 脚本不是将数据发送到 CPU，而是允许您执行最接近数据的逻辑，从而减少网络延迟和数据的冗余传输。
在 Redis 中，Lua 的一个非常经典的用例是数据过滤或将数据聚合到应用程序中。 通过将处理工作流程封装到脚本中，您只需调用它即可在更短的时间内、用更少的资源获得更小的答案。
专家提示：Lua 很棒，但它也有一些问题，例如难以报告和处理错误。 明智的方法是使用 Redis 的 Pub/Sub 功能，并让脚本通过专用通道推送日志消息。 然后建立订阅者进程并进行相应的处理。
