redis：redis终章(四)

1、基数统计计数Hyperloglog

1.1为什么会出现HLL

统计网站uv时如果将所有数据放在redis中会随着时间的推移，这些统计数据所占用的空间会越来越大，逐渐超出我们能承载最大空间，所以就出现了基数统计算法

1.2基数计数的含义

所谓的基数计数就是统计一组元素中不重复的元素的个数。如统计某个网站的UV(unique visitor通过互联网访问、浏览这个网页的自然人)，或者用户搜索网站的关键词数量；再如对一个网站分别统计了三天的UV，现在需要知道这三天的UV总量是多少，怎么融合多个统计值。

1.3基数统计的特点

①能够使用极少的内存来统计巨量的数据，它只需要 12K 空间就能统计 2^64 的数据；
②统计存在一定的误差，误差率整体较低，标准误差为 0.81%；
③误差可以被设置辅助计算因子进行降低。

1.4HLL的使用

pfadd key element [element]：添加一个或多个元素至 HLL 结构中。如果添加的element已经存在返回0添加失败，如果不存在返回1添加成功
pfcount key [key …]：统计不重复的元素

pfmerge destkey sourcekey [sourcekey …]：合并一个或多个 HLL 至新结构
pfmerge k3 k k2… ：新增 k 和 k2 取并集合并至新结构 k3 中

2、布隆过滤器

2.1为什么布隆过滤器会出现

用HLL做基数统计的时候，他只提供了添加，查询数量和合并三种方法，没有判断一个值是否存在的查询方法，如果使用传统的方式判断，例如 SQL 中的传统查询，因为数据量太多，查询效率又低有占用系统的资源，因此我们需要一个优秀的算法和功能来实现这个需求，这就是布隆过滤器产生的原因

2.2安装布隆过滤器

开启布隆过滤器 在 Redis 中不能直接使用布隆过滤器，但我们可以通过 Redis 4.0 版本之后提供的 modules（扩展模块）的方式引入，相当于python的第三方模块，需要自己导入了才能使用。

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

2.2.1第一步git下载安装包文件夹

提前换源，免得超时或者太慢，换源方式查看前面文章2种方式

2.2.cd进入文件夹make源码安装

2.2.3验证是否安装成功

有redisbloom.so这个可执行文件就成功了

2.3启动布隆过滤器

通过配置文件启动后要加入导入模块–loadmodule redisbloom的绝对路径,正常连接redis服务器
敲入布隆过滤器的命令如果像下图一样有提示则说明开启成功

2.4布隆过滤器的使用

bf.add key options：添加元素，有了返回0没有添加成功返回1

bf.exists key options：判断某个元素是否存在，存在返回1，不存在返回0
特点：当查询数据是如果因为存在错误率所以他说有该数据，该数据不一定存在，但是他说没有则该数据一定不存在

bf.madd key options：添加多个元素

bf.mexists key options：判断多个元素是否存在

bf.reserve key options(错误率 元素的存储大小) ：设置布隆过滤器的准确率，不能是已存在的key

3、缓存穿透/缓存雪崩/缓存击穿

3.1缓存雪崩

3.2缓存穿透

3.3缓存击穿

4、内存淘汰机制与算法

4.1为什么会有内存淘汰机制

当Redis 运行内存已经超过 Redis 设置的最大内存之后，将采用删除符合淘汰条件的键值对，以此来保障 Redis 高效的运行。

127.0.0.1:6379> config get maxmemory
"maxmemory"
"0"

64 位操作系统默认的值为 0 ，表示没有内存大小限制

127.0.0.1:6379> config get maxmemory-policy
"maxmemory-policy"
"noeviction"

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

4.2redis的内存淘汰机制有哪些

①noeviction：不淘汰任何数据，当内存不足时，新增操作会报错，Redis 默认内存淘汰策略
②allkeys-lru：淘汰整个键值中最久未使用的键值
③allkeys-random：随机淘汰任意键值
④volatile-lru：淘汰所有设置了过期时间的键值中最久未使用的键值
⑤volatile-random：随机淘汰设置了过期时间的任意键值
⑥volatile-ttl：优先淘汰更早过期的键值
在 Redis 4.0 版本中又新增了 2 种淘汰策略：
⑦volatile-lfu：淘汰所有设置了过期时间的键值中，最少使用的键值
⑧allkeys-lfu：淘汰整个键值中最少使用的键值
其中 allkeys-xxx 表示从所有的键值中淘汰数据，而 volatile-xxx 表示从设置了过期键的键值中淘汰数据。

4.3修改 Redis 内存淘汰策略

方式一：通过“config set maxmemory-policy 策略”命令设置。它的优点是设置之后立即生效，不需要重启 Redis 服务，缺点是重启 Redis 之后，设置就会失效。
方式二：通过修改 Redis 配置文件修改，设置“maxmemory-policy 策略”，它的优点是重启 Redis 服务后配置不会丢失，缺点是必须重启 Redis 服务，设置才能生效。

4.4内存淘汰算法

4.4.1LRU 算法

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

4.4.2LFU 算法

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

5、redis性能测试

