redis高级技巧操作，还有相关的内容

1.Redis 管道技术——Pipeline

• 管道技术是客户端提供的一种批处理技术，用于一次处理多个Redis命令，从而提高整个交互性能。
• 通常情况下Redis是单行执行的，客户端先向服务器发送请求，服务端接收并处理请求后再把结果返回给客户端，这种处理模式在非频繁请求时不会有任何问题。
• 如果出现集中大批量的请求时，因为每个请求都要经历先请求再响应的过程，这就会造成网络资源浪费，此时就需要管道技术来把所有的命令整合一次发给服务端，再一次响应给客户端，这样就能大大的提升了 Redis 的响应速度。

普通命令模式

管道模式

管道技术解决的问题
管道技术解决了多个命令集中请求时造成网络资源浪费的问题，加快了 Redis 的响应速度，让 Redis 拥有更高的运行速度。但要注意的一点是，管道技术本质上是客户端提供的功能，而非 Redis 服务器端的功能。

管道技术需要注意的事项
管道技术虽然有它的优势，但在使用时还需注意以下几个细节：

• 发送的命令数量不会被限制，但输入缓存区也就是命令的最大存储体积为 1GB，当发送的命令超过此限制时，命令不会被执行，并且会被 Redis 服务器端断开此链接；
• 如果管道的数据过多可能会导致客户端的等待时间过长，导致网络阻塞；
• 部分客户端自己本身也有缓存区大小的设置，如果管道命令没有没执行或者是执行不完整，可以排查此情况或较少管道内的命令重新尝试执行。

管道相关的总结
使用管道技术可以解决多个命令执行时的网络等待，它是把多个命令整合到一起发送给服务器端处理之后统一返回给客户端，这样就免去了每条命令执行后都要等待的情况，从而有效地提高了程序的执行效率，但使用管道技术也要注意避免发送的命令过大，或管道内的数据太多而导致的网络阻塞。

2.查询附近的人

我们所在的位置都可以用经度和纬度来标识，经度范围-180到180，纬度范围为-90到90。
纬度以赤道为界，赤道以南为负数，赤道以北为正数；经度以本初子午线（英国格林尼治天文台）为界，东边为正数，西边为负数。

Redis 在 3.2 版本中增加了 GEO 类型用于存储和查询地理位置，关于 GEO 的命令不多，主要包含以下 6 个：

• geoadd：添加地理位置
• geopos：查询位置信息
• geodist：距离统计
• georadius：查询某位置的其他成员信息
• goehash：查询位置的哈希值
• zrem：删除地理位置

基础命令的使用

• 添加地理位置
  我们先用百度地图提供的经纬度查询工具，地址：
  http://api.map.baidu.com/lbsapi/getpoint/index.html

找了以下 4 个地点，添加到 Redis 中
天安门：116.404269,39.913164 月坛公园：116.36,39.922461 北京欢乐谷：

116.499705,39.874635 香山公园：116.193275,39.996348
geoadd site 116.404269 39.913164 tianan
(integer) 1
geoadd site 116.36 39.922461 yuetan
(integer) 1
geoadd site 116.499705 39.874635 huanle
(integer) 1
geoadd site 116.193275 39.996348 xiangshan
(integer) 1

• 重点参数说明
  longitude表示经度
  latitude表示纬度
  member为经度纬度起的名字 命令支持一次添加一个或多个位置信息

查询位置信息

geopos site tianan
1) 1) "116.40541702508926392"
   2) "39.91316289865137179"

相关语法
geopos key member [member …]
此命令支持查看一个或多个位置信息。
距离统计

127.0.0.1:6379> geodist site tianan yuetan km
"3.9153"

https://www.hhlink.com/经纬度
相关语法

geodist key member1 member2 [unit]

unit 参数表示统计单位，它可以设置以下值：
• m：以米为单位，默认单位；
• km：以千米为单位；
• mi：以英里为单位；
• ft：以英尺为单位。
查询某位置内的其他成员信息

127.0.0.1:6379> georadius site 116.405419 39.913164 5 km
1) "tianan"
2) "yuetan"

此命令的意思是查询天安门（116.405419,39.913164）附近 5 公里范围内的成员列表。
相关语法

georadius key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC]

1. WITHCOORD
说明：返回满足条件位置的经纬度信息。

