第5章 Redis新类型

5.1 为什么出来这三个类型？

5.1.1 大厂真实需求

• 手机APP中的每天用户登录信息：1天对应1系列用户ID或移动设备ID
• 电商网站上商品的用户评论列表：1个商品对应了1系列的评论
• 用户在手机APP上的签到打卡信息：1天对应1系列用户的签到记录
• 应用网站上的网页访问信息：1个网页对应1系列的访问点击

5.1.2 面试题反馈

• 记录对集合中的数据进行统计

• 在移动应用中，需要统计每天的新增用户数和第2天的留存用户数

• 在电商网站的商品评论中，需要统计评论列表中的最新评论

• 在签到打卡中，需要统计一个月内连续打卡的用户数

• 在网页访问记录中，需要统计独立访客（UniqueVisitor，UV）量

5.1.3 痛点

类似于今日头条、抖音、淘宝这样的用户访问级别都是亿级的，请问如何处理？

• 亿级数据的收集 + 统计

• 一句话：存的进 + 取得快 + 多统计

• 真正有价值的是统计。。。

5.2 统计的类型有哪些？

亿级系统中常见的四种统计：

➥ 聚合统计：统计多个集合元素的聚合结果，就是前面讲过的交叉并等集合统计。

➥ 排序统计：抖音视频最新评论留言的场景，请你设计一个展现列表。考察你的数据结构和设计思路。【排序、分页、高并发高性能】

• list

  每个商品评论对应一个List集合，这个List包含了对这个商品的所有评论，而且会按照评论时间保存这些评论，
  每来一个新评论就用LPUSH命令把它插入List的对头。但是，如果在演示第二页前，又产生了一个新评论，第二页的评论就不一样了。原因：List是通过元素在List中的位置来排序的，当有一个新元素插入时，原先的元素在List中的位置都后移了一位，原来在第一位的元素现在排在了第二位，当LRANGE读取时，就会读到旧元素。

  

• zset

  

• 总结：在需要展示最新列表、排行榜等场景时，如果数据更新频繁或者需要分页显示，建议使用zset

➥ 二值统计：集合元素的取值就只有0和1两种。

• 在钉钉上班签到打卡的场景中，我们只用记录：有签到（1）或没签到（0）【见bitmap】

➥ 基数统计：指统计一个集合中不重复的元素个数【见hyperloglog】

5.3 bitmap

5.3.1 是什么

一句话：由0和1状态表现的二进制位的bit数组

说明：用String类型作为底层数据结构实现的一种统计二值状态的数据类型

位图本质是数组，它是基于String数据类型的按位的操作。该数组由多个二进制位组成，每个二进制位都对应一个偏移量（我们可以称之为一个索引或者格位）。Bitmap支持的最大位数是2^32位，它可以极大的节约存储空间，使用512M内存就可以存储42.9亿的字节信息。

5.3.2 能干嘛

1）用于状态统计

2）看需求

• 用户是否登录过。比如京东每日签到送京豆
• 电影、广告是否被点击播放过
• 钉钉打卡上下班，签到统计

3）大厂真实案例

• 日活统计
• 连续签到打卡
• 最近一周的活跃用户
• 统计指定用户一年之中的登录天数
• 某用户按照一年365，哪几天登录过？哪几天没有登录？全年中登录的天数共计多少？

5.3.3 京东签到领取京豆

1）需求说明

签到日历仅展示当前月签到数据、签到日历需展示最近连续签到天数

假设目前日期是20221012，且20221010未签到。

若20221011已签到且1012未签到，则连续签到天数为1.

若20221011已签到且1012已签到，则连续签到天数为2

连续签到天数越多，奖励越大。所有用户均可签到。

截止2020年3月31日的12个月，京东年度活跃用户数3.87亿，同比增长24.8%，环比增长超2500万，此外，2020年3月移动端日均活跃用户数同比增长46%。假设10%左右的用户参与签到，签到用户也高达3千万。。。。

