开心一刻
我在食堂吃饭,咬到了舌头我疼的大叫。。。
二货室友问我怎么了,我疼的说不出话就指指嘴,然后吐了点血。。。
这二货大叫:“大家别吃了,饭里有毒!”
题目引出
Redis本身作为一个Nosql型数据库,具有Nosql型数据库的优点,同时实现多种数据类型,具有丰富的应用场景,在这里记录一些典型的应用场景,以便后续的学习。
字符串应用场景
- 缓存功能
典型使用场景:Redis作为缓存层,MySQL作为存储层,绝大部分请求的数据都是从Redis中获取,由于Redis具有支撑高并发的特性,所以缓存通常能起到加速读写和降低后端压力的作用。
- 计数
典型应用场景:视频播放数计数的基础组件,用户每播放一次视频,相应的视频播放数就会自增1。Redis可以实现快速计数、查询缓存的功能,同时数据可以异步落地到其他数据源。
开发提示:实际上一个真实的计数系统要考虑的问题会很多,防作弊、按照不同维度计数,数据持久化到底层数据源等。
- 共享Session
典型应用场景:用户登陆信息,Redis将用户的Session进行集中管理,每次用户更新或查询登陆信息都直接从Redis中集中获取。
- 限速
典型应用场景:验证码接口访问频率限制,用户登陆时需要让用户输入手机验证码,从而确定是否是用户本人,但是为了短信接口不被频繁访问,会限制用户每分钟获取验证码的频率,例如一分钟不能超过5次。
- 分布式锁
利用Redis中的SETNX可以实现简单的分布式锁。
哈希应用场景
- 缓存用户信息
相比于使用字符串序列化缓存用户信息,哈希类型变得更加直观,并且在更新操作上会更加便捷。可以将每个用户的id定义为键后缀,多对field-value对应每个用户的属性。
哈希类型和关系型数据库不同之处:
哈希类型是稀疏的,而关系型数据库是完全结构化的,例如哈希类型每个键可以有不同的field,而关系型数据库一旦添加新的列,所有行都要为其设置值(即使为NULL)。
关系型数据库可以做复杂的关系查询,而Redis去模拟关系型复杂查询开发困难,维护成本高。
三种缓存用户信息优缺点比较:
原生字符串类型:每个属性一个键
优点:简单直观,每个属性都支持更新操作。
缺点:占用过多的键,内存占用量较大,同时用户信息内聚性比较差,所以此种方案一般不会在生产环境使用。
序列化字符串类型:将用户信息序列化后用一个键保存。
优点:简化编程,如果合理的使用序列化可以提高内存的使用效率。
缺点:序列化和反序列化有一定的开销,同时每次更新属性都需要把全部数据取出进行反序列化,更新后再序列化到Redis中。
哈希类型:每个用户属性使用一对field-value,但是只用一个键保存。
优点:简单直观,如果使用合理可以减少内存空间的使用。
缺点:要控制哈希在ziplist和hashtable两种内部编码的转换,hashtable会消耗更多内存。
列表应用场景
- 消息队列
Redis的lpush+brpop命令组合即可实现阻塞队列,生产者客户端使用lrpush从列表左侧插入元素,多个消费者客户端使用brpop命令阻塞式的"抢"列表尾部的元素,多个客户端保证了消费的负载均衡和高可用性。
- 文章列表
每个用户有属于自己的文章列表,现在需要分页展示文章列表。此时可以考虑使用列表,因为列表不但是有序的,同时支持按照索引范围获取元素。
- 用作栈、队列、有限集合、消息队列等
lpush + lpop = Stack(栈)
lpush + rpop = Queue(队列)
lpush + ltrim = Capped Collection(有限集合)
lpush + brpop = Message Queue(消息队列)
集合应用场景
集合类型比较典型的使用场景是标签(tag),例如一个用户可能对娱乐、体育比较感兴趣,另一个用户可能对历史、新闻比较感兴趣,这些兴趣就是标签。 开发提示:用户和标签的关系维护应该在一个事物执行,防止部分命令失败造成的数据不一致。
还可以使用集合的交并补等操作,用于计算两个用户之间的共同好友等。用户点赞、收藏等
有序集合应用场景
有序集合比较典型的使用场景就是排行榜系统,例如视频网站需要对用户上传的视频做排行榜,榜单的维度可能是多个方面的:按照时间、按照播放数量、按照获得的赞数。
其他
Redis中除了5种基本数据类型,还有三种特殊数据类型geospatial、hyperloglog、bitmap 。
- geospatial: Redis 在 3.2 推出 Geo 类型,该功能可以推算出地理位置信息,两地之间的距离。
- hyperloglog:基数:数学上集合的元素个数,是不能重复的。这个数据结构常用于统计网站的 UV。
- bitmap 常用于统计用户信息比如活跃粉丝和不活跃粉丝、登录和未登录、是否打卡等。