Redis数据存储类型
Redis数据存储类型
- redis 数据存储格式
- String类型
- string 作为数值操作
- 业务场景一
- 解决方案:
- 业务场景二
- 解决方案
- string 类型数据操作的注意事项
- 业务场景三
- 解决方案
- 数据库中的热点数据key命名惯例
- hash类型
- hash 类型数据操作的注意事项
- hash类型应用场景
- 业务场景一
- 解决方案
- 业务场景二
- 解决方案
- list类型
- 业务场景一
- 解决方案
- list 类型数据操作注意事项
- 业务场景二
- 解决方案
- set类型
- 业务场景一
- 业务分析
- 解决方案
- 业务场景二
- 业务分析
- 解决方案
- set 类型数据操作的注意事项
- 业务场景三
- 解决方案
- 业务场景四
- 解决方案
- sorted_set 类型
- 业务场景一
- 业务分析
- 解决方案
- sorted_set 类型数据操作的注意事项
- 业务场景二
- 解决方案
- 业务场景三
- 解决方案
- 解决方案列表总结
redis 数据存储格式
- redis 自身是一个 Map，其中所有的数据都是采用 key : value 的形式存储
- 数据类型指的是存储的数据的类型，也就是 value 部分的类型， key 部分永远都是字符串
String类型
存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型
存储数据的格式：一个存储空间保存一个数据
存储内容：通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用
string 作为数值操作
- string在redis内部存储默认就是一个字符串，当遇到增减类操作incr， decr时会转成数值型进行计算
- redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发 带来的数据影响
- 注意： 按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis 数值上限范围，将报错。 9223372036854775807（ java中long型数据最大值， Long.MAX_VALUE）
业务场景一
大型企业级应用中，分表操作是基本操作，使用多张表存储同类型数据，但是对应的主键 id必须保证统一性，不能重复。Oracle 数据库具有sequence设定，可以解决该问题，但是MySQL数据库并不具有类似的机制，那么如何解决?
解决方案:
- 设置数值数据增加指定范围的值
- 设置数据减少指定范围的值
Tips 1：
- redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性
- 此方案适用于所有数据库，且支持数据库集群
业务场景二
“最强女生”启动海选投票，只能通过微信投票，每个微信号每 4 小时只能投1票。
电商商家开启热门商品推荐，热门商品不能一直处于热门期，每种商品热门期维持3天，3天后自动取消热门。
新闻网站会出现热点新闻，热点新闻最大的特征是时效性，如何自动控制热点新闻的时效性。
针对着三个场景，可以对数据指定声明周期
解决方案
- 设置数据具有指定的声明周期
Tips 2：
- redis 控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作
string 类型数据操作的注意事项
- 数据操作不成功的反馈与数据正常操作之间的差异
- ① 表示运行结果是否成功
- (integer) 0 → false 失败
- (integer) 1 → true 成功
- ② 表示运行结果值
- (integer) 3 → 3 3个
- (integer) 1 → 1 1个
- 数据未获取到
（ nil）等同于null - 数据最大存储量
- 512MB
- 数值计算最大范围（ java中的long的最大值）
- 9223372036854775807
业务场景三
主页高频访问信息显示控制，例如新浪微博大V主页显示粉丝数与微博数量
解决方案
- 在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可
eg: user:id:3506728370:fans → 12210947
eg: user:id:3506728370:blogs → 6164
eg: user:id:3506728370:focuss → 83
- 在redis中以json格式存储大V用户信息，定时刷新(也可以使用hash类型)
eg: user:id:3506728370 →{“id”:3506728370,”name”:”春晚”,”fans”:12210862,”blogs”:6164, “focus”:83}
Tips 3：
- redis应用于各种结构型和非结构型高热度数据访问加速
数据库中的热点数据key命名惯例
表名 : 主键名 : 主键值 : 字段名
eg1: order: id : 29437595 : name
eg2: equip: id : 390472345 : type
eg3: news : id : 202004150 : title
hash类型
- 新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息
- 需要的存储结构：一个存储空间保存多个键值对数据
- hash类型：底层使用哈希表结构实现数据存储
hash存储结构优化 - 如果field数量较少，存储结构优化为类数组结构
- 如果field数量较多，存储结构使用HashMap结构
hash 类型数据操作的注意事项
- hash类型下的value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（ nil）
- 每个 hash 可以存储 232 - 1 个键值对
- hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用
- hgetall 操作可以获取全部属性，如果内部field过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈
hash类型应用场景
业务场景一
电商网站购物车设计与实现（这里仅分析购物车redis存储模型，添加、浏览、更改数量、删除、清空）
解决方案
- 以客户id作为key，每位客户创建一个hash存储结构存储对应的购物车信息
- 将商品编号作为field，购买数量作为value进行存储
- 添加商品：追加全新的field与value
- 浏览：遍历hash
- 更改数量：自增/自减，设置value值
- 删除商品：删除field
- 清空：删除key
但是当前这种设计仅仅是将数据存储到了redis中，并没有起到加速的作用，商品信息还需要二次查询数据库，所有可以在属性中加入商品信息
- 每条购物车中的商品记录保存成两条field
- field1专用于保存购买数量
命名格式：商品id:nums
保存数据：数值 - field2专用于保存购物车中显示的信息，包含文字描述，图片地址，所属商家信息等
命名格式：商品id:info
保存数据：json
但是这种设计也存在一个缺陷，就是有重复字段信息，如果有多个用户买这个商品，那么每个用户都有这个商品信息，这样就造成了冗余。可以把这个信息抽取出来，作为单独的hash存储。
Tips 4：
- redis 应用于购物车数据存储设计
业务场景二
- 双11活动日，销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000张
解决方案
- 以商家id作为key
- 将参与抢购的商品id作为field
- 将参与抢购的商品数量作为对应的value
- 抢购时使用降值的方式控制产品数量
Tips 5：
- redis 应用于抢购，限购类、限量发放优惠卷、激活码等业务的数据存储设计
list类型
数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
- 需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
- list类型：保存多个数据，底层使用双向链表存储结构实现
业务场景一
微信朋友圈点赞，要求按照点赞顺序显示点赞好友信息 如果取消点赞，移除对应好友信息。
解决方案
- 可以用lrem key count value命令移除对应的好友信息
Tips 6：
- redis 应用于具有操作先后顺序的数据控制
list 类型数据操作注意事项
- list中保存的数据都是string类型的，数据总容量是有限的，最多232 - 1 个元素 (4294967295)。
- list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
- 获取全部数据操作结束索引设置为-1
- list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载
业务场景二
twitter、新浪微博、腾讯微博中个人用户的关注列表需要按照用户的关注顺序进行展示，粉丝列表需要将最 近关注的粉丝列在前面
新闻、资讯类网站如何将最新的新闻或资讯按照发生的时间顺序展示?
企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出?
解决方案
- 依赖list的数据具有顺序的特征对信息进行管理
- 使用队列模型解决多路信息汇总合并的问题
- 使用栈模型解决最新消息的问题
Tips 7：
- redis 应用于最新消息展示
set类型
- 新的存储需求：存储大量的数据，在查询方面提供更高的效率
- 需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
- set类型：与hash存储结构完全相同，仅存储键，不存储值（ nil），并且值是不允许重复的
业务场景一
每位用户首次使用今日头条时会设置3项爱好的内容，但是后期为了增加用户的活跃度、兴趣点，必须让用户对其他信息类别逐渐产生兴趣，增加客户留存度，如何实现?
业务分析
系统分析出各个分类的最新或最热点信息条目并组织成set集合
随机挑选其中部分信息
配合用户关注信息分类中的热点信息组织成展示的全信息集合
解决方案
- 随机获取集合中指定数量的数据
- 随机获取集合中的某个数据并将该数据移出集合
Tips 8：
- redis 应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用APP推荐，大V推荐等
业务场景二
脉脉为了促进用户间的交流，保障业务成单率的提升，需要让每位用户拥有大量的好友，事实上职场新人不具有更多的职场好友，如何快速为用户积累更多的好友?
业务分析
系统分析出各个用户的好友列表，并组成set集合
将各个用户的好友列表与好友的好友列表进行交、并、差集
将交、并、差集的筛选出的结果推送给用户
解决方案
- 求两个集合的交、并、差集
- 求两个集合的交、并、差集并存储到指定集合中
- 将指定数据从原始集合中移动到目标集合中
Tips 9：
- redis 应用于同类信息的关联搜索，二度关联搜索，深度关联搜索
- 显示共同关注（一度）
- 显示共同好友（一度）
- 由用户A出发，获取到好友用户B的好友信息列表（一度）
- 由用户A出发，获取到好友用户B的购物清单列表（二度）
- 由用户A出发，获取到好友用户B的游戏充值列表（二度）
Tips 10：
- redis 应用于同类型不重复数据的合并、取交集操作
set 类型数据操作的注意事项
-
set 类型不允许数据重复，如果添加的数据在 set 中已经存在，将只保留一份
-
set 虽然与hash的存储结构相同，但是无法启用hash中存储值的空间
业务场景三
公司对旗下新的网站做推广，统计网站的PV(访问量),UV(独立访客),IP(独立IP)。
PV:网站被访问次数，可通过刷新页面提高访问量
UV:网站被不同用户访问的次数，可通过cookie统计访问量，相同用户切换IP地址，UV不变
IP:网站被不同IP地址访问的总次数，可通过IP地址统计访问量，相同IP不同用户访问，IP不变
解决方案
- 利用set集合的数据去重特征，记录各种访问数据
- 建立string类型数据，利用incr统计日访问量(PV)
- 建立set模型，记录不同cookie数量(UV)
- 建立set模型，记录不同IP数量(IP)
Tips 11：
- redis 应用于同类型数据的快速去重
业务场景四
网站的黑白名单设置
解决方案
- 基于经营战略设定问题用户发现、鉴别规则
- 周期性更新满足规则的用户黑名单，加入set集合
- 用户行为信息达到后与黑名单进行比对，确认行为去向
- 黑名单过滤IP地址:应用于开放游客访问权限的信息源
- 黑名单过滤设备信息:应用于限定访问设备的信息源
- 黑名单过滤用户:应用于基于访问权限的信息源
Tips 12：
- redis 应用于基于黑名单与白名单设定的服务控制
sorted_set 类型
- 新的存储需求：数据排序有利于数据的有效展示，需要提供一种可以根据自身特征进行排序的方式
- 需要的存储结构：新的存储模型，可以保存可排序的数据
- sorted_set类型：在set的存储结构基础上添加可排序字段
业务场景一
票选广东十大杰出青年，各类综艺选秀海选投票
各类资源网站TOP10(电影，歌曲，文档，电商，游戏等)
聊天室活跃度统计
游戏好友亲密度
业务分析
为所有参与排名的资源建立排序依据
解决方案
- 获取数据对应的索引（排名）
- score值获取与修改
- redis 应用于计数器组合排序功能对应的排名
Tips 13：
- redis 应用于计数器组合排序功能对应的排名
sorted_set 类型数据操作的注意事项
- score保存的数据存储空间是64位，如果是整数范围是-9007199254740992~9007199254740992
- score保存的数据也可以是一个双精度的double值，基于双精度浮点数的特征，可能会丢失精度，使用时候要慎重
- sorted_set 底层存储还是基于set结构的，因此数据不能重复，如果重复添加相同的数据， score值将被反复覆盖，保留最后一次修改的结果
业务场景二
基础服务+增值服务类网站会设定各位会员的试用，让用户充分体验会员优势。例如观影试用VIP、游戏 VIP体验、云盘下载体验VIP、数据查看体验VIP。当VIP体验到期后，如果有效管理此类信息。即便对于正式 VIP用户也存在对应的管理方式。
网站会定期开启投票、讨论，限时进行，逾期作废。如何有效管理此类过期信息。
解决方案
对于基于时间线限定的任务处理，将处理时间记录为score值，利用排序功能区分处理的先后顺序
- 记录下一个要处理的时间，当到期后处理对应任务，移除redis中的记录，并记录下一个要处理的时间
- 当新任务加入时，判定并更新当前下一个要处理的任务时间
- 为提升sorted_set的性能，通常将任务根据特征存储成若干个sorted_set。例如1小时内，1天内，周内，月内，季内，年度等，操作时逐级提升，将即将操作的若干个任务纳入到1小时内处理的队列中
- 获取当前系统时间
Tips 14：
- redis 应用于定时任务执行顺序管理或任务过期管理
业务场景三
任务/消息权重设定应用
当任务或者消息待处理，形成了任务队列或消息队列时，对于高优先级的任务要保障对其优先处理，如何实现任务权重管理。
解决方案
- 对于带有权重的任务，优先处理权重高的任务，采用score记录权重即可 多条件任务权重设定
如果权重条件过多时，需要对排序score值进行处理，保障score值能够兼容2条件或者多条件，例如外贸订单优先于国内订单，总裁订单优先于员工订单，经理订单优先于员工订单
- 因score长度受限，需要对数据进行截断处理，尤其是时间设置为小时或分钟级即可(折算后)
- 先设定订单类别，后设定订单发起角色类别，整体score长度必须是统一的，不足位补0。第一排序规则首位不得是0
- 例如外贸101，国内102，经理004，员工008。
- 员工下的外贸单score值为101008(优先)
- 经理下的国内单score值为102004
Tips 15：
- redis 应用于即时任务/消息队列执行管理
解决方案列表总结
Tips 1： redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性
- Tips 2： redis 控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作
- Tips 3： redis应用于各种结构型和非结构型高热度数据访问加速
- Tips 4： redis 应用于购物车数据存储设计
- Tips 5： redis 应用于抢购，限购类、限量发放优惠卷、激活码等业务的数据存储设计
- Tips 6： redis 应用于具有操作先后顺序的数据控制
- Tips 7： redis 应用于最新消息展示
- Tips 8： redis 应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用APP推荐，大V推荐等
- Tips 9： redis 应用于同类信息的关联搜索，二度关联搜索，深度关联搜索
- Tips 10： redis 应用于同类型不重复数据的合并、取交集操作
- Tips 11： redis 应用于同类型数据的快速去重
- Tips 12： redis 应用于基于黑名单与白名单设定的服务控制
- Tips 13： redis 应用于计数器组合排序功能对应的排名
- Tips 14： redis 应用于定时任务执行顺序管理或任务过期管理
- Tips 15： redis 应用于及时任务/消息队列执行管理
- Tips 16： redis 应用于按次结算的服务控制
- Tips 17： redis 应用于基于时间顺序的数据操作，而不关注具体时间