2）小厂方法：传统mysql方式

建表：

困难与解决思路：

方法正确但是难以落地实现。签到用户量较小时这么设计可行，但京东这个体量的用户（估算3000w签到用户，一天一条数据，一个月就是9亿数据）。

对于京东这样的体量，如果一条签到记录对应着当日用户记录，那会很恐怖…

如何解决这个痛点？

• 一条签到记录对应一条记录，会占据越来越大的空间

• 一个月最多31天，刚好我们的int类型是32位。那这样一个int类型就可以搞定一个月，32位大于31天，当天来了位是1，没来就是0

• 亿条数据直接存储一个月的签到记录，不再是存储一天的签到记录。

3）大厂方法：基于Redis的Bitmap实现签到日历

建表 —— 按位 —— redis bitmap

在签到统计时，每个用户一天的签到用1个bit位就能表示。

一个月（假设是31天）的签到情况用31个bit位就可以，一年的签到也只需要用356个bit位，根本不用太复杂的集合类型

5.3.4 基本命令

命令	作用	时间复杂度
setbit key offset val	给指定key的值的第offset赋值val	O(1)
getbit key offset	获取指定key的第oddset位	O(1)
bitcount key start end	返回指定key中[start,end]中为1的数量	O(n)
bittop operation destkey key	对不同的二进制存储数据进行位运算（AND、OR、NOT、XOR）	O(n)

• setbit key offset value：给指定key的值的第offset赋值value

  • setbit 键 偏移位 值(只能是0或者1)

  • bitmap的偏移量offset是从0开始算的

  • 127.0.0.1:6379> setbit sign:zhang3 1 1
    (integer) 0
    

  • 上面一条指令，保存到redis后的数据就是下边这个样子：
    

  • 8位1Byte，会自动扩容，最大可以存2³² = 512MB

• getbit key offset：获取指定key的第offset位

• setbit和getbit案例说明：

  • 按照天：

    127.0.0.1:6379> setbit sign:u1:202106 0 1
    (integer) 0
    127.0.0.1:6379> setbit sign:u1:202106 1 1
    (integer) 0
    127.0.0.1:6379> setbit sign:u1:202106 2 1
    (integer) 0
    127.0.0.1:6379> setbit sign:u1:202106 3 1
    (integer) 0
    127.0.0.1:6379> setbit sign:u1:202106 6 1
    (integer) 0
    127.0.0.1:6379> getbit sign:u1:202106 3
    (integer) 1
    127.0.0.1:6379> getbit sign:u1:202106 30
    (integer) 0
    127.0.0.1:6379> 
    127.0.0.1:6379> bitcount sign:u1:202106 0 30
    (integer) 5
    127.0.0.1:6379> 
    

  • 按照年：

    • 按年去存储一个用户的签到情况，365天只需要365 / 8 ≈ 46byte，100w用户量一年也只需要44MB就足够了。
    • 假如是亿级的系统，每天使用1个1亿位的bitmap约占12MB的内存（10⁸ / 8 / 1024 / 1024），10天的bitmap的内存开销约为120MB，内存压力不算太高。
    • 在实际使用时，最好对bitmap设置过期时间，让Redis自动删除不再需要的签到记录以节省内存开销。

• bitmap的底层编码说明，get命令操作如何

  • 实质是二进制的ASCII编码对应

  • redis里面用type命令看看bitmap实质是什么类？？？

    > setbit k1 1 1
    0
    > setbit k1 6 1
    0
    > type k1
    "string"
    > get k1
    "B"
    #01000010  ==>  2^6 + 2^1 = 66 ==> B
    #实质是二进制的ASCII编码对应的值
    
    127.0.0.1:6379> setbit key1 1 1
    (integer) 0
    127.0.0.1:6379> setbit key1 7 1
    (integer) 0
    # 01000001
    127.0.0.1:6379> get key1
    "A"
    

