这里我们通过几个场景，不同维度说下Redis的应用。
高性能适合当做缓存
缓存是Redis最常见的应用场景，之所有这么使用，主要是因为Redis读写性能优异。而且逐渐有取代memcached，成为首选服务端缓存的组件。而且，Redis内部是支持事务的，在使用时候能有效保证数据的一致性。
作为缓存使用时，一般有两种方式保存数据：
1、读取前，先去读Redis，如果没有数据，读取数据库，将数据拉入Redis。
2、插入数据时，同时写入Redis。
方案一：实施起来简单，但是有两个需要注意的地方：
1、避免缓存击穿。（数据库没有就需要命中的数据，导致Redis一直没有数据，而一直命中数据库。）
使用redis的 setnx方法构建一个互斥锁，只有一个请求线程获得锁去更新数据，其他请求等待，之后去请求最新缓存。
2、数据的实时性相对会差一点。
方案二：数据实时性强，但是开发时不便于统一处理。
当然，两种方式根据实际情况来适用。如：方案一适用于对于数据实时性要求不是特别高的场景。方案二适用于字典表、数据量不大的数据存储。
单线程可以作为分布式锁
谈到Redis和Memcached 的区别，大家更多的是谈到数据结构和持久化这两个特性，其实还有一个比较大的区别就是：
Redis 是单线程，多路复用方式提高处理效率。
Memcached 是多线程的，通过CPU线程切换来提高处理效率。
所以Redis单线程的这个特性，其实也是很重要的应用场景，最常用的就是分布式锁。
应对高并发的系统，都是用多服务器部署，每个技术框架针对数据锁都有很好的处理方式，如 .net 的lock,java 的synchronized,都能通过锁住某个对象来应对线程导致的数据污染问题。但是毕竟，只能控制本服务器的线程，分布式部署以后数据污染问题，就比较难处理了。Redis的单线程这个特性，就非常符合这个需求，伪代码如下：
//产生锁
while lock!=1
//过期时间是为了避免死锁
now = int(time.time()) lock_timeout = now + LOCK_TIMEOUT + 1lock = redis_client.setnx(lock_key, lock_timeout)
//真正要处理的业务
doing()
//释放锁
now = int(time.time())ifnow < lock_timeout: redis_client.delete(lock_key)
以上是一个只说明流程的伪代码，其实整体的逻辑是很简单的，只要考虑到死锁时的情况，就比较好处理了。Redis作为分布式锁，因为其性能的优势，不会成为瓶颈，一般会产生瓶颈的是真正的业务处理内容，还是尽量缩小锁的范围来确保系统性能。
自动过期能有效提升开发效率
Redis针对数据都可以设置过期时间，这个特点也是大家应用比较多的，过期的数据清理无需使用方去关注，所以开发效率也比较高，当然，性能也比较高。最常见的就是：短信验证码、具有时间性的商品展示等。无需像数据库还要去查时间进行对比。因为使用比较简单，就不赘述了。
秒杀和Redis的结合
秒杀是现在互联网系统中常见的营销模式，作为开发者，其实最不愿意这样的活动，因为非技术人员无法理解到其中的技术难度，导致在资源协调上总是有些偏差。
秒杀其实经常会出现的问题包括：
- 并发太高导致程序阻塞。
- 库存无法有效控制，出现超卖的情况。
其实解决这些问题基本就两个方案：
- 数据尽量缓存,阻断用户和数据库的直接交互。
- 通过锁来控制避免超卖现象。
现在说明一下，如果现在做一个秒杀，那么，Redis应该如何结合进行使用?
*提前预热数据，放入Redis
- 商品列表放入Redis List
- 商品的详情数据 Redis hash保存，设置过期时间
- 商品的库存数据Redis sorted set保存
- 用户的地址信息Redis set保存
- 订单产生扣库存通过Redis制造分布式锁，库存同步扣除
- 订单产生后发货的数据，产生Redis list，通过消息队列处理
- 秒杀结束后，再把Redis数据和数据库进行同步
以上是一个简略的秒杀系统和Redis结合的方案，当然实际可能还会引入http缓存，或者将消息对接用MQ代替等方案，也会出现业务遗漏的情况，这个只是希望能抛砖引玉。