127.0.0.1:6379> georadius site 116.405419 39.913164 5 km withcoord
1) 1) "tianan"
   2) 1) "116.40426903963088989"
      2) "39.91316289865137179"
2) 1) "yuetan"
   2) 1) "116.36000186204910278"
      2) "39.92246025586381819"

2. WITHDIST
说明：返回满足条件位置与查询位置的直线距离。

127.0.0.1:6379> georadius site 116.405419 39.913164 5 km withdist
1) 1) "tianan"
   2) "0.0981"
2) 1) "yuetan"
   2) "4.0100"

3. WITHHASH
说明：返回满足条件位置的哈希信息。

127.0.0.1:6379> georadius site 116.405419 39.913164 5 km withhash
1) 1) "tianan"
   2) (integer) 4069885552230465
2) 1) "yuetan"
   2) (integer) 4069879797297521

4. COUNT count
说明：指定返回满足条件位置的个数。
例如，指定返回一条满足条件的信息，代码如下：

127.0.0.1:6379> georadius site 116.405419 39.913164 5 km count 1
1) "tianan"

5.ASC|DESC
说明：从近到远|从远到近排序返回。

127.0.0.1:6379> georadius site 116.405419 39.913164 5 km desc
1) "yuetan"
2) "tianan"
127.0.0.1:6379> georadius site 116.405419 39.913164 5 km asc
1) "tianan"
2) "yuetan"

当然以上这些可选参数也可以一起使用

127.0.0.1:6379> georadius site 116.405419 39.913164 5 km withdist desc
1) 1) "yuetan"
   2) "4.0100"
2) 1) "tianan"
   2) "0.0981"

查询哈希值

geohash site tianan
1) "wx4g0cgp000"

相关语法：

geohash key member [member ...]

此命令支持查询一个或多个地址的哈希值。

删除地理位置

zrem site xiaoming
(integer) 1

相关语法：

zrem key member [member ...]

此命令支持删除一个或多个位置信息。

应用场景
Redis 中的 GEO 经典使用场景如下：
• 查询附近的人、附近的地点等；
• 计算相关的距离信息。

小结
GEO 是 Redis 3.2 版本中新增的功能，只有升级到 3.2+ 才能使用，GEO 本质上是基于 ZSet 实现的，这点在 Redis 源码找到相关信息，我们可以 GEO 使用实现查找附近的人或者附近的地点，还可以用它来计算两个位置相隔的直线距离。

3.基数统计算法-HyperLogLog

为什么要使用HyperLogLog
在我们实际开发的过程中，可能会遇到这样一个问题，当我们需要统计一个大型网站的独立访问次数时，该用什么的类型来统计？
如果我们使用 Redis 中的集合来统计，当它每天有数千万级别的访问时，将会是一个巨大的问题。因为这些访问量不能被清空，我们运营人员可能会随时查看这些信息，那么随着时间的推移，这些统计数据所占用的空间会越来越大，逐渐超出我们能承载最大空间。
例如，我们用 IP 来作为独立访问的判断依据，那么我们就要把每个独立 IP 进行存储，以 IP4 来计算，IP4 最多需要 15 个字节来存储信息，例如：110.110.110.110。当有一千万个独立 IP 时，所占用的空间就是 15 bit*10000000 约定于 143MB，但这只是一个页面的统计信息，假如我们有 1 万个这样的页面，那我们就需要 1T 以上的空间来存储这些数据，而且随着 IP6 的普及，这个存储数字会越来越大，那我们就不能用集合的方式来存储了，这个时候我们需要开发新的数据类型 HyperLogLog 来做这件事了。

HyperLogLog介绍
HyperLogLog（下文简称为 HLL）是 Redis 2.8.9 版本添加的数据结构，它用于高性能的基数（去重）统计功能，它的缺点就是存在极低的误差率。
HLL 具有以下几个特点：
• 能够使用极少的内存来统计巨量的数据，它只需要 12K 空间就能统计 2^64 的数据；
• 统计存在一定的误差，误差率整体较低，标准误差为 0.81%；
• 误差可以被设置辅助计算因子进行降低。

基础使用

HLL 的命令只有 3 个，但都非常的实用。

添加元素

