String

这应该是应用最广泛的了,简单的 key-value 类型。value 不仅可以是 String，也可以是数字。还可以享受 Redis 的定时持久化（可以选择 RDB 模式或者 AOF 模式），操作日志及 Replication 等功能。

Set

利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。Redis 非常人性化的为集合提供了求交集、并集、差集等操作。

Set 和 String 是在广告系统中使用最广泛的 redis 数据结构

List

Hash

Sorted Set

和 Sets 相比，Sorted Sets 是将 Set 中的元素增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，比如一个存储全班同学成绩的 Sorted Sets，其集合 value 可以是同学的学号，而 score 就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。

数据结构选型

一定要 Set 吗?

网上的文章讲到这里的时候都会说 Redis 的 Set 提供了一些方便的交集、并集、差集的操作。但是实际上我们在生产环境的时候不会用这些操作，数据库一般是系统压垮的最后一根稻草,如果数据库垮了,基本就是系统 GG 了。补救办法基本没有。所以,选型的时候能让服务器做的,就不会让数据库做,所以交集、并集、差集这些操作会放在服务器的内部逻辑去做。如果服务器撑不住，大不了就加机子嘛。

Set vs String

我们系统中,大多数时候是用 key/value 的结构。从某种意义上他们两个在逻辑上可以实现等价。

1. key -> "value1,value2,value3,value4"
2. key -> Set(value1,value2,value3,value4)

第一种我们直接用 string,只不过 value 的获取完我们自己分割。用哪种还是看你们的业务场景。Set 的缺点是比 string 占用更多的空间;优点是天然的是 value 之间是不会重复的。

1. 我们线上系统用户已经安装的 app 是多个地方上报的,我们就用 Set 去存储,每次上报就直接更新就可以,如果这时候我们用的是 String 就不太适合,因为要读一次 redis,做一次去重,再写入;
2. 我们线上使用的已经曝光的广告不想让用户看到这个功能我们就用的是 String,因为我们每次下发的广告已经从逻辑上保证了不是重复的.