redis系列（一）
1、Redis为什么选择单线程？
这种问法其实并不严谨，为啥这么说呢?
Redis的版本很多3.x、4.x、6.x，版本不同架构也是不同的，不限定版本问是否单线程也不太严谨。
- 版本3.x ，最早版本，也就是大家口口相传的redis是单线程，阳哥2016年讲解的redis就是3.X的版本。
- 版本4.x，严格意义来说也不是单线程，而是负责处理客户端请求的线程是单线程，但是开始加了点多线程的东西(异步删除)。
- 最新版本的6.0.x后，告别了大家印象中的单线程，用一种全新的多线程来解决问题。
1.1、Redis3.x单线程但性能依旧很快的主要原因？
- 基于内存操作：Redis 的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高；
- 数据结构简单：Redis 的数据结构是专门设计的，而这些简单的数据结构的查找和操作的时间大部分复杂度都是 O(1)，因此性能比较高；
- 多路复用和非阻塞 I/O：Redis使用 I/O多路复用功能来监听多个 socket连接客户端，这样就可以使用一个线程连接来处理多个请求，减少线程切换带来的开销，同时也避免了 I/O 阻塞操作
- 避免上下文切换：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的消耗，而且单线程不会导致死锁问题的发生
1.2、Redis 4.0之前一直采用单线程的主要原因有以下三个？
- 使用单线程模型是 Redis 的开发和维护更简单，因为单线程模型方便开发和调试；
- 即使使用单线程模型也并发的处理多客户端的请求，主要使用的是多路复用和非阻塞 IO；
- 对于 Redis 系统来说，主要的性能瓶颈是内存或者网络带宽而并非 CPU。
2、既然单线程这么好，为什么逐渐又加入了多线程特性？
4.1、出现的问题场景：
正常情况下使用 del 指令可以很快的删除数据，而当被删除的 key 是一个非常大的对象时，例如时包含了成千上万个元素的 hash 集合时，那么 del 指令就会造成 Redis 主线程卡顿，如果这个时候，有大量的请求进入，则会进行阻塞，阻塞会消耗内存和带宽，造成服务宕机，这也是redis3.x单线程时代最经典的故障，大key删除的头疼问题。
2.2、解决方式：
使用惰性删除可以有效的避免 Redis 卡顿的问题，也就是说当删除一个很大的数据的key时，会将这个删除的工作交给子线程异步去执行。从redis主线程剥离让bio子线程来处理，极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。
比如当我（Redis）需要删除一个很大的数据时，因为是单线程同步操作，这就会导致 Redis 服务卡顿，于是在 Redis 4.0 中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的。虽然在Redis 4.0就引入了多个线程来实现数据的异步惰性删除等功能，但是其处理读写请求的仍然只有一个线程，所以仍然算是狭义上的单线程。
3、Redis6.0是属于单线程还是多线程？
版本4.x之前的Redis是单线程：主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取 (读取socket )、解析请求、执行操作、内容返回 (写入socket ) 等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程。但Redis的其他功能，比如持久化、异步删除、集群数据同步等等，其实是由额外的线程执行的。Redis工作线程是单线程的，但是，整个Redis来说，是多线程的；
I/O 的读和写本身是堵塞的，比如当 socket 中有数据时，Redis 会通过调用先将数据从内核态空间拷贝到用户态空间，再交给 Redis 调用，而这个拷贝的过程就是阻塞的，当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的，所以说Redis主要的性能瓶颈是内存或者网络带宽而并非 CPU。
在Redis6版本，redis就开启了真正使用多线程，更为准确的说是在 Redis 6.0 中新增了多线程的功能来提高 I/O 的读写性能，他的主要实现思路是将主线程的 IO 读写任务拆分给一组独立的线程去执行，这样就可以使多个 socket 的读写可以并行化了，采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），将最耗时的Socket的读取、请求解析、写入单独外包出去，剩下的命令执行仍然由主线程串行执行并和内存的数据交互，其核心部分仍然是线程安全的。所以说Redis主工作线程是单线程的，但是对整个Redis来说，是多线程的，既能保证线程安全，又能以多路IO问题增加效率。
4、Redis6.0默认是否开启了多线程？
Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理8W到10W的QPS，这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了。
在Redis6.0中，多线程机制默认是关闭的，如果需要使用多线程功能，需要在redis.conf中完成两个设置
- 设置io-thread-do-reads配置项为yes，表示启动多线程。
- 设置线程个数：
- 关于线程数的设置，官方的建议是如果为 4 核的 CPU，建议线程数设置为 2 或 3，
- 如果为 8 核 CPU 建议线程数设置为 6，线程数一定要小于机器核数，线程数并不是越大越好。
5、双端检索机制的应用，防止缓存击穿
/**
* 加强补充，避免突然key实现了，打爆mysql，做一下预防，尽量不出现击穿的情况。
* @param id
* @return
*/
public User findUserById(Integer id)
{
User user = null;
String key = CACHE_KEY_USER+id;
//1 先从redis里面查询，如果有直接返回结果，如果没有再去查询mysql
user = (User) redisTemplate.opsForValue().get(key);
if(user == null)
{
//2 大厂用，对于高QPS的优化，进来就先加锁，保证一个请求操作，让外面的redis等待一下，避免击穿mysql
synchronized (UserService.class){
user = (User) redisTemplate.opsForValue().get(key);
//3 二次查redis还是null，可以去查mysql了(mysql默认有数据)
if (user == null) {
//4 查询mysql拿数据
user = userMapper.selectByPrimaryKey(id);//mysql有数据默认
if (user == null) {
return null;
}else{
//5 mysql里面有数据的，需要回写redis，完成数据一致性的同步工作
redisTemplate.opsForValue().setIfAbsent(key,user,7L,TimeUnit.DAYS);
}
}
}
}
return user;
}
6、redis经典五种数据类型介绍及落地运用
6.1、九大类型结构
- String(字符类型)
- Hash(散列类型)
- List(列表类型)
- Set(集合类型)
- SortedSet(有序集合类型，简称zset)
- Bitmap(位图)
- HyperLogLog(统计)
- 8.GEO(地理)
- Stream
命令不区分大小写，但是Key是区分大小的。
6.2、常用的5大类型结构
6.2.1、String(字符类型)
最常用的
set key valueget key
同时设置/获取多个键值
MSET key value [key value ...]MGET key [key ....]
数值增减
- 递增数字：
INCR key - 增加指定的整数：
INCRBY key increment - 递减数值：
DECR key - 减少指定的整数：
DECRBY key decrement
主要用于量的计算，比如抖音无限点赞某个视频或者商品，点一下加一次是否喜欢的文章
获取字符串长度：STRLEN key
分布式锁
setnx key valueset key value [Ex seconds][PX milliseconds] [NX|XX]
EX: key在多少秒之后过期
PX: key在多少毫秒之后过期
NX:当key不存在的时候，才创建key，效果等同于setnx· XX:当key存在的时候，覆盖key
6.2.2、 Hash(散列类型)
Map
- 一次设置一个字段值：
HSET key field value - 一次获取一个字段值：
HGET key field - 一次设置多个字段值：
HMSET key field value [field value....] - 一次获取多个字段值：
HMGET key field [field ....] - 获取所有字段值：
hgetall key - 获取某个key内的全部数量：
hlen key - 删除一个key：
hdel key field
6.2.3、 List(列表类型)
一个双端链表的结构，容量是2的32次方减1个元素，大概40多亿，主要功能有push/pop等，一般用在栈、队列、消息队列等场景。
- 向列表左边添加元素：
LPUSH key value [value...] - 向列表右边添加元素：
RPUSH key value [value ...] - 查看列表：
LRANGE key start stop - 获取列表中元素的个数：
LLEN key
应用场景
-
微信公众号订阅的消息
- 比方说大V作者李永乐老师和CSDN发布了文章分别是11和22，
- 关注了他们两个，只要他们发布了新文章，就会安装进我的List， lpush likearticle:我的id 11 22
- 查看自己的号订阅的全部文章，类似分页，下面0~10就是一次显示10条 lrange likearticle:我的id 0 9
-
商品评论列表
- 需求1:用户针对某一商品发布评论，乡个商品会被不同的用户进行评论，保存商品评论时，要按时间顺序排序
- 需要2:用户在前端页面查询该商品的评论，需要按照时间顺序降序排序
使用list存储商品评论信息，key是该商品的id，value是商品评论信息商品编号为1001的商品评论key 【items.comment10011】
lpush items.comment1001 {"id":1001,"name":"huawei","date":1600484283054,"content":"lasjfdlisafedlkajsd,fsa,jflasiflasfdlsad7"}
6.2.4、 Set(集合类型)
- 添加元素：
SADD key member [member ...] - 删除元素：
SREM key member [member ...] - 遍历集合中的所有元素：
SMEMBERS key - 判断元素是否在集合中：
SISMEMBER key member - 获取集合中的元素总数：
SCARD key - 从集合中随机弹出一个元素，元素不删除：
SRANDMEMBER key[数字] （可以用于抽奖） - 从集合中随机弹出一个元素，出一个删除一个：
SPOP key[数字]（可以用于抽奖）
集合运算：现有AB两个值，A 为a，b，c，1，2，B为1，2，3，a，x
- 集合的差集运算A-B
- 属于A但不属于B的元素构成的集合
SDIFF key [key ..]
- 集合的交集运算A∩B
- 属于A同时也属于B的共同拥有的元素构成的集合
SINTER key [key ...]
- 集合的并集运算AUB
- 属于A或者属于B的元素合并后的集合
SUNION key [key ...]
应用场景
- 微信抽奖小程序
- 用户ID，立即参与按钮 ：
sadd key 用户ID - 显示已经有多少人参与了，上图23208人参加：
SCARD key - 抽奖(从set中任意选取N个中奖人)：随机抽奖2个人，元素不删除用
SRANDMEMBER key 2，随机抽奖3个人，元素会删除，用SPOP key 3
-
微信朋友圈点赞
- 新增点赞：
sadd pub:msglD 点赞用户ID1 点赞用户ID2 - 取消点赞：
srem pub:msglD点赞用户ID - 展现所有点赞过的用户：
SMEMBERS pub:msglD - 点赞用户数统计，就是常见的点赞红色数字：
scard pub:msglD - 判断某个朋友是否对楼主点赞过：
SISMEMBER pub:msglD用户ID
- 新增点赞：
-
微博好友关注社交关系
- 共同关注：我和局座共同关注的，交集：
SINTER key [key ...] - 我关注的人也关注他：我关注了华为余承东，余承东也关注了局座召忠，我和余总有共同的爱好 判断元素是否在集合中：
SISMEMBER key member
- 共同关注：我和局座共同关注的，交集：
-
QQ内推可能认识的人
- 集合的并集运算AUB，属于A或者属于B的元素合并后的集合：
SUNION key [key ...]
6.2.5、 SortedSet(有序集合类型，简称zset)
- 向有序集合中加入一个元素和该元素的分数，添加元素：
ZADD key score member [score member ...] - 按照元素分数从小到大的顺序，返回索引从start到stop之间的所有元素：
ZRANGE key start stop [WITHSCORES] - 获取元素的分数：
ZSCORE key member - 删除元素：
ZREM key member [member ...] - 获取指定分数范围的元素：
ZRANGEBYSCORE key min max [WITHSCORES][LIMIT offset count] - 增加某个元素的分数：
ZINCRBY key increment member - 获取集合中元素的数量：
ZCARD key - 获得指定分数范围内的元素个数：
ZCOUNT key min max - 按照排名范围删除元素：
ZREMRANGEBYRANK key start stop - 获取元素的排名
- 从小到大：
ZRANK key member - 从大到小：
ZREVRANK key member
- 从小到大：
应用场景：
- 根据商品销售对商品进行排序显示
思路:定义商品销售排行榜(sorted set集合)，key为goods:sellsort，分数为商品销售数量。
商品编号1001的销量是9，商品编号1002的销量是15：zadd goods:sellsort 9 1001 15 1002
有一个客户又买了2件商品1001，商品编号1001销量加2 ：zincrby goods:sellsort 2 1001
求商品销量前10名：ZRANGE goods:sellsort 0 9 withscores - 抖音热搜
- 点击视频：
ZINCRBY hotvcr:202009191八佰
ZINCRBY hotvcr:20200919 15八佰2花木兰
- 展示当日排行前10条
ZREVRANGE hotvcr:20200919 0 9 withscores
7、 数据类型统计
手机App中的每天的用户登录信息:1天对应1系列用户ID或移动设备ID;
电商网站上商品的用户评论列表:1个商品对应了1系列的评论;
用户在手机App上的签到打卡信息:1天对应1系列用户的签到记录;
应用网站上的网页访问信息:1个网页对应1系列的访问点击
记录对集合中的数据进行统计，在移动应用中，需要统计每天的新增用户数和第2天的留存用户数;
在电商网站的商品评论中，需要统计评论列表中的最新评论;
在签到打卡中，需要统计一个月内连续打卡的用户数;
在网页访问记录中，需要统计独立访客(UniqueVisitor，UV）量。
类似今日头条、抖音、淘宝这样的额用户访问级别都是亿级的，请问如何处理?
7.1、数据的统计类型
亿级数据的收集+统计：需要存的进+取得快+多统计
7.1.1、数据的统计类型主要有4种：
- 聚合统计
- 排序统计
- 二值统计
- 基数统计
7.1.1.1、 聚合统计：统计多个集合元素的聚合结果，就是前面讲解过的交差并等集合统计，交并差集和聚合函数的应用
7.1.1.2、 排序统计：按照顺序进行元素统计
面试题：
- 抖音视频最新评论留言的场景，请你设计一个展现列表，说一下你的数据结构和设计思路(字节面试题，时间倒排，分页，高并发)
答案：list、zset都能实现。
- List的话： 添加数据：
LPUSH key value [value...]分页：LRANGE key start stop
出现的现象：每个视频的评价对应一个List集合，这个List包含了对这个视频的所有评论，而且会按照评论时间保存这些评论，每 来一个新评论就用LPUSH命令把它插入List的队头，但是，如果在查看第二页前，又产生了一个新评论，那么第2页的评论就会出现刚才第一页中的数据。
现象的原因：List类型是通过元素在List中的位置来排序的，当有一个新元素插入时，原先的元素在List中的位置都后移了一位，原来在第1位的元素现在排在了第2位，当LRANGE读取时，就会读到旧元素。 - zset的话： 使用当前的时间戳当做分数，进行存储，因为存储的数据默认是以从小到大去读取的（
ZRANGE key start stop [WITHSCORES]），可以使用从大到小进行读取（ZREVRANGE key start stop [WITHSCORES]），然后携带分页的时间戳（也就是分数）使用limit来进行分页，可以保证数据不会出现重复
在面对需要展示最新列表、排行榜等场景时，如果数据更新频繁或者需要分页显示，建议使用ZSet
7.1.1.3、二值统计：集合元素的取值就只有0和1两种，在钉钉上班签到打卡的场景中，我们只用记录有签到(1)或没签到(O)
见bitmap
7.1.1.4、基数统计：指统计一个集合中不重复的元素个数
见hyperloglog
8、Bitmap(位图)
说明:用String类型作为底层数据结构实现的一种统计二值状态的数据类型
位图本质是数组，它是基于String数据类型的按位的操作。该数组由多个二进制位组成，每个二进制位都对应一个偏移量(我们可以称之为一个索引或者位格)。Bitmap支持的最大位数是2*32位，它可以极大的节约存储空间，使用512M内存就可以存储多大42.9亿的字节信息(2’32=4294967296)
8.1、能干嘛：用于状态统计，Y、N，类似AtomicBoolean
看需求
- 钉钉打卡上下班
- 签到统计
- 用户是否登陆过Y,N，比如京东每日签到送京电影、广告是否被点击播放过
8.2、真实案例：
- 日活统计
- 连续签到打卡
- 最近一周的活跃用户
- 统计指定用户一年之中的登陆天数
- 某用户按照一年365天，哪几天登陆过?哪几天没有登陆?全年中登录的天数共计多少?
签到日历,仅展示当月签到数据,签到日历需展示最近连续签到天数
假设当前日期是20210618，且20210616未签到
若20210617已签到且0618未签到，则连续签到天数为1
若20210617已签到且0618已签到，则连续签到天数为2
连续签到天数越多，奖励越大
所有用户均可签到
截至2020年3月31的12个月，京东年度活跃用户数3.87亿，同比增长24.8%，环比增长超2500万，此外，2020年3月移动端日均活跃用户数同比增长46%假设10%左右的用户参与签到，签到用户也高达3千万。。。。。。
mysql也可以实现，但是在大数据量的时候，方法正确但是难以落地实现，签到用户量较小时这么设计能行，比方说京东这个体量的用户（估算30OOW签到用户，一天一条数据，一个月就是9亿数据)对于京东这样的体量，如果一条签到记录对应着当日用记录，那会很恐怖…
如何解决这个痛点?
1一条签到记录对应一条记录，会占据越来越大的空间。
2一个月最多31天，刚好我们的int类型是32位，那这样一个int类型就可以搞定一个月，32位大于31天，当天来了位是1没来就是0。3一条数据直接存储一个月的签到记录，不再是存储一天的签到记录。
基于Redis的Bitmaps实现签到日历，建表-按位-redis bitmap
在签到统计时，每个用户一天的签到用1个bit位就能表示，一个月（假设是31天〉的签到情况用31个bit位就可以，一年的签到也只需要用365个bit位，根本不用太复杂的集合类型
8.3、常用方法
8.3.1、setbit
setbit 键偏移位只能零或者1：setbit key offset value
Bitmap的偏移量是从零开始算的
8.3.2、getbit
根据键获取该offset的值
getbit key offset value
8.3.2.1、setbit和getbit案例说明
按年去存储一个用户的签到情况，365天只需要365/8～46 Byte，1000W用户量一年也只需要44 MB就足够了。
假如是亿级的系统，
每天使用1个1亿位的Bitmap约占12MB的内存（10^8/8/1024/1024），10天的Bitmap的内存开销约为120MB，内存压力不算太高。
在实际使用时，最好对Bitmap设置过期时间，让Redis自动删除不再需要的签到记录以节省内存开销。
8.3.2.2、bitmap的底层编码说明，get命令操作如何
bitmap是用String类型作为底层数据结构实现的一种统计二值状态的数据类型，在redis中存储的数据，其实质是二进制的ascii编码对应。
在linux服务器上查看ASCII表：man ascii
8.3.3、strlen
strlen：统计的是字符串的长度，是按照字节来统计的
bitmap的扩容机制：扩容方式是按照8位一个字节去扩容的，不是字符串长度而是占据几个字节，超过8位后自己按照8位一组一byte再扩容
8.3.4、bitcount
bitcount：返回指定key中[start,end]中为1的数量
8.3.5、bitop
bitop：对不同的二进制存储数据进行，bitop operation destkey key位运算(AND、OR、NOT、XOR)，destkey 中存放的是操作后的结果
redis> SETBIT bits-1 0 1 # bits-1 = 1001
(integer) 0
redis> SETBIT bits-1 3 1
(integer) 0
redis> SETBIT bits-2 0 1 # bits-2 = 1011
(integer) 0
redis> SETBIT bits-2 1 1
(integer) 0
redis> SETBIT bits-2 3 1
(integer) 0
redis> BITOP AND and-result bits-1 bits-2
(integer) 1
redis> GETBIT and-result 0 # and-result = 1001
(integer) 1
redis> GETBIT and-result 1
(integer) 0
redis> GETBIT and-result 2
(integer) 0
redis> GETBIT and-result 3
(integer) 1
查询连续2天都签到的用户，假如某个网站或者系统，它的用户有1000W，做个位置和用户id的映射
比如O号位对应用户id:uid-092iok-lkj
比如1号位对应用户id: uid-7388c-xxx
格式为：setbit 日期 位置 是否签到
9、HyperLogLog (统计)
9.1、UV、PV、DAU、MAU
- 什么是UV：Unique Visitor，独立访客，一般理解为客户端IP，需要去重考虑
- 什么是PV：Page View，页面浏览量，不用去重
- 什么是DAU：Daily Active User，日活跃用户量，登录或者使用了某个产品的用户数(去重复登录的用户)，常用于反映网站、互联网应用或者网络游戏的运营情况
- 什么是MAU：Monthly Active User，月活跃用户量
9.2、解决的需求
统计某个网站的UV、统计某个文章的UV
用户搜索网站关键词的数量
统计用户每天搜索不同词条个数
9.3、HyperLogLog是什么
HyperLogLog是去重复统计功能的基数估计算法。
Redis HyperLogLog，Redis在2.8.9版本添加了HyperLogLog 结构，Redis HyperLogLog是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
在Redis里面，每个HyperLogLog键只需要花费12KB内存，就可以计算接近2^64个不同元素的基数这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比，但是，因为HyperLogLog只会根据输入元素来计算基数，而不会储存输入元素本身，所以HyperLogLog不能像集合那样，返回输入的各个元素。
基数：是一种数据集，去重复后的真实个数。(全集)I={2,4,6,8,77,39,4,8,10}，去掉重复的内容，基数={2,4,6,8,77,39,10} =7
基数统计：用于统计一个集合中不重复的元素个数，就是对集合去重脱水后的真实数据。
如果数据显较大亿级统计,使用bitmaps同样会有这个问题，bitmap是通过用位bit数组来表示各元素是否出现，每个元素对应一位，所需的总内存为N个bit。基数计数则将每一个元素对应到bit数组中的其中一位，比如bit数组10010101(按照从零开始下标，有的就是1、4、6、8)。新进入的元素只需要将已经有的bit数组和新加入的元素进行按位或计算就行。这个方式能大大减少内存占用且位操作迅速。But，假设一个样本案例就是一亿个基数位值数据，一个样本就是一亿，如果要统计1亿个数据的基数位值,大约需要内存100000000/8/1024/1024约等于12M,内存减少占用的效果显著。这样得到统计一个对象样本的基数值需要12M。如果统计10000个对象样本(1w个亿级),就需要117.1875G将近120G，可见使用bitmaps还是不适用大数据量下(亿级)的基数计数场景。
但具bitmap方法是精确计算的
样本元素越多内存消耗急剧增大，难以管控+各种慢，对于亿级统计不太合适，大数据害死人
概率算法：通过牺牲准确率来换取空间，对于不要求绝对准确率的场景下可以使用，因为概率算法不直接存储数据本身，通过一定的概率统计方法预估基数值，同时保证误差在一定范围内，由于又不储存数据故此可以大大节约内存。
HyperLogLog就是一种概率算法的实现。
1去重复
2不直接存储数据本身
3通过牺牲准确率来换取空间，它不准确
只是进行不重复的基数统计，不是集合也不保存数据，只记录数量而不是具体内容
非精确统计，有误差，牺牲准确率来换取空间，误差仅仅只是0.81%左右
9.3.1、经典面试题：为什么redis集群的最大槽数是16384个?
Redis集群并没有使用一致性hash而是引入了哈希槽的概念。Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。但为什么哈希槽的数量是16384(2^14）个呢?
CRC16算法产生的hash值有16bit，该算法可以产生2^16=65536个值。
换句话说值是分布在0~65535之间。那作者在做mod运算的时候，为什么不mod65536
而选择mod16384?
正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。
这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间（使用65k的插槽）。同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。
因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵.
但数量足够少，可以轻松地将插槽配置作为原始
位图传播。请注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot / N位占设置位的很大百分比。
(1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
在消息头中最占空间的是myslots[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主节点的配置信息中它所负责的哈希槽是通过一张btimap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots /N很高的话(N表示节点数)， bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话,bitmap的压缩率就很低。
9.4、常用命令
- 将所有元素添加到key中：pfadd key element …
- 统计key的估算值(不精确)：pfcount key
- 合并key至新key：pgmerge new_key key1 key2…
9.4.1、天猫网站首页亿级uV的Redis统计方案应用案例
UV的统计需要去重，一个用户一天内的多次访问只能算作一次。
淘宝、天猫首页的UV，平均每天是1~1.5个亿左右。
每天存1.5个亿的IP，访问者来了后先去查是否存在，不存在加入。
redis——hash =
按照ipv4的结构来说明，每个ipv4的地址最多是15个字节(ip = “192.168.111.1”，最多XXX.XXX.XXX.XXX)
某一天的1.5亿*15个字节=2G，一个月60G，redis死定了。
redis的hash结构，技术上没错，但是无法落地，按照天猫、淘宝的体量，一个月redis需要60G大小
Redis HyperLogLog，Redis 在2.8.9版本添加了HyperLogLog 结构。
Redis HyperLogLog是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数星或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。在Redis里面，每个HyperLogLog键只需要花费12KB内存，就可以计算接近264个不同元素的基数
这和计算基数时，元素越多耗费，内存就越多的集合形成鲜明对比。
但是，因为HyperLogLog只会根据输入元素来计算基数，而不会储存输入元素本身，所以HyperLogLog不能像集合那样，返回输入的各个元素。
为什么是12Kb?每个桶取6位，163846÷8= 12kb，每个桶有6位，最大全部都是1，值就是63
9.4.2、案例代码
@Api(description = "案例实战总03:天猫网站首页亿级UV的Redis统计方案")
@RestController
@Slf4j
public class HyperLogLogController
{
@Resource
private RedisTemplate redisTemplate;
@ApiOperation("获得ip去重复后的首页访问量，总数统计")
@RequestMapping(value = "/uv",method = RequestMethod.GET)
public long uv()
{
//pfcount
return redisTemplate.opsForHyperLogLog().size("hll");
}
}
@Service
@Slf4j
public class HyperLogLogService
{
@Resource
private RedisTemplate redisTemplate;
/**
* 模拟有用户来点击首页，每个用户就是不同的ip，不重复记录，重复不记录
*/
@PostConstruct
public void init()
{
log.info("------模拟后台有用户点击，每个用户ip不同");
//自己启动线程模拟，实际上产不是线程
new Thread(() -> {
String ip = null;
for (int i = 1; i <=200; i++) {
Random random = new Random();
ip = random.nextInt(255)+"."+random.nextInt(255)+"."+random.nextInt(255)+"."+random.nextInt(255);
Long hll = redisTemplate.opsForHyperLogLog().add("hll", ip);
log.info("ip={},该ip访问过的次数={}",ip,hll);
//暂停3秒钟线程
try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
}
},"t1").start();
}
}
10、GEO(地理)
移动互联网时代LBS应用越来越多，交友软件中附近的小姐姐、外卖软件中附近的美食店铺、打车软件附近的车辆等等，那这种附近各种形形色色的XXX地址位置选择是如何实现的?
地球上的地理位置是使用二维的经纬度表示，经度范围(-180，180]，纬度范围(-90,90]，只要我们确定一个点的经纬度就可以名曲他在地球的位置。
例如滴滴打车，最直观的操作就是实时记录更新各个车的位置，然后当我们要找车时，在数据库中查找距离我们(坐标x0,y0)附近r公里范围内部的车辆
使用如下SQL即可:
select taxi from position where x0-r
1.查询性能问题，如果并发高，数据量大这种查询是要搞垮数据库的
2.这个查询的是一个矩形访问，而不是以我为中心r公里为半径的圆形访问。
3.精准度的问题，我们知道地球不是平面坐标系，而是一个圆球，这种矩形计算在长距离计算时会有很大误差
核心思想就是将球体转换为平面，区块转换为一点
主要分为三步，将三维的地球变为二维的坐标在将二维的坐标转换为一维的点块，最后将一维的卓块转换为二进制再通过base32编码
GeoHash核心原理解析：https://www.cnblogs.com/LBSer/p/3310455.html
10.1、地理概念
10.1.1、经纬度
经纬度：经度与纬度的合称组成一个坐标系统。又称为地理坐标系统，它是一种利用三度空间的球面来定义地球上的空间的球面坐标系统，能够标示地球上的任何一个位置。
10.1.2、经线和纬线
经线和纬线：是人们为了在地球上确定位置和方向的，在地球仪和地图上画出来的，地面上并线。和经线相垂直的线叫做纬线(纬线指示东西方向)。纬线是一条条长度不等的圆圈。最长的纬线就是赤道。因为经线指示南北方向，所以经线又叫子午线。国际上规定，把通过英国格林尼治天文台原址的经线叫做0°所以经线也叫本初子午线。在地球上经线指示南北方向，纬线指示东西方向。东西半球分界线:东经160°西经20°
10.1.3、经度和维度
经度和维度：经度(longitude):东经为正数，西经为负数。东西经纬度(latitude):北纬为正数，南纬为负数。南北纬
经纬度查询：https://jingweidu.bmcx.com/
10.2、命令
- GEOADD：多个经度(longitude)、纬度(latitude)、位置名称(member)添加到指定的key ：
GEOADD key longitude latitude member [longitude latitude member ...] - GEOPOS ：从键里面返回所有给定位置元素的位置（经度和纬度)：
GEOPOS key member [member ...] - GEODIST：返回两个给定位置之间的距离 ：
GEODIST key member1 member2 [m|km|ft|mi] - GEORADIUS ：以给定的经纬度为中心，返回与中心的距离不超过给定最大距离的所在地理位置集合：
GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key] - GEORADIUSBYMEMBER：georadiusbymember 和 GEORADIUS 命令一样， 都可以找出位于指定范围内的元素， 但是 georadiusbymember 的中心点是由给定的位置元素决定的， 而不是使用经度和纬度来决定中心点。
GEORADIUSBYMEMBER key member radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key] - GEOHASH ：返回一个或多个位置元素的Geohash表示：
GEOHASH key member [member ...]
10.3、命令实操
10.3.1、 如何获得某个地址的经纬度
- http://api.map.baidu.com/lbsapi/getpoint/
- https://jingweidu.bmcx.com/
10.3.2、GEOADD添加经纬度坐标
geoadd：geoadd用于存储指定的地理空间位置，可以将一个或多个经度(longitude)、纬度(latitude)、位置名称(member)添加到指定的key
geoadd语法格式如下: GEOADD key longitude latitude member [longitude latitude member ...]
geo的类型其本质是zset类型
中文乱码如何处理：–rw
10.3.3、GEOPOS返回经纬度
GEOPOS ：从键里面返回所有给定位置元素的位置（经度和纬度)：GEOPOS key member [member ...]
geopos city 北京
10.3.4、GEOHASH返回坐标的geohash表示
GEOHASH ：返回一个或多个位置元素的Geohash表示：GEOHASH key member [member ...]
geohash city 北京
10.3.5、GEODIST两个位置之间距离
GEODIST：返回两个给定位置之间的距离 ：GEODIST key member1 member2 [m|km|ft|mi]，member1 member2 为两个地理位置。
最后一个距离单位参数说明：
- m ：米，默认单位。
- km ：千米。
- mi ：英里。
- ft ：英尺。
10.3.6、GEORADIUS
GEORADIUS ：以给定的经纬度为中心，返回与中心的距离不超过给定最大距离的所在地理位置集合：GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
主要用于以半径为中心，查找附近的XXX
参数说明：
- m ：米，默认单位。
- km ：千米。
- mi ：英里。
- ft ：英尺。
- WITHDIST: 在返回位置元素的同时， 将位置元素与中心之间的距离也一并返回。
- WITHCOORD: 将位置元素的经度和纬度也一并返回。
- WITHHASH: 以 52 位有符号整数的形式， 返回位置元素经过原始 geohash 编码的有序集合分值。 这个选项主要用于底层应用或者调试， 实际中的作用并不大。
- COUNT 限定返回的记录数。
- ASC: 查找结果根据距离从近到远排序。
- DESC: 查找结果根据从远到近排序。
10.3.7、GEORADIUSBYMEMBER
GEORADIUSBYMEMBER：georadiusbymember 和 GEORADIUS 命令一样， 都可以找出位于指定范围内的元素， 但是 georadiusbymember 的中心点是由给定的位置元素决定的， 而不是使用经度和纬度来决定中心点。GEORADIUSBYMEMBER key member radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
GEORADIUSBYMEMBER找出位于指定范围内的元素，中心点是由给定的位置元素决定
参数说明：
- m ：米，默认单位。
- km ：千米。
- mi ：英里。
- ft ：英尺。
- WITHDIST: 在返回位置元素的同时， 将位置元素与中心之间的距离也一并返回。
- WITHCOORD: 将位置元素的经度和纬度也一并返回。
- WITHHASH: 以 52 位有符号整数的形式， 返回位置元素经过原始 geohash 编码的有序集合分值。 这个选项主要用于底层应用或者调试， 实际中的作用并不大。
- COUNT 限定返回的记录数。
- ASC: 查找结果根据距离从近到远排序。
- DESC: 查找结果根据从远到近排序。
10.4、地图附近搜索案例
需求：
- 微信附近的人或者一公里以内的各种营业厅、加油站、理发店、超市
- 摇个妹子
- 找个单车
- 附近的酒店
@RestController
public class GeoController
{
public static final String CITY ="city";
@Autowired
private RedisTemplate redisTemplate;
@ApiOperation("新增天安门故宫长城经纬度")
@RequestMapping(value = "/geoadd",method = RequestMethod.POST)
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.362639));
redisTemplate.opsForGeo().add(CITY,map);
return map.toString();
}
@ApiOperation("获取地理位置的坐标")
@RequestMapping(value = "/geopos",method = RequestMethod.GET)
public Point position(String member) {
//获取经纬度坐标
List<Point> list= this.redisTemplate.opsForGeo().position(CITY,member);
return list.get(0);
}
@ApiOperation("geohash算法生成的base32编码值")
@RequestMapping(value = "/geohash",method = RequestMethod.GET)
public String hash(String member) {
//geohash算法生成的base32编码值
List<String> list= this.redisTemplate.opsForGeo().hash(CITY,member);
return list.get(0);
}
@ApiOperation("计算两个位置之间的距离")
@RequestMapping(value = "/geodist",method = RequestMethod.GET)
public Distance distance(String member1, String member2) {
Distance distance= this.redisTemplate.opsForGeo().distance(CITY,member1,member2, RedisGeoCommands.DistanceUnit.KILOMETERS);
return distance;
}
/**
* 通过经度，纬度查找附近的
* 北京王府井位置116.418017,39.914402,这里为了方便讲课，故意写死
*/
@ApiOperation("通过经度，纬度查找附近的")
@RequestMapping(value = "/georadius",method = RequestMethod.GET)
public GeoResults radiusByxy() {
//这个坐标是北京王府井位置
Circle circle = new Circle(116.418017, 39.914402, Metrics.MILES.getMultiplier());
//返回50条
RedisGeoCommands.GeoRadiusCommandArgs args = RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates().sortAscending().limit(10);
GeoResults<RedisGeoCommands.GeoLocation<String>> geoResults= this.redisTemplate.opsForGeo().radius(CITY,circle, args);
return geoResults;
}
/**
* 通过地方查找附近
*/
@ApiOperation("通过地方查找附近")
@RequestMapping(value = "/georadiusByMember",method = RequestMethod.GET)
public GeoResults radiusByMember() {
String member="天安门";
//返回50条
RedisGeoCommands.GeoRadiusCommandArgs args = RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates().sortAscending().limit(10);
//半径10公里内
Distance distance=new Distance(10, Metrics.KILOMETERS);
GeoResults<RedisGeoCommands.GeoLocation<String>> geoResults= this.redisTemplate.opsForGeo().radius(CITY,member, distance,args);
return geoResults;
}
}