Redis-day1

NoSQL = Not only SQL 泛指非关系型的数据库，这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展

什么是BSON：

BSON是一种类json的一种二进制形式的存储格式，简称Binary JSON,它和JSON一样，支持内嵌的文档对象和数组对象

高并发的操作是不太建议有关联查询的，互联网公司用冗余数据来避免关联查询。
分布式事务是支持不了太多并发的

NoSQL数据库的四大分类：

1.KV键值：
2.文档型数据库(bson格式比较多)：典型介绍
3.列存储数据库
4.图关系数据库：它不是放图形的，放的是关系 Neo4J,InfoGrid

CAP原理：

C：Consistency 强一致性
A：Availability 可用性
P：Partition tolerance 分区容错性

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求

CAP的3进2：最多只能满足两个。

根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些

分区容忍性是我们必须要实现的。

CA 传统Oracle数据库
AP 大多数网站架构的选择
CP Redis、Mongodb

一致性和可用性的抉择：

数据库事务的一致性需求：
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高，允许实现最终一致性

数据库的写实时性和读实时性需求：

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。

对复杂的SQL查询，特别是多表关联查询的需求：
任何大数据量的WEB系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案

BASE：

基本可用（Basically Available）
软状态（Soft state）
最终一致（Eventually consistent）

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。

分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rml之间通信和调用，对外提高服务和组内协作。

集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问

Redis:REmote DIctionary Server（远程字典服务器）

Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
Redis不仅仅支持简单的key-value类型的数据，同时还提供List,set,zset,hash等数据结构的存储
Redis支持数据的备份，即master-slave模式的数据备份

Redis能干嘛：
内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务取最新N个数据的操作

set k1 v1 设定值
get k1 获取
select 切换数据库
FLUSHALL 删除所有库的数据

redis的索引都是从零开始

启动redis

#redis-server /mybatis/redis.conf
#redis-cli -p 6379
默认端口是6379

Redis常用的五大类型：
1.String 字符串
string是redis最基本的类型，一个Key对应一个value String类型是二进制安全的，意思是可以包含任何数据

2.Hash 类似java中的Map<String,Object>
Redis hash 是一个键值对集合，是一个string类型的filed和value的映射表，特别适合用于存储对象

3.List
Redis 列表是简单的字符串列表，按照插入顺序排序，可以添加一个元素到列表的头部或者尾部
底层实际上是链表

4.Set
Redis的set是string类型的无序集合。它是通过HashTable实现的

5.Zset(sorted set) 有序集合
Redis zset 和 Set 一样也是string类型元素的集合，且不允许重复的成员
不同的是每一个元素都会关联一个double类型的分数
redis正是通过分数来为集合中的成员进行从小到大的排序，zset的成员是唯一的，但分数都可以重复

Key:
keys * 查看所有的key
exists [key] 判断某个key是否存在
move key db 移动Key从当前库到另一个库
ttl key 查看还要多久过期，-1表示永不过期，-2表示已经过期
type key 查看你的key是什么类型

string：
set/get/del/append 如果 key 已经存在并且是一个字符串， APPEND 命令将指定的 value 追加到该 key 原来值（value）的末尾
strlen 返回 key 所储存的字符串值的长度。
Incr/decr将 key中的数字值增一或者减一 incrby/decrby 将 key 所储存的值加上或减去给定的增量值一定要是数字才能进行加减
getrange 返回 key 中字符串值的子字符
setrange 用 value 参数覆写给定 key 所储存的字符串值，从偏移量 offset 开始。
setex(set with expire)键秒值 将值 value 关联到 key ，并将 key 的过期时间设为 seconds (以秒为单位)。
setnx(set if not exist) 只有在 key 不存在时设置 key 的值。
mset 同时设置一个或多个 key-value 对。
mget 获取所有(一个或多个)给定 key 的值
msetnx 同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。
getset(先get再set) 将给定 key 的值设为 value ，并返回 key 的旧值(old value)。

List 单值多value

性能总结：

它是一个字符串链表，left、right都可以插入添加；
如果键不存在，创建新的链表；
如果键已存在，新增内容；
如果值全移除，对应的键也就消失了。
链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。

Set

Hash KV模式不变，但V是一个键值对

Zset

配置文件

Units 单位
配置大小单位，开头定义了一些基本的度量单位，只支持bytes,不支持Bit
对大小写不敏感

持久化之RDB：

Redis会单独创建（Fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了最高的性能。如果需要进行大规模的数据恢复，且对子数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork 的作用是复制一个与当前进程一样的进程，新的进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

rdb 保存的是dump.rdb文件
相关配置在配置文件的位置 - 在redis.conf搜寻### SNAPSHOTTING ###

如何触发RDB快照：

配置文件中默认的快照配置dbfilename dump.rdb
冷拷贝后重新使用
可以cp dump.rdb dump_new.rdb

命令save或者是bgsave
Save：save时只管保存，其它不管，全部阻塞
BGSAVE：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

SNAPSHOTTING快照：

save [秒数] [ 操作次数 ]

如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以

stop-writes-on-bgsave-error 如果配置成no 表示不在乎数据不一致或者有其他的手段发现和控制

rdbcompression 对于存储到磁盘中的快照，可以设置是否进行压缩存储，如果是的话，redis会采用LZF算法进行压缩，如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

rdbchecksum:在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望读取到最大的性能提升，可以关闭此功能

如何触发RDB快照：

1.配置文件中默认的快照配置
2.命令save或者是bgsave
save只管保存，其他不管，全部阻塞
bgsave redis会在后台异步进行快照操作。快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间
3.执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

如何恢复：

将备份文件(dump.rdb)移动到redis安装目录并启动服务即可
CONFIG GET dir 获取目录

优势：

适合大规模的数据恢复
对数据完整性和一致性要求不高

劣势：

在一定间隔时间内做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
Fork的时候，内存中的数据克隆了一份，大致2倍的膨胀性需要考虑

如何停止：

动态所有停止RDB保存的方法：redis-cli ocnfig set save “”

持久化之AOF：

是什么？
以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF保存的是appendonly.aof文件

Appendfsync:
Always:同步持久化，每次发生数据变更就会被立即记录到磁盘，性能较差但数据完整性较好
Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失
appendfsync no ：从不同步

No-appendfsync-on-rewrite:重写时是否可以运用Appendfsync,用默认no即可，保证数据安全性
Auto-aof-rewrite-min-size:设置重写的基准值
Auto-aof-rewrite-percentage：设置重写的基准值

AOF启动 设置yes
修复 Redis-check-aof–fix进行修复
恢复 重启redis然后重新加载

AOF Rewrite

AOF采用文件追加方式，文件会越来越大，为了避免出现此情况，新增了重写机制，当AOF文件的大小超过所设定的阙值时，Redis就会启动AOF文件的内容压缩：只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

重写原理：
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename）遍历新进程的内容中数据，每条记录有一条的Set语句，重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

触发机制：
Redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64M时触发

auto-aof-rewrite-min-size 64M

劣势：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度大于rdb
aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重写执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，redis还能对aof文件进行后台重写，使得aof文件的体积不至于过大

只做缓存:如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式

同时开启两种持久化方式：
在这种情况下，当redis重启的时候会优先载入aof文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，建议不要只使用aof，因为rdb更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug,留着作为一个万一的手段。

性能建议：

因为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 Replication 实现高可用性也可以，能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个