一、关系型数据库和NoSQL数据库
1.1数据库主要分为两大类:关系型数据库与NoSQL****数据库
关系型数据库 ,是建立在关系模型基础上的数据库,其借助于集合代数等数学概念和方法来处理数据库中的数据主流的 MySQL 、 Oracle 、 MS SQL Server 和 DB2 都属于这类传统数据库。
NoSQL****数据库,全称为 Not Only SQL,意思就是适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。主要分为临时性键值存储(memcached、Redis)、永久性键值存储(ROMA、Redis)、面向文档的数据库(MongoDB、CouchDB)、面向列的数据库(Cassandra、HBase),每种 NoSQL 都有其特有的使用场景及优点。
1.2为什么还要用NoSQL****数据库呢?
主要是由于随着互联网发展,数据量越来越大,对性能要求越来越高,传统数据库存在着先天性的缺陷,即单机(单库)性能瓶颈,并且扩展困难。这样既有单机单库瓶颈,却又扩展困难,自然无法满足日益增长的海量数据存储及其性能要求,所以才会出现了各种不同的 NoSQL 产品, NoSQL 根本性的优势在于在云计算时代,简单、易于大规模分布式扩展,并且读写性能非常高
1.3 RDBMS和NOSQL****的特点及优缺点:
二、Remote Dictionary Server简介
2.1什么是redis
Redis (Remote Dictionary Server)
在 2009 年发布,开发者是意大利的萨尔瓦多 · 桑菲利波普( Salvatore Sanfilippo ),他本想为自己的公司开发一个用于替换MySQL 的产品 Redis ,但是没有想到他把 Redis 开源后大受欢迎,短短几年, Redis 就有了很大的用户群体,目前国内外使用的公司众多, 比如 : 阿里 , 百度 , 新浪微博 , 知乎网 ,GitHub,Twitter 等
Redis 是一个开源的、遵循 BSD 协议的、基于内存的而且目前比较流行的键值数据库 (key-value database),是一个非关系型数据库, redis 提供将内存通过网络远程共享的一种服务,提供类似功能的还有memcached ,但相比 memcached , redis 还提供了易扩展、高性能、具备数据持久性等功能。
Redis 在高并发、低延迟环境要求比较高的环境使用量非常广泛
2.2 Redis****特性
- 速度快: 10W QPS,基于内存,C语言实现
- 单线程
- 持久化
- 支持多种数据结构
- 支持多种编程语言
- 功能丰富: 支持Lua脚本,发布订阅,事务,pipeline等功能
- 简单: 代码短小精悍(单机核心代码只有23000行左右),单线程开发容易,不依赖外部库,使用简单
- 主从复制
- 支持高可用和分布式
单线程为何如此快 ?
- 纯内存
- 非阻塞
- 避免线程切换和竞态消耗
2.3 Redis****应用场景
- Session 共享:常见于web集群中的Tomcat或者PHP中多web服务器session共享
- 缓存:数据查询、电商网站商品信息、新闻内容
- 计数器:访问排行榜、商品浏览数等和次数相关的数值统计场景
- 微博/微信社交场合:共同好友,粉丝数,关注,点赞评论等
- 消息队列:ELK的日志缓存、部分业务的订阅发布系统
- 地理位置: 基于GEO(地理信息定位),实现摇一摇,附近的人,外卖等功能
2.4****缓存的实现流程
数据更新操作流程
数据读操作流程
三、Redis的安装
3.1 源码安装
导入压缩包,解压
下载编译软件
编译
启动Redis
文件内
配置redis
四、Redis的基本操作
五、Redis主从复制
5.1****环境配置
redis-node1 master
redis-node2 slave
redis-node3 slave
5.2****配置主从同步
5.2.1.修改mastser****节点的配置文件
5.2.2.配置slave****节点(2/3都要)
**5.2.3.**测试效果
在mastser节点
在slave节点查看
5.3****主从同步过程
slave节点发送同步亲求到master节点
slave节点通过master节点的认证开始进行同步
master节点会开启bgsave进程发送内存rbd到slave节点,在此过程中是异步操作,也就是说master节点仍然可以进行写入动作
slave节点收到rdb后首先清空自己的所有数据
slave节点加载rdb并进行数据恢复
在master和slave同步过程中master还会开启新的bgsave进程把没有同步的数据进行缓存
然后通过自有的replactionfeedslave函数把未通过内存快照发动到slave的数据一条一条写入到slave中
六、Redis的哨兵(高可用)
实验环境:我们用主两从来实现Redis的高可用架构
6.1 Redis****哨兵
Sentinel 进程是用于监控 redis 集群中 Master 主服务器工作的状态,在 Master 主服务器发生故障的时候,可以实现Master 和 Slave 服务器的切换,保证系统的高可用,此功能在 redis2.6+ 的版本已引用, Redis 的哨兵模式到了2.8 版本之后就稳定了下来。一般在生产环境也建议使用 Redis 的 2.8 版本的以后版本
每个哨兵 (Sentinel) 进程会向其它哨兵 (Sentinel) 、 Master 、 Slave 定时发送消息,以确认对方是否 " 活 "着,如果发现对方在指定配置时间( 此项可配置 ) 内未得到回应,则暂时认为对方已离线,就是所谓的 "主观认为宕机" ( 主观 : 是每个成员都具有的独自的而且可能相同也可能不同的意识 ) ,英文名称:Subjective Down,简称 SDOWN
有主观宕机,对应的有客观宕机。当 " 哨兵群 " 中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的 Master Server 下线判断,这种方式就是" 客观宕机 "( 客观 : 是不依赖于某种意识而已经实际存在的一切事物 ) ,英文名称是:Objectively Down, 简称 ODOWN
通过一定的 vote 算法,从剩下的 slave 从服务器节点中,选一台提升为 Master 服务器节点,然后自动修改相关配置,并开启故障转移(failover )
Sentinel 机制可以解决 master 和 slave 角色的自动切换问题,但单个 Master 的性能瓶颈问题无法解决 , 类似于MySQL 中的 MHA 功能
Redis Sentinel 中的 Sentinel 节点个数应该为大于等于 3 且最好为奇数
sentinel 中的三个定时任务
- 每10秒每个sentinel对master和slave执行info
- 发现slave节点
- 确认主从关系
- 每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
- 通过sentinel__:hello频道交互
- 交互对节点的"看法"和自身信息
- 每1秒每个sentinel对其他sentinel和redis执行pi
6.2****哨兵的实验过程
在所有阶段中关闭 protected-mode no
6.2.1.在master节点中
protected-mode no #关闭保护模式 port 26379 #监听端口 daemonize no #进入不打如后台 pidfile /var/run/redis-sentinel.pid #sentinel进程pid文件 loglevel notice #日志级别 sentinel monitor mymaster 172.25.254.100 6379 2 #创建sentinel监控监控master主机,2表示必须得到2票 sentinel down-after-milliseconds mymaster 10000 #master中断时长,10秒连不上视为 master下线 sentinel parallel-syncs mymaster 1 #发生故障转移后,同时开始同步新master数据的slave数量 sentinel failover-timeout mymaster 180000 #整个故障切换的超时时间为3分钟
6.2.2 启动服务
**6.3.**在整个架构中可能会出现的问题
问题:
在生产环境中如果 master 和 slave 中的网络出现故障,由于哨兵的存在会把 master 提出去
当网络恢复后, master 发现环境发生改变, master 就会把自己的身份转换成 slave
master 变成 slave 后会把网络故障那段时间写入自己中的数据清掉,这样数据就丢失了。
解决:
master 在被写入数据时会持续连接 slave , mater 确保有 2 个 slave 可以写入我才允许写入
如果 slave 数量少于 2 个便拒绝写入
在matster中设定
七、Redis Cluster(无中心化设计)
7.1 Redis Cluster****工作原理
在哨兵 sentinel 机制中,可以解决 redis 高可用问题,即当 master 故障后可以自动将 slave 提升为 master ,从而可以保证redis 服务的正常使用,但是无法解决 redis 单机写入的瓶颈问题,即单机 redis 写入性能受限于单机的内存大小、并发数量、网卡速率等因素。
redis 3.0 版本之后推出了无中心架构的 redis cluster 机制,在无中心的 redis 集群当中,其每个节点保存当前节点数据和整个集群状态, 每个节点都和其他所有节点连接
Redis Cluster 特点如下
- 所有Redis节点使用(PING机制)互联
- 集群中某个节点的是否失效,是由整个集群中超过半数的节点监测都失效,才能算真正的失效
- 客户端不需要proxy即可直接连接redis,应用程序中需要配置有全部的redis服务器IP
- redis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上,读写需要到指定的redis node上进行操作,因此有多少个redis node相当于redis 并发扩展了多少倍,每个redis node 承担16384/N个槽位
- Redis cluster预先分配16384个(slot)槽位,当需要在redis集群中写入一个key -value的时候,会使用CRC16(key) mod 16384之后的值,决定将key写入值哪一个槽位从而决定写入哪一个Redis节点上,从而有效解决单机瓶颈。
Redis cluster 架构
假如三个主节点分别是: A, B, C 三个节点,采用哈希槽 (hash slot) 的方式来分配 16384 个 slot 的话它们三个节点分别承担的slot 区间可以是:
节点A覆盖 0-5460 节点B覆盖 5461-10922 节点C覆盖 10923-16383
Redis cluster 主从架构
Redis cluster 的架构虽然解决了并发的问题,但是又引入了一个新的问题,每个 Redis master 的高可用如何解决?
那就是对每个 master 节点都实现主从复制 , 从而实现 redis 高可用性
Redis Cluster 部署架构说明
7.2创建redis cluster****的前提
每个redis node节点采用相同的硬件配置、相同的密码、相同的redis版本。
每个节点必须开启的参数
cluster-enabled yes #必须开启集群状态,开启后redis进程会有cluster显示
cluster-config-file nodes-6380.conf #此文件有redis cluster集群自动创建和维护,不需要任何手动操作所有redis服务器必须没有任何数据
先启动为单机redis且没有任何key value
7.3部署redis cluster
在所有 redis 主机中
vim /etc/redis/redis.conf masterauth "123456" requirepass "123456" cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000
启动
systemctl restart redis.service
进入认证
将文件复制到其他主机上
然后启动
7.4 创建****redis-cluster
7.4.1配置集群cluster
设置主和从
检测redis集群状态
集群info
7.5****集群扩容
四主四从
添加master
redis-cli -a 123456 --cluster add-node 172.25.254.40:6379 172.25.254.10:6379
分配槽位
redis-cli -a 123456 --cluster reshard 172.25.254.10:6379
添加salve
redis-cli -a 123456 --cluster add-node 172.25.254.140:6379 172.25.254.10:6379 --cluster-slave --cluster-master-id 009571cb206a89afa6658b60b2d403136056ac09
结果
7.6 clsuter集群维护点我去使用流量券~
添加节点的时候是先添加 node 节点到集群,然后分配槽位,删除节点的操作与添加节点的操作正好相反,是先将被删除的Redis node 上的槽位迁移到集群中的其他 Redis node 节点上,然后再将其删除,如果一个Redis node 节点上的槽位没有被完全迁移,删除该 node 的时候会提示有数据且无法删除。
删除master
redis-cli -a 123456 --cluster del-node 172.25.254.120:6379 d458f34fa900d83212c021dc1e65396e490b5495 redis-cli -a 123456 --cluster del-node 172.25.254.120:6379 d458f34fa900d83212c021dc1e65396e490b5495
移除要下线主机的哈希槽位
redis-cli -a 123456 --cluster reshard 172.25.254.20:6379