3 进阶功能

3.1 慢查询

说明

慢查询发生在第 3 阶段（执行命令阶段）
客户端超时不一定慢查询，但慢查询是客户端超时的一个可能

配置

slowlog-man-len
1. 先进先出队列
2. 固定长度
3. 保存在内存内，即，随重启而重置
slowlog-log-slower-than
1. 慢查询阈值（微秒）
2. slowlog-log-slower-than = 0 ，记录所有命令
3. slowlog-log-slower-than < 0, 不记录任何命令

配置方法

默认值
1. config get slowlog-man-len = 128
2. config slowlog-log-slower-than = 10000
修改配置文件重启
- 一旦 Redis 运行之后，不建议进行重启操作
动态配置
1. config get slowlog-man-len value
2. config slowlog-log-slower-than value

命令

slowlog get [n] 获取慢查询队列
slowlog len 获取慢查询队列长度
slowlog reset 清空慢查询队列

tips

slowlog-man-len 不要设置过大。默认 10ms，通常设置 1ms
slowlog-log-slower-than 不要设置过小，通常设置 1000
理解生命周期
定期持久化查询

3.2 pipeline

通常情况下，执行一条命令就需要一次客户端和服务端的交互。而 redis 的命令时间是微秒级别的，那么提高 redis 的执行效率的一个主要方向就是减少服务器与客户端的交互频率。

pipeline 的功能就是将一组命令打包并发送到服务器，在服务器依次执行之后，再将结果打包返回给客户端，这样一来客户端与服务端就只需要交互一次，在涉及大量交互的情境下无疑十分地便利。

tips1

注意每次使用 pipeline 的数据携带量
一个 redis 服务器一次只能运行一条 pipeline

对比

这里我使用 python 对 redis 做了小实验。写入 100000 条数据的情况下，使用 pipeline 和不适用 pipeline 的耗时对比。

补充说明，这里使用了远程的 redis 服务器，更好地体现出交互过程在整个 redis 数据库操作中所占的时间比重。

def try_pipeline():
    start = time.time()
    with client.pipeline(transaction=False) as p:
        for foo in range(100000):
            key = 'uuid_{}'.format(foo)
            p.pfadd(key,foo)
        p.execute()
    print(time.time() - start)

def without_pipeline():
    start = time.time()
    for foo in range(100000):
        key = 'uuid_{}'.format(foo)
        client.pfadd(key,foo)
    print(time.time() - start)

输出结果如下

try_pipeline : 2.6968681812286377
without_pipeline : 3320.136715888977

3.3 发布订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

当有新消息通过 PUBLISH 命令发送给频道 channel1 时，这个消息就会被发送给订阅它的三个客户端：

p21

类比生产者-消费者模型进行理解。发送者对应生产者，订阅者对应消费者。

常用命令

subscribe channel 进行订阅监听
unsubscribe channel 解除订阅
publish channel message 进行发布消息广播

应用

顾名思义，发布订阅的一个典型的应用场景就是实现自动更新的订阅功能(类比于门户网站的关注功能)。

还有一个应用场景就是实时聊天系统。

个人(redis 初学者)感觉 redis 的订阅功能很粗糙，如果追求更加细致的发布订阅动能可以考虑诸如ActiveMQ等。

通过一个 bit 位来表示某个元素对应的值或者状态,其中的 key 就是对应元素本身。Bitmaps 本身不是一种数据结构，实际上它就是字符串（key 对应的 value 就是上图中最后的一串二进制），但是它可以对字符串的位进行操作。 Bitmaps 单独提供了一套命令，所以在 Redis 中使用 Bitmaps 和使用字符串的方法不太相同。可以把 Bitmaps 想象成一个以位为单位的数组，数组的每个单元只能存储 0 和 1，数组的下标在 Bitmaps 中叫做偏移量。

如，zxj 这个字符串
z 对应的二进制值为 01111010
x 对应的二进制值为 01111000
j 对应的二进制值为 01101010

常用命令1

GETBIT key offset 获取字符串值指定偏移量上的位(bit)
SETBIT key offset value 对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。
BITCOUNT key [start end] 计算给定字符串中，被设置为 1 的比特位的数量