• strlen统计字节数占用多少

  • 127.0.0.1:6379> setbit k3 0 1
    0
    127.0.0.1:6379> setbit k3 7 1
    0
    127.0.0.1:6379> strlen k3
    (integer) 1
    
    127.0.0.1:6379> setbit k3 8 1
    0
    127.0.0.1:6379> strlen k3
    (integer) 2
    

  • 不是字符串长度而是占据几个字节，超过8位后自己按照8位一组Byte扩容。

  • 一年365天，全年天天登录占用多少字节？ ==> 46byte ==> 46 * 8 = 368位

    > setbit k3 364 1
    0
    > strlen k3
    (integer) 46
    

• bitcount key [start end]：返回指定key中[start,stop]中为1的数量

• bitop operation destkey key：对不同的二进制存储数据进行位运算

  连续两天签到的用户：假如某个网站，它的用户有1000w，做个用户id和位置的映射。比如0号位对应用户id：uid-095120…

  > setbit 20221010 0 1
  0
  > setbit 20221010 1 1
  0
  > setbit 20221010 2 1
  0
  > setbit 20221010 3 1
  0
  
  > setbit 20221011 0 1
  0
  > setbit 20221011 2 1
  0
  
  > bitcount 20221010
  4
  > bitcount 20221011
  2
  
  > bitop and destkey 20221010 20221011
  1
  > bitcount destkey
  2
  

5.4 hyperloglog

5.4.1 说名词

➥ UV（Unique Visitor）：独立访客，一般理解为客户端IP，需要考虑去重

➥ PV（Page View）：页面浏览量，不用去重

➥ DAU（Daily Active User）：日活跃用户量，登录或者使用了某个产品的用户数（去重复登录的用户）

• 常用于反映网站、互联网应用或者网络游戏的运营情况

➥ MAU（Monthly Active User）：月活跃用户量

5.4.2 看需求

• 统计某个网站的UV、统计某个文章的UV
• 用户搜索网站关键词的数量
• 统计用户每天搜索不同词条个数

5.4.3 是什么

去重复统计功能的基本估计算法 —— 就是HyperLogLog。

Redis HyperLogLog是用来做基数统计的算法。

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

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

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

基数：是一种数据集，去重复后的真实个数

(全集) = {2,4,6,8,77,39,4,8,10}

去掉重复的内容
基数 = {2,4,6,8,77,39,10}

5.4.4 HyperLogLog如何做的？如何演化出来的？

1）去重复统计你先会想到哪些方式？

• Java HashSet

• redis Set

• bitmap

  如果数据是较大亿级统计，使用bitmap同样会有这个问题：

  • bitmap是通过用位bit数组来表示各元素是否出现，每个元素对应一位，所需的总内存为N个bit。
    基数计数则将每一个元素对应到bit数组中的其中一位，比如bit数组010010101（按照从下标0开始，有的就是1、4、6、8）。
    新进入的元素只需要将已经有的bit数组和新加入的元素进行按位或计算就行。这个方式能大大减少内存占用且位操作迅速。
  • But，假设一个样本案例就是一亿个基数位值数据，一个样本就是一亿。
    如果要统计1亿个数据的基数位值，大约需要内存 1亿 / 8 / 1024 / 1024 约等于12M，内存减少占用的效果显著。
    这样得到统计一个对象样本的基数值需要12M。
  • 如果统计10000个对象样本（1w个亿级）就需要117.1875G将近120G，可见使用bitmap还是不适用大数据量下的基数计数场景，但是bitmap方法时精确计算的。

• 结论：样本元素越多内存消耗急剧增大，难以管控 + 各种慢。对于亿级统计不太合适，大数据害死人，o(╥﹏╥)o

概率算法

通过牺牲准确率来换取空间，对于不要求绝对精确的场景下可以使用，因为概率算法不直接存储数据本身，通过一定的概率统计方法预估基数值，同时保证误差在一定范围内，由于又不存储数据，故此可以大大节约内存。

