redis的五种基础数据类型

String数据类型、List 数据类型、Hash数据类型（散列类型）、set数据类型（无序集合）、Sorted Set数据类型 (zset、有序集合)。

String

String是 redis 最基本的类型，最大能存储 512MB 的数据，String类型是二进制安全的，即可以存储任何数据、比如数字、图片、序列化对象等。 INCR key: key值递增加1 ( key值必须为整数)、DECR key: key值递增减1 (key值必须为整数)、GETSET key value: 获取key值并返回， 同时给key设置新值。

Hash数据类型（散列类型）

hash用于存储对象。可以采用这样的命名方式：对象类别和ID构成键名，使用字段表示对象的属性，而字段值则存储属性值。 如：存储 ID 为 2 的汽车对象。如果Hash中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储4294967295个键值对。

列表list

Redis的列表允许用户从序列的两端推入或者弹出元素，列表由多个字符串值组成的有序可重复的序列，是链表结构，所以向列表两端添加元素的时间复杂度为0(1)， 获取越接近两端的元素速度就越快。这意味着，即使有数以千万计的元素列表，也可以极快地获得10条记录在头部或尾部。 可列入名单的要素最多只有4294967295个。应用场景：（1）最新消息排行榜。（2）消息队列，以完成多程序之间的消息交换。 可以用push操作将任务存在list中（生产者），然后线程在用pop操作将任务取出进行执行。（消费者）

集合sets

所谓集合就是一堆不重复值的组合，并且是没有顺序的。在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。 Redis还提供了诸如collection、union和differences等操作，使得实现诸如commandism、poperhike、secondfriends这样的功能变得很容易， 或者选择是将结果返回给客户机，还是将它们保存到使用不同命令的新的集合中。

有序集合sort sets

Redis zset和set一样也是string类型元素的集合，且不允许重复的成员。不同之处在于，每个元素都与双类型的分数相关联。 Redis使用分数将集合的成员从小到大排序。zset的成员是唯一的，但是grazentra的分数可以重复。sorted set是插入有序的，即自动排序。 常用命令：zadd、zrange、zrem、zcard等。当你需要一个有序的并且不重复的集合列表时，那么可以选择sorted set数据结构。 应用举例：（1）例如存储全班同学的成绩，其集合value可以是同学的学号，而score就可以是成绩。（2）排行榜应用，根据得分列出topN的用户等。

实现消息队列

基于list实现

消息队列的基础结构是队列，而redis正好有相对应的数据结构：list。 这种模式由于一个list里的消息只能被消费一次，最适合单队列的生产-消费模式的消息队列。 由一个或多个生产者将消息放入list,1个消费者从list取出消息消费，如果要多个消费者消费同一条消息则要建立多个list,这样会造成资源浪费。

• 实时性 实时性较好，可以通过brpop方式阻塞获取新消息，有高实时性；或者通过定时任务方式监听队列，存在较低延迟。
• 可靠性 综合可靠性一般，在点对点的消息推送机制下（lpush + rpop方案）不容易存在消息丢失，可以保证高可靠性。在其它场景可能存在并发安全性问题，但是可以通过加锁解决。存在事务失败问题，但是发生的概率较低。存在消息丢失问题，但是可以自己实现ack机制。
• 功能性 功能性一般，通过自己的额外扩展可以满足多种不同的消息队列功能，如多对多、发布订阅模式。

pub/sub模式

pub-sub 是redis官方支持的一种发布订阅模式。 他是redis开发出专门用于消息队列的一个模式。

首先需要着重注意的是，pub-sub机制和list不同，list是redis的数据结构，redis自身会保证其数据持久化的可靠性， 而pub-sub则没有持久化机制，这意味着，如果发生消息时，消费者宕机，那么消息也就丢失了。所以该种方式是不满足可靠性要求的。

• 实时性 实时性极好，实现的消息推送机制本身就是高实时性的。
• 可靠性 可靠性较差。一旦消费者宕机消息就会直接被丢弃。
• 功能性 功能性一般，实现简单的发布订阅还好，但是为了满足一些高可用性就需要增加很多额外的操作。

基于redis5的stream实现

Redis Stream 是 Redis 5.0 版本新增加的数据结构。

Redis Stream 主要用于消息队列（MQ，Message Queue），Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能，但它有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。

简单来说发布订阅 (pub/sub) 可以分发消息，但无法记录历史消息。

而 Redis Stream 提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。

可以说stream是对原pub/sub类型无法实现的一些功能的补充，解决一些痛点，整合pub/sub和list。

• 实时性 实时性好，可以通过block方式阻塞获取新消息，有高实时性；
• 可靠性 可靠性好，redis的自带的持久化机制可以防止消息丢失，但是相比kafka的磁盘写入还是略不可靠。自带的ack机制可以满足消息应答实现，防止消息丢失。但是需要注意对于死信息积压在pending区的数据需要定时去处理回收。此外，积压的消息会一直保存在stream中，哪怕已经ack过，还需要额外的一个线程定时将已经读取完的消息删除。
• 功能性 功能性好，可以轻松实现多种不同的消息队列功能，如多对多、发布订阅模式。

redis使用场景本人理解和说明及对比

redis本身是一个key-value结构的内存数据库，同时开发了消息队列功能。可以说将Memcached和kafka两者的功能同时实现。而和两者在各个领域的功能和性能区别在哪呢？

与Memcached比较

在数据类型上Memcached没有细分的数据类型，而redis有5种类型应用与不通场景，拥有更高的功能性和存取性能。但在redis在大文件缓存时的性能较低，如图片，视频等。 redis虽是内存数据库，但其拥有持久化功能，当内存用完时可将一些很久没用的数据交换到磁盘中，或用户主动将数据存入磁盘。而memcache仅仅是一个缓存系统，一旦崩溃或重启，数据将无法恢复。 可以说除了大数据缓存，redis基本已全面碾压memcached

与kafka比较

redis大部分使用消息队列的场景都可以使用stream替代。基于redis的高性能和使用内存的机制使得其的性能优于大部分消息队列包含kafka。 据我了解redis是消息队列中数据实时性最高的。 但同时受限与内存机制，其难以接受瞬间的大流量冲击。和对大文件数据的处理会相对低下。 其最适用的使用场景是对数据实时性高，数据生产消费过程整体较平稳，单个数据文件不大，对数据尽量快产快消。而这刚好是物联网的使用场景。

kafka作为消息队列的大哥。其在稳定性（可面对大流量冲击），数据保留性（数据是存入磁盘的），对大数据的读写性都优于redis。弱与redis的数据的实时性（磁盘存储）。 现在kafka最热门的应用场景就是大数据实时计算，其大流量吞吐，高可靠性，和较好的实时性，是大数据实时计算所需的，实时性虽然相对redis不如，但几毫秒和几百毫秒对于大数据实时计算上的体现几乎无差别。况且当吞吐量上升到几十上百万时redis还不一定能到这么高的实时性。