无休居士的博客

Redis是一个开源的、基于内存的键值对数据库，支持多种数据类型，如字符串（strings）、列表（lists）、集合（sets）、有序集合（sorted sets）、哈希表（hashes）、位图（bitmaps）、超日志（hyperloglogs）和地理空间索引（geospatial indexes）。由于其数据存储在内存中，Redis能够提供极高的数据读写速度。

通过上述表格和示例，你应该能够更好地理解在 Redis Cluster 模式下使用 Lua 脚本时需要注意的事项。必须带有至少一个键：确保 Lua 脚本中至少有一个键，以便代理可以根据键将脚本转发到正确的 DB 分片。多个键必须属于同一个槽位：使用哈希标签确保多个键属于同一个槽位，避免跨槽位操作。

综合来看，在redis cluster下使用lua脚本是唯一可以原子化操作序列的方式。为了避免跨slot操作key，可以使用hashtag，也可以用新特性直接操作。但是hashtag无疑是更好的方式，毕竟跨了slot对性能也略有影响，官方也不建议这么操作。

Redis 支持三种不同的集群模式：主从模式、哨兵模式和Cluster模式，各具特色，应对不同的应用场景。初始阶段，Redis 采用主从模式进行集群构建。在此模式中，主节点（master）负责数据写入，而从节点（slave）则用于数据读取和备份。若主节点发生故障，需人工介入，将某个从节点提升为新的主节点。但这种模式在故障恢复上效率较低，无法实现高度自动化。为了提升系统的高可用性，Redis 推出了哨兵模式。在此模式下，通过一个哨兵集群来监控主从节点的健康状态。

这些知识点涵盖了Redis的基本概念、数据结构、内存管理、缓存问题及解决方案、集群架构以及一些应用场景和操作命令。对于面试准备来说，重点可以关注持久化方式的选择、数据结构的应用场景、内存管理和缓存相关的问题解决方法等。

单个Redis支持的读写能力还是有限的,此时我们可以使用多个redis来提高redis的并发处理能力,这些redis如何协同,就需要有一定的架构设计,这里我们首先从主从(Master/Slave)架构进行分析和实现.

Redis是一个开源（BSD许可），内存数据结构存储，用作数据库，缓存和消息代理。它支持数据结构，如字符串，散列，列表，集合，带有范围查询的排序集，位图，超级日志，具有半径查询和流的地理空间索引。Redis具有内置复制，Lua脚本，LRU驱逐，事务和不同级别的磁盘持久性，并通过Redis Sentinel和Redis Cluster自动分区。您可以对这些类型运行原子操作，例如附加到字符串;递增哈希值;将元素推送到列表中;计算集合交集， 并集和差异;或者在排序集中获得排名最高的成员。

热 key 问题就是突然有几十万的请求去访问 redis 上的某个特定 key，那么这样会造成流量过于集中，达到物理网卡上限，从而导致这台 redis 服务器直接宕机。

简单来说，如果一个 key 对应的 value 所占用的内存比较大，那这个 key 就可以看作是 bigkey。具体多大才算大呢？人认为：只有影响的查询效率的Key才叫BigKey！

Redis 的有序集合（Sorted Set）是一种数据结构，它可以存储唯一的字符串成员，并为每个成员关联一个分数（score），以此来对成员进行排序。有序集合结合了集合的唯一性和分数排序的功能，使其非常适合需要按分数排序的应用场景。在Redis内部，有序集合通常使用跳跃表（skiplist）来实现，这使得插入、删除和查找操作的时间复杂度接近O(log N)。跳跃表的使用使得有序集合在处理大量数据时依然能够保持高效的性能。

Ziplist在存储小数据集时非常高效，但由于其紧凑存储的特性，在进行插入、删除和更新操作时可能会涉及到内存的重新分配和复制。因此，Ziplist最适合用于内存敏感的应用场景，特别是当数据集较小且操作以读取为主时。对于大型数据集或频繁的写操作，Redis可能会选择其他更适合的数据结构。

Quicklist 是 Redis 3.2 引入的一种新的数据结构，旨在优化列表类型的存储。Quicklist 是一种链表结构，其中每个节点都是一个ziplist。这样做的目的是结合ziplist的优点（内存效率）和传统链表的优点（更好的插入和删除性能）。在Redis 7.0版本之前，quicklist是由双向链表和压缩列表构成的。然而，在Redis 7.0版本中，quicklist的底层实现由双向链表和压缩列表变为了由双向链表和listpack构成的结构。