5.1为什么要做性能测试

技术选型，比如测试 Memcached 和 Redis；
对比单机 Redis 和集群 Redis 的吞吐量；
评估不同类型的存储性能，例如集合和有序集合；
对比开启持久化和关闭持久化的吞吐量；
对比调优和未调优的吞吐量；
对比不同 Redis 版本的吞吐量，作为是否升级的一个参考标准。

5.2使用 redis-benchmark 进行性能测试

redis-benchmark一般在src里，通过下述命令可以查看所有的测试选项

翻译为中文就是

-h <hostname>：服务器的主机名（默认值为 127.0.0.1）。
-p <port>：服务器的端口号（默认值为 6379）。
-s <socket>：服务器的套接字（会覆盖主机名和端口号）。
-a <password>：登录 Redis 时进行身份验证的密码。
-c <clients>：并发的连接数量（默认值为 50）。
-n <requests>：发出的请求总数（默认值为 100000）。
-d <size>：SET/GET 命令所操作的值的数据大小，以字节为单位（默认值为 2）。
–dbnum <db>：选择用于性能测试的数据库的编号（默认值为 0）。
-k <boolean>：1 = 保持连接；0 = 重新连接（默认值为 1）。
-r <keyspacelen>：SET/GET/INCR 命令使用随机键，SADD 命令使用随机值。通过这个选项，基准测试会将参数中的 __rand_int__ 字符串替换为一个 12 位的整数，这个整数的取值范围从 0 到 keyspacelen-1。每次执行一条命令的时候，用于替换的整数值都会改变。通过这个参数，默认的测试方案会在指定范围之内尝试命中随机键。
-P <numreq>：使用管道机制处理 <numreq> 条 Redis 请求。默认值为 1（不使用管道机制）。
-q：静默测试，只显示 QPS 的值。精简测试不显示其他冗余的数据
–csv：将测试结果输出为 CSV 格式的文件。
-l：循环测试。基准测试会永远运行下去。
-t <tests>：基准测试只会运行列表中用逗号分隔的命令。测试命令的名称和结果输出产生的名称相同。
-I：空闲模式，只会打开 N 个空闲的连接，然后等待。

常用的测试，具体看自己需求通过上面的基准测试命令来测试

同样是每个指令执行 100次，可以看出 Pipeline 的性能几乎是普通命令的 8 倍， -P 10 表示每次执行 10 个 Redis 命令。

5.3基准测试的影响元素

①网络带宽和网络延迟可能是 Redis 操作最大的性能瓶颈，比如有 10w q/s，平均每个请求负责传输 8 KB 的字符，那我们需要的理论带宽是 7.6 Gbits/s，如果服务器配置的是 1 Gbits/s，那么一定会有很多信息在排队等候传输，因此运行效率可想而知，这也是很多 Redis 生产坏境之所以效率不高的原因；
②CPU 可能是 Redis 运行的另一个重要的影响因素，如果 CPU 的计算能力跟不上 Redis 要求的话，也会影响 Redis 的运行效率；
③如果 Redis 运行在虚拟设备上，性能也会受影响，因为普通操作在虚拟设备上会有额外的消耗；
④普通操作和批量操作（Pipeline）对 Redis 的吞吐量也有很大的影响。
以上原因就是为什么每次执行 10 个 Redis 命令，Pipeline 的效率为什么达不到普通命令的 10 倍而是只达到了8倍

6、redis慢查询

6.1慢查询的配置项

slowlog-log-slower-than：用于设置慢查询的评定时间，也就是说超过此配置项的命令，将会被当成慢操作记录在慢查询日志中，它执行单位是微秒（1 秒等于 1000000 微秒）；
slowlog-max-len：用来配置慢查询日志的最大记录数。
从下图可以看出慢查询的临界值是 10000 微秒，默认保存 128 条慢查询记录。

6.2慢查询日志的使用

通过slowlog get [argument返回想要查看的条数]可以查慢查询日志里卖有哪些命令

slowlog reset表示清空慢查询日志
修改配置项：slowlog-log-slower-than 和 slowlog-max-len 可以通过 config set xxx 的模式来修改，也可以通过配置文件来修改，例如 config set slowlog-max-len 200 设置慢查询最大记录数为 200 条。
获取慢查询队列长度：slowlog len
可以定期检查慢查询日志，及时发现和改进 Redis 运行中不合理的操作

7、redis的哨兵(sentinel)

7.1什么是哨兵系统

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）可配置多个哨兵

7.2哨兵系统的作用

①监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
②提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
③自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

7.3部署一主两从redis

7.3.1开启三台服务

将redis.conf复制两份，取名为slave.conf和slave1.conf，通过配置文件开启三台redis服务这时候就是一主两从的redis

连接上之后可以通过role查看他当前的角色，通过info replication可以查看详细信息

7.3.2分别连接服务端

指定端口连接

7.4部署的哨兵系统

直接运行src/redis-sentinel sentinel.conf
如果主服务器出现了问题，就会从从服务器里面选举一个当作主机，如果以前的主机重新上线则会变成从机连接到原本是从机的主机，