bitop op dtstkey key [key…] 做多个 bitmap 的 and(交集),or(并集),not(非),xor(异或)操作并将结果保存在 destkey 中

bitpos key targetBit [start] [end]  计算位图指定范围(start到end,单位为字节，如果不指定就是获取全部)第一个偏移量对应的值等于targetBit的位置

127.0.0.1:6379[1]> set zxj zxj2333
OK
127.0.0.1:6379[1]> GETBIT zxj 1
(integer) 1
127.0.0.1:6379[1]> SETBIT zxj 1 0
(integer) 1
127.0.0.1:6379[1]> get zxj
":xj2333"
127.0.0.1:6379[1]> BITCOUNT zxj
(integer) 27

127.0.0.1:6379[1]> set tt tt
OK
127.0.0.1:6379[1]> BITOP and zxj tt
(integer) 2
127.0.0.1:6379[1]>

3.4 bitmap

应用1

参考自redis 用 setbit(bitmap)统计活跃用户

如果一个网站有 1 亿用户，假如 user_id 用的是整型，长度为 32 位，每天有 5 千万独立用户访问，如何判断是哪 5 千万用户访问了网站

方式一：用 set 来保存

使用 set 来保存数据运行一天需要占用的内存为

32bit * 50000000 = (4 * 50000000) / 1024 /1024 MB，约为200MB

运行一个月需要占用的内存为 6G，运行一年占用的内存为 72G

30 * 200 = 6G

方式二：使用 bitmap 的方式

如果 user_id 访问网站，则在 user_id 的索引上设置为 1，没有访问网站的 user_id，其索引设置为 0，此种方式运行一天占用的内存为

1 * 100000000 = 100000000 / 1024 /1024/ 8MB，约为12.5MB

运行一个月占用的内存为 375MB，一年占用的内存容量为 4.5G

由此可见，使用 bitmap 可以节省大量的内存资源

补充

bitmap 是 string 类型，单个值最大可以使用的内存容量为 512MB
setbit 时是设置每个 value 的偏移量，可以有较大耗时
bitmap 不是绝对好，用在合适的场景最好

有关 redis bitmap 的更详细知识可以参考掘金的 dzzgml 写的Redis-BitMap

3.5 HyperLogLog

Redis 在 2.8.9 版本添加了 HyperLogLog 结构。

Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的 。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数?
比如数据集 {1，2,1,2} 那么这个数据集的基数集为 {1，2}, 基数(不重复元素)为 2。基数估计就是在误差可接受的范围内，快速计算基数。

命令2

PFADD key element [element …] 新增元素
PFCOUNT key [key…] 获取基数的估计值
PFMERGE destkey sourcekey [sourcekey] 将多个 HyperLogLog 合并为一个 HyperLogLog

命令演示

127.0.0.1:6379[1]> PFADD 2020_02_09:unique:ids 'uuid-1' 'uuid-2' 'uuid-3' 'uuid-4'
(integer) 1
127.0.0.1:6379[1]> PFCOUNT 2020_02_09:unique:ids
(integer) 4
127.0.0.1:6379[1]> PFADD 2020_02_09:unique:ids 'uuid-1' 'uuid-90'
(integer) 1
127.0.0.1:6379[1]> PFCOUNT 2020_02_09:unique:ids
(integer) 5

向其中注入 100000 条数据，看看数据库的大小变化如何

# 注入数据之前
# Memory
used_memory:830624
used_memory_human:811.16K
used_memory_rss:7327744
used_memory_peak:908432
used_memory_peak_human:887.14K
used_memory_lua:33792
mem_fragmentation_ratio:8.82
mem_allocator:jemalloc-3.6.0

# 注入数据之后(with HyperLogLog)
# Memory
used_memory:890456
used_memory_human:869.59K
used_memory_rss:10792960
used_memory_peak:18084664
used_memory_peak_human:17.25M
used_memory_lua:33792
mem_fragmentation_ratio:12.12
mem_allocator:jemalloc-3.6.0


# 注入数据之后(without HyperLogLog)
# Memory
used_memory:9760408
used_memory_human:9.31M
used_memory_rss:18481152
used_memory_peak:18084664
used_memory_peak_human:17.25M
used_memory_lua:33792
mem_fragmentation_ratio:1.89
mem_allocator:jemalloc-3.6.0

