不瘦原来对 Redis 也是有个大概的了解(就你知道的多), 但是最近和大神聊天的过程中才明白自己知道的简直就是鸡毛蒜皮(让你得瑟), 所以不瘦打算从头在捋一遍, 顺便把过程也记录下来, 如果能给大家在学习 Redis 的道路上提供一条清晰的线索, 不瘦胖也瞑目了.
我们知道 Redis 没有直接使用 C 语言中的字符串, 而是定义了简单动态字符串 (simple dynamic string,SDS) 的抽象类型, 并将 SDS 用作 Redis 的默认字符串表示. 其中 SDS 数据结构如下:
- struct sdshdr {
- int len; // len 表示 buf 中存储的字符串的长度
- int free; // free 表示 buf 中空闲空间的长度
- char buf[]; // buf 用于存储字符串内容.
- };
可以看到, 就是将一个字符数组和两个整型变量封装在结构体中, 但是这一封装加上一些看似简单的方法 (大道至简) 就为 SDS 增加了很多特性:
二进制安全
和 C 语言字符串只能某种编码(如 ASCII), 并且出结尾不能有'\0'字符相比, SDS 也可以存储像图片, 音频, 视频这样的二进制数据
字符串长度计算, 时间复杂度为 O(1)
因为在 SDS 结构体中存储了 len, 计算长度时直接返回即可(以空间换时间), 而 C 语言要计算字符串长度时间复杂度为 O(n)
杜绝缓冲区溢出
我们知道在 C 语言拼接字符串时, 如果超出原字符串申请的内存大小就会导致缓冲区溢出, 而 SDS 的空间分配策略直接避免了溢出的可能性: 当对 SDS 修改时, 会先检查剩余空间是否 满足(free 变量的作用), 如果不满足, 则进行自动扩容.
减少修改带来内存分配次数
Redis 作为数据库经常被用于速度要求严苛, 数据被频繁修改的场合, 如果每次修改长度都需要执行一次内存重分配的话, 那么光是执行内存重分配的时间就会占去修改所用时间的 一大部分, 如果这种修改频繁地发生的话, 可能还会对性能造成影响.
为了应对这种应用场景, Redis 采取了两种策略: 增加长度时空间预分配(每次多申请点), 减少长度时空间惰性释放(只改 free 的大小, 不实际释放空间)
注意事项:
SDS 作为 key 时长度不能超过 512MB
参考:
《Redis 设计与实现》
这里是老瘦家的儿子, 如需转载请声明, 我替老瘦感谢你.
来源: https://www.cnblogs.com/art-geek/p/10140956.html