RedLock方案相比普通的Redis分布式锁方案可靠性确实大大提升。但是，任何事情都具有两面性，因为我们的业务一般只需要一个Redis Cluster，或者一个Sentinel，但是这两者都不能承载RedLock的落地。如果你想要使用RedLock方案，还需要专门搭建一套环境。所以，如果不是对分布式锁可靠性有极高的要求（比如金融场景），不太建议使用RedLock方案。当然，作为基于Redis最牛的分布式锁方案，你依然必须掌握的非常好，以便在有需要时（比如面试）能应付自如。

当Redis在线上环境中出现超时问题时，首要任务是快速定位并解决。首先，通过监控系统确认问题的存在，并启用告警机制。接着，分析Redis日志以寻找错误信息。检查服务器资源使用情况，包括CPU、内存及磁盘IO。利用INFO命令获取Redis状态，并通过SLOWLOG检查是否存在慢查询。调整Redis配置，如调整最大内存限制，优化客户端连接管理策略。必要时，考虑水平或垂直扩展来缓解负载。最后，总结经验教训，分享给团队，防止类似问题再次发生。

在 Redis 的上下文中，“psync”是指部分同步（partial synchronization）的一个缩写，它是 Redis 主从复制机制的一部分。当 Redis 的从节点（slave）与主节点（master）断开连接后重新连接时，如果从节点已经有了部分数据，那么在重新建立连接后，不需要进行完整的数据同步，而是只需要同步从上次断开连接后主节点发生改变的数据部分即可。这就是所谓的部分同步（psync）。

对于缓存与数据库分离的场景，在结合了业界多家公司的实践经验以及ROI权衡之后，前述的两个最佳实践是被应用的最为广泛的，尤其是最佳实践一，应该作为我们日常应用的首选。同时，为了最大限度的避免每个最佳实践背后可能发生的不一致性问题，我们还需要切合业务的特点，在关键的场景上做一些保障一致性的设计（比如前述的营销在下单时使用数据库读而不是缓存读），这也显得尤为重要（毕竟如“背景”中所述，并不存在完美的技术方案）。

Redis 性能下降时，首先检查系统资源（CPU、内存、磁盘I/O、网络带宽）是否饱和。使用 `INFO` 命令检查 Redis 服务器状态，关注 `used_memory` 和 `used_memory_rss` 确认内存使用情况。查看 `slowlog` 日志定位慢查询。使用 `TOP` 或 `htop` 监控系统进程，排除外部干扰。优化大键和复杂命令的使用，定期执行 `BGREWRITEAOF` 和 `BGSAVE` 减少磁盘I/O阻塞。确保 Redis 与客户端之间的网络延迟低且稳定。必要时调整配置

Redis 支持多种高可用性和扩展性方案，包括主从复制、哨兵和集群。主从复制通过数据同步实现数据冗余和读写分离，提高系统可用性和负载均衡能力。哨兵系统则监控主从实例的健康状况，自动故障转移，增强系统的容错性。集群模式进一步提升了Redis的水平扩展能力，通过分区数据到多个节点上，不仅提高了吞吐量，还增强了系统的整体稳定性。每种方案都有助于构建更加健壮和高性能的Redis部署。

分布式系统绕不开的核心之一的就是数据缓存，有了缓存的支撑，系统的整体吞吐量会有很大的提升。通过使用缓存，我们把频繁查询的数据由磁盘调度到缓存中，保证数据的高效率读写。当然，除了在内存内运行还远远不够，我们今天就以具有代表性的缓存中间件Redis为例子，分析下，它是如何达到飞起的效率。

任何一门技术都有利有弊，技术的世界里没有银弹。所以，我们对使用到生产环境的任何一个技术，都要非常熟悉：知道它所擅长的和它的弱点，这样才能结合自己的项目特点，设计出更合理的架构，编写出最合理的代码，不给生产环境造成影响，不给公司带来损失 – 千万不要成为那个执行KEYS命令导致给公司造成金钱损失的人！

Redis作为一款高性能的内存数据库，具有丰富的功能和广泛的应用场景。通过文中关键点，读者可以全面了解Redis的基本原理、核心功能、高级特性和实战应用。合理利用Redis的各项特性，可以极大地提升应用的性能和稳定性。在实际部署和使用过程中，还需要注重性能优化、高可用性设计和安全性配置，确保系统的高效运行。