很明显，使用 HyperLogLog 注入 10 万条数据占用的内存为 869.59K -811.16K = 58.43k , 而直接使用 set 键值对的方法，占用的内存接近9M 。

这个差距是非常巨大的，但是天下没有免费的午餐，那么 HyperLogLog 低内存的代价是什么呢？

127.0.0.1:6379> PFCOUNT loglog
(integer) 99556

查询一下基数估计值，发现并不是我们所插入的 10 万条那么多。

这就引出了 HyperLogLog 的一个最大的缺点，有一定的错误率 ，根据官方的数据来看，这个错误率大约是 0.81%.

同时，HyperLogLog 还有一个很显著的缺点，在于 没法取出单条数据 。

综上，在使用 HyperLogLog 之前，一定要衡量好是否可以接受它的缺点所带来的损失 。

补充1

更多关于 HyperLogLog 的知识可以看rainybowe 的 blog

3.6 GEO(geospatial)

GEO 特性是 Redis 3.2 版本的特性

官网的介绍如下，总的来说，就是用来进行地理位置的相关操作的(如：存储经纬度，计算两地距离，范围计算等)

Adds the specified geospatial items (latitude, longitude, name) to the specified key. Data is stored into the key as a sorted set, in a way that makes it possible to later retrieve items using a query by radius with theGEORADIUS or GEORADIUSBYMEMBER commands.

The command takes arguments in the standard format x,y so the longitude must be specified before the latitude. There are limits to the coordinates that can be indexed: areas very near to the poles are not indexable. The exact limits, as specified by EPSG:900913 / EPSG:3785 / OSGEO:41001 are the following:

    Valid longitudes are from -180 to 180 degrees.
    Valid latitudes are from -85.05112878 to 85.05112878 degrees.

The command will report an error when the user attempts to index coordinates outside the specified ranges.

Note: there is no GEODEL command because you can use ZREM in order to remove elements. The Geo index structure is just a sorted set.

常用命令3

geoadd key longitude latitude member [longitude latitude member …] 增加地理位置信息预处理
geopos key member [member …] 获取地理位置信息
geodist key member1 member2 [unit] 获取两个地理位置之间的距离
GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [ASC|DESC] [COUNT count] 获取指定位置范围的地理信息位置集合
- WITHDIST ：在返回位置元素的同时，将位置元素与中心之间的距离也一并返回。距离的单位和用户给定的范围单位保持一致
- WITHCOORD ：将位置元素的经度和维度也一并返回
- WITHHASH ：以 52 位有符号整数的形式，返回位置元素经过原始 geohash 编码的有序集合分值。这个选项主要用于底层应用或者调试，实际中的作用并不大。命令默认返回未排序的位置元素。通过以下两个参数，用户可以指定被返回位置元素的排序方式
- COUNT ：指定返回结果的数量
- ASC ：根据中心的位置，按照从近到远的方式返回位置元素。DESC ：根据中心的位置，按照从远到近的方式返回位置元素
- store key ：将返回结果的地理位置信息保存到指定键
- storedist key ：将返回结果距离中心节点的距离保存到指定键
GEORADIUSBYMEMBER key member radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [ASC|DESC] [COUNT count] 获取指定元素范围的地理信息位置集合

命令演示3

127.0.0.1:6379[1]> GEOADD cities:locations 116.28 39.55 bejing
(integer) 1
127.0.0.1:6379[1]> GEOADD cities:locations 117.12 39.08 tianjing
(integer) 1
127.0.0.1:6379[1]> GEOADD cities:locations 114.29 38.02 shijiazhuang 118.01 39.38 tangshan 115.29 38.51 baoding (integer) 3
127.0.0.1:6379[1]> GEOPOS cities:locations tianjing
1) 1) "117.12000042200088501"
   2) "39.0800000535766543"
127.0.0.1:6379[1]> GEODIST cities:locations bejing tianjing
"89206.0576"
127.0.0.1:6379[1]> GEORADIUSBYMEMBER cities:locations bejing 150 km
1) "bejing"
2) "tianjing"
3) "tangshan"
4) "baoding"