HyperLogLog就是一种概率算法的实现

2）原理说明

只是进行不重复的基数统计，不是集合也不保存数据，只记录数量而不是具体内容。

有误差：非精确统计、牺牲准确率来换取空间，误差仅为0.81%左右

这个误差如何来的？

• http://antirez.com/news/75

• Redis之父安迪雷斯的回答：
  

3）经典面试题：为什么Redis集群的最大槽数是16384？

Redis集群并没有使用一致性hash，而是引入了哈希槽的概念。Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

但为什么哈希槽的数量是16384(2*14)个呢？

CRC16算法产生的hash值有16bit，该算法可以产生2^16 = 65536个值。
换句话说值是分布在0~65535之间。那作者在做mod运算的时候，为什么不mod65536，而选择16384？

https://github.com/redis/redis/issues/2576

正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新就得配置。
这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间（使用65k的插槽）
同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。
因为16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。请注意，在小型集群中，位图将难以压缩，因为当N较小时，位图将设置的slot / N位占设置位的很大百分比。

原因1：如果槽位65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
在消息头中最占空间的是myslotsp[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是：65536 ÷ 8 ÷ 1024 = 8kb。
​ 因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大，浪费带宽。

原因2：redis的集群主节点数量基本不可能超过1000个。
​集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议redis cluster节点数量超过1000个。那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要扩展到65536个。

原因3：槽位越小，节点少的情况下，压缩比高，容易传输
Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话（N表示节点数），bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

5.4.5 基本命令

命令	作用
pfadd key element …	将所有元素添加到key中
pfcount key	统计key的估算值（不精确）
pfmerge new_key key1 key2	合并key1和key2

5.4.6 案例实战3：天猫网站首页亿级uv的Redis统计方案

1）需求

• UV的统计需要去重，一个用户一天内的多次访问只能算作一次
• 淘宝、天猫首页的UV，平均每天是1~1.5个亿左右
• 每天存1.5个亿的IP，访问者来了后先去查是否存在，不存在加入

2）方案讨论

① 用MySQL

② 用redis的hash结构存储

> hset 20221010uv 192.168.123.111 1
1
> hget 20221010uv 192.168.123.111
"1"

> hset 20221010uv 192.168.123.112 1
1
> hset 20221010uv 192.168.123.113 1
1
> hset 20221010uv 192.168.123.114 1
1
> hset 20221010uv 192.168.123.115 1
1

> hgetall 20221010uv
1) "192.168.123.111"
2) "1"
3) "192.168.123.112"
4) "1"
5) "192.168.123.113"
6) "1"
7) "192.168.123.114"
8) "1"
9) "192.168.123.115"
10) "1"

redis ------  hash = <keyDay,<ip,1>>

按照ipv4的结构来说明，每个ipv4的地址最多是15个字节（ip = “192.168.123.133”）

某一天的1.5亿个字节 = 2G，一个月60G，redis死定了。o(╥﹏╥)o

③ HyperLogLog

为什么是12KB？ 每个桶取6位，16384 * 6 ÷ 8 = 12kb，每个桶有6位，最大全部都是1，值就是63

3）HyperLogLogController

@Api(description = "案例实战3：天猫网站首页亿级UV的Redis统计方案")
@RestController
@Slf4j
public class HyperLogLogController {

    @Autowired
    private RedisTemplate redisTemplate;

    @ApiOperation("获取ip去重复后的首页访问量，总数统计")
    @GetMapping("/uv")
    public Long uv(){
        return redisTemplate.opsForHyperLogLog().size("UVCount");
    }
}

4）HyperLogLogService

@Service
@Slf4j
public class HyperLogLogService {

    @Autowired
    private RedisTemplate redisTemplate;