127.0.0.1:6379> pfadd key "redis"
(integer) 1
127.0.0.1:6379> pfadd key "java" "sql"
(integer) 1

相关语法：

pfadd key element [element ...]

此命令支持添加一个或多个元素至 HLL 结构中。
统计不重复的元素

127.0.0.1:6379> pfadd key "redis"
(integer) 1
127.0.0.1:6379> pfadd key "sql"
(integer) 1
127.0.0.1:6379> pfadd key "redis"
(integer) 0
127.0.0.1:6379> pfcount key
(integer) 2

从 pfcount 的结果可以看出，在 HLL 结构中键值为 key 的元素，有 2 个不重复的值：redis 和 sql，可以看出结果还是挺准的。
相关语法：

pfcount key [key ...]

此命令支持统计一个或多个 HLL 结构。
合并一个或多个 HLL 至新结构 新增 k 和 k2 合并至新结构 k3 中

127.0.0.1:6379> pfadd k "java" "sql"
(integer) 1
127.0.0.1:6379> pfadd k2 "redis" "sql"
(integer) 1
127.0.0.1:6379> pfmerge k3 k k2
OK
127.0.0.1:6379> pfcount k3
(integer) 3

相关语法

pfmerge destkey sourcekey [sourcekey ...]

4.布隆过滤器

HyperLogLog 可以用来做基数统计，但它没提供判断一个值是否存在的查询方法，那我们如何才能查询一个值是否存在于海量数据之中呢？
如果使用传统的方式，例如 SQL 中的传统查询，因为数据量太多，查询效率又低有占用系统的资源，因此我们需要一个优秀的算法和功能来实现这个需求。
开启布隆过滤器 在 Redis 中不能直接使用布隆过滤器，但我们可以通过 Redis 4.0 版本之后提供的 modules（扩展模块）的方式引入，本文提供两种方式的开启方式。

编译方式
下载并安装布隆过滤器

git clone https://github.com/RedisLabsModules/redisbloom.git
cd redisbloom
make # 编译redisbloom

编译正常执行完，会在根目录生成一个 redisbloom.so 文件。
启动 Redis 服务器

> ./src/redis-server redis.conf --loadmodule ./src/modules/RedisBloom-master/redisbloom.so

其中 --loadmodule 为加载扩展模块的意思，后面跟的是 redisbloom.so 文件的目录。
启动验证
服务启动之后，我们需要判断布隆过滤器是否正常开启，此时我们只需使用 redis-cli 连接到服务端，输入 bf.add 看有没有命令提示，就可以判断是否正常启动了，如下图所示：

如果有命令提示则表名 Redis 服务器已经开启了布隆过滤器。
布隆过滤器的使用 布隆过滤器的命令不是很多，主要包含以下几个：
• bf.add：添加元素
• bf.exists：判断某个元素是否存在
• bf.madd：添加多个元素
• bf.mexists：判断多个元素是否存在
• bf.reserve：设置布隆过滤器的准确率

5.缓存雪崩&缓存穿透

缓存雪崩
缓存雪崩是指在短时间内，有大量缓存同时过期，导致大量的请求直接查询数据库，从而对数据库造成了巨大的压力，严重情况下可能会导致数据库宕机的情况叫做缓存雪崩。
我们先来看下正常情况下和缓存雪崩时程序的执行流程图，正常情况下系统的执行流程如下图所示：

缓存雪崩的执行流程，如下图所示：

缓存雪崩的常用解决方案有以下几个。

随机化过期时间
为了避免缓存同时过期，可在设置缓存时添加随机时间，这样就可以极大的避免大量的缓存同时失效。
加锁排队
加锁排队可以起到缓冲的作用，防止大量的请求同时操作数据库，但它的缺点是增加了系统的响应时间，降低了系统的吞吐量，牺牲了一部分用户体验。
缓存穿透
缓存穿透是指查询数据库和缓存都无数据，因为数据库查询无数据，出于容错考虑，不会将结果保存到缓存中，因此每次请求都会去查询数据库，这种情况就叫做缓存穿透。
缓存穿透执行流程如下图所示：

