Redis（三）——配置文件详解、发布和订阅、新数据类型

配置文件详解

Units 单位

includes 包含

网络相关配置

配置文件详解

Units 单位

配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit，不区分大小写

includes 包含

类似jsp中的include，多实例的情况可以把公用的配置文件提取出来

网络相关配置

bind

默认情况bind=127.0.0.1只能接受本机的访问请求

不写的情况下，无限制接受任何ip地址的访问

生产环境肯定要写你应用服务器的地址；服务器是需要远程访问的，所以需要将其注释掉

protected-mode

保护模式，只允许本机访问。将本机访问保护模式设置no。

port

端口号，默认 6379

tcp-backlog

设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。

timeout

连上redis过了一段时间没有操作

一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

tcp-keepalive

对访问客户端的一种心跳检测，每个n秒检测一次。

连接redis之后很长一段时间没有操作，此时redis有一种检测机制，会检测你的心跳。如果还在操作，则会继续提供服务，如果没有操作就会断开连接，每隔300s就检测这个连接是否活着，如果活着，继续提供服务，如果没活着，那么就释放连接。

单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

更多配置文件详解参考博客：Redis配置文件详解-完全版

发布和订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。Redis 客户端可以订阅任意数量的频道。

客户端可以订阅频道

当给这个频道发布消息后，消息就会发送给订阅的客户端

发布订阅命令行实现

注：发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息

新数据类型

Bitmaps

1、setbit

2、getbit

3、bitcount

统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。

举例： K1 【01000001 01000000 00000000 00100001】，对应【0，1，2，3】

bitcount K1 1 2 ：统计下标1、2字节组中bit=1的个数，即01000000 00000000

--》bitcount K1 1 2 　　--》1

bitcount K1 1 3 ：统计下标1、2字节组中bit=1的个数，即01000000 00000000 00100001

--》bitcount K1 1 3　　--》3

bitcount K1 0 -2 ：统计下标0到下标倒数第2，字节组中bit=1的个数，即01000001 01000000 00000000

--》bitcount K1 0 -2　　--》3

注意：redis的setbit设置或清除的是bit位置，而bitcount计算的是byte位置。（统计1出现的个数）

4、bitop

Bitmaps与set对比

HyperLogLog

        在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站PV（PageView页面访问量）,可以使用Redis的incr、incrby轻松实现。

        但像UV（UniqueVisitor，独立访客）、独立IP数（同一ip多次访问只记录一次）、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。

什么是基数?

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

解决基数问题有很多种方案：

（1）数据存储在MySQL表中，使用distinct count计算不重复个数
（2）使用Redis提供的hash、set、bitmaps等数据结构来处理

        以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。

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

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

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