    /**
     * 模拟有用户来点击首页，每个用户就是不同的ip，不重复记录，重复不记录
     */
    @PostConstruct
    public void init(){
        new Thread(() -> {
            String ip = null;
            Random random = new Random();

            for (int i = 0; i < 200; i++) {
                ip = random.nextInt(255)+"."+random.nextInt(255)+"."+random.nextInt(255)+"."+random.nextInt(255);

                Long count = redisTemplate.opsForHyperLogLog().add("UVCount", ip);

                log.info("ip={},该ip访问过的次数={}",ip,count);

                try {Thread.sleep(1000);} catch (InterruptedException e) {throw new RuntimeException(e);}
            }
        },"t1").start();
    }
}

5.5 GEO

5.5.1 简介

移动互联网时代LBS应用越来越多，交友软件中附近的小姐姐、外卖软件中附近的美食店铺、打车软件附近的车辆等等，那这种附近各种形形色色的XXX地址位置选择是如何实现的？

地球上的地理位置是使用二维的经纬度表示，经度范围（-180,180]，维度范围（-90,90]，只要我们确定一个点的经纬度就可以明确他在地球尚的位置。

例如滴滴打车，最直观的操作就是实时记录更新各个车的位置。

然后当我们要找车时，在数据库中查找距离我们坐标（x，y）附近r公里范围内的全部车辆

使用如下SQL即可：

select taxi from position where x-r < x < x + r and y-r < y < y+r

但是这样会有什么问题呢？

• 查询性能问题，如果并发高，数据量大。这种查询是要搞垮数据库的
• 这个查询的是一个矩形访问，而不是以我为中心r公里为半径的圆形访问。
• 精准度的问题，我们直到地球不是平台坐标系，而是一个圆球，这种矩形计算在长距离计算时会有很大误差

Redis在3.2版本以后增加了地理位置的处理

5.5.2 原理

核心思想就是将球体转换为平面，区块转换为一点。

主要分为三步：

1. 将三维的地球变为二维的坐标
2. 再将二维的坐标转换为一维的点块
3. 最后将一维的点块转换为二进制再通过base32编码

难点：GeoHash核心原理解析

补充知识：

➥ 经纬度

​ 经度与纬度的合成组成一个坐标系统，又称为地理坐标系统，它是一种利用三度空间的球面来定义地球上的空间的球面坐标系统，能够标示地球上的任何一个位置。

➥ 经线与纬线

​ 是人们为了在地球上确定位置和方向的，在地球仪和地图上画出来的，地面上并线。

​ 和经线相垂直的线叫做纬线（纬线指示东西方向）。纬线是一条条长度不等的圆圈。最长的纬线就是赤道。

​ 因为经线指示南北方向，所以经线又叫子午线。国际上规定，把通过英国格林尼治天文台原址的经线叫做0°，所以经线也叫本初子午线。在地球上经线指示南北方向，纬线指示东西方向。东西半球分界线：东经160°，西经20°。

➥ 经度与纬度

• 经度（longitude）：东经为正数，西经为负数。东西经
• 纬度（latitude）：北纬为正数，南纬为负数。南北纬

5.5.3 命令

命令	说明
GEOADD key longitude latitude m/km	多个经度（longitude）、纬度（latitude）、位置名称（member）添加到指定的key中
GEOPOS key member [member …]	从键里面返回所有给定位置元素的位置（精度和纬度）
GEODIST key member1 member2 m/km	返回两点给定位置之间的距离
GEORADIUS key longitude latitude m/km	以给定的经纬度为中心，返回与中心的距离不超过给定最大距离的所有元素
GEORADIUSBYMEMBER key member radius m/km	跟GEORADIUS类似
DEOHASH key member [member …]	返回一个或多个位置元素的GeoHash表示

5.5.4 命令实操

➥ 如何获得某个地址的经纬度

• http://api.map.baidu.com/lbsapi/getpoint
• https://jingweidu.bmcx.com

➥ GEOADD添加经纬度坐标

