⭐ 作者简介:码上言
⭐ 代表教程:Spring Boot + vue-element 开发个人博客项目实战教程
⭐专栏内容:个人博客系统
⭐我的文档网站:http://xyhwh-nav.cn/
在学习redis之前,我们先学习一下NoSQL。
NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”,“Not Only SQL”也被很多人接受(“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字)。NoSQL被我们用得最多的当数key-value存储,当然还有其他的文档型的、列存储、图型数据库、xml数据库等。
很多的数据类型用户的个人信息,社交网络,地理位置。这些数据类型的存储不需要一个固定的格式! 不需要多月的操作就可以横向扩展的 ! Map
NoSQL 数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。
数据之间无关系,这样就非常容易扩展,也无形之间,在架构的层面上带来了可扩展的能力。
NoSQL数据库都具有非常高的读写性能,尤其是在大数据量下,同样表现优秀。这得益于它的非关系 性,数据库的结构简单。
一般MySQL使用Query Cache
,每次表的更新Cache就失效,是一种大力度的Cache
,在针对Web2.0的 交互频繁应用,Cache性能不高,而NoSQL
的Cache是记录级的,是一种细粒度的Cache,所以NoSQL 在这个层面上来说就要性能高很多了。
官方记录:Redis 一秒可以写8万次,读11万次!
NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式,而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是噩梦。
分类 | 例子 | 应用场景 | 数据结构 | 优点 | 缺点 |
---|---|---|---|---|---|
键值(key - value) | Tokyo Cabinet/Tyrant,Redis,Oracle | 内存缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统等等。 | key指向value的键值对,通常用hash table来实现 | 查找速度快 | 数据无结构化,通常只被当作字符串或者二进制数。 |
列存储数据库 | Cassandra,HBase,Riak | 分布式的文件系统 | 以列簇式存储,将同一列数据存在一起 | 查找速度快,可扩展性强,更容易进行分布式扩展。 | 功能相对局限 |
文档型数据库 | CouchDB,MongoDb | Web应用(与Key-Value类似,Value是结构化的,不同的是数据库能够了解Value的内容) | Key-Value对应的键值对,Value为结构化数据 | 数据结构要求不严格,表结构可变,不需要想关系型数据库一样需要预先定义表结构 | 查询性能不高,而且缺乏统一的查询语法。 |
图形数据库 | Neo4J,InfoGrid,Graph | 社交网络,推荐系统等,专注于构建关系图谱 | 图结构 | 利用图结构相关算法。比如最短路径寻址,N度关系查找。 | 这种结构不太好做分布式的集群方案 |
CAP即:
这三个性质对应了分布式系统的三个指标:
而CAP理论说的就是:一个分布式系统,不可能同时做到这三点,最多只能实现上面的两点。如下图:
而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容错性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。
注意:分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用,其实并不需要强一致性。
因此牺牲C换取P,这是目前分布式数据库产品的方向
对于一个分布式系统而言,P是前提,必须保证,因为只要有网络交互就一定会有延迟和数据丢失,这种状况我们必须接受,必须保证系统不能挂掉。所以只剩下C、A可以选择。要么保证数据一致性(保证数据绝对正确),要么保证可用性(保证系统不出错)。
当选择了C(一致性)时,如果由于网络分区而无法保证特定信息是最新的,则系统将返回错误或超时。
当选择了A(可用性)时,系统将始终处理客户端的查询并尝试返回最新的可用的信息版本,即使由于网络分区而无法保证其是最新的。
对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地
很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低, 有些场合对写一致性要求并不 高。允许实现最终一致性。
对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应 用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看 到这条动态是完全可以接受的。
任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特 别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主 键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。
CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求, 最多只能同时较好的满足两个。因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
CP - 满足一致性,分区容忍必的系统,通常性能不是特别高。
AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
BASE模型与ACID模型截然不同,满足CAP理论,通过牺牲强一致性,获得可用性,一般应用在服务化系统的应用层或者大数据处理系统,通过达到最终一致性来尽量满足业务的绝大部分需求。
BASE模型包含个三个元素:
系统出现了不可预知的故障,但还是能用,相比较正常的系统而言会有响应时间上的损失和功能上的损失。
什么是软状态呢?相对于原子性而言,要求多个节点的数据副本都是一致的,这是一种“硬状态”。
软状态指的是:允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时。
最终一致性是指系统中的所有数据副本经过一定时间后,最 终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么 这么说呢,缘由就在于大型系统往往由于地域分布和极高性能的要求,不可能采用分布式事务来完成这 些指标,要想获得这些指标,我们必须采用另外一种方式来完成,这里BASE就是解决这个问题的办法!
注:
1、分布式:不同的多台服务器上面部署不同的服务模块(工程),他们之间通过Rpc通信和调用,对外 提供服务和组内协作。
2、集群:不同的多台服务器上面部署相同的服务模块,通过分布式调度软件进行统一的调度,对外提供 服务和访问。
对于分布式系统的项目,使用中没有强制要求一定是CAP中要达到某几种,具体根据各自业务场景所需来制定相应的策略而选择适合的产品服务等。
例如:支付订单场景中,由于分布式本身就在数据一致性上面很难保证,从A服务到B服务的订单数据有可能由于服务宕机或其他原因而造成数据不一致性。因此此类场景会酌情考虑:AP,不强制保证数据一致性,但保证数据最终一致性。
Redis 是完全开源的,遵守 BSD 协议,是一个高性能的 key-value 数据库,基于内存运行,并支持持久化的NoSQL数据库,是当前最热门的NoSQL数据库之一,也被人们称为 数据结构服务器。
Redis 与其他 key - value 缓存产品有以下三个特点:
Strings
, Lists
, Hashes
, Sets
及 Ordered Sets
数据类型操作。MULTI
和EXEC指令
包起来。 publish/subscribe
, 通知key 过期等等特性。官网 :https://redis.io/
中文网: http://www.redis.cn
windows安装很简单的。Redis 支持 32 位和 64 位。这个需要根据你系统平台的实际情况选择
下载地址:https://github.com/tporadowski/redis/releases
下载完后,解压文件,然后打开文件夹,内容如下:
我们直接双击redis-server.exe即可启动。
这时候另启一个 cmd 窗口,原来的不要关闭,不然就无法访问服务端了。
通过客户端去访问 redis-cli.exe
设置键值对:
set myKey abc
取出键值对:
get myKey
windows我们自己平时练习一下就行了,Redis主要是放在Linux上使用。
1、redis压力测试工具-----Redis-benchmark
Redis-benchmark是官方自带的Redis性能测试工具,可以有效的测试Redis服务的性能。
2、redis-benchmark工具存放在Redis的src目录下
使用 redis-benchmark -h 命令来查看使用参数
redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]
-h <hostname> 指定服务器主机名 (默认 127.0.0.1)
-p <port> 指定服务器端口 (默认 6379)
-s <socket> 指定服务器 socket
-a <password> Redis 认证密码
-c <clients> 指定并发连接数 (默认 50)
-n <requests> 指定请求数 (默认 100000)
-d <size> 以字节的形式指定 SET/GET 值的数据大小 (默认 2)
--dbnum <db> 选择指定的数据库号 (默认 0)
-k <boolean> 1=keep alive 0=reconnect (默认 1)
-r <keyspacelen> SET/GET/INCR 使用随机 key, SADD 使用随机值
-P <numreq> 通过管道传输 <numreq> 请求 (no pipeline)
-q 退出,仅显示 query/sec 值
--csv 以 CSV 格式输出
-l 生成循环,永久执行测试
-t <tests> 仅运行以逗号分隔的测试命令列表
-I Idle 模式,仅打开 N 个 idle 连接并等待
3、压力测试
对127.0.0.1使用20个并行客户端,总共10万个请求
./redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 20 -q
默认16个数据库,类似数组下标从零开始,初始默认使用零号库。
查看 redis.conf ,里面有默认的配置
# Set the number of databases. The default database is DB 0, you can select
# a different one on a per-connection basis using SELECT where
# dbid is a number between 0 and 'databases'-1
databases 16
1、Select命令切换数据库
127.0.0.1:6379> select 7
OK
127.0.0.1:6379[7]>
# 不同的库可以存不同的数据
2、Dbsize查看当前数据库的key的数量
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> DBSIZE
(integer) 0
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> DBSIZE
(integer) 5
127.0.0.1:6379> keys * # 查看具体的key
1) "counter:__rand_int__"
2) "mylist"
3) "k1"
4) "myset:__rand_int__"
5) "key:__rand_int__"
3、Flushdb:清空当前库
4、Flushall:清空全部的库
127.0.0.1:6379> FLUSHDB
OK
127.0.0.1:6379> DBSIZE
(integer) 0
官方解释:因为Redis是基于内存的操作,CPU不是Redis的瓶颈,Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现,而且CPU不会成为瓶颈,那就 顺理成章地采用单线程的方案了!
我们所说的Redis
的单线程,不是指Redis
程序真的只会有一个线程。这里所说的单线程,指的是Redis处理客户端发来的数据操作请求(增删改查),只会使用一个线程去执行。但是实际上,Redis
在执行其他操作的时候,可能会开启多个进程或线程,比如说持久化。Redis
执行BGSAVE
指令,进行快照持久化时,就会fork
出一个子进程,然后子进程去创建快照,完成持久化操作。
多线程 一定比 单线程 效率高,其实不然!
redis 核心就是 如果我的数据全都在内存里,我单线程的去操作 就是效率最高的,为什么呢,因为 多线程的本质就是 CPU 模拟出来多个线程的情况,这种模拟出来的情况就有一个代价,就是上下文的切 换,对于一个内存的系统来说,它没有上下文的切换就是效率最高的。redis 用 单个CPU 绑定一块内存 的数据,然后针对这块内存的数据进行多次读写的时候,都是在一个CPU上完成的,所以它是单线程处 理这个事。在内存的情况下,这个方案就是最佳方案。
因为一次CPU上下文的切换大概在 1500ns 左右。从内存中读取 1MB 的连续数据,耗时大约为 250us, 假设1MB的数据由多个线程读取了1000次,那么就有1000次时间上下文的切换,那么就有1500ns * 1000 = 1500us ,我单线程的读完1MB数据才250us ,你光时间上下文的切换就用了1500us了,我还不 算你每次读一点数据 的时间。
现在的CPU
一般都有多个核心,每个核心可以单独执行。Redis
处理客户端请求使用单线程,那么自然而然,无法将CPU
的所有核心都占用,也就造成了资源的浪费。而解决的方式也比较简单,我们可以在同一个服务器上开启多个Redis
程序,每个Redis
程序使用不同的端口,相互独立,以此提高CPU
的使用率。而这多个Redis
程序可以配置成主从节点,共同为一个程序服务,也可以相互独立,服务于多个程序。
下载地址:https://github.com/uglide/RedisDesktopManager,该仓库提供的是RedisDesktopManager的源码,并未提供windows安装包。
在下面这个仓库可以找到安装包:https://github.com/lework/RedisDesktopManager-Windows/releases
既然是学习使用,我们就是使用最新的版本即可。
下载完成之后,我们解压一下,然后看到文件夹中一个exe文件,我们双击安装。
安装完成之后,打开安装的目录,找到这个resp.exe文件。
双击运行即可:
点击左上角的连接到Redis服务器按钮:
这里启动可以在本地装一个redis,然后启动起来,我们这里默认地址即可,填写一个名字,其余的可为空,如果你连接的是服务器上的,可能设置密码,再填写密码即可。
填写完之后,先别着急点确定,点击左下角的测试连接,先测试一下连接是否通,然后再确定
测试成功之后,再点击确定,然后打开我们新添加的test,就会看到16个数据库了。
Redis默认有16个仓库,编号从0至15. 通过配置文件可以设置仓库数量,但是不超过16,并且不能自定义仓库名称。
以上就是学习Redis入门需要了解的知识,我是一步一步的操作的,接下来进入redis实际的应用。