Redis 原理及应用（4）--Redis应用场景分析

    来到了Redis系列的最后一篇，在前三篇中，介绍了Redis的数据类型及底层实现，持久化，集群分区，事务，缓存淘汰策略，HA哨兵机制等内容，其实关于Redis最重要的是其应用场景，只有知道Redis在什么场景下使用才是第一步。在这篇文章中，我们就来讨论一下Redis典型的应用场景。

缓存

提到redis，我们第一想到的应用场景肯定是缓存，因为redis是基于内存的<K,V>数据库，具有很强大的读写性能。当我们出现读多写少的热点数据时，缓存会起到非常非常重要的作用。如何保证缓存的一致性是很重要的。

热点数据（经常会被查询，但是不经常被修改或者删除的数据），首选是使用redis缓存，毕竟强大的QPS和极强的稳定性不是所有类似工具都有的，而且相比于memcached还提供了丰富的数据类型可以使用，另外，内存中的数据也提供了AOF和RDB等持久化机制可以选择，要冷、热的还是忽冷忽热的都可选。

结合具体应用需要注意一下：很多人用spring的AOP来构建redis缓存的自动生产和清除，过程可能如下：

• Select 数据库前查询redis，有的话使用redis数据，放弃select 数据库，没有的话，select 数据库，然后将数据插入redis

• update或者delete数据库钱，查询redis是否存在该数据，存在的话先删除redis中数据，然后再update或者delete数据库中的数据

上面这种操作，如果并发量很小的情况下基本没问题，但是高并发的情况请注意下面场景：

为了update先删掉了redis中的该数据，这时候另一个线程执行查询，发现redis中没有，瞬间执行了查询SQL，并且插入到redis中一条数据，回到刚才那个update语句，这个悲催的线程压根不知道刚才那个该死的select线程犯了一个弥天大错！于是这个redis中的错误数据就永远的存在了下去，直到下一个update或者delete。

<k,v>数据库

首先Redis就是一个基于<k,v>的内存数据库，当然可以当做数据库来使用。比如：在单点登录系统中(SSO)，我们就可以用Redis中存储共享Session，并设置相应的过期时间，这样就可以实现高性能的SSO。

队列--分布式消息队列

任务队列：顾名思义，就是“传递消息的队列”。与任务队列进行交互的实体有两类，一类是生产者（producer），另一类则是消费者（consumer）。生产者将需要处理的任务放入任务队列中，而消费者则不断地从任务独立中读入任务信息并执行。

任务队列的好处：

1. 松耦合。生产者和消费者只需按照约定的任务描述格式，进行编写代码。
2. 易于扩展。多消费者模式下，消费者可以分布在多个不同的服务器中，由此降低单台服务器的负载。

由于Redis有提供了队列（列表）的数据类型，我们可以把他用作分布式队列。 实现任务队列，只需让生产者将任务使用LPUSH加入到某个键中，然后另一个消费者不断地使用RPOP命令从该键中取出任务即可。