NoSQL：即 Not-Only SQL（ 泛指非关系型的数据库），作为关系型数据库的补充。
作用：应对基于海量用户和海量数据前提下的数据处理问题。
特征：
⚫ 可扩容，可伸缩
⚫ 大数据量下高性能
⚫ 灵活的数据模型
⚫ 高可用
常见 Nosql 数据库：
⚫ Redis
⚫ memcache
⚫ HBase
⚫ MongoDB
概念：Redis (REmote DIctionary Server 远程字典服务) 是用 C 语言开发的一个开源的高性能键值对（key-value）数据库。
特征：
数据间没有必然的关联关系
内部采用单线程机制进行工作
高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
多数据类型支持
◆ 字符串类型 string
◆ 列表类型 list
◆ 散列类型 hash
◆ 集合类型 set
◆ 有序集合类型 zset/sorted_set
支持持久化，可以进行数据灾难恢复
⚫ 为热点数据加速查询（主要场景），如热点商品、热点新闻、热点资讯、推广类等高访问量信息等
⚫ 即时信息查询，如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等
⚫ 时效性信息控制，如验证码控制、投票控制等
⚫ 分布式数据共享，如分布式集群架构中的 session 分离
⚫ 消息队列(逐渐被取代)
1.设置数据
set key value2.获取数据
get key3.帮助命令
help ⚫ redis 自身是一个 Map，其中所有的数据都是采用 key : value 的形式存储
⚫ 数据类型指的是存储的数据的类型，也就是 value 部分的类型，key 部分永远都是字符串
⚫ 添加/修改数据
set key value ⚫ 获取数据
get key ⚫ 删除数据
del key ⚫ 判定性添加数据
setnx key value ⚫ 添加/修改多个数据
mset key1 value1 key2 value2 … ⚫ 获取多个数据
mget key1 key2 … ⚫ 获取数据字符个数（字符串长度）
strlen key ⚫ 追加信息到原始信息后部（如果原始信息存在就追加，否则新建）
append key value ⚫ 设置数值数据增加指定范围的值
incr key incrby key increment incrbyfloat key increment ⚫ 设置数值数据减少指定范围的值
decr key decrby key increment ⚫ 设置数据具有指定的生命周期
setex key seconds value (seconds设置保存数据的秒数) psetex key milliseconds value (milliseconds设置保存数据的秒数)redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响
⚫ 数据库中的热点数据key命名惯例
表名 : 主键名 : 主键值 : 字段名
例order:oid : 99 : name
⚫ 添加/修改数据
hset key field value ⚫ 获取数据
hget key field hgetall key ⚫ 删除数据
hdel key field1 [field2] ⚫ 设置field的值，如果该field存在则不做任何操作
hsetnx key field value ⚫ 添加/修改多个数据
hmset key field1 value1 field2 value2 … ⚫ 获取多个数据
hmget key field1 field2 … ⚫ 获取哈希表中字段的数量
hlen key ⚫ 获取哈希表中是否存在指定的字段
hexists key field ⚫ 获取哈希表中所有的字段名或字段值
hkeys key hvals key ⚫ 设置指定字段的数值数据增加指定范围的值
hincrby key field increment hincrbyfloat key field incrementhash类型中value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）
每个 hash 可以存储 2^32 - 1 个键值对
hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计的 ，切记不可滥用，更不可以将hash作为对象列表使用
hgetall 操作可以获取全部属性，如果内部field过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈
⚫ 数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
⚫ 需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
⚫ list类型：保存多个数据，底层使用双向链表存储结构实现
⚫ 添加/修改数据
lpush key value1 [value2] …… rpush key value1 [value2] …… ⚫ 获取数据
lrange key start stop lindex key index llen key ⚫ 获取并移除数据
lpop key rpop key ⚫ 遍历集合的方法
lrange key 0 -1 ⚫ 移除指定数据
lrem key count value ⚫ 规定时间内获取并移除数据
blpop key1 [key2] timeout brpop key1 [key2] timeout brpoplpush source destination timeoutlist中保存的数据都是string类型的，数据总容量是有限的，最多2^32 - 1 个元素 (4294967295)。
list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
获取全部数据操作结束索引设置为-1
list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载
⚫ 新的存储需求：存储大量的数据，在查询方面提供更高的效率
⚫ 需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
⚫ set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的
⚫ 添加数据
sadd key member1 [member2] ⚫ 获取全部数据
smembers key ⚫ 删除数据
srem key member1 [member2] ⚫ 获取集合数据总量
scard key ⚫ 判断集合中是否包含指定数据
sismember key member ⚫ 随机获取集合中指定数量的数据
srandmember key [count] ⚫ 随机获取集合中的某个数据并将该数据移出集合
spop key [count] ⚫ 求两个集合的交、并、差集
sinter key1 [key2 …] sunion key1 [key2 …] sdiff key1 [key2 …] ⚫ 求两个集合的交、并、差集并存储到指定集合中
sinterstore destination key1 [key2 …] sunionstore destination key1 [key2 …] sdiffstore destination key1 [key2 …] ⚫ 将指定数据从原始集合中移动到目标集合中
smove source destination member ⚫ 求两个集合的交、并、差集
sinter key1 [key2 …] sunion key1 [key2 …] sdiff key1 [key2 …] ⚫ 求两个集合的交、并、差集并存储到指定集合中
sinterstore destination key1 [key2 …] sunionstore destination key1 [key2 …] sdiffstore destination key1 [key2 …] ⚫ 将指定数据从原始集合中移动到目标集合中
smove source destination member ⚫ set 类型不允许数据重复，如果添加的数据在 set 中已经存在，将只保留一份
⚫ set 虽然与hash的存储结构相同，但是无法启用hash中存储值的空间
⚫ 删除指定key
del key⚫ 获取key是否存在
exists key⚫ 获取key的类型
type key⚫ 排序
sort⚫ 改名
rename key newkey renamenx key newkey⚫ 为指定key设置有效期
expire key seconds pexpire key milliseconds expireat key timestamp pexpireat key milliseconds-timestamp⚫ 获取key的有效时间
ttl key (返回结果为-1,代表永久有效; 为-2,代表已经失效了) pttl key⚫ 切换key从时效性转换为永久性
persist key⚫ 查询key
keys pattern 查询模式规则 * 匹配任意数量的任意符号 ? 配合一个任意符号 [] 匹配一个指定符号 keys * 查询所有 keys it* 查询所有以it开头 keys *heima 查询所有以heima结尾 keys ??heima 查询所有前面两个字符任意，后面以heima结尾 keys user:? 查询所有以user:开头，最后一个字符任意 keys u[st]er:1 查询所有以u开头，以er:1结尾，中间包含一个字母，s或t⚫ 切换数据库
select index⚫ 其他操作
ping⚫ 数据移动
move key db⚫ 数据总量
dbsize⚫ 数据清除
flushdb flushallkey 的重复问题
⚫ key是由程序员定义的
⚫ redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key
⚫ 数据不区分种类、类别混杂在一起，极易出现重复或冲突
解决方案
⚫ redis为每个服务提供有16个数据库，编号从0到15
⚫ 每个数据库之间的数据相互独立
⚫ 连接redis
Jedis jedis = new Jedis("localhost", 6379);⚫ 操作redis
jedis.set("name", "zhangsan"); jedis.get("name");⚫ 关闭redis连接
jedis.close();定义 : 利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化
目的 : 防止数据丢失对数据进行备份
方式 :
RDB : 数据(快照),保存数据AOF : 过程(日志),保存操作 ⚫ 手动执行一次保存操作
save**注意：**如果在执行save指令时是存储的大量数据 , save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。
⚫ 手动启动后台保存操作，但不是立即执行
bgsave注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用**。**
⚫ 设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化
save second changes ⚫ 参数
second：监控时间范围
changes：监控key的变化量
⚫ 范例
save 900 1 save 300 10 save 60 10000注意： save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的 . save配置启动后执行的是bgsave操作
⚫ RDB是一个紧凑压缩的二进制文件，存储效率较高
⚫ RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
⚫ RDB恢复数据的速度要比AOF快很多
⚫ 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。
⚫ RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
⚫ bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
⚫ Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象
⚫ 存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
⚫ 大数据量下的IO性能较低
⚫ 基于fork创建子进程，内存产生额外消耗
⚫ 宕机带来的数据丢失风险
⚫ 不写全数据，仅记录部分数据
⚫ 降低区分数据是否改变的难度，改记录数据为记录操作过程
⚫ 对所有操作均进行记录，排除丢失数据的风险
记录操作日志,恢复时直接重新执行一遍用户的操作来恢复数据.
⚫ AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令
达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
⚫ AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
⚫ 开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no ⚫ AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename ⚫ AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir ⚫ AOF写数据策略，默认为everysec
appendfsync always|everysec|no ⚫ always(每次）：每次写入操作均同步到AOF文件中
数据零误差，性能较低，不建议使用。
⚫ everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据
数据准确性较高，性能较高，建议使用，也是默认配置
⚫ no（系统控制）：由操作系统控制每次同步到AOF文件的周期
整体过程不可控
⚫ 降低磁盘占用量，提高磁盘利用率
⚫ 提高持久化效率，降低持久化写时间，提高IO性能
⚫ 降低数据恢复用时，提高数据恢复效率
⚫ 手动重写
bgrewriteaof⚫ 自动重写
auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percentage⚫ 对数据非常敏感，建议使用默认的AOF持久化方案
⚫ AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
⚫ 注意：由于AOF文件存储体积较大，且恢复速度较慢
⚫ 数据呈现阶段有效性，建议使用RDB持久化方案
⚫ 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
⚫ 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
⚫ 综合比对
⚫ RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
⚫ 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
⚫ 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
⚫ 灾难恢复选用RDB
⚫ 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量
