NOSQL概述
为什么要用Nosql
用户的个人信息,社交网络,地理位置。用户自己产生的数据,用户日志等等爆发式增长!
这时候我们就需要使用NoSQL数据库的,Nosql可以很好的处理以上的情况!
1、单机MySQL的年代!(DAL数据库访问层)
90年代,一个基本的网站访问量一般不会太大 ,单个数据库完全足够!那个时候,更多的去使用静态网页Html ~服务器根本没有太大的压力!
思考一下,这种情况下:整个网站的瓶颈是什么?
- 数据量如果太大、一一个机器放不下了!
- 数据的索引(B+Tree),一个机器内存也放不下
- 访问量(读写混合) ,一个服务器承受不了
只要你开始出现以上的三种情况之一, 那么你就必须要晋级!
2、Memcached (缓存) + MySQL +垂直拆分(解决读的问题)
网站80%的情况都是在读,每次都要去查询数据库的话就十分的麻烦!所以说我们希望减轻数据的压力我们可以使用缓存来保证效率!
发展过程:优化数据结构和索引–>文件缓存( I0 ) --> Memcached (当时最热门的技术! )
3、分库分表 + 水平拆分 + MySQL集群(解决写的问题)
4、如今的年代
2010–2020十年之间,世界已经发生了翻天覆地的变化; ( 定位,也是一种数据, 音乐,热榜! )
MySQL等关系型数据库就不够用了!数据量很多,变化很快~ !
MySQL有的使用它来村粗一-些比较大的文件,博客,图片!数据库表很大,效率就低了!如果有一种数据来专处理这种数据,
MySQL压力就变得十分小(研究如何处理这些问题! ) 大数据的I0压力下,表几乎没法更大! .
目前一个基本的互联网项目
什么是NoSQL
NoSQL
NoSQL = Not Only SQL (不仅仅是SQL )
关系型数据库::表格、行、列
泛指非关系型数据库的,随着web2.0互联网的诞生! 传统的关系型数据库很对付web2.0时代!尤其是超大规模的高并发的社区!暴露出来很多难以克服的问题, NoSQL在当今大数据环境下发展的十分速, Redis是发展最快的,而且是我们当下必须要掌握的一个技术!
很多的数据类型用户的个人信息,社交网络,地理位置。这些数据类型的存储需要一个固定的格式!不需要多月的操作就可以横向扩展的!Map<String,Object>使用键值对来控制!
NoSQL特点
解耦!
- 方便扩展(数据之间没有关系,很好扩展!)
- 大数据量高性能( Redis 一秒写8万次,读取11万, NoSQL的缓存记录级,是一种细粒度的缓存,性能比高! )
- 数据类型是多样型的! (不需要事先设计数据库!随取随用!如果是数据量十分大的表,很多人就无法设计了! )
- 传统的RDBMS 和 NoSQL
传统的RDBMS
- 结构化组织
- SQL
- 数据和关系都存在单独的表中 一操作操作,数据定义语言
- 严格的一致性
- 基础的事务
- …
NoSQL
- 不仅仅是数据
- 没有固定的查询语言
- 键值对存储,列存储,文档存储,图形数据库(社交关系)
- 最终一致性,
- CAP定理和BASE (异地多活)初级架构师!
- 高性能,高可用,高可扩
- …
了解:3V + 3高
大数据时代的3V :主要是描述问题的
- 海量 Volume
- 多样 Variety
- 实时 Velocity
大数据时代的3高:主要是对程序的要求
- 高并发
- 高可拓.
- 高性能.
真正在公司中的实践: NoSQL + RDBMS 一起使用才是最强的
商品的基本信息 名称、价格、商家信息;
- 关系型数据库就可以解决了! MySQL / oracle 淘宝内部的MySQL 不是大家用的MySQL
商品的描述、评论(文字比较多)
- 文档型数据库中,MongoDB
图片
- 分布式文件系统 FastDFS
- 淘宝自己的 TFS
- Gooale的 GFS
- Hadoop HDFS
- 阿里云的 OSS
商品的关键字(搜索)
- 搜索引擎so1r elasticsearch
- ISerach: 多隆()
商品热门的波段信息
- 内存数据库
- Redis Tair、Memache
商品的交易,外部的支付接口
- 三方应用
NoSQL四大分类
KV键值对F
- 新浪:Redis
- 美团: Redis + Tair
- 阿里、百度: Redis + memecache .
文档型数据库( bson格式和json一样) :
- MongoDB (一般必须要掌握)
- MongoDB是一个基于分布式文件存储的数据库, C++编写,主要用来处理大量的文档!
- MongoDB是一个介于关系型数据库和非关系型数据中中间的产品! MongoDB是非关系型数据库中功能最丰富,最像关系型数据库的!
- ConthDB
列存储数据库
- HBase
- 分布式文件系统
图关系数据库,
- 他不是存图形,放的是关系,比如:朋友圈社交网络,广告推荐!
- Neo4j,InfoGrid ;
区别对比:
Redis入门
概述
Redis是什么
Redis ( Remote Dictionary Server ) ,即远程字典服务!
是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库 ,并提供多种语言的API。免费和开源!是当下最热门J的NoSQL技术之一!!也被人们称之为结构化数据库!
Redis能干嘛
- 内存存储、持久化,内存中是断电即失、所以说持久化很重要( rdb、 aof )
- 效率高,可以用于高速缓存
- 发布订阅系统
- 地图信息分析
- 计时器、计数器(浏览量!)
- …
特性
- 多样的数据类型
- 持久化
- 集群
- 事务
linux安装
1、官网下载:https://redis.io/
2、解压
3、进入解压后的文件,可以看到Redis的配置文件
4、基本的环境安装
# yum install gcc-c++
# make
# make install
5、redis的默认安装路径/usr/local/bin
6、将Redis的配置文件拷贝一份
7、redis默认不是后台启动的, 修改配置文件!
默认这里是 no 我们要改为 yes
8、启动Redis服务
9、使用 redis.cli 进行连接测试
10、查看redis的进程是否开启
11、如何关闭Redis服务
12、 后面我们会使用单机多Redis启动集群测试!
测试性能
redis-benchmark是一个压力测试工具
官方自带的性能测试工具
redis-benchmark + 命令参数
基础知识
redis默认有16个数据库,默认使用的第0个
可以使用select切换数据库
select 3 切换数据库
dbsize 查看数据库大小
keys * 查看所有的key值
flushdb 清空数据
Redis是单线程的,6.0之后引入了多线程
明白Redis是很快的,官方表示,,Redis是基于内存操作, CPU不是Redis性能瓶颈,Redis的瓶颈是根据机器的内存和网络带宽,既然可以使用单线程来实现,就使用单线程了!所有就使用了单线程了!
Redis是C语言写的,官方提供的数据为100000+ 的QPS ,完全这个不比Memecache差!
Redis为什么单线程还这么快?
1、误区1 :高性能的服务器一定是多线程的?
2、误区2:多线程( CPU上下文会切换! )一定比单线程效率高!
先去CPU>内存>硬盘的速度要有所了解!
核心: redis是将所有的数据全部放在内存中的,所以说使用单线程去操作效率就是最高的,多线程( CPU上下文会切换;耗时的操作! ! ! ),对于内存系统来说,如果没有上下文切换效率就是最高的!多次读写都是在一个CPU 上的,在内存情况下,这个就是最佳的方案
五大数据类型
Redis是一个开源( BSD许可)的,内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件MQ。它支持多种类型的数据结构,如字符串( strings),散列( hashes), 列表(lists),集合(sets),有序集合( sorted sets )与范围查询,bitmaps,hyperloglogs 和地理空间( geospatial )索引半径查询。Redis 内置了复制( replication) , LUA脚本( Lua scripting),LRU驱动事件( LRU eviction) , 事务( transactions )和不同级别的磁盘持久化( persistence ),并通过Redis哨兵( Sentinel )和自动分区( Cluster )提供高可用性( high availability)。
Redis-key
127.0.0.1:6379> keys * # 查看所有的key
(empty array)
127.0.0.1:6379> set name wlq
OK
127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> exists name # 判断当前key是否存在
(integer) 1
127.0.0.1:6379> move name 1 # 将当前key移动到1号库
(integer) 1
127.0.0.1:6379> keys *
1) "age"
127.0.0.1:6379> set name wlq
OK
127.0.0.1:6379> keys *
1) "name"
2) "age"
127.0.0.1:6379> get name
"wlq"
127.0.0.1:6379> expire name 5 # 设置key的过期时间
(integer) 1
127.0.0.1:6379> ttl name # 查看当前key剩余时间
(integer) 4
127.0.0.1:6379> get name
(nil)
127.0.0.1:6379> type name # 返回类型
string
(nil)
127.0.0.1:6379>
string
**************************************************************
127.0.0.1:6379> set name wlq
OK
127.0.0.1:6379> append name "hello" # 追加字符
(integer) 8
127.0.0.1:6379> get name
"wlqhello"
127.0.0.1:6379> strlen name # 获取字符长度
(integer) 8
**************************************************************
# i++
# 步长 i+=
127.0.0.1:6379> set views 0
OK
127.0.0.1:6379> get views
"0"
127.0.0.1:6379> incr views # 自增1
(integer) 1
127.0.0.1:6379> incr views
(integer) 2
127.0.0.1:6379> decr views # 自减1
(integer) 1
127.0.0.1:6379> get views
"1"
127.0.0.1:6379> incrby views 9 # 自增9
(integer) 10
**************************************************************
# 字符串范围
127.0.0.1:6379> getrange name 1 5 # 截取字符串区间
"lqhel"
127.0.0.1:6379> getrange name 0 -1 # 获取全部字符串
"wlqhello"
127.0.0.1:6379>
**************************************************************
# 替换
127.0.0.1:6379> setrange name 1 xx # 替换指定范围的开始的字符串
(integer) 8
127.0.0.1:6379> get name
"wxxhello"
127.0.0.1:6379>
**************************************************************
# setex (set with expire) # 设置过期时间
# setnx (set if not exist) # 不存在在设置(在分布式锁中会常常使用!
**************************************************************
# mset # 设置多个值
# mget
127.0.0.1:6379> mset k1 v1 k2 v2 k3 v3 # 同时设置多个值
OK
127.0.0.1:6379> keys *
1) "k3"
2) "k1"
3) "k2"
127.0.0.1:6379> mget k1 k2 k3
1) "v1"
2) "v2"
3) "v3"
127.0.0.1:6379> msetnx k1 v1 k4 v4 # msetnx 是一个原子性的操作,要么一起成功,要么一起失败!
(integer) 0
127.0.0.1:6379> get k4
(nil)
127.0.0.1:6379>
**************************************************************
#对象
set user:1 {name:zhangsan,age:3} # 设置一个user:1对象值为json字符来保存一个对象!
**************************************************************
#这里的key是一个巧妙的设计: user:{id}:{fi1ed},如此设计在Redis中是完全0K了!
127.0.0.1:6379> mset user:1:name zhangsan user:1:age 18
OK
127.0.0.1:6379> mget user:1:name user:1:age
1) "zhangsan"
2) "18"
127.0.0.1:6379>
**************************************************************
# getser # 先get 再set
127.0.0.1:6379> getset db redis
(nil)
127.0.0.1:6379> get db
"redis"
127.0.0.1:6379> getset db mongodb
"redis"
127.0.0.1:6379> get db
"mongodb"
127.0.0.1:6379>
String类似的使用场景: value除了是我们的字符串还可以是我们的数字!
- 计数器
- 统计多单位的数量
- 粉丝数
- 对象缓存存储!
list
基本的数据类型,列表
在redis里面,我们可以把list玩成,栈、队列、阻塞队列!
所有的list命令都是用 l 开头的
**************************************************************
127.0.0.1:6379> lpush list one # 将一个或多个值插入到列表头部(左)
(integer) 1
127.0.0.1:6379> lpush list two
(integer) 2
127.0.0.1:6379> lpush list three
(integer) 3
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
127.0.0.1:6379> RPUSH list four # 将一个或多个值插入到列表尾部(右)
(integer) 4
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
4) "four"
127.0.0.1:6379>
**************************************************************
# LPOP
# RPOP
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
4) "four"
127.0.0.1:6379> LPOP list # 移除左边第一个
"three"
127.0.0.1:6379> RPOP list # 移除右边第一个
"four"
127.0.0.1:6379> LRANGE list 0 -1
1) "two"
2) "one"
**************************************************************
# Lindex # 通过下标获取值
127.0.0.1:6379> LRANGE list 0 -1
1) "two"
2) "one"
127.0.0.1:6379> lindex list 0 # 通过下标获第一个值
"two"
127.0.0.1:6379> lindex list 1
"one"
127.0.0.1:6379>
**************************************************************
# Llen
127.0.0.1:6379> LLEN list # 返回列表的长度
(integer) 2
**************************************************************
# 移除指定的值
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
4) "four"
127.0.0.1:6379> LREM list 1 four # 移除list集合中指定个数的value,精确匹配
(integer) 1
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
127.0.0.1:6379> LPUSH list three
(integer) 4
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "three"
3) "two"
4) "one"
127.0.0.1:6379> LREM list 2 three
(integer) 2
127.0.0.1:6379> LRANGE list 0 -1
1) "two"
2) "one"
127.0.0.1:6379>
**************************************************************
# trim 修剪 list 截断
127.0.0.1:6379> RPUSH list "wlq1"
(integer) 1
127.0.0.1:6379> RPUSH list "wlq2"
(integer) 2
127.0.0.1:6379> RPUSH list "wlq3"
(integer) 3
127.0.0.1:6379> RPUSH list "wlq4"
(integer) 4
127.0.0.1:6379> LTRIM list 1 2 # 通过下标截取指定的长度,这个list已经被改变了,截断了只剩下截取的元素!
OK
127.0.0.1:6379> LRANGE list 0 -1
1) "wlq2"
2) "wlq3"
127.0.0.1:6379>
**************************************************************
# rpoplpush # 移除列表的最后一个元素,
127.0.0.1:6379> rpush list "hello"
(integer) 1
127.0.0.1:6379> rpush list "hello1"
(integer) 2
127.0.0.1:6379> rpush list "hello2"
(integer) 3
127.0.0.1:6379> RPOPLPUSH list list1 # 移除列表的最后一个元素,将他移动到新的列表中!
"hello2"
127.0.0.1:6379> LRANGE list 0 -1 # 查看原来列表
1) "hello"
2) "hello1"
127.0.0.1:6379> LRANGE list1 0 -1 # 发现目标文件确实存在改值
1) "hello2"
127.0.0.1:6379>
**************************************************************
# lset # 将列表中指定下标的值替换为另外一个值,
127.0.0.1:6379> LPUSH list value
(integer) 1
127.0.0.1:6379> LRANGE list 0 -1
1) "value"
127.0.0.1:6379> LSET list 0 item # 如果不存在列表我们去更新就会报错,如果存在,更新当前下标的值
OK
127.0.0.1:6379> LRANGE list 0 -1
1) "item"
127.0.0.1:6379>
**************************************************************
# 将某个具体的value插入到列把你中某个元素的前面或者后面! |
127.0.0.1:6379> lpush list wlq
(integer) 1
127.0.0.1:6379> lpush list world
(integer) 2
127.0.0.1:6379> LINSERT list before world wlq # 插入到前面
(integer) 3
127.0.0.1:6379> LRANGE list 0 -1
1) "wlq"
2) "world"
3) "wlq"
127.0.0.1:6379> LINSERT list after world q # 插入到后面
(integer) 4
127.0.0.1:6379> LRANGE list 0 -1
1) "wlq"
2) "world"
3) "q"
4) "wlq"
127.0.0.1:6379>
小结
- 他实际上是一个链表, before Node after ,left , right都可以插入值
- 如果key不存在,创建新的链表
- 如果key存在,新增内容
- 如果移除了所有值,空链表,也代表不存在!
- 在两边插入或者改动值,效率最高!中间元素,相对来说效率会低一点
消息排队!消息队列( Lpush Rpop) ,栈( Lpush Lpop )
set(集合)
set中的值不能重读
**************************************************************
127.0.0.1:6379> sadd myset "hello" # set集合中添加值
(integer) 1
127.0.0.1:6379> sadd myset "world"
(integer) 1
127.0.0.1:6379> sadd myset "wlq"
(integer) 1
127.0.0.1:6379> SMEMBERS myset # 查看指定 set 的所有值
1) "hello"
2) "world"
3) "wlq"
127.0.0.1:6379> SISMEMBER myset wlq # 判断元素是否存在set集合中
(integer) 1
127.0.0.1:6379>
**************************************************************
127.0.0.1:6379> scard myset # 获取set集合中元素个数
(integer) 3
**************************************************************
127.0.0.1:6379> srem myset hello # 移除set集合中的指定元素
(integer) 1
127.0.0.1:6379> SMEMBERS myset
1) "world"
2) "wlq"
127.0.0.1:6379>
**************************************************************
# set 无需不重复集合,抽随机
127.0.0.1:6379> SRANDMEMBER myset
"wlq"
127.0.0.1:6379> SRANDMEMBER myset
"world"
127.0.0.1:6379> SRANDMEMBER myset
"wlq"
127.0.0.1:6379> SRANDMEMBER myset 2 # 随机抽取指定个数元素
1) "world"
2) "wlq"
127.0.0.1:6379>
**************************************************************
# 随机删除
127.0.0.1:6379> spop myset
"world"
127.0.0.1:6379> scard myset
(integer) 1
127.0.0.1:6379> SMEMBERS myset
1) "wlq"
127.0.0.1:6379>
**************************************************************
# 将一个指定的值,移动到另一个set集合
127.0.0.1:6379> sadd myset "hello"
(integer) 1
127.0.0.1:6379> sadd myset "world"
(integer) 1
127.0.0.1:6379> sadd myset "wlq"
(integer) 1
127.0.0.1:6379> sadd myset2 "hello2"
(integer) 1
127.0.0.1:6379> SMOVE myset myset2 wlq
(integer) 1
127.0.0.1:6379> SMEMBERS myset2
1) "hello2"
2) "wlq"
127.0.0.1:6379> SMEMBERS myset
1) "hello"
2) "world"
127.0.0.1:6379>
**************************************************************
微博,B站,共同关注! (交集)
数字集合类:
- 差集
- 交集
- 并集
127.0.0.1:6379> sadd myset a
(integer) 1
127.0.0.1:6379> sadd myset b
(integer) 1
127.0.0.1:6379> sadd myset c
(integer) 1
127.0.0.1:6379> sadd myset2 c
(integer) 1
127.0.0.1:6379> sadd myset2 d
(integer) 1
127.0.0.1:6379> sadd myset2 e
(integer) 1
127.0.0.1:6379> SDIFF myset myset2 # 差集
1) "a"
2) "b"
127.0.0.1:6379> SINTER myset myset2 # 交集 (共同好友实现)
1) "c"
127.0.0.1:6379> SUNION myset myset2 # 并集
1) "a"
2) "b"
3) "c"
4) "e"
5) "d"
127.0.0.1:6379>
微博,A用户将所有关注的人放在一个set集合中!将它的粉丝也放在一个集合中!
共同关注,共同爱好,二度好友,推荐好友!(六度分割理论)
Hash(哈希)
Map集合, key-map!时候这个值是一个map集合 !本质和string类型没有区别还是一个简单地key-value
127.0.0.1:6379> hset myhash field1 wlq # set一个具体key-v1aue
(integer) 1
127.0.0.1:6379> hmset myhash field1 hello field2 world # set多个key-vlaue
OK
127.0.0.1:6379> hget myhash field1 # 获取一个字段值
"hello"
127.0.0.1:6379> hmget myhash field1 field2 # 获取多个字段值
1) "hello"
2) "world"
127.0.0.1:6379> hgetall myhash # 获取全部数据
1) "field1"
2) "hello"
3) "field2"
4) "world"
127.0.0.1:6379> HDEL myhash field1 # 删除hash指定key字段! 对应的value值 也就消失了!
(integer) 1
127.0.0.1:6379> hgetall myhash
1) "field2"
2) "world"
127.0.0.1:6379>
**************************************************************
# hlen
127.0.0.1:6379> HLEN myhash # 获取hash表的字段数量!
(integer) 1
**************************************************************
# HEXISTS
127.0.0.1:6379> HEXISTS myhash field1 # 判断hash中指定字段是否存在!
(integer) 0
127.0.0.1:6379> HEXISTS myhash field2
(integer) 1
**************************************************************
# 只获得所有field
# 只获得所有value
127.0.0.1:6379> hkeys myhash
1) "field2"
2) "field1"
127.0.0.1:6379> HVALS myhash
1) "world"
2) "wlq"
127.0.0.1:6379>
**************************************************************
# incr
# decr
127.0.0.1:6379> hset myhash field3 5
(integer) 1
127.0.0.1:6379> HINCRBY myhash field3 1
(integer) 6
127.0.0.1:6379> HSETNX myhash field4 hello # 如果不存在则可以设置
(integer) 1
127.0.0.1:6379> HSETNX myhash field4 world # 如果存在则不能设置
(integer) 0
127.0.0.1:6379>
hash变更的数据user name age,尤其是是用户信息之类的,经常变动的信息! hash 更适合于对象的存储, String更加适合字符串存储!
Zset(有序集合)
在set的基础上,增加了一一个值, set k1 v1 ; zset k1 score1 v1
**************************************************************
127.0.0.1:6379> zadd myset 1 one 2 two 3 three
(integer) 3
127.0.0.1:6379> ZRANGE myset 0 -1
1) "one"
2) "two"
3) "three"
127.0.0.1:6379>
**************************************************************
排序如何实现
127.0.0.1:6379> zadd salary 100 zhangsan
(integer) 1
127.0.0.1:6379> zadd salary 200 lisi
(integer) 1
127.0.0.1:6379> zadd salary 300 wangwu
(integer) 1
127.0.0.1:6379> ZRANGEBYSCORE salary -inf +inf # 显示所有用户,从小到大
1) "zhangsan"
2) "lisi"
3) "wangwu"
127.0.0.1:6379> ZRANGEBYSCORE salary -inf +inf withscores # 显示所有用户,从小到大,并附带scores
1) "zhangsan"
2) "100"
3) "lisi"
4) "200"
5) "wangwu"
6) "300"
127.0.0.1:6379> ZREVRANGE salary 0 -1 withscores # 显示所有用户,从大到小,并附带scores
1) "wangwu"
2) "300"
3) "zhangsan"
4) "100"
127.0.0.1:6379>
**************************************************************
# rem # 删除
127.0.0.1:6379> ZREM salary lisi
(integer) 1
127.0.0.1:6379> ZRANGEBYSCORE salary -inf +inf
1) "zhangsan"
2) "wangwu"
127.0.0.1:6379> ZCARD salary # 获取元素个数
(integer) 2
127.0.0.1:6379> ZCOUNT salary 0 200 # 获取区间元素个数
(integer) 1
案例思路: set排序存储班级成绩表,工资表排序!
普通消息,1,重要消息2 ,带权重进行判断!
排行榜应用实现,取Top N测试!
三种特殊数据类型
geospatial(地理位置)
朋友的定位,附近的人,打车距离计算?
Redis的Geo在Redis3.2版本就推出了!这个功能可以推算地理位置的信息,两地之间的距离,方圆几里的人!
只有六个命令
- GEOADD
添加地理位置
规则:两级无法直接添加,我们一般会下载城市数据,直接通过java程序一次性导入! 参数key值(纬度、经度、名称)
有效的经度从-180度到180度。 有效的纬度从-85.05112878度到85.05112878度。
当坐标位置超出上述指定范围时,该命令将会返回一个错误。
- GEODIST
返回两个给定位置之间的距离
指定单位的参数unit必须是以下单位的其中一个:
m 示单位为米。
km 示单位为千米。
mi 表示单位为英里。
ft 示单位为英尺。
如果用户没有显式地指定单位参数,那么GEODIST 默认使用米作为单位。
- GEOHASH
返回一个或多个位置元素的Geohash表示,将二维的经纬度转换为一维的字符串,
- GEOPOS
获得当前定位:一定是一个坐标值!
- GEORADIUS
以给定的经纬度为中心,找出某一半径内的元素
我附近的人? ( 获得所有附近的人的地址,定位! )通过半径来查询!
获得指定数量的人,
- GEORADIUSBYMEMBER
找出位于指定范围内的元素,中心点是由给定的位置元素决定
GEO底层的实现原理其实就是Zset !我们可以使用Zset命令来操作geo !
hyperloglog
Redis Hyperloglog基数统计的算法!
基数(不重复的元素) ,可以接受误差!
Redis 2.8.9版本就更新了Hyperloglog 数据结构!
优点:占用的内存是固定, 2^64不同的元素的基数,只需要废12KB内存!
网页的UV (一个人访问一个网站多次,但是还是算作一个人! )
传统的方式,set 保存用户的id ,然后就可以统计set中的元素数量作为标准判断!
这个方式如果保存大量的用户id ,就会比较麻烦!我们的目的是为了计数,而不是保存用户id ;
如果允许容错,那么一定可以使用Hyperloglog !
如果不允许容错,就使用 set 或者自己的数据类型即可!
bitmaps
位存储
统计用户信息,活跃,不活跃!登录、未登录!打卡, 365打卡!两个状态的,都可以使用Bitmaps !
Bitmaps位图,数据结构!都是操作二进制位来进行记录,就只有0和1两个状态!
365天= 365 bit 1字节= 8bit 46 个字节左右!
事务
Redis事务本质: 一组命令的集合;一个事务中的所有命令都会被序列化,在事务执行过程的中,会按照顺序执行!
一次性、顺序性、排他性、执行一些列的命令!
Redis事务没有没有隔离级别的概念!
所有的命令在事务中,并没有直接被执行!只有发起执行命令的时候才会执行! Exec
Redis单条命令式保存原子性的,但是事务不保证原子性
redis事务:
- 开启事务 ( multi)
- 命令入队 ( …)
- 执行事务(exec)
正常执行事务
127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379(TX)> set k1 v1 # 命令入队
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> exec # 执行事务
1) OK
2) OK
3) OK
127.0.0.1:6379>
放弃事务
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> DISCARD # 取消事务
OK
127.0.0.1:6379> get k4 # 事务队列中命令都不会被执行! |
(nil)
127.0.0.1:6379> get k3
(nil)
127.0.0.1:6379>
编译型异常(代码有问题!命令有错! ),事务中所有的命令都不会被执行 !
运行时异常( 1/0),如果事务队列中存在语法性,那么执行命令的时候,其他命令式可以正常执行的
监控 watch
悲观锁:
- 很悲观,认为什么时候都会出问题,无论做什么都会加锁
乐观锁:
- 很乐观,认为什么时候都不会出问题,所以不会上锁!更新数据的时候去判断一 下,在此期间是否有人修改过这个数据,
- 获取version
- 更新的时候比较version
Redis测监视测试
正式执行成功
127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money # 监视money对象
OK
127.0.0.1:6379> multi # 事务正常结束,数据期间没有发生变动,这个时候就正常执行成功!
OK
127.0.0.1:6379(TX)> DECRBY money 20
QUEUED
127.0.0.1:6379(TX)> INCRBY out 20
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 80
2) (integer) 20
127.0.0.1:6379>
测试多线程修改值,使用watch可以当做redis的乐观锁操作!
127.0.0.1:6379> watch money # 监视 money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 10
QUEUED
127.0.0.1:6379> INCRBY out 10
QUEUED
127.0.0.1:6379> exec # 执行之前,另外一个线程,修改了我们的值,这个时候,就会导致事务执行失败!
(ni1)
如果修改失败,获取最新的就行
127.0.0.1:6379> UNWATCH # 如果事务执行失败,先解锁
OK
127.0.0.1:6379> WATCH money # 获取最新的值,再次监视,select version
OK
127.0.0.1:6379> exec # 比对监视的值是否发生改变,无变化就执行成功,否则继续执行上面解锁步骤
Jedis
我们要使用Java来操作Redis .
什么是Jedis是Redis官方推荐的 java 连接开发工具!使用 java 操作 Redis 中间件!
测试:
<!--导入jedis依赖-->
<!-- https://mvnrepository.com/artifact/redis.clients/jedis -->
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>3.3.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/com.alibaba/fastjson -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.75</version>
</dependency>
public static void main(String[] args) {
//1、new jedis 对象
Jedis jedis = new Jedis("ip",6379);
//2、jedis所有的命令就是我们之前学习的所有指令!
System.out.println(jedis.ping());
//输出PONG说明连接成功
}
SpringBoot整合
说明:在SpringBoot2.x之后,原来使用的jedis被替换为了lettuce
- jedis :采用的直连,多个线程操作的话,是不安全的,如果想要避免不安全的,使用jedis pool 连接池!更像BIO模式
- lettuce :采用netty ,实例可以再多个线程中进行共享,不存在线程不安全的情况!可以减少线程数据了,更像NIO 模式
源码解析:
@Bean
@ConditionalOnMissingBean(
name = {"redisTemplate"}
)
// 我们可以自己定 义一个redi sTemplate来替换这个默认的
@ConditionalOnSingleCandidate(RedisConnectionFactory.class)
public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
//默认的RedisTemplate 没有过多的设置,redis 对象都是需要序列化!
//两个泛型都是object, object 的类型,我们后使用需要强制转换<String, object>
RedisTemplate<Object, Object> template = new RedisTemplate();
template.setConnectionFactory(redisConnectionFactory);
return template;
}
@Bean
@ConditionalOnMissingBean
@ConditionalOnSingleCandidate(RedisConnectionFactory.class)
// 由于string是redis中最常使用的类型,所以说单独提出来了一个bean!
public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
StringRedisTemplate template = new StringRedisTemplate();
template.setConnectionFactory(redisConnectionFactory);
return template;
}
整合测试:
1、导入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
2、配置链接
# 配置redis
spring.redis.host=127.0.0.1
spring.redis.port=6379
3、测试
@Test
void contextLoads() {
// redisTemplate 操作不同的数 据类型,api和我们的指令是一样的
// opsForValue 操作字符串 类似String
// opsForList 操作List类似ist
// opsForSet
// opsForHash
// opsForZSet
// opsForGeo
// opsForHyperLogLog
//除了进本的操作,我们常用的方法都可以直接通过redisTemplate操作, 比如事务,和基本的CRUD
//获取redis的连接对象
// RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
// connection.flushDb();
// connection.flushAll();
redisTemplate.opsForValue().set("v1","wlq");
System.out.println(redisTemplate.opsForValue().get("v1"));
}
编写一个自己的template
@Configuration
public class RedisConfig {
// 自己定义了一个 RedisTemplate
@Bean
@SuppressWarnings("all")
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
// 我们为了自己开发方便,一般直接使用 <String, Object>
RedisTemplate<String, Object> template = new RedisTemplate<String, Object>();
template.setConnectionFactory(factory);
// Json序列化配置
Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
ObjectMapper om = new ObjectMapper();
om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
jackson2JsonRedisSerializer.setObjectMapper(om);
// String 的序列化
StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
// key采用String的序列化方式
template.setKeySerializer(stringRedisSerializer);
// hash的key也采用String的序列化方式
template.setHashKeySerializer(stringRedisSerializer);
// value序列化方式采用jackson
template.setValueSerializer(jackson2JsonRedisSerializer);
// hash的value序列化方式采用jackson
template.setHashValueSerializer(jackson2JsonRedisSerializer);
template.afterPropertiesSet();
return template;
}
}
在我们真实的分发中,或者你们在公司,一般都可以看到一个公司自己封装RedisUtil
//在企业中,我们所有的been类都需要序列化
public class User implements Serializable {
private String name;
private int age;
}
@Autowired
private RedisUtil redisUtil;
@Test
public void test1( ){
redisUtil. set("name" , "wlq" ) ;
System. out . println( redisUtil.get("name"));
}
Redis.conf详解
启动需要配置文件来启动
1、单位,对大小写不敏感
2、包含
3、网路
bind 127.0.0.1 # 绑定的ip
protected-mode yes # 保护模式
port 6379
4、通用GENERAL
daemonize yes # 以守护进程的方式运行,默认是no,我们需要自己开启为yes!
pidfile /var/run/redis_6379.pid # 如果以后台的方式运行,我们就需要指定一个pid文件!
# 日志
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice
1ogfile "" # 日志的文件位置名
databases 16 # 数据库的数量,默认是16个数据库
always-show-1ogo yes # 是否总是 显示LOGO
5、快照
持久化,在规定的时间内,执行了多少次操作,则会持久化到文件.rdb. aof
redis是内存数据库,如果没有持久化,那么数据断电及失!
# 如果3600s内,如果至少有一个1 key进行了修改,我们及进行持久化操作
# save 3600 1
# 如果300s内,如果至少有100 key进行了修改,我们及进行持久化操作
# save 300 100
# 如果60s内,如果至少有10000 key进行了修改,我们及进行持久化操作
# save 60 10000
# 我们之后学习持久化,会自己定义这个测试i!
stop-writes-on-bgsave-error yes # 持久化如果出错,当bgsave快照操作出错时停上写数据到磁盘
rdbcompression yes # 是否压缩rdb文件,需要消耗一些cpu资源!
rdbchecksum yes # 保存rdb文件的时候,进行错误的检查校验!
dir./ # rdb文件保存的目录
6、安全SECURITY
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get requirepass # 查看密码
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass "1346258" # 设置密码
OK
127.0.0.1:6379> auth 1346258 # 认证登入
OK
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get requirepass # 查看密码
1) "requirepass"
2) "1346258"
127.0.0.1:6379>
7、限制
maxc1ients 10000 # 设置能连接上redis的最大客户端的数量
maxmemory <bytes> # redis 配置最大的内存容量
` 面试会问
maxmemory-policy noeviction # 内存到达上限之后的处理策略
1、volatile-1ru: 只对设置了过期时间的key进行LRU (默认值)
2、al1keys-1ru :删除lru算法的key
3、volatile- random:随机删除即将过期key
4、al1keys-random: 随机删除
5、volatile-tt1 :删除即将过期的
6、noeviction :永不过期, 返回错误
`
8、APPEND ONLY模式aof配置
appendonly no # 默认是不开启aof模式的,默认是使用rdb方式持久化的,在大部分所有的情况下,rdb完全够用!
appendfilename "appendonly.aof" # 持久化的文件的名字
# appendfsync always # 每次修改都会sync。消耗性能
appendfsync everysec # 每秒执行一次sync, 可能会丢失这1s的数据!
# appendfsync no # 不执行sync,这个时候操作系统自己同步数据,速度最快!
9、REPLICATION复制,我们后面讲解主从复制的,时候再进行讲解
具体的配置,我们在Redis持久化中去给大家详细详解!
Redis持久化
面试和工作,持久化都是重点!
Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦 服务器进程退出,服务器中的数据库状态也会消失。所以Redis提供了持久化功能!
RDB(Redis DataBase)
在主从复制中, rdb就是备用了!从机上面!
在指定的时间间隔内将内存中的数据集快照写入磁盘T也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建( fork ) 一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后-次持久化后的数据可能丢失。
rdlb保存的文件是dump.rdb
触发规则:
- save的规则满足的情况下,会自动触发rdb规则
- 执行flushall命令,也会触发我们的rdb规则!
- 退出redis ,也会产生rdb文件!
备份就自动生成一一个 dump.rdb
如何恢复rdb文件
1、只需要将rdb文件放在我们redis启动目录就可以, redis启动的时候会自动检查dump.rdb恢复其中的数据!
2、查看需要存在的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在dump.rdb 文件,启动就会自动恢复其中的数据
几乎就他自己默认的配置就够用了, 但是我们还是需要去学习!
- 优点
1、适合大规模的数据恢复!
2、对数据的完整性要不高! - 缺点
1、需要一定的时间间隔进程操作!如果redis意外宕机了,这个最后一次修改数据就没有的了!
2、fork进程的时候,会占用一定的内容空间!
AOF ( Append Only File )
将我们的所有命令都记录下来, history ,恢复的时候就把这个文件全部在执行一遍!
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录) , 只许追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据,换言之, redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF保存的是appendonly.aof文件
append,默认是不开启的
默认是不开启的,我们需要手动进行配置!我们只需要将appendorly改为yes就开启了aof !
重启, redis就可以生效了!
如果这个aof文件有错位,这时候redis是启动不起来的吗,我们需要修复这个aof文件
redis给我们提供了一个工具 redis-check-aof --fix
重写规则
aof默认就是文件的无限追加,文件会越来越大!
如果aof文件大于64m ,太大了! fork- -个新的进程来将我们的文件进行重写,
优缺点:
appendonly no # 默认是不开启aof模式的, 默认是使用rdb方式持久化的,在大部分所有的情况下,rdb完全够用!
appendfilename "appendonly. aof" # 持久化的文件的名字
# appendfsync always # 每次修改都会sync。 消耗性能
appendfsync everysec # 每秒执行一次sync, 可能会丢失这1s的数据!
# appendfsync no # 不执行sync,这个时候操作系统自己同步数据,速度最快!
- 优点
- 每一次修改都同步,文件的完整会更加好!
- 每秒同步一次,可能会丢失一秒的数据
- 从不同步,效率最高的!
- 缺点
- 相对于数据文件来说, aof远远大于rdb ,修复的速度也比rdb慢!
- Aof 运行效率也要比rdb慢,所以我们redis默认的配置是rdb持久化
扩展
1、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据, AOF命令以Redis协议追加保存每次写的操作到文件末尾, Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
3、只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化
4、同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?作者建议不要,因为RDB更适合用于备份数据库( AOF在不断变化不好备份) , 快速重启,而且不会有AOF可能潜在的Bug ,留着作为一个万一的手段。
5、性能建议
- 因为RDB文件只用作后备用途,建议只在Slave.上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条
规则。 - 如果Enable AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了,代价一是带来 了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重写可以改到话当的数值.
- 如果不Enable AOF , 仅靠Master .Slave Repllcation实现高可用性也可以,能省掉一大笔IO ,也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉,会丢失十几分钟的数据 ,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个,微博就是这种架构。
Redis发布订阅
Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。微信、微博、关注系统!
Redis客户端可以订阅任意数量的频道。
订阅/发布消息图:
下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系:
当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户端:
常用命令:
这些命令被广泛用于构建即时通信应用,比如网络聊天室(chatroom)和实时广播、实时提醒等。
测试:
- 订阅端:
127.0.0.1:6379> SUBSCRIBE wlq # 订阅一个频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "wlq"
3) (integer) 1
# 等待读取推送的消息
1) "message" # 消息
2) "wlq" # 哪个频道
3) "hello,redis" # 消息的具体内容
1) "message"
2) "wlq"
3) "hello,wlq"
- 发送端
127.0.0.1:6379> PUBLISH wlq "hello,redis" # 发布者发布消息到频道
(integer) 1
127.0.0.1:6379> PUBLISH wlq "hello,wlq" # 发布者发布消息到频道
(integer) 1
127.0.0.1:6379>
原理:
Redis是使用C实现的,通过分析Redis源码里的pubsub.c文件,了解发布和订阅机制的底层实现,籍此加深对Redis的理解。
Redis通过PUBLISH、SUBSCRIBE 和PSUBSCRIBE等命令实现发布和订阅功能。
通过SUBSCRIBE命令订阅某频道后, redis-server 里维护了一个字典,字典的键就是一个个channel ,而字典的值则是一个链表,链表中保存了所有订阅这个channel的客户端。SUBSCRIBE 命令的关键,就是将客户端添加到给定channel的订阅链表中。
通过PUBLISH命令向订阅者发送消息, redis-server 会使用给定的频道作为键,在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表,遍历这个链表,将消息发布给所有订阅者。
Pub/Sub从字面上理解就是发布( Publish )与订阅( Subscribe ) , 在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。
使用场景:
- 实时消息系统!
- 事实聊天! (频道当做聊天室,将信息回显给所有人即可! )
- 订阅,关注系统都是可以的!
稍微复杂的场景我们就会使用消息中间件MQ ( )
Redis主从复制
概念:
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master/leader) ,后者称为从节点(slave/follower) ;数据的复制是单向的,只能由主节点到从节点。Master以写为主 , Slave以读为主。
默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点) ,但一个从节点只能有一个主节点。
主从复制的作用主要包括:
- 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
- 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
- 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接
主节点,读Redis数据时应用连接从节点) , 分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大
大提高Redis服务器的并发量。 - 高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。
一般来说,要将Redis运用于工程项目中,只使用一台Redis是万万不能的,原因如下:
- 从结构上,单个Redis服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大;
- 从容量上,单个Redis服务器内存容量有限,就算一台Redis服务器内存容 量为256G ,也不能将所有内存用作Redis存储内存,
一般来说,单台Redis最大使用内存不应该超过20G。
电商网站.上的商品,一般都是一 次上传,无数次浏览的,说专业点也就是"多读少写"。
对于这种场景,我们可以使如下这种架构:
主从复制,读写分离! 80% 的情况下都是在进行读操作!减缓服务器的压力!架构中经常使用!
只要在公司中,主从复制就是必须要使用的,因为在真实的项目中不可能单机使用Redis !
复制原理:
Slave启动成功连接到master后会发送一个sync命令
Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后, master将传送整个数据文件到slave ,并完成一次完全同步。
全量复制:slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制: Master继续将新的所有收集到的修改命令依次传给slave ,完成同步
但是只要是重新连接master , 一次完全同步(全量复制)将被自动执行
环境配置:
只配置从库,不配主库
复制三个配置文件,然后修改对应点信息
- 端口
- pid名字
- log文件名字
- dump.rdb 名字
修改完毕之后,启动我们的3个redis服务器,可以通过进程信息查看
一主二从:
默认情况下,每台Redis服务器都是主节点;我们一般情况下只用配置从机就好了!
认老大!
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 # SL AVEOF host 6379找谁当自己的老大!
ok
127.0.0.1:6380> info rep1ication
# Replication
role:s1ave # 当前角色是从机
master_ host:127.0.0.1 # 主机地址
master_ port:6379 # 主机端口
master_1ink_ _status:up
master_ last _10_ seconds_ _ago:3
master_ sync_ _in_ progress:0
s1ave_ rep1_ offset:14
slave_ _priority:100
slave_ read_ only:1
connected_ slaves:0
# 在主机中查看!
127.0.0.1:6379> info replication
# Replication
role :master
connected_ slaves:1 # 多了从机的配置,有一个从机了
slave0:ip=127.0.0.1, port=6380, state=online,offset=42, lag=1
master_ replid : a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_ rep1i d2 : 0000000000000000000000000000000000000000
master_ rep1_ offset:42
second_ rep1_ offset:-1
rep1_ back1og_ _active:1
rep1_ back1og_ size:1048576
rep1_ back7og_ first_ byte_ offset:1
rep1_ back1og_ histlen:42
真实的从主配置应该在配置文件中配置,这样的话是永久的,我们这里使用的是命令,暂时的!
细节:
主机可以写,从机不能写只能读!主机中的所有信息和数据,都会自动被从机保存!
测试:主机断开连接,从机依旧连接到主机的,但是没有写操作,这个时候,主机如果回来了,从机依旧可以直接获取到主机写的信息!
如果是使用命令行,来配置的主从,这个时候如果重启了,就会变回主机!
只要变为从机,立马就会从主机中获取值!
如果主机断开了连接,我们可以使用SLAVEOF no one
让自己变成主机 !其他的节点就可以手动连接到最新的这个主节点(手动),如果这个时候老大修复了,那就重新配置!
哨兵模式(自动选举老大)
概述:
主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵)架构来解决这个问题。
谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
这里的哨兵有两个作用
- 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
- 当哨兵监测到master宕机,会自动将slave切换成master ,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。
假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。
当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票 ,投票的结果由一个哨兵发起,进行failover[故障转移]操作。
切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。
测试
我们目前的状态是一主二从!
1、配置哨兵配置文件sentinel.conf
# sentine1 monitor 被监控的名称host port 1
sentine1 monitor myredis 127.0.0.1 6379 1
后面的这个数字1 , 代表主机挂了, slave投票看让谁接替成为主机,票数最多的,就会成为主机!
2、启动哨兵
redis-sentinel kconfig/sentineL.conf
如果Master节点断开了,这个时候就会从从机中随机选择一个服务器当主机 ! (这里有投票算法)
如果主机此时回来了,只能归并到新的主机下,当做从机,这就是哨兵模式的规则!
哨兵模式
- 优点:
- 哨兵集群,基于主从复制模式,所有的主从配置优点,它全有
- 主从可以切换 ,故障可以转移,系统的可用性就会更好
- 哨兵模式就是主从模式的升级,手动到自动,更加健壮!
- 缺点:
- Redis不好啊在线扩容的,集群容量–旦到达上限,在线扩容就+分麻烦!
- 实现哨兵模式的配置其实是很麻烦的,里面有很多选择!
哨兵模式的全部配置:
# Examp1e sentine1.conf
# 哨兵sentine1实例运行的端口默认26379
port 26379
#哨兵sentine1的工作目录
dir /tmp
#哨兵sentinel 监控的redis主节点的ip port
# master-name 可以自己命名的主节点名字只能由字母A-z、 数字0-9、这三个字符".- "组成。
# quorum 配置多少个sentine1哨兵统一认为master主节点失联那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
#当在Redis实例中开启了requirepass foobared 授权密码这样所有连接Redi s实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passwOrd
# 指定多少毫秒之后主节点没有应答哨兵sentine1 此时哨兵主观上认为主节点下线默认30秒
# sentinel down-after-mi 11i seconds <master-name> <mi 11i seconds>
sentinel down-after-mi 11iseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步,
这个数字越小,完成failover所 需的时间就越长,
但是如果这个数字越大,就意味着越多的slave因为replicati on而不可用。
可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
# sentinel para1le1-syncs <master-name> <nums laves>
sentinel paral1e1-syncs mymaster 1
# 故障转移的超时时间 fai lover-timeout 可以用在以下这些方面:
#1.同一个sentinel对同一 个master两次failover之间的间隔时间。
#2.当一个s1ave从一个错 误的master那里同步数据开始计算时间。直到s1ave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的fai lover所需要的时间。
#4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves 依然会被正确配置为指向master,但是就不按paralle1-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-ti meout <master-name> <mi 11i seconds>
sentinel failover-ti meout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则:
#若脚本执行后返回1,那么该脚本稍后将会被再次执行,重复次数目前默认为10
#若脚本执行后返回2,或者比2更高的-一个返回值,脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了,则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s,如果超过这个时间,脚本将会被一个SIGKILL信号终止,之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本,这时这个脚本应该通过邮件,SMS 等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时,将传给脚本两个参数,一个是事件的类型,个是事件的描述。如果sentinel. conf配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无法正常启动成功。
#通知脚本
# shell编程
# sentinel notificati on-script <master-name> <script-path>
sentinel notificati on-script mymaster /var/redis/notify. sh
#客户端重新配置主节点参数脚本
#当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生改变的信息。
#以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#目前<state>总是“failover”,
# <role>是“7eader”或者“observer"中的一个。
#参数from-ip, from-port, to-ip, to-port是用来和旧的master和新的master (即旧的s1ave)通信的
#这个脚本应该是通用的,能被多次调用,不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig. sh
Redis缓存穿透和雪崩(面试高频,工作常用)
服务的高可用问题
Redis缓存的使用,极大的提升了应用程序的性能和效率,特别是数据查询方面。但同时,它也带来了-些问题。其中,最要害的问题,就是数据的-致性问题,从严格意义上讲,这个问题无解。如果对数据的一致性要求很高 ,那么就不能使用缓存。
另外的一些典型问题就是,缓存穿透、缓存雪崩和缓存击穿。目前,业界也都有比较流行的解决方案。
缓存穿透(查不到)
概念
缓存穿透的概念很简单,用户想要查询一个数据,发现redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询。发现也没有,于是本次查询失败。
当用户很多的时候,缓存都没有命中(秒杀! ) , 于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力,这时候就相当于出现了缓存穿透。
解决方案
布隆过滤器:
布隆过滤器是一 种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;(通过一种算法结合数据判断其是否有效 无效则丢弃掉)
缓存空对象
当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间 ,之后再访问这个数据将会从缓存中获取,保护了后端数据源;
但是这种方法会存在两个问题:
- 如果空值能够被缓存起来I这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;
- 即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一段时间窗口的不一致,这对于需要保持一致性的业务会有影响。
缓存击穿(查的量太多,缓存过期)
概述
这里需要注意和缓存击穿的区别,缓存击穿,是指一-个key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问 ,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。
当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。
解决方案
设置热点数据永不过期
从缓存层面来看,没有设置过期时间,所以不会出现热点key过期后产生的问题。
加互斥锁
分布式锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。
缓存雪崩
概念
缓存雪崩,是指在某一个时间段 ,缓存集中过期失效。Redis宕机
产生雪崩的原因之一 ,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一个小时。 那么到了凌晨一点钟的时候 ,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。
其实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩,一定是在某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。
双十一:工 停掉一些服务,(保证主要的服务可用! )(服务降级)
解决方案
-
redis高可用
这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis ,这样一台挂掉之 后其他的还可以继续工作,其实就是搭建的集群。(异地多活! ) -
限流降级(在SpringCloud讲解过! )
这个解决方案的思想是,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。 -
数据预热
数据加热的含义就是在正式部署之前,我先把可能的数据先预先访问一遍,这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key ,设置不同的过期时间,让缓存失效的时间点尽量均匀。