关系数据库与非关系型数据库
关系型数据库
关系型数据库是一个结构化的数据库，创建在关系模型（二维表格模型〉基础上，一般面向于记录。SQL语句(标准数据查询语言)就是一种基于关系型数据库的语言，用于执行对关系型数据库中数据的检索和操作。主流的关系型数据库包括oracle、MysQL Server、Microsoft Access、DB2等。
非关系型数据库
NoSQL(NoSQL=NotonlysQL)，意思是"不仅仅是SQL"，是非关系型数据库的总称。除了主流的关系型数据库外的数据库，都认为是非关系型。
主流的NoSQL，数据库有Redis、MongBD、 Hbase、 Memcached等。
关系型数据库和非关系型数据库区别
1，数据存储方式不同
关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的，因此存储在数据表的行和列中。数据表可以彼此关联协作存储，也很容易提取数据。
与其相反，非关系型数据不适合存储在数据表的行和列中，而是大块组合在一起。非关系型数据通常存储在数据集中，就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。
关系型：依赖于关系模型E–R图，同时以表格式的方式存储数据
非关系型：处理以表格形式存储之外，通常会以大块的形式组合在一起存储数据
2，扩展方式不同
SQL和NoSQL数据库最大的差别可能是在扩展方式上，要支持日益增长的需求当然要扩展。
要支持更多并发量，SQL数据库是纵向扩展，也就是说提高处理能力，使用速度更快速的计算机，这样处理相同的数据集就更快了。因为数据存储在关系表中，操作的性能瓶颈可能涉及很多个表，这都需要通过提高计算机性能来克服。虽然SQL数据库有很大扩展空间，但最终肯定会达到纵向扩展的上限。
而NoSQL数据库是横向扩展的。因为非关系型数据存储天然就是分布式的，NoSQL数据库的扩展可以通过给资源池添加更多普通的数据库服务器（节点)来分担负载。
关系型：纵向（天然表格式）
非关系型：横向（天然分布式）
3，对事务的支持不同
如果数据操作需要高事务性或者复杂数据查询需要控制执行计划，那么传统的soL数据库从性能和稳定性方面考虑是最佳选择。sQL数据库支持对事务原子性细粒度控制，并且易于回滚事务。
虽然NosQL数据库也可以使用事务操作，但稳定性方面没法和关系型数据库比较，所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。
关系型：特别适合高事务性要求和需要控制执行计划的任务
非关系型：这里会稍显弱势，主要功能在于高扩展性和大数据量处理方面
非关系型数据库产生背景
主要用于应对Web2.0纯动态网站类型的三高问题
（1）High performance 对数据库高并发读写需求
（2）HugeStorage 对海量数据高效存储与访问需求
（3）High Scalability 与High Availability 对数据库高可扩展性与高可用性需求
数据库记录过程
关系型数据库:
实例->数据库->表(table)->记录行(row)、数据字段(column)
非关系型数据库:
实例->数据库->集合(collection)–>键值对(key-value)
非关系型数据库不需要手动建数据库和集合(表)。
Redis简介
1，Redis是一个开源的，使用C语言编写的非关系型数据库。它基于内存运行并支持持久化，采用key-value的存储形式，是目前分布式架构中不可缺少的一部分。
2，Redis服务器是单进程模型。Redis服务在一台服务器上可以同时启动多进程，其处理速度则是完全依靠主进程的执行效率。若只是运行一个进程，处理能力会有所下降，但运行多个，在遇到高并发情况时，会给CPU造成很大压力。所以，需要根据实际要求来开启进程。
建议开启2个进程
①，起到备份的作用
②，起到抗高并发且同时不给CPU造成太大压力
Redis优点
1，具有极高的数据读写速度
2，支持丰富的数据类型支持
3，支持数据的持久化
4，原子性
5，支持数据备份
Redis安装
1，Redis安装部署
systemctl stop firewalld
setenforce 0
yum install -y gcc gcc-c++ make
#将redis-5.0.7.tar.gz压缩包上传到/opt目录中
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
cd /opt/ redis-5.0.7/utils
./install server.sh
#一直回车
Please select the redis executable path [/usr/local/bin/redis-server]
/usr/local/redis/bin/ redis-server
需要手动修改为/usr/local/redis/bin/redis-server 注意要一次性正确输入
优化启动路径
ln -s /usr/local/redis/bin/* /usr/local/bin/
查看启动成功与否
netstat -natp | grep redis
#Redis服务控制
/etc/init.d/redis_6379 stop #停止
/etc/init.d/redis_6379 start #启动
/etc/init.d/redis_6379 restart #重启
/etc/init.d/redis_6379 status #状态
#修改配置/etc/redis/6379.conf参数
vim /etc/redis/6379.conf
bind 127.0.0.1 192.168.226.129 #70行,添加监听的主机地址
port 6379 #93行，Redis默认的监听端口
daemonize yes #137行，启用守护进程
pidfile /var/run/redis_6379.pid #159行，指定PID文件
loglevel notice #167行，日志级别
logfile /var/log/redis_6379.log #172行，指定日志文件
2，Redis命令工具
redis-server：用于启动Redis的工具
redi s-benchmark：用于检测Redis在本机的运行效率
redis-check-aof:修复AOF持久化文件
redis-check-rdb:修复RDB持久化文件
redis-cli: Redis 命令行工具.
rdb和aof是redis服务中持久化功能的两种形式RDB AOF
redis-cli常用于登陆至redis数据库
3，redis-cli命令行工具(远程登陆
语法: redis-cli -h host -p port -a password
-h:指定远程主机
-p:指定Redis 服务的端口号
-a:指定密码，未设置数据库密码可以省略-a选项
若不添加任何选项表示，则使用127.0.0.1:6379 连接本机上的Redis数据库，
redis-cli -h 192.168.226.70 -p 6379
4，redi s-benchmark 测试工具
redis-benchmark 是官方自带的Redis 性能测试工具，可以有效的测试Redis 服务的性能。
基本的测试语法: redis-benchmark [选项] [选项值]
-h :指定服务器主机名。
-P :指定服务器端口。
-s :指定服务器socket (套接字)
-c :指定并发连接数。
-n :指定请求数。
-d :以字节的形式指定SET/GET 值的数据大小。
-k : 1=keep alive 0=reconnect
-r : SET/GET/INCR使用随机key，SADD使用随机值。
-P :通过管道传输<numreq>请求。
-q :强制退出redis。仅显示query/sec 值。
--csv :以csv格式输出。
-1 :生成循环，永久执行测试。
-t :仅运行以逗号分隔的测试命令列表。
-I : Idle模式。仅打开N个idle连接并等待。
#向IP地址为192.168.226.70、端口为6379的Redis服务器发送100个并发连接与100000个请求测试性能
redis-benchmark -h 192.168.226.129 -p 6379 -c 100 -n 100000
#测试存取大小为100字节的数据包的性能
redis-benchmark -h 192.168.226.129 -p 6379 -q -d 100
#测试本机.上Redis服务在进行set与lpush操作时的性能
redis-benchmark -t set, lpush -n 100000 -q
5，Redis数据库常用命令
set: 存放数据，命令格式为set key value
get: 获取数据，命令格式为get key
127.0.0.1 :6379> set k1 1 #k1为键名，1为值
127.0.0.1:6379> KEYS * #查看当前数据库中所有键
127.0.0.1:6379> KEYS v* #查看当前数据库中以v开头的数据
127.0.0.1:6379> KEYS v? #查看库中以v开头后面包含任意一位的数据
127.0.0.1:6379> exists wj #判断wj键是否存在
127.0.0.1:6379> exists wu #返回为0不存在
127.0.0.1:6379> del wj #删除当前键
127.0.0.1:6379> type lrr #查看lrr的对应value类型
127.0.0.1:6379> rename wmm lrr #重命名，但会对已有键的值进行覆盖，已有键也会消失
127.0.0.1:6379> renamenx wmm lrr #会先判断旧键是否有再改名
127.0.0.1:6379> dbsize #查看当前库中有多少键
127.0.0.1:6379> select 10 #Redis中有0-15共16个库，切换库
127 .0.0.1:6379> move lrr 1 #将当期库中的lrr键，移到1号库中。
Redis高可用
在Redis中，实现高可用的技术主要包括持久性，主从复制，哨兵和集群。
1，持久化
持久化是最简单的高可用方法，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
2，主从复制
主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。
主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
缺陷:故障恢复无法自动化；写操作无法负载均衡;存储能力受到单机的限制。
3，哨兵:在主从复制的基础上，哨兵实现了自动化的故障恢复。
缺陷:写操作无法负载均衡;存储能力受到单机的限制。
4，集群:通过集群
Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
持久化
原因：Redis是一个内存数据库，其数据会存储在内存中，在断电等服务器断掉时，其数据便会大量丢失。为了文件的保存，需要定期将内存中的数据保存下来。在Redis重启时，再将保存下来的文件进行读取。来恢复丢失的数据。
RDB
RDB持久化：简单来说就是将内存中的数据每隔一段时间就备份到磁盘中，起到保存数据的作用。类似于快照。
手动：save，bgsave。
save：在备份时会阻塞整个Redis进程，导致不能接受任何请求，在完成备份后才能接收其他请求
bgsave：执行bgsave后，父进程会先判断有没有save或bgsave进程运行，没有的话，会fock出一个子进程来备份。但父进程在fork子进程时会形成阻塞，期间Redis不会接收其他请求，fork完子进程后，Redis会恢复请求。fork的子进程会进行快照式的备份
自动：自动会使用bgsave来备份。通过配置文件vim /etc/redis/6379.conf来完成自动备份
AOF持久化：进行的是实时保存，将Redis的操作以追加的方式保存在文件中，类似于MySQL中二进制文件。
与RDB相比，RDB是将一段时间的Redis进程进行备份，而AOF则是实时的将Redis的一些操作保存在文件中。AOF只对操作进行备份，包括增删改，查询则不会。在Redis重启时，会读取文件，将这些操作进行重写。
AOF的执行流程
文件追加：将文件写入到缓冲区aof_buf中
文件写入与文件同步：根据不同的同步策略将缓冲区中的操作写入磁盘
文件重写：定期的重写文件，一些写入和删除的命令，会让文件的整体性不变，重写删除这些命令，达到压缩文件的目的。
文件追加：Redis的操作在写入文件时，并不是直接写入磁盘中。如果每一个操作都写入一次，会导致磁盘的读写负载过大。
文件重写：文件重写时并不会对原文件操作，而是对Redis进程进行操作。
启动时加载
在Redis挂掉重启时
如果AOF开启，那么会首先读取AOF文件，用AOF文件来进行持久化恢复
只有在AOF关闭时，才会使用RDB文件进行数据恢复
AOF没有开启，但是有AOF文件时。也不会应用RDB文件来进行持久化恢复，即使RDB文件存在
Redis在用AOF文件恢复时
如果文件损坏，则日志中会打印错误，Redis启动失败。
但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load-truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。
RDB与AOF优缺点
(一)、RDB持久化
优点: RDB文件紧凑，体积小，网络传输快，适合全量复制;恢复速度比AOF快很多。当然，与AOF相比,RDB最重要的优点之一是 对性能的影响相对较小。
缺点:RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受。
对于RDB持久化，一方 面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来I0压力。
(二)、AOF持久化
AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。
对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略下为秒级)，I0压力更大，甚至可能造成AOF追加阻塞问题。
AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的I0压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此对Redis主进程性能的影响会更大
Redis的性能管理
1，内存使用情况
127.0.0.1:6379> info memory
2，内存碎片化
操作系统分配的内存值used_memory_rss除以Redis使用的内存值used_momoey计算得来。
内存稍碎片率大于1是合理的，表示内存碎片率比较低
内存碎片率大于1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率。
需要通过redis-cli 工具输入shutdown save命令，重启Redis服务器
内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加物理内存或减少Redis内存占用<
3，内存使用率
redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换。
避免内存交换发生的方法：
针对缓存数据大小选择安装 Redis 实例
尽可能的使用Hash数据结构存储
设置key的过期时间
4，内回收key
保证合理分配redis有限的内存资源。
当达到设置的最大阀值时，需选择一种key的回收策略，默认情况下回收策略是禁止删除。
配置文件中修改maxmemory-policy属性值:
vim /etc/ redis/6379. conf
--598 --
maxmemory-policy noenviction
●volatile-lru:使用LRU算法从已设置过期时间的数据集合中淘汰数据
●volatile-ttl:从已设置过期时间的数据集合中挑选即将过期的数据淘汰
●volatile-random:从已设置过期时间的数据集合中随机挑选数据淘汰
●allkeys-lru:使用LRU算法从所有数据集合中淘汰数据
●allkeys-random:从数据集合中任意选择数据淘汰
●noenviction:禁止淘汰数据
总结
1，Redis是一种非关系型数据库（内存/缓存）
2，Redis强于其他非关系型数据库在于
①，所支持的数据类型丰富
②，具有持久化特性，可以将内存中的数据保存在磁盘中。
3，Redis的高可用
①，主从：提供备份冗余，对读操作的负载均衡，但无法针对故障进行自动修复，写操作无法负载均衡
②，哨兵：以主从为基础，提供了故障自动修复的功能，但写操作还是无法负载均衡
③，集群：基于主从基础，解决了故障自动修复的功能，以及写操作负载均衡的问题。对比前两种有一些改善。
高可用之持久化
RDB与AOF
（1）持久化方式
RDB：周期性的对Redis进程快照式的备份
AOF：以接近实时性的方式对Redis操作进行类似MySQL二进制文件的方式进行保存。
（2）Redis恢复文件时的优先级
AOF>RDB，只有在AOF关闭时才会使用RDB文件恢复数据，即使AOF开启，但没有AOF文件，也不会使用RDB方式恢复。
（3）RDB与AOF的持久化过程
RDB
会有Redis主进程周期性fork派生出子进程来对Redis内存中的数据进行备份，生成到.rdb文件中。在父进程fork子进程的时间里，Redis是不会对外响应请求的。
AOF
根据持久化策略，先将Redis中的语句保存在缓冲区中，再从缓冲区同步到.aof文件中。
redis恢复策略的优势
Redis可以将内存中的数据通过RDB或AOF的持久化功能保存在磁盘中，这样，当Redis重启后，内存中的数据虽会丢失，但还可以从磁盘中的AOF文件中恢复。相比于其他类型的非关系型数据库，可以来持久化保存数据。
347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
