Redis应用场景
String--字符串
redis最能想到的就是使用序列化的字符串缓存，通常为json格式，把一些在mysql中需要大量sql查询操作和计算得到的数据缓存起来，再次访问的时候就可以直接读取数据，可有效降低数据库的压力，例如网站首页的某些排名信息，查询比较复杂，但是对实时性要求没那么高的，可以设置一个定时过期的缓存，这是最简单的缓存应用场景，redis提供了丰富的数据结构，可以用在很多web应用的场景。
Hash--哈希
哈希表是redis中很有用的数据结构，有时候我们需要存储结构话的数据，例如用户的登录信息
uid:1 // 用户uid
username:xxx // 用户名
age:18 // 年龄
head:xxx //头像
String模式
按照普通缓存的模式，存储这个结构需要先将其序列化，转换成json字符串，以user-uid为键名，这样做有个问题，假如说现在需要修改head字段，我需要经历如下步骤：
- 根据键名
user-1获取到json字符串 - 解析
json - 修改结构体中的
head字段 - 再次序列化成
json -
set key存储
Hash模式
接下来使用Hash来存储，使用HMSET命令存储所有字段
HMSET user-1 uid 1 username xxx age 18 head:xxx
这时候需要修改字段head仅需一条命令即可：
HSET user-1 head zzz
相比之下是不是简单了很多，Hash模式不仅操作大大简化，而且节省了String模式中大量的序列化和反序列化的性能消耗。
List -- 列表
List在redis中的应用也比较广泛，最典型的就是消息队列，在某些高并发场景下，由于mysql存储介质为磁盘，在写入性能上由于磁盘的读写速度限制，它的写入速度可能达不到要求。但是redis不一样，redis是完全基于内存数据库nosql，没有I/O瓶颈，写入和读取速度都非常快，这也是redis流行的原因。假设现在要做一个商城的秒杀活动，在同一时刻必然会有大量的订单提交操作，mysql可能来不及写入，会导致其它用户阻塞，糟糕的情况下甚至系统奔溃，影响用户体验。在这种场景下就可以通过消息队列来处理，即：
- 先把提交的订单信息写入消息队列，可通过
LPUSH和RPOP命令实现入队和出队的操作。 - 通过异步程序将订单存储到
mysql
另一种场景是可作为IM聊天系统的timeline模型，即每个用户对应一个timeline模型，根据时间顺序排列，每个用户通过timeline获取消息
Set -- 集合
集合和List的类似，区别是集合是可以自动排重的，且集合是无序的。例如：存储某个用户的所有粉丝和所有的好友等。
Sorted Set 有序集合
有序集合根据score字段来排序，通过ZADD可添加一个有序集合，例如：
ZADD page_rank 10 google.com
上面命令的意思是在page_rank集合中添加字符串google.com，score为10。
有序集合可用来数据分页，例如我们查询用户积分前100名的用户，每页20条展示，通过
ZRANGE key start stop [WITHSCORES]命令可实现分页，时间复杂度为O(log(N)+M)，
在数据量大，查询比较耗时，可大大提高web的性能。
Pub/Sub -- 发布 / 订阅
发布订阅模式通过发布和订阅发送和接收消息，例如A和B订阅(subscribe)了频道news.it，这时候C向改频道发送(publish)一条信息hello，这时候A和B会收到这条消息，这就是最简单的发布订阅模式，A和B也可以订阅别的频道，可以接受来自不同频道的信息，注意这里的A和B是长连接，PUBSUB CHANNELS命令可查看当前活跃的频道。这个功能最典型应用就是IM系统，广播等场景，但是redis发布和订阅没有确认的过程，消息发出就没了，不管有没有收到，在实际场景中可能会选择别的方案。
