Redis第二天

复习{
redis:
是非关系型数据库: No Sql not Only Sql
redis 功能 注册中心，消息中间件，缓存， 数据库 …
redis是基于内存的一个 存储系统，会定期的向文件中做持久化操作
学习redis， 学的是数据类型;
11万/s ，写 8万/s
string ,lists,hash , set, sorted set

1.redis的性能检测:
./redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 10000
-c 100并发线程
-n 10000请求

redis 默认16个数据库  从0 - 15  
 
keys * 查看当前数据库中的所有key 
flushdb sync 清除当前数据库
flushall 清除所有
del key 删除指定的键
dbsize 返回当前数据库的 元素个数
shutdown save

string:
set key value
get key
mset key value key value
mget key key key
getset key a b
append key value
incr key
incrby key 3
decr key
decrby key 4
*** setex key value 3 设置过期时间
setnx key value 没有创建， 有不做任何操作
strlen key 返回 字符串长度

list: 列表
lpush key value value value
lpop key 查看并删除列表的第一个元素
blpop key
lrange key 0 -1 获取列表中指定区间的值
llen 返回列表长度
rpush

hash: 哈希表 适用于存储对象
hset key field name admin age 23
hget key
hmset field name amdin age 23
hmget key field
hkeys key 返回所有的键
hvals key 返回所有的值
hgetall 查询所有
hdel key field 删除key中的指定属性
hlen key 返回当前哈希的个数

sort:
sadd 添加
smembers 查看
scard 查看个数
sdiff 查看两个集合的 不同以 第一个为主
sinter 查看两个集合的交集
sismemeber 判断这个元素是否是存在
srem 删除指定key中的元素

zsort:
zadd key score value score value:
zrange key 0 -1
zrem 删除
zcount key 1 3返回集合的个数
zcard key 返回集合的元素
zscore 查看所有的分
}

redis的事务:
数据库事务: 特性 ACID
原子性: 事务是最小的执行单位，不可在分
一致性: 主表和从表的关系， 主表的主键字段修改，从表的外键字段必须修改
隔离性: 事务和事务之间执行时，相互不干扰，具有互斥性
mysql有四个隔离级别:
1.read uncommited 读未提交数据
2.read commited 读已提交数据 oracle
3.repeatable read 可重复读 默认
4.serializable 串行化

隔离问题: 
	1.脏读  	  
	2.不可重复读  体现的是update
	3.幻读  体现的是insert 事务A 

mysql的锁: 
	悲观锁: 认为 mysql每次执行sql语句时，他就会任务你会出现问题
			  select * from user for update;
			 
	乐观锁: 认为 mysql每次执行sql语句 时，都不会出现问题
		     version 版本号， 
			 timestamp 时间戳
		  
持久性: 事务一旦commit 永久有效 ， 不可回滚

redis:
特点呢: 单挑redis命令具备原子性， 但是redis的事务不具备原子性；

redis: 的事务操作其实 就是 入队 set 列表

 顺序性，一次性 ，互斥性

multi 开启事务
  
   入队
   
exec 执行事务   

discard 取消事务

redis的事务支持 乐观锁 watch 监控

watch key1 key2 key3 设置监控得到值
unwatch 取消监控所有的字段

watch 监控的变量，在执行事务的时候 被其他事务干扰，那么当前事务
在执行时 会取消操作，需要重新开启事务进行操作

总结：多个事务在对一个或多个变量进行操作时，需要watch 监控
这样保证了事务和事务之间的互斥性

multi 开启事务
exec 执行事务
discard 取消事务
watch 监控字段
unwatch取消所有监控字段

redis的编译时异常 会取消整个redis的事务
redis的运行时异常 会正常执行其他正确的命令，错误的不执行

mysql的事务 和 redis的事务对比:
…

Jedis: java代码连接redis 进行操作
下午自己练习所有方法;

Redis配置文件: 从头看到尾巴 ，了解redis配置文件的核心内容
1. INCLUDE
#include /path/to/other.conf 可以包含其他文件
2. NETWORK
#bind 192.168.200.128 -::1 指定ip连接redis 服务器
port 6379
3. GENERAL 通用配置
daemonize yes 后台运行
pidfile /var/run/redis_6379.pid 进程ip文件 不需要动
logfile “redis6379.log” 自行设置 日志文件
databases 16 默认数据库个数
*** 4. snapshotting 快照
save 60 5 60秒内 执行了5次命令 就持久化一次
dbfilename dump.rdb 默认redis 数据库的名字
5. REPLICATION 主从复制 读写分离
6. SECURITY 设置密码
config set requirepass “123”
auth “123” 才能正常操作
但是别设置
*** 7. APPEND ONLY MODE append only mode aof持久化
以日志形式做持久化操作，性能比rdb慢，

	   appendonly no 是否开启aof 
	   appendfilename "appendonly.aof" aof文件名
	aof运行机制: 
	   appendfsync always: 在每次执行命令的时候，执行一次持久化一次
	   appendfsync everysec: 每秒拼接一次
	   appendfsync no : 从不拼接
	   
	 auto-aof-rewrite-min-size 64mb 开启重写功能
	 
				java.util.concrueent.*