127.0.0.1:6379> geoadd city 116.403963 39.915119 "天安门" 116.403414 39.924091 "故宫" 116.024067 40.362439 "长城"
(integer) 3
127.0.0.1:6379> type city
zset

[root@test100 ~]# redis-cli --raw
127.0.0.1:6379> zrange city 0 -1
天安门
故宫
长城

➥ GEOPOS返回经纬度

127.0.0.1:6379> geopos city 天安门 故宫
116.40396326780319214
39.91511970338637383
116.40341609716415405
39.92409008156928252

➥ GEOHASH返回坐标的GeoHash表示

127.0.0.1:6379> geohash city 天安门
wx4g0f6f2v0

➥ GEODIST两个位置之间的距离

127.0.0.1:6379> geodist city 天安门 长城 m
59320.3258

➥ GEORADIUS（以半径为中心，查找附近的XXX）

#116.40396326780319214 39.91511970338637383 当前我自己所在的位置经纬度
127.0.0.1:6379> georadius city 116.40396326780319214 39.91511970338637383 1000 m
天安门
故宫

➥ GEORADIUSBYMEMBER

127.0.0.1:6379> georadiusbymember city 天安门 10 km
天安门
故宫

5.5.5 案例实战4：美团地图位置附近的酒店推送

1）需求分析

• 微信附近的人活着一公里以内的各种营业厅、加油站、理发店
• 摇个妹子
• 找个单车
• 附近的酒店
  

2）架构设计

• Redis的新类型GEO
• 命令：http://www.redis.cn/commands/geoadd.html

3）编码实现

@Api(description = "案例实战4：美团地图位置附近的酒店推送")
@RestController
public class GeoController {

    @Autowired
    private RedisTemplate redisTemplate;

    @ApiOperation("新增天安门故宫长城经纬度")
    @PostMapping("/geoadd")
    public String geoAdd(){
        Map<String, Point> map = new HashMap<>();
        map.put("天安门",new Point(116.403963,39.915119));
        map.put("故宫",new Point(116.403414,39.924091));
        map.put("长城",new Point(116.024067,40.362439));

        redisTemplate.opsForGeo().add("city",map);
        return map.toString();
    }

    @ApiOperation("获取地理位置的坐标")
    @GetMapping("/geopos")
    public Point position(String member){
        //获取经纬度坐标
        List<Point> list = redisTemplate.opsForGeo().position("city", member);
        return list.get(0);
    }

    @ApiOperation("geohash算法生成的base32编码值")
    @GetMapping("/geohash")
    public String geohash(String member){
        List<String> list = redisTemplate.opsForGeo().hash("city", member);
        return list.get(0);
    }

    @ApiOperation("计算两个位置之间的距离")
    @GetMapping("/geodist")
    public Distance geodist(String member1,String member2){
        Distance distance = redisTemplate.opsForGeo().distance("city", member1, member2, RedisGeoCommands.DistanceUnit.KILOMETERS);
        return distance;
    }

    @ApiOperation("通过经纬度查找附近的XXX")
    @GetMapping("/georadius")
    public GeoResults radiusByXY(){
        //这个坐标是北京王府井位置
        Circle circle = new Circle(116.418017,39.914402, Metrics.MILES.getMultiplier());

        RedisGeoCommands.GeoRadiusCommandArgs args = RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs()
            .includeDistance().includeCoordinates().sortAscending().limit(10);

        GeoResults geoResults = redisTemplate.opsForGeo().radius("city", circle, args);
        return geoResults;
    }

    @ApiOperation("通过地方查找附近的XXX")
    @GetMapping("/georadiusByMember")
    public GeoResults radiusByMember(){
        String member = "天安门";

        RedisGeoCommands.GeoRadiusCommandArgs args = RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs()
            .includeDistance().includeCoordinates().sortAscending().limit(10);

        Distance distance = new Distance(10,Metrics.KILOMETERS);
        GeoResults geoResults = redisTemplate.opsForGeo().radius("city", member, distance, args);
        return geoResults;
    }
}