1.Redis是什么？
这里引用Redis官网上的一句话：
Redis是一个开源（BSD许可），内存数据结构存储，用作数据库，缓存和消息代理。 它支持数据结构，如字符串，散列，列表，集合，带有范围查询的排序集，位图，超级日志和带有半径查询的地理空间索引。 Redis具有内置复制，Lua脚本，LRU驱逐，事务和不同级别的磁盘持久性，并通过Redis Sentinel提供高可用性并使用Redis Cluster自动分区。
2.为什么要使用Redis?
主要还是两个方面：性能和并发量，原来做小型项目的时候基本都是内部人员去使用根本就不太需要考虑性能更不要说并发了，一般的操作就是url映射到我们的Controller，然后Controller以来我们的Service,最后Service以来Dao对数据库进行操作，简化起来就是
当我们系统规模小的时候基本都是这样来一个请求都可能是直接到数据库里操作一把再处理一下数据返回一个json串给前台。所以我们只要对数据库进行一定的优化，代码优化一下基本上是没有问题的。但是如果对于互联网项目来说用户爆发式增长，数据量和并发量暴涨，在这样高并发的情况下所有请求都间接的变成了对数据库的访问，就可能出现数据库连接异常等情况导致数据库挂掉。
所以就出现了缓存这么一个解决方案，在数据库上在建立一个缓存层，对于我们耗时比较久并且结果不会经常变动的数据我们都放入缓存里，所有的操作都先经过缓存层的过滤，这样就帮助DB顶住了一些压力，之前的一些操作就变成了：
查询操作变成了：
1.查询缓存中有没有数据
2. if(缓存中有数据)
{
返回数据
}
else
{
查询数据库
有数据就写入缓存中
再返回数据
}
更新操作:
更新数据库，删除对应缓存题外话：在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署，对同一个数据进行读写，并发的读写并不能保证完成顺序，就可能导致数据库与缓存不一致，脏数据等。
- 发生了写请求 A，A 的第一步淘汰了 cache（如上图中的1）；
- A 的第二步写数据库，发出修改请求（如上图中的2）；
- 发生了读请求 B，B 的第一步读取 cache，发现 cache 中是空的（如上图中的步骤3）；
- B 的第二步读取数据库，发出读取请求，此时 A 的第二步写数据还没开始，读出了一个脏数据放入 cache（如上图中的步骤4）。
3.Redis数据类型？
Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。
4.Redis为什么这么快？
| 本地/局域网 | 读写类型 | 测试命令 | client连接数 | qps | 延迟响应 <= 1ms比例 | 延迟响应 <= 2ms比例 | 延迟响应 <= 4ms比例 | 延迟响应 <= 8ms比例 |
| 本地 | 写 | lpush | 1 | 35714 | 100% | 100% | 100% | 100% |
| 本地 | 写 | lpush | 2 | 63000 | 100% | 100% | 100% | 100% |
| 本地 | 写 | lpush | 4 | 153846 | 100% | 100% | 100% | 100% |
| 本地 | 写 | lpush | 8 | 155914 | 100% | 100% | 100% | 100% |
| 本地 | 写 | lpush | 16 | 151788 | 99.99% | 100% | 100% | 100% |
这是一部分对redis的list数据结构性能的测试数据。可以看出性能是非常牛的。
1.首先Redis是纯内存操作，所以相对于磁盘的IO，读写内存的速度就不是几倍几十倍了，一般，hash查找可以达到每秒百万次的数量级。
2.Redis是单线程操作的，所以就避免了频繁的上下文的切换时间（即使是单核的cpu也能够执行多线程，cpu通过给每个线程分配时间片来实现这个机制。时间片是cpu分配给各个线程的时间，因为时间非常短，所以cpu通过不断地切换线程，让我们感觉多个线程是同时执行的，一般时间片为几十毫秒）
3.用了非组赛的IO多路复用机制(“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗）。可以直接理解为：单线程的原子操作，避免上下文切换的时间和性能消耗；加上对内存中数据的处理速度，很自然的提高redis的吞吐量。)，所以相比传统的每一个IO流都有一个新的线程管理比较自然要快得多。