Hashtable   和 CucurrentHashMap
	独占锁	 	   分段锁

========================================================================
redis持久化: 将内存中的数据 定时的 ，定期的写入到 磁盘中
1.rdb: dump.rdb redis 默认的持久化机制
修改 redis.conf 文件的持久化
redis 持久化的触发机制:

	1.#save 3600 1
	  #save 300 10 
	  #save 60 5 

	2.save 手动持久化
	3.flushdb 手动持久化
	4.flushall 
	 
 2.aof:
	 appendonly yes 开启 aof 持久化

	如果我们修改了appenonlyfile.aof文件 ，那么整个文件属于受损状态
	不能启动服务器,所以要执行以下操作
	redis-check-aof --fix appenonlyfile.aof 修复整个受损的aof文件
	这样才能开起服务器

总结： redis的持久化操作
	 1.redis默认是rdb持久化
	 2.redis可以同时开启两个持久化操作，rdb ，aof 但是会占用cpu
	   如果同时开启，优先加载的是aof ，在加载rdb
	
	如果出现强制断电操作，aof 会丢失1秒的数据， rdb会丢失最后一次操作

	如果应用后 二次开启，反序列化操作，那么rdb 比 aof 性能高
	
	整体而言 ，rdb性能 比aof 好，适合处理大型文件
	
	如果aof文件大于64mb ，会触发重写机制;
	
原理图: 
		fork
		redis 会自动的向Linux操作提供 ，请求一个fork 子进程 
		 让整个子进程进行持久化，主进程该干什么 就干什么
		 所以性能很快

首先要先说下redis持久化的意义：
redis持久化的意义主要在于故障恢复，比如你部署一个redis，
作为缓存有可能里边有一些比较重要的数据，如果没有持久化的时候，
redis遇到灾难性故障的时候就会丢失所有的数据。
多以持久化是必不可少的。

1.RDB和AOF两种持久化机制的介绍
RDB持久化机制对redis中的数据执行周期性的持久化。
AOF持久化机制对每条写入命令作为日志，以append-only模式写入一个日志文件中，在redis重启的时候，可以通过AOF写入的指令来重新构建整个数据集。
通过RDB和AOF都可以将redis内存中的数据持久化到硬盘上，然后可以将数据备份到云服务器上。
如果redis挂了可以从云服务器上的备份文件copy到指定位置然后重启redis，redis就会自动持久化文件中的数据，去恢复内存中的数据。
如果同时使用RDB和AOF两种持久化机制，那么redis重启的时候，会使用AOF来构建数据，因为AOF的数据更加完整。

当满足条件时,redis需要执行RDB的时候服务器会执行以下操作：
1.redis调用系统的fork()函数创建一个子进程
2.子进程将数据集写入一个临时的RDB文件
3.当子进程完成对临时的RDB文件的写入时，redis用新的RDB文件来替换原来旧的RDB文件，并将旧的RDB文件删除

redis在进行快照的过程中不会对RDB文件进行修改，只有快照结束后才会将旧快照替换成新快照，也就是说任何时候RDB都是完整的

RDB优点：
（1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。
（2）RDB对redis对外提供读写服务的时候，影像非常小，因为redis 主进程只需要fork一个子进程出来，让子进程对磁盘io来进行rdb持久化
(3).RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB缺点
（1）如果redis要故障时要尽可能少的丢失数据，RDB没有AOF好，例如1:00进行的快照，在1:10又要进行快照的时候宕机了，这个时候就会丢失10分钟的数据。
（2）RDB每次fork出子进程来执行RDB快照生成文件时，如果文件特别大，可能会导致客户端提供服务暂停数毫秒或者几秒

redis中的数据是有一定限量的，不可能说redis中的数据无限增长，进而导致AOF文件无限增长。
内存大小是一定的，等到了一定大小redis 会采用淘汰策略lru,自动将内存中的数据清除掉
AOF是存放每条写命令的，所以会不断的增大，当大到一定程度时，AOF会做rewrite操作,rewrite操作就是基于当时redis的数据重新构造一个小的AOF文件，然后将大的AOF文件删除。

AOF的优点：
（1）AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
（2）AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
（3）AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。
AOF的缺点
（1）对于同一份文件AOF文件比RDB数据快照要大。
（2）AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的
（3）数据恢复比较慢，不适合做冷备。

RDB和AOF到底如何选择
（1）不要仅仅使用RDB这样会丢失很多数据。
（2）也不要仅仅使用AOF，因为这一会有两个问题，第一通过AOF做冷备没有RDB做冷备恢复的速度快；第二RDB每次简单粗暴生成数据快照，更加健壮。
（3）综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，可以使用RDB进行快速的数据恢复。

redis发布订阅:

redis主从复制 读写分离， 哨兵

redis 雪崩 ，穿透 ， 击穿