redis常见应用场景有哪些?(redis数据类型和应用场景类型区别)

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

大家好，今天来介绍redis常见应用场景有哪些?的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

redis数据类型和应用场景

Redis是当前比较热门的NOSQL系统之一，它是一个开源的使用ANSI c语言编写的key-value存储系统（区别于MySQL的二维表格的形式存储。），Redis数据都是缓存在计算机内存中并且它会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，实现数据的持久化。谈到存储数据，那么必然要涉及到相关的数据类型，redis主要有以下数据类型：

描述：string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个启碧 value。value其实不仅是String，也可以是数字。string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。

常用命令：get、set、incr、decr、mget等。

应用场景：规key-value缓存应用。常规计数: 点赞数, 粉丝数。

描述： hash 是一个键值(key => value)对集合。Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。

常用命令：hget,hset,hgetall 等。

应用场景：存储部分变更数据，如商品信息等。

描述：list 列表是简单的字符串列表，按照插入顺序排序。你可以添加一指圆个元素到列表的头部（左边）或者尾部（右边）。列表最多可存储 232 - 1 元素 (4294967295, 每个列表可存储40多亿)。

常用命令：lpush（添加左边元素）,rpush,lpop（移除左边第一个元素）,rpop,lrange（获取列表片段，LRANGE key start stop）等。

应用场景：消息队列，关注列表，粉丝列表等都可以用Redis的list结构来实现。

描述： set是string类型的无序集合。集合是通过hashtable实现的，概念和数学中个的集合基本类似，可以交集，并集，差集等等，set中的元素是没有顺序的。所以添加，删除，查找的复杂度都是O(1)。

常用命令：sadd,spop,smembers,sunion 等。

应用场景：交集，并集，差集（微博中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中）

描述：zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。不同是可以打分（排序）

常用命令：zadd,zrange,zrem,zcard等

应用场唯旁塌景：排行榜，带权重的消息队列

描述：Bitmaps这个“数据结构”可以实现对位的操作。 把数据结构加上引号主要因为：
Bitmaps本身不是一种数据结构， 实际上它就是字符串 ， 但是它可以对字符串的位进行操作。
Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。其实大多数Bitmaps的应用场景可以用其他数据类型来实现，用Bitmaps主要是存储空间占用特别少

常用命令：getbit key offset；setbit key offset value

应用场景：统计用户访问，统计电影某天的的播放量

描述：Redis 在 2.8.9 版本添加了 HyperLogLog 结构。Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。这类数据结构的基本大的思路就是使用统计概率上的算法，牺牲数据的精准性来节省内存的占用空间及提升相关操作的性能

常用命令：pfadd， pfcount，pfmerge

应用场景：统计网站的每日UV

描述：GEO功能在Redis3.2版本提供，支持存储地理位置信息用来实现诸如附近位置、摇一摇这类依赖于地理位置信息的功能.geo的数据类型为zset.

常用命令：geoadd，geopos， geodist

应用场景：附近位置、摇一摇

参考列表：
Redis五种数据类型及应用场景

Redis的使用_springboot中redis的使用

Redis是一个nosql数据库，可以存储key-value值。因为其底层实现中，数据读写是基于内存，速度非常快，所以常用于缓存；进而因其衡蔽为独立部署的中间件，常用于分布式缓存的实现方案。

常用场景有：缓存咐瞎州、秒杀控制、分布式锁。

虽然其是基于内存读写，但底层也有持久化机神察制；同时具备集群模式；不用担心其可用性。

关于Redis的使用，可以参考《Redis的使用方法、常见应用场景》

谈谈redismemcache的区别和具体应用场景

①Redis定义：

Redis是由意大利人SalvatoreSanfilippo（网名：antirez）开发的一款内存高速缓存数据库。Redis全称为：RemoteDictionaryServer（远程数据服务），该软件使用C语言编写，Redis是一个key-value存储系统，它支持丰富的数据类型，如：string、list、set、zset(sortedset)、hash。

②Redis特点

Redis以内存作为数据存储介质，所以读写数据的效率极高，远远超过数据库。以设置和获取一个256字节字符串为例，它的读取速度可高达110000次/s，写速度高达81000次/s。

Redis跟memcache不同的是，储存在Redis中的数据是持久化的，断电或重启后，数据也不会丢失。因为Redis的存储分为内存存储、磁盘存储和log文件三部分，重启后，Redis可以从磁盘重新将数据加载到内存中，这些可以通过配置文件对其进行配置，正因为这样，Redis才能实现持久化。

Redis支持主从模式，可以配置集银御仔群，这样更利于支撑起大型的项目，这也是Redis的一大亮点。

③Redis应用场景，它能做什么

众多语言都支持Redis，因为Redis交换数据快，所以在服务器中常用来存储一些需要频繁调取的数据，这样可以大大节省系统直接读取磁盘来获得数据的I/O开销，更拆庆重要的是可以极大提升速度。

拿大型网站来举个例子，比锋汪如a网站首页一天有100万人访问，其中有一个板块为推荐新闻。要是直接从数据库查询，那么一天就要多消耗100万次数据库请求。上面已经说过，Redis支持丰富的数据类型，所以这完全可以用Redis来完成，将这种热点数据存到Redis（内存）中，要用的时候，直接从内存取，极大的提高了速度和节约了服务器的开销。

总之，Redis的应用是非常广泛的，而且极有价值，真是服务器中的一件利器，所以从现在开始，我们就来一步步学好它。

Redis应用场景

Redis实际应用场景
1、显示最新的项目列表
下面这个语句常用来显示最新项目，随着数据多了，查询毫无疑问会越来越慢。
SELECT FROM fOO WHERE ORDER BY time DESC LIMIT 10
在Web应用中，“列出最新的回复”之类的查询非常普遍，这通常会带来可扩展性问题。这令人沮丧，因为项目本来就是按这个顺序被创建的，但要输出这个顺序却不得不进行排序操作。类似的问题就可以用Redis来解决。比如说，我们的一个Web应宏迅用想要列出用户贴出的最新20条评论。在最新的评论边上我们有一个“显示全部”的链接，点击后就可以获得更多的评论。我们假设数据库中的每条评论都有一个唯一的递态姿增的ID字段。我们可以使用分页来制作主页和评论页，使用Redis的模板，每次新评论发表时，我们会将它的蔽闭此ID添加到一个Redis列表：
LPUSH latest.comments
我们将列表裁剪为指定长度，因此Redis只需要保存最新的5000条评论：
LTRIM latest.comments 0 5000
每次我们需要获取最新评论的项目范围时，我们调用一个函数来完成（使用伪代码）：
FUNCTION get_latest_comments(start,num_items):
id list =redis.lrange("latest.comments",start,start+num items -1) IF id list.length<num items
id list = SQL DB("SELECT ... ORDER BY time LIMIT ...") END
RETURN id list END
这里我们做的很简单。在Redis中我们的最新ID使用了常驻缓存，这是一直更新的。但是我们做了限制不能超过5000个ID，因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候，才需要去访问数据库。
我们的系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。