GeminiDB新特性:让Redis广告频控爱不释手的exHASH

举报
GaussDB 数据库 发表于 2023/11/22 10:25:38 2023/11/22
【摘要】 GeminiDB Redis接口现已支持可为Field设置过期时间和版本的exHash类型,对开源Redis的Hash类型进行了扩展。

exHash类型是一种支持Field过期的新型数据类型,它在原先的Hash类型基础上进行了扩展:在支持Hash类型的通用功能以外,exHash类型还支持为Field设置过期时间和版本,增强了数据结构的灵活性,从而简化了很多复杂场景下的业务开发工作。

本文以两种常见的场景(频控场景&购物车)为例,通过使用GeminiDB Redis接口中的exHash类命令来实现复杂的业务,简化开发难度。

一、exHash命令使用简介

1.png

命令语法定义如下:

  • 大写关键字:命令关键字。
  • 斜体:变量。
  • [options]:可选参数,不在括号中的参数为必选。
  • A|B:该组参数互斥,请进行二选一或多选一。
  • ...:前面的内容可重复。

二、应用场景

1. 频控场景

频控指的是对用户在一定时间内(例如一天、一周、一个月)进行某种操作的次数进行限制,可以控制特定广告或信息在一定时间内在特定平台上的展示次数,以避免过度曝光和广告疲劳,同时优化广告效果和用户体验;对于广告来说,也可以提高广告的效果和转化率。此外,频控还可以避免恶意行为,如刷流量、刷评论、刷点赞等。

频控的3个要素包含用户ID、广告ID、触发次数;以用户IDkey,广告IDfield,指定时间内的触发次数为value,恰好构成频控的三要素。先配置好各个广告的指定频控策略,如下图所示即可根据如下的方式来实现频控:

2.png

  • 最左边通过Hash类型来实现,通过expire命令设置User_1的过期时间为一天,每推送一次通过hincrby来增加指定广告的推送次数,每次推送指定广告前在一天内的推送次数则可以通过hget获取进行判断,一天后该用户的数据自动过期无需手动清理,这样便可以简单地实现频控。但这个方案的缺点在于对于每个用户(即每个key)只能设置一个过期时间,无法做到例如8小时3次这样指定时间段内的灵活的频控策略。
  • 为了做到对每个广告都配置指定时间段内的灵活频控,如中间图所示可以通过将时间戳拼接在value里的方式用Hash类型来实现,但这种方案无疑是增加了业务侧开发的工作量。
  • 如最右图所示,支持给field设置过期时间的exHash类型可以很完美地解决Hash类型面对频控场景的缺点。由于Field支持过期时间设置,那么该场景下,平台可以给每个广告都配置不同时间段内的频次要求,假设此时给AD_2配置的频控策略为8小时内2次,那么如图所示在下一次再准备给User_1推送AD_2广告前,先通过exhget User_1 AD_2命令获取到了该值已经是2时,便可以判断出此时根据平台频控策略,不应该再给User_1推送AD_2广告了。而当8小时一过,User_1AD_2这个field过期后,exhget无法再获取到这个field的信息,则可以继续给User_1推送AD_2广告了。

2. 购物车场景

最近双十一期间,相信很多同学购物车里都填满了各种想要清空的宝贝,这里就以购物车场景为例介绍该场景的几种不同Redis类型的实现,并比较这几种实现方案的优缺点。

1)基于String实现购物车功能

如图所示基于String可以轻松地实现各个用户的购物车功能,该方案需要将用户ID与商品ID进行拼接作为key,例如User_1#Earphones_1key对应的value为购物车中用户准备购买的数量,其中可能有部分商品为限时特购,所以有过期时间,为key对应的过期时间。

3.png

涉及命令如下:

4.png

该方案会存在如下问题:

  • 额外拼接增加编、解码开发工作量
  • 某个用户获取自己的购物车清单时还需要通过scan命令前缀匹配扫描所有key,并通过get命令去获取对应的值。
  • 想要直接获取清单长度时,仍然需要遍历整个前缀key的数目,方法复杂。
  • 存在大量重复的用户名前缀,浪费存储空间。

2)基于Hash实现购物车功能

可以根据如图所示的Hash类型来实现购物车的管理,用户ID作为key,商品ID作为fieldvalue为购物车中对应商品的数量。其中对于部分限时特购的商品,其过期时间通过拼接的方式放到field对应的value里。

5.png

涉及命令如下:

6.png

该方案相对于String类型的方案有了不少优化:

  • 获取某个用户购物车中的所有商品清单仅需要一个hgetall命令即可
  • 获取某个用户的清单长度时直接hlen获取即可
  • 不存在大量重复的用户名前缀问题

然而该方案仍存在一个明显的缺点,即对于部分限时特购的商品处理起来复杂:对于User_1Keyboard_1商品,如果要再加一个数量,不能直接使用hincrby,而是需要先hget获取Keyboard_1商品的值并解码,再加上指定的数量再编码后hset对应的值。

3)基于exHash实现购物车功能

根据如图所示的exHash类型来实现购物车的管理,同Hash类型一样,用户ID作为key,商品ID作为fieldvalue为购物车中对应商品的数量。其中对于部分限时特购的商品,由于exHash类型可以为Field设置过期时间,其过期时间可通过hset命令直接设置。

7.png

涉及命令如下:

8.png

该方案相对于Hash类型的优化主要体现在可以直接为各field设置过期时间,使业务侧使用起来简单又高效。可以看到exHash类型相关的命令和Hash类型是类似的,使用起来学习成本很低,业务侧改造成本相对也比较低。

9.png

图1.1 华为商城购物车中,用户ID、商品ID、商品数量及exhash类型命令的使用。

三、总结

本文介绍了GeminiDB Redis接口的exHash类型的特性、使用方法及应用场景。为客户提供了一种语法与原生Redis Hash类型类似、和Hash类型的使用相互隔离、支持给Field单独设置过期时间和版本的exHash类型作为各种复杂场景的解决方案。未来,GeminiDB Redis接口将持续致力于开发更多好用的企业级特性,帮助客户轻松运维,高效开发。

如果你的业务需要一款稳定可靠的KV数据库,可以试试GeminiDB Redis接口。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。