为什么要选择 Redis：介绍Redis的使用场景与使用 Redis 的原因。

*Redis 不是万金油

在面试的时候，常被问比较下 Redis 与 Memcache 的优缺点，个人觉得这二者并不适合一起比较，一个是非关系型数据库不仅可以做缓存还能干其他事情，一个是仅用做缓存。常常让我们对这二者进行比较，主要也是由于 Redis 最广泛的应用场景就是 Cache，那么 Redis 到底能干什么？又不能干什么呢？

*Redis都可以干什么事儿

缓存，毫无疑问这是 Redis 当今最为人熟知的使用场景，再提升服务器性能方面非常有效。

  1. 排行榜，如果使用传统的关系型数据库来做，非常麻烦，而利用 Redis 的 SortSet 数据结构能够非常方便搞定；

  2. 计算器/限速器，利用 Redis 中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数等，这类操作如果用 MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场景是限制某个用户访问某个 API 的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压力；

  3. 好友关系，利用集合的一些命令，比如求交集、并集、差集等，可以方便搞定一些共同好友、共同爱好之类的功能；

  4. 简单消息队列，除了 Redis 自身的发布/订阅模式，我们也可以利用 List 来实现一个队列机制，比如到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的 DB 压力，完全可以用 List 来完成异步解耦；

  5. Session 共享，以 PHP 为例，默认 Session 是保存在服务器的文件中，如果是集群服务，同一个用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用 Redis 保存 Session 后，无论用户落在那台机器上都能够获取到对应的 Session 信息。

*Redis 不能干什么事儿

Redis 感觉能干的事情特别多，但它不是万能的，合适的地方用它事半功倍，如果滥用可能导致系统的不稳定、成本增高等问题。

  1. 比如，用 Redis 去保存用户的基本信息，虽然它能够支持持久化，但是它的持久化方案并不能保证数据绝对的落地，并且还可能带来 Redis 性能下降，因为持久化太过频繁会增大 Redis 服务的压力。

  2. 简单总结就是数据量太大、数据访问频率非常低的业务都不适合使用 Redis，数据太大会增加成本，访问频率太低，保存在内存中纯属浪费资源。

*选择总需要找个理由

上面说了 Redis 的一些使用场景，那么这些场景的解决方案也有很多其它选择，比如缓存可以用 Memcache，Session共享还能用 MySql 来实现，消息队列可以用RabbitMQ，我们为什么一定要用 Redis 呢？

速度快，完全基于内存，使用 C 语言实现，网络层使用 epoll 解决高并发问题，单线程模型避免了不必要的上下文切换及竞争条件；

注意：单线程仅仅是说在网络请求这一模块上用一个请求处理客户端的请求，像持久化它就会重开一个线程/进程去进行处理。

丰富的数据类型，Redis 有 8 种数据类型，当然常用的主要是 String、Hash、List、Set、 SortSet 这 5 种类型，他们都是基于键值的方式组织数据。每一种数据类型提供了非常丰富的操作命令，可以满足绝大部分需求，如果有特殊需求还能自己通过 lua 脚本自己创建新的命令（具备原子性）；

除了提供的丰富的数据类型，Redis 还提供了像慢查询分析、性能测试、Pipeline、事务、Lua自定义命令、Bitmaps、HyperLogLog、发布/订阅、Geo 等个性化功能。

Redis 的代码开源在 GitHub，代码非常简单优雅，任何人都能够吃透它的源码；它的编译安装也是非常的简单，没有任何的系统依赖；有非常活跃的社区，各种客户端的语言支持也是非常完善。另外它还支持事务（没用过）、持久化、主从复制让高可用、分布式成为可能。

做为一个开发者，对于我们使用的东西不能让它成为一个黑盒子，我们应该深入进去，对它更了解、更熟悉，今天简单说了下 Redis 的使用场景，以及为什么选择了 Redis 而不是其他。