其中红色路径表示缓存穿透的执行路径，可以看出缓存穿透会给数据库造成很大的压力。
缓存穿透的解决方案有以下几个。
使用过滤器
我们可以使用过滤器来减少对数据库的请求，例如使用我们前面所学的布隆过滤器。
缓存空结果
另一种方式是我们可以把每次从数据库查询的数据都保存到缓存中，为了提高前台用户的使用体验 (解决长时间内查询不到任何信息的情况)，我们可以将空结果的缓存时间设置得短一些，例如 3~5 分钟。

6.内存淘汰机制与算法

而 Redis内存淘汰机制指的是，当Redis 运行内存已经超过 Redis 设置的最大内存之后，将采用什么策略来删除符合条件的键值对，以此来保障 Redis 高效的运行。
Redis 最大运行内存
只有在 Redis 的运行内存达到了某个阀值，才会触发内存淘汰机制，这个阀值就是我们设置的最大运行内存，此值在 Redis 的配置文件中可以找到，配置项为 maxmemory。

内存淘汰执行流程，如下图所示：

查询最大运行内存
我们可以使用命令 config get maxmemory 来查看设置的最大运行内存

127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "0"

我们发现此值竟然是 0，这是 64 位操作系统默认的值，当 maxmemory 为 0 时，表示没有内存大小限制。

内存淘汰策略

查看 Redis 内存淘汰策略
我们可以使用 config get maxmemory-policy 命令，来查看当前 Redis 的内存淘汰策略

127.0.0.1:6379> config get maxmemory-policy
1) "maxmemory-policy"
2) "noeviction"

可以看出此 Redis 使用的是 noeviction 类型的内存淘汰机制，它表示当运行内存超过最大设置内存时，不淘汰任何数据，但新增操作会报错。

内存淘汰策略分类
早期版本的 Redis 有以下 6 种淘汰策略：
• noeviction：不淘汰任何数据，当内存不足时，新增操作会报错，Redis 默认内存淘汰策略；
• allkeys-lru：淘汰整个键值中最久未使用的键值；
• allkeys-random：随机淘汰任意键值;
• volatile-lru：淘汰所有设置了过期时间的键值中最久未使用的键值；
• volatile-random：随机淘汰设置了过期时间的任意键值；
• volatile-ttl：优先淘汰更早过期的键值。
在 Redis 4.0 版本中又新增了 2 种淘汰策略：
• volatile-lfu：淘汰所有设置了过期时间的键值中，最少使用的键值；
• allkeys-lfu：淘汰整个键值中最少使用的键值。
其中 allkeys-xxx 表示从所有的键值中淘汰数据，而 volatile-xxx 表示从设置了过期键的键值中淘汰数据。
修改 Redis 内存淘汰策略
设置内存淘汰策略有两种方法，这两种方法各有利弊，需要使用者自己去权衡。
• 方式一：通过“config set maxmemory-policy 策略”命令设置。它的优点是设置之后立即生效，不需要重启 Redis 服务，缺点是重启 Redis 之后，设置就会失效。
• 方式二：通过修改 Redis 配置文件修改，设置“maxmemory-policy 策略”，它的优点是重启 Redis 服务后配置不会丢失，缺点是必须重启 Redis 服务，设置才能生效。

内存淘汰算法
从内测淘汰策略分类上，我们可以得知，除了随机删除和不删除之外，主要有两种淘汰算法：LRU 算法和 LFU 算法。

LRU 算法
LRU 全称是 Least Recently Used 译为最近最少使用，是一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰。

1. LRU 算法实现
   LRU 算法需要基于链表结构，链表中的元素按照操作顺序从前往后排列，最新操作的键会被移动到表头，当需要内存淘汰时，只需要删除链表尾部的元素即可。
2. 近 LRU 算法
   Redis 使用的是一种近似 LRU 算法，目的是为了更好的节约内存，它的实现方式是给现有的数据结构添加一个额外的字段，用于记录此键值的最后一次访问时间，Redis 内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值（此值可配置），然后淘汰最久没有使用的那个。
3. LRU 算法缺点
   LRU 算法有一个缺点，比如说很久没有使用的一个键值，如果最近被访问了一次，那么它就不会被淘汰，即使它是使用次数最少的缓存，那它也不会被淘汰，因此在 Redis 4.0 之后引入了 LFU 算法，下面我们一起来看。

LFU 算法
LFU 全称是 Least Frequently Used 翻译为最不常用的，最不常用的算法是根据总访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。