Redis开发与运维

[Danceiny]

《Redis开发与运维 》Google Drive

[Danceiny]

查看内部数据结构实现

> object encoding KEY

[Danceiny]

字符串

[Danceiny]

哈希

[Danceiny]

列表

[Danceiny]

集合

[Danceiny]

有序集合

[Danceiny]

GEO

• geopos key member [member ...]
• geodist key member1 member2 [unit]

unit: m, km, mi, ft

获取指定位置范围内的地理位置信息集合

• georadius key longtitude latitude radius m|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key] [storedist key]
• georadiusbymember key member radius m|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key] [storedist key]

获取geohash

• GEO的数据类型为zset，score就是geohash（member就是地名，因此删除就是zrem key member）
• geohash字符串越长，位置就越精确，geohash长度为9时，精度在2米左右
• 两个字符串越相似，则距离越近，redis使用字符串前缀匹配算法实现相关命令
• geohash编码和经纬度是可以互转的

[Danceiny]

RESP协议

发送命令

*<参数数量> CRLF
$<参数1的字节数> CRLF
<参数1> CRLF
...
$<参数N的字节数> CRLF
<参数N> CRLF

[Danceiny]

输入缓冲区 qbuf qbuf-free

每个客户端的输入缓冲区硬编码为1GB，一旦超过该值，客户端会被关闭。
输入缓冲区不受maxmemory限制，如果一个redis实例设置maxmemory为4G，已经存储2G数据库，此时输入缓冲区使用了3G，可能会导致数据丢失、键值淘汰、OOM等。
输入缓冲区过大的原因：

• redis的处理速度跟不上输入缓冲区的输入速度，且每次进入缓冲区的命令包含了大量的bigkey
• redis发生阻塞

输出缓冲区 obl oll omem

输出缓冲区由两部分组成：固定缓冲区（16KB）和动态缓冲区。

typedef struct redisClient {
    // 动态缓冲区列表
    list *reply;
    // 动态缓冲区列表长度（对象个数）
    unsigned long reply_bytes;
    // 固定缓冲区已经使用的字节数
    int bufpos;
    // 字节数组作为固定缓冲区
    char buf[REDIS_REPLY_CHUNK_BYTES];
} redisClient;

如何预防输出缓冲区出现异常？（比输入缓冲区异常概率更大）

• 限制普通客户端输出缓冲区
• 适当增大slave的输出缓冲区，如果master写入较大，slave的输出缓冲区可能会比较大，一旦slave客户端连接因为输出缓冲区溢出被kill，会造成复制重连。（？？？？）
• 限制容易让输出缓冲区增大的命令，如高并发下的monitor命令。

[Danceiny]

客户端类型

客户端配置

[Danceiny]

AOF

[Danceiny]

Redis阻塞 https://redis.io/topics/latency

[Danceiny]

阻塞的外在原因

1. CPU竞争
2. 内存交换
3. 网络问题
   

[Danceiny]

1. 对象内存
   key对象和value对象。

2. 缓冲内存

• 客户端缓冲

输入缓冲无法控制，最大1G；输出通过client-output-buffer-limit控制。

• 复制积压缓冲
• AOF缓冲

内存碎片

默认使用的内存分配器采用jemelloc，可选的还有glibc和tcmalloc。

[Danceiny]

redisObject对象