【Redis基础知识 一】Redis基本概念

除了业务本领，技术本领也得练好，听从大佬们的指导后决定深入一门技术，在精挑细选后，决定拿Redis开刀，于是买了本老钱的《Redis深度历险》，准备对核心原理和应用实践做个深入学习，按照往日的学习风格，先开始对整体目录结构做一个认知：搞了个viso图如下：

依据老钱的学习布局应该是这个样子的：

• 基础和应用篇：篇幅最大，能直接用的，学会这部分可以说是会用Redis
• 原理篇：主要内容是一些Redis底层的基本原理，也是第一部分的深入，为什么这么用Redis
• 集群篇：主要内容是Redis在分布式集群中的应用，相当于Redis在集群中的高级使用吧
• 拓展篇：主要内容是Redis核心部分的一些拓展，可以当做一些策略和使用技巧介绍吧
• 源码篇：满足高阶用户的需求，读懂源码，再造一个Redis!

于是这本200多页薄薄的教材就开始上手啃吧，争取在Q2季度结束的时候可以给大家分享下Redis的使用技巧，为期三个月，来一个Redis的深入历险吧！

在正式学习Redis前，先了解下前因后果，依据《原则》：你想要什么？事实是什么？如何行动？ 所以先了解下时代背景还是有意义的，所以先了解下什么是NoSql,以及为什么需要NoSql,来引出Redis的使用来。

NoSQL概述

关系型数据库由于严格的ACID，和复杂的查询语句，以及强结构难扩展很难适应海量数据的读写、存储并发，但是具有设计的完整性，所以比较适合要求高的传统的例如银行系统。NoSQL具有结构简单，高并发、海量数据存储，高扩展性等优点，但也不能够提供像SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性，只适合存储一些较为简单的数据。

• 关系型数据库：要求高的事务一致性，读写实时，快速进行复杂SQL查询，传统的银行系统
• 非关系型数据库：要求高并发读写，海量数据高效存储和访问，高扩展性和高可用性，web2.0时代的社交网站。

二者的应用场景不同，其实没什么优劣。

时代背景

NoSQL = Not Only SQL，也就是非关系型数据库，既然有了SQL，为什么还需要NoSQL？首先了解下时代背景，区分web1.0和web2.0时代：

• web1.0，是基于浏览器，用户通过浏览器获取内容信息。
• web2.0，是基于1.0，增加了用户与系统的交互，使用者既是网络内容的获取者，也是网络数据的制造者，例如：论坛、博客、微博等相关社交类型的平台。

我们当前身处web2.0时代，面对很多问题：

• High performance - 高并发读写，在web2.0时代，需要依据用户个性化需要高并发读写，关系型数据库读还可以，写就很难做到了。例如论坛这样的站点， 网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈
• Huge Storage - 海量数据的高效率存储和访问，海量数据高效率存储和访问， 网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的，类似facebook这样的社交网站、社区。
• High Scalability && High Availability - 高科拓展性和高可用性， 在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

这些问题主要是由于关系型数据库要求的：事务一致性: 读写实时性: 复杂SQL的查询而这些场景和严格的要求在很多场景下不必要了，例如社交网络。这些都是导致关系型数据库性能差的原因，当然最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。而NoSQL因为它的易扩展、大数据量高性能、灵活的数据模型和高可用在社区时代可以发挥很大的作用。

NoSQL分类

NoSQL 依据存储的内容也分很多种，让我们从这些类别里来定位Redis吧！依据使用场景来划分类别，按照上面我们提到的三种优点，看看哪种能发挥极致：

• 面向高性能并发读写的key-value数据库：key-value数据库的主要特点即使具有极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的代表，我理解主要是用了Redis缓存的特性，防止直接进行IO读写。
• 面向海量数据访问的面向文档数据库：这类数据库的特点是，可以在海量的数据中快速的查询数据，典型代表为MongoDB以及CouchDB
• 面向可扩展性的分布式数据库：这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化

而如果按照存储方式划分的话又分为如下几类：

Redis概述

redis在现在的应用中使用的非常广泛。从上表中可以看到它的典型应用是：内容缓存，主要用于处理大量数据的高访问负载，优点就是快速查询。

应用场景

Redis有很多应用场景，缓存，任务队列，网站访问统计，数据过期处理，应用排行榜，分布式集群架构中的session分离等很多功能。详细介绍下：

• 缓存，缓存现在几乎是所有中大型网站都在用的必杀技，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。Redis提供了键过期功能，也提供了灵活的键淘汰策略，所以，现在Redis用在缓存的场合非常多。存储访问频率高的热数据防止穿透到数据库。
• 排行榜，很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。
• 计数器，什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。
• 分布式会话，集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。
• 分布式锁，在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。
• 社交网络，点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。
• 最新列表，Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。
• 消息系统，消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

感觉这些场景都是当下大型电商网站和社交网站需要的。所以Reids火也不奇怪，其它的NoSQL数据库的应用场景都比较窄，类似文档存储和图片存储等，都在特定应用场景下使用。

数据类型

Redis是高性能键值对数据库，支持的键值数据类型：字符串类型 ，散列类型，列表类型 ，集合类型，有序集合类型 ,这些类型下一篇博客详细说明。

Redis安装

从官网上下载redis的最新版：windows版本Reids，但我在本地安装的过程中总是启动不了服务端，所以选择了网页版Redis去使用。

总结

今天学习了下Redis的使用背景，有因才有果嘛，首先了解了我们的 web时代背景，然后了解了关系型数据的瓶颈，进而引出了非关系型数据库的妙用，然后依据使用场景找到了应用场景最为广泛的Redis,明白了Redis的特性，简单了解了Redis的数据类型，使用了网页版Redis设置了第一个键值对。