手机网站建设报价多少,wordpress中上传图片,网络游戏那个网站做的最好,市场营销考试题目及答案2022目录标题 数据类型String优点缺点底层结构使用场景实际使用 List优点缺点底层结构使用场景实际使用 Hash优点缺点底层结构使用场景实际使用 Set优点缺点底层结构使用场景实际使用 Zset优点缺点底层结构使用场景实际使用 HyperLogLog优点缺点底层结构使用场景实际使用 GEO优点缺… 目录标题 数据类型String优点缺点底层结构使用场景实际使用 List优点缺点底层结构使用场景实际使用 Hash优点缺点底层结构使用场景实际使用 Set优点缺点底层结构使用场景实际使用 Zset优点缺点底层结构使用场景实际使用 HyperLogLog优点缺点底层结构使用场景实际使用 GEO优点缺点底层结构使用场景实际使用 Stream简介使用场景实际使用 BitMap 类型抉择空间占用数据特征数据删除策略定时删除惰性删除定期删除 数据淘汰策略 数据类型
redis中value的最大容量默认是 512M各个数据类型初始容量如下
String512MSetZSetListHash2^32 -1 个元素
总结任何系统都是在内存和性能之间不断抉择使用最少的内存提供可接受的反应速度。redis亦如此。
String
优点
简单直观便捷存储单个元素/散列元素。提供字符串函数append等
缺点
占用过多的键内存占用量较大同时用户信息内聚性比较差。难以管理
底层结构
简单动态字符串simple dynamic string字节数组未用空间已用空间预分配空间方便快速扩容及确定字段长度牺牲空间换时间
使用场景
可以存储任意类型的数据包括文本、数字等。
实际使用
热点用户个人信息库存计数器分布式锁项目奖品策略广告点击次数验证码
List
优点
存储有序数据支持从列表的两端进行元素的插入和删除操作。
缺点
数据耦合高取内部元素相对耗时
底层结构
老版本是双向链表压缩列表双向链表即prevaluenext压缩链表即分配一段连续内存省掉pre和next的损耗前者适合大量元素后者适合少量元素
新版本采用快速链表是前两者的融合pre小型双向链表next即将长度较大的双向链表进行分段存储。
压缩列表ziplist 插入元素过多或字符串太大就需要调用 realloc 扩展内存 双向链表linkedlist 需附加指针prev 和 next较浪费空间加重内存的碎片化
因为双向链表占用的内存比压缩列表要多所以当创建新列表时会优先考虑使用压缩列表并且在有需要的时候才从压缩列表实现转换到双向链表实现。
压缩列表转化成双向链表条件有两个
列表中某个字符串值超过 list_max_ziplist_value默认64字节 列表的元素个数超过 list_max_ziplist_entries默认 512个
使用场景
有序消息或者固定容量数据。例如消息队列、最新消息排行
实际使用
消息队列虽然可以但不建议因为redis会丢消息它是缓存不是持久存储除非是不重要的消息
广告展示默认展示最新条数设置长度固定的list每次从顶端插入从尾端剔除元素中奖名单同样固定容量顶端插入提出尾部元素。
Hash
优点
通过一个key对应多个字段和对应的值适用于存储对象属性、配置信息等复杂数据结构。
缺点
数据占用空间过大时增删耗时旧甚至引起reids卡顿
底层结构
压缩列表hashtable与list的压缩列表不同的是它存储的不仅是feildvalue交替存储hashtable即java的hashmap数组链表。 渐进式扩容新老hashtable交替执行即旧数据慢慢同步至新hashtable中。
新建hash值时优先使用压缩列表实现压缩列表使用更加紧凑的连续内存结构可以节省空间其读写复杂度为On当数据量过大或者字段过多读写效率减低此时会转化为hashtable占用更多的内存读写复杂度降低为O1。转化条件
哈希类型元素个数大于hash-max-ziplist-entries配置默认512个有字段值大于hash-max-ziplist-value配置默认64字节
使用场景
总是需要获取单一属性的值数据既耦合又方便存取。
实际使用
地理位置信息对应关系项目配置信息
Set
优点
无序集合可以存储多个字符串元素并提供高效的集合操作如交集、并集、差集等。
缺点
大量数据会导致redis卡顿
底层结构
intsethashTable采用hashTable存储只是value统一设置为null为什么不用ziplist来节省空间是因为必须保证元素的唯一性。
inset可理解为数组使用intset存储必须满足下面两个条件否则使用hashtable条件如下
对象保存的所有元素都是整数值int对象保存的元素数量不超过512个
使用场景
需要进行集合运算的数据。
例如文章标签管理-可根据多个标签聚合查询文章社交网络好友关系-将每个用户的好友列表存储在Redis的集合中使用集合操作可以快速判断两个用户是否是好友还可以进行好友推荐等功能。
实际使用
经销商的门店服务列表业务员可以交叉负责经销商底下的门店利用经销商和门店的归属关系可以去重聚合出经销商的门店列表策略集聚合一个转盘会对应多个策略集通过条件判断出新老用户概念确定出需要聚合哪些的策略。
Zset
优点
存储多个字符串元素并为每个元素关联一个分数支持按照分数进行排序和范围查找。
缺点 内存开销Zset是基于跳表和哈希表实现的存储数据时会占用比简单的集合或列表更多的内存。因此在存储较大规模的数据时内存开销可能会显著增加。 性能开销在一些特定操作中如按得分范围查询ZRANGEBYSCORE或根据排名进行范围查询ZRANGE操作的复杂度为O(log(N) M)其中N是集合的大小而M是返回的小集合大小。这与其他类型的数据结构相比可能在性能上有所逊色尤其是在处理大数据量时。 数据排序虽然Zset提供了自动排序功能但在某些情况下如频繁更新得分这可能导致性能下降尤其是在需要多次更新和读取的场景下。
底层结构
hashtableskiplsithashtable存储k-score skiplist中的每个node存储 层级valuescore插入时按照score排序。
当元素数量不多时hashtable和SkipList的优势不明显而且更耗内存。因此zset还会采用ZipList结构来节省内存。
查询效率和红黑树相当。
使用场景
需要排序的数据
实际使用
业务员的补货数量排名。
HyperLogLog
优点
在输入元素的数量或者体积非常非常大时计算基数所需的空间总是固定 的、并且是很小的。
缺点
HyperLogLog 只会根据输入元素来计算基数而不会储存输入元素本身所以 HyperLogLog 不能像集合那样返回输入的各个元素。
底层结构
类似于java的set
使用场景
比如数据集 {1, 3, 5, 7, 5, 7, 8} 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内快速计算基数。
实际使用
需要用set的地方都可以使用
GEO
优点
进行坐标计算
缺点
相较于一些专门的地理空间数据库如 PostGISRedis Geo 的地理空间索引功能较为基本可能不适合需要复杂空间分析的应用。
底层结构
有序集合Sorted SetRedis 使用有序集合来存储地理位置数据每个地理位置由一个成员通常是地点的名称或标识符和对应的分值经纬度信息组成。分值是通过将经纬度转化为一个可以唯一标识该点的整数值。
使用场景
地理位置计算
实际使用
附近门店功能
Stream
简介
Stream 是 Redis 5.0 版本新增加的数据结构主要用于消息队列MQMessage QueueRedis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能。 但它有个缺点就是消息无法持久化如果出现网络断开、Redis 宕机等消息就会被丢弃。
使用场景
在处理可丢失的信息时可以采用该方式但一定要配合兜底的定时任务防止消息丢失后完全处理失败。
实际使用
入金后修改只读账号状态
BitMap
Bitmap数据类型可以看作是一种特殊的字符串它所占用空间中的每一个bit都只能是0或1。Redis内部将每个字符bit作为一个元素来处理因此我们可以在非常小的空间中存储大量的位信息。这使得Bitmap非常适合于存储和处理大规模的布尔型信息如用户的在线状态、活跃用户、用户访问记录等。
统计消费者的参与情况和业务员的工作情况。
类型抉择
多个集合操作聚合操作----用Set集合数据排序排序操作 ---- 分页排序建议使用ZSet集合数据只有0、1两种状态二值型数据----------- 0/1状态数据建议使用Bitmap集合中不重复元素个数基数统计----如果数据量达到亿级的话建议使用HyperLogLog。
当然以上都是套话任何抉择都一样搞清楚自己的需求对症下药即可当你对各种数据类型的特性了解之后自然就可以做出最正确的选择。何时何地何事都如此。
空间占用
以String类型计算k是tc:jdb:/UZJXTIP0CTZ6L0 v是32010670
2.4kw 5G1ww 25G
总结起来就是 1个kv占用218B。而在计算机中一个英文字母/整数通常占用1个字节1 B。这是因为在使用 ASCII 编码时单个英文字母无论是大写还是小写或者整数都可以用一个字节表示。
所以redis的空间占用大概是字节数的7倍。
数据特征
Redis是一种内存级数据库所有数据均存放在内存中内存中的数据可以通过TTL指令获取其状态。TTL返回的值有三种情况正数-1-2
正数代表该数据在内存中还能存活的时间-1永久有效的数据-2已经过期的数据 或被删除的数据 或 未定义的数据
redis中的过期时间是单独存储的Hash结构field是内存地址value是过期时间保存了所有key的过期描述在最终进行过期处理的时候对该空间的数据进行检测 当时间到期之后通过field找到内存该地址处的数据然后进行相关操作。 数据删除策略
删除策略就是针对已过期数据的处理策略已过期的数据是真的就立即删除了吗其实并不是redis有多种删除策略在不同的场景下使用不同的删除方式会有不同效果。
不同的删除策略就是对内存占用与CPU占用之间的不同侧重。目前有三种删除策略
定时删除时间换空间通过对cpu的无间断占用节约内存惰性删除空间换时间通过对内存的占用节约cpu资源定期删除折中方案花费少量cpu资源节约少量内存
定时删除
创建一个定时器当key设置有过期时间且过期时间到达时由定时器任务立即执行对键的删除操作
惰性删除
数据到达过期时间不做处理等该数据被访问时进行过期判断。如果未过期直接返回数据如果已过期先删除数据再返回数据不存在
定期删除
定时删除和惰性删除这两种方案都是走的极端那有没有折中方案是的redis还引入了一种定期删除策略进行了空间和性能的折中处理
已知redis 会将每个设置了过期时间的 key 放入到一个独立的字典中该方案是默认每秒进行十次过期扫描100ms一次过期扫描不会遍历过期字典中所有的 key而是采用了一种简单的贪心策略。
从过期字典中随机 20 个 key删除这 20 个 key 中已经过期的 key如果过期的 key 比率超过 1/4那就重复步骤 1
数据淘汰策略
