关注 O(N) 命令中的 N
hgetall、lrange、smembers、zrange、sinter 等命令建议不要过多地使用，当使用时，需要明确 N 的值。
Redis 中的 hscan、sscan 和 zscan 命令可以用于遍历哈希表、集合和有序集合。这些命令可以通过迭代器逐步扫描数据集中的元素，而不会像 hgetall、smembers 和 zrange 那样一次性返回所有元素。在实际使用中，建议在使用这些命令时指定合适的 COUNT 参数，以避免一次性返回过多的元素导致 Redis 的性能下降。通常情况下，每次遍历返回1000个元素左右是比较合适的选择。但是具体的数量限制还取决于 Redis 的实际环境和硬件配置，需要根据实际情况进行调整。
禁用命令
禁止线上使用 keys、flushall、flushdb 等，因为 CRedis 是单线程工作，这些命令执行时间过长，易导致命令执行阻塞。建议通过 scan 的方式渐进式处理，或通过参数 disable-command-list 配置禁用命令。
FLUSHDB 和 FLUSHALL：这两个命令可以清空 Redis 中的所有数据，因此在生产环境中应该避免使用。
KEYS：此命令可以返回与指定模式匹配的所有键，但由于它会阻塞 Redis 服务器，因此在生产环境中不建议使用。
RANDOMKEY：此命令可以随机返回一个键，但由于它会阻塞 Redis 服务器，因此在生产环境中不建议使用。
INFO：此命令可以返回 Redis 服务器的各种统计信息和配置选项，但由于它会阻塞 Redis 服务器，因此在生产环境中不建议使用。
CONFIG：此命令可以用于修改 Redis 服务器的配置选项，但由于它可能会导致服务器崩溃，因此在生产环境中应该谨慎使用。
SHUTDOWN：此命令可以关闭 Redis 服务器，但由于它会导致数据丢失，因此在生产环境中应该避免使用。
BGREWRITEAOF 和 BGSAVE：这两个命令可以用于异步地重写 AOF 文件和 RDB 快照文件，但由于它们可能会消耗大量的系统资源，因此在生产环境中应该谨慎使用。
合理使用 Select
Redis 多数据库采用递增数字的命名方式，在使用过程中可随时使用 SELECT 更换数据库。数据库索引号 Index 用数字值指定，以0作为起始索引值。
Redis 支持多数据库操作方式，在标准版场景客户可以根据多 DB 进行数据区分。但是 Redis 本身是单线程处理数据，即使使用多 DB，业务请求也会受到其他DB 操作影响。在集群版场景，建议客户优先使用0号 DB，非0 DB 不支持扩容。并且在客户请求时，可以不执行 select 0，减少非必要交互。
适当使用批量操作
应用侧访问 Redis，其中较多一部分耗时是网络 RTT。如果应用需要做大量的 get 或者 set，可以适当使用 mget、mset 进行批量数据操作以降低网络 RTT 开销。使用 mget、mset 一般元素个数不超过500，mget 和 mset 的操作 Key 越大时，后端如果出现抖动或者扩容时，对业务影响也会更大。
原生命令：例如 mget、mset。
非原生命令：可以使用 pipeline 提高效率。
说明：
注意控制一次批量操作的元素个数，建议在500以内，同时注意批量操作的元素中是否有 Big key。
原生是原子操作，pipeline 是非原子操作。
pipeline 可以打包不同的命令，原生不支持。
pipeline 需要客户端和服务端同时支持。
不建议使用事务
Redis 的事务功能较弱，不支持回滚，而且集群版本要求一次事务操作的 Key 必须在同一个 Slot 上。
集群版使用 Lua 的特殊要求
所有 Key 都应该由 KEYS 数组来传递。redis.call/pcall 里面调用的 Redis 命令，Key 的位置必须是 KEYS array, 否则直接返回如下错误信息：
error，"-ERR bad lua script for redis cluster,all the keys that the script uses should be passed using the KEYS array"单个 Lua 脚本操作的 Key 必须在同一个节点上，否则直接返回如下错误信息：
Lua script attempted to access a non local key in a cluster node关于 monitor 命令
Monitor 本身对 Redis 的性能有一定的影响。日常使用时，只用于分析命令的执行，不用于监控。若不进行相关问题排查和分析时，不建议开启。必要情况下，使用 Monitor 命令时，需要注意及时停止，不要长时间开启。
使用 Hashtag 建议
Hashtag 是 Redis 集群提供的一种特殊规则，用于通过特定语法强制将多个不同的键（Key）分配至同一个哈希槽（Hash Slot）。其主要目的是为了支持那些要求所有键必须位于同一槽位的跨键操作。如使用不当，Hashtag 将导致严重的数据与请求倾斜问题，且该问题无法通过集群扩容解决。
数据倾斜（Memory Skew）：大量使用相同 Hashtag 的键会聚集在集群的某一个节点上，导致该节点内存使用率远高于其他节点，可能提前触发内存告警或写满宕机。
请求倾斜（Hotspot）：所有针对这些数据的读写请求都会命中同一个节点，使其成为性能瓶颈，导致延迟增加，甚至拖垮整个集群。
不可扩容性：由于哈希槽的计算依赖于固定的 Hashtag，因此由此引发的倾斜问题无法通过简单地增加集群节点来缓解。数据会根据 Hashtag 始终落在特定节点，新节点无法分担其负载。
遵循以下原则，以安全、高效地使用 Hashtag：
1. 最小化与拆分原则：
不要为所有关联数据使用一个庞大、统一的 Hashtag（例如所有用户数据都用 {global} 或 {user_id}）。
应该将数据按业务类型、功能模块或访问模式进行垂直拆分，使用不同的、细粒度的 Hashtag。
2. 保证均匀分布：
确保 Hashtag 值本身（即花括号内的内容）在整体上均匀分布。例如，直接使用随机性不高的用户 ID 作为 Hashtag 可能依然是危险的。
可以考虑在原始 ID 后添加后缀（如 {user_id:1}, {user_id:2}）来进行人工分片，但需在应用中维护好映射规则。
3. 仅在必要时使用：
仅在必须使用事务、Lua 脚本或多键命令时，才使用 Hashtag。对于无关的键，切勿滥用此特性。
禁止将 Redis 作为消息队列
严禁将 Redis 当作消息队列使用，否则可能会有容量、网络、效率、功能方面的多种问题。
