(1)快速了解Redis

前言

什么是NoSQL？

NoSQL，泛指非关系型的数据库，NoSQL即Not-Only SQL，它可以作为关系型数据库的良好补充。随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance - 对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

2、Huge Storage - 对海量数据的高效率存储和访问的需求

类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

一些主流的NOSQL产品：

NoSQL数据库的四大分类如下：

【1】键值(Key-Value)存储数据库

相关产品： Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB

典型应用： 内容缓存，主要用于处理大量数据的高访问负载。 

数据模型： 一系列键值对

优势： 快速查询

劣势： 存储的数据缺少结构化

【2】列存储数据库

相关产品：Cassandra, HBase, Riak

典型应用：分布式的文件系统

数据模型：以列簇式存储，将同一列数据存在一起

优势：查找速度快，可扩展性强，更容易进行分布式扩展

劣势：功能相对局限

【3】文档型数据库

相关产品：CouchDB、MongoDB

典型应用：Web应用（与Key-Value类似，Value是结构化的）

数据模型： 一系列键值对

 优势：数据结构要求不严格

 劣势： 查询性能不高，而且缺乏统一的查询语法

【4】图形(Graph)数据库

相关数据库：Neo4J、InfoGrid、Infinite Graph

典型应用：社交网络

数据模型：图结构

优势：利用图结构相关算法。

劣势：需要对整个图做计算才能得出结果，不容易做分布式的集群方案。

1、Redis概述

Redis是用C语言开发的一个开源的高性能键值对（key-value）数据库。它通过提供多种键值数据类型来适应不同场景下的存储需求。
Redis 与其他 key - value 缓存产品有以下三个特点：

Redis是基于内存的读/写，支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
Redis支持数据的备份，即master-slave模式的数据备份。

Redis优势

性能极高：Redis能读的速度是110000次/s,写的速度是81000次/s 。
丰富的数据类型：Redis支持6种数据类型，数据结构比较简单，规则较少。
原子性：Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
丰富的特性： Redis还支持 基础事务、回滚、监控事务、流水线、发布订阅publish/subscribe、 超时命令等等特性。

Redis与其他key-value存储有什么不同

Redis有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。
Redis运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，应为数据量不能大于硬件内存。在内存数据库方面的另一个优点是， 相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。 同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。

Redis支持的键值数据类型：

字符串类型

散列类型

列表类型

集合类型

有序集合类型。

2、Redis在Java Web中的应用

2.1缓存

一般而言Redis在JavaWeb应用中存在两个主要的场景，一个是缓存常用的数据，另一个是在需要高速读／写的场合使用它快速读／写，比如一些需要进行商品抢购和抢红包的场合。由于在高并发的情况下，需要对数据进行高速读／写的场景，一个最为核心的问题是数据一致性和访问控制。在使用Redis存储时，需要考虑：

※业务数据常用吗？命中率如何？如果命中率很低，就没必要写入缓存

※该业务数据是读操作多，还是写操作多

※业务数据大小如何？如果存储几百兆字节的文件，会给缓存带来很大压力，有没有必要？

考虑过上述问题后，如果有必要使用缓存，那么就使用它。使用Redis作为缓存的读取逻辑如下图：

图中可以知道以下两点。

·   当第一次读取数据的时候，读取Redis的数据就会失败，此时会触发程序读取数据库，把数据读取出来，并且写入Redis。

．当第二次及以后读取数据时，就直接读取Redis，读数据后就结束了流程，这样速度就大大提高了。

从上面的分析可知，大部分的操作是读操作，使用Redis应读操作，速度就会十分迅速，同时也降低了对数据库的依赖，大大降低了数据库的负担。

分析了读操作的逻辑后，下面再来分析写操作的流程，如图所示

从流程可以看出，更新或者写入的操作，需要多个Redis的操作。如果业数据写次数远大于读次数没有必要使用Redis。如果是读次数远大于写次数，则使用Redis就有其价值了，因为写入Redis虽然要消耗定的代价，但是其性能良好，相对数据库而言，几乎可以忽略不计。

2.2高速读/写场合

互联网的应用中，往往存在一些需要高速读／写的合，比如商品的秒杀，抢红包，淘宝、京东的双十一活动或者春运抢票等。这类场合在一个瞬间成千上万的请求就会达到服务器，如果使用的是数据库，一个瞬间数据库就需要执行成千上万的SQL，很容易造成数据库的瓶颈，严重的会导致数据库瘫痪，造成JavaWeb系统服务崩溃。在这样的场合的应对办法往往是考虑异步写入数据库，而在高速读／写的场合中单单使用Redis去应对，把这些需要高速读／写的数据，缓存到Redis中，而在满足一定的条件下，触发这些缓存的数据写入数据库中。先看看一次请求操作的流程图。

进一步论述这个过程：当一个请求达到服务器，只是把业务数据先在Redis读／写，而没有进行任何对数据库的操作，换句话说系统仅仅是操作Redis缓存，而没有操作数据库，这个速度就比操作数据库要快得多，从而达到需要高速响应的效果。但是一般缓存不能持久化，或者所持久化的数据不太规范，因此需要把这些数据存入数据库，所以在一个请求操作完Redis的读／写后，会去判断该高速读／写的业务是否结束。这个判断的条件往往就是秒杀商品剩余个数为0，抢红包金额为0，如果不成立，则不会操作数据库；如果成立，则触发事件将Redis缓存的数据以批量的形式一次性写入数据库，从而完成持久化的工作。

假设面对的是一个商品秒杀的场景，从上面的流程看，一个用户抢购商品，绝大部分的场合都是在操作内存数据库Redis，而不是磁盘数据库，所以其性能更为优越。只有在商品被抢购一空后才会触发系统把Redis缓存的数据写入数据库磁盘中，这样系统大部分的操作基于内存，就能够在秒杀的场合高速响应用户的请求，达到快速应答。

2.3 应用场合汇总

缓存（数据查询、短连接、新闻内容、商品内容等等）。（最多使用）

分布式集群架构中的session分离。

聊天室的在线好友列表。

任务队列。（秒杀、抢购、12306等等）

应用排行榜。

网站访问统计。

数据过期处理（可以精确到毫秒）