^^《榴芒客服系统》是我们工作室开发的在线客服系统欢迎下载试用《榴芒客服系统》https://blog.csdn.net/look4liming/article/details/164755808底层数据结构Redis对外暴露了String、List、Hash、Set、ZSet等抽象类型但在底层它为了在内存占用和操作效率之间取得极致平衡会根据数据规模动态切换实现方式。以String类型为例Redis没有直接使用C语言原生的字符串而是构建了SDS简单动态字符串。SDS通过预分配和惰性释放空间避免了频繁的内存重分配同时记录了字符串长度使得获取长度操作从O(N)变为O(1)并且保证了二进制安全。这种策略在集合类型上体现得更明显。例如Hash类型在元素较少时会使用压缩列表ziplist这是一种连续内存结构能极大节省内存只有当元素数量或单个元素大小超过阈值时才会转为哈希表dict以保证O(1)的查找效率。ZSet有序集合也类似小数据量用压缩列表大数据量则采用跳跃表skiplist与哈希表组合兼顾范围查询与单点查找。单线程与IO多路复用“Redis为什么快”是深入理解它的必答题。除了纯内存操作其核心在于IO多路复用与单线程命令处理的组合。Redis的网络模型基于epollLinux 下一个线程可以同时监听成千上万个连接避免了为每个连接创建线程的开销。当事件就绪后命令的执行却是单线程串行化的。这看似是瓶颈实则避免了多线程环境下的锁竞争和上下文切换开销保证了操作的原子性这也是Redis能轻松支撑10万QPS的原因之一。持久化Redis提供了两种持久化方式它们代表了不同的取舍。RDB是周期性的全量快照文件紧凑、恢复速度快适合备份和灾难恢复但可能丢失最后一次快照后的数据。AOF则记录每一次写命令数据安全性更高最高可配置为每秒同步但文件更大恢复时需要重放所有命令。Redis 4.0之后引入了混合持久化它结合了两者优势AOF重写时将当前数据以RDB格式写入文件头部后续的写命令则以AOF格式追加。这样重启时先加载RDB部分快速恢复再重放少量AOF命令兼顾了速度与安全。架构演化为了突破单机内存和可用性的限制Redis的架构经历了清晰的演化路径主从复制实现了数据的热备份和读写分离Master写、Slave读但故障恢复需要人工介入。哨兵Sentinel在主从基础上引入监控者。哨兵集群通过投票机制在Master宕机时自动进行故障转移选出一个Slave升级为新Master实现了高可用。Cluster集群为了解决单机存储容量和写性能的瓶颈Redis Cluster采用无中心化设计将数据分片到16384个哈希槽slot 中每个节点负责一部分槽位。节点间通过Gossip协议通信客户端可直连任意节点存取数据。留意深入理解Redis也意味着要清楚它的边界。例如大Key如一个包含百万元素的 Hash在执行HGETALL或DEL时可能阻塞单线程主进程甚至引发主备切换。热Key则可能导致集群分片负载不均。此外Redis的事务功能相对简单不支持回滚且作为消息队列在可靠性和堆积能力上不如Kafka等专用中间件。^^《榴芒客服系统》是我们工作室开发的在线客服系统欢迎下载试用《榴芒客服系统》https://blog.csdn.net/look4liming/article/details/164755808