了解redis以及使用规则_redis 出入规则

redis详解

一:Redis介绍

1.1redis是一个key-value存储系统

支持存储的value类型繁多 包括 string-字符串			list-链表、set-集合
				zset(sorted set)--有序集合		hash-哈希类型
这些数据类型都支持push/pop、add/remove及取交集并集和差集及丰富的操作，
而且这些操作都是原子性的.redis支持各种不同方式的排序。
为了保证效率，数据都是缓存在内存中。
redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件
还实现了master-slave(主从)同步。
常见用法:
	可以当做缓存
	可以当做数据库使用  
	验证码
	消息中间件使用
1
2
3
4
5
6
7
8
9
10
11
12

1.2.redis原子性说明

redis的操作时单进程单线程操作,所以没有并发性的安全问题,采用队列的方式一个一个操作
1

二.redis的持久化说明

redis默认条件下支持数据的持久化操作,当redis中有数据时,会定时的保存到磁盘中,
当redis服务器重启时会根据配置文件读取指定的持久化文件,实现数据的恢复
1
2

1.RDB模式:

	特点:
		1:redis默认的持久化策略,
		2:RDB模式记录的是redis内存数据的快照,最新的快照会覆盖掉旧的快照 
	这种模式占用空间小,持久化效率高--但是定期持久化可能会造成数据丢失
	命令:
		save:立刻执行持久化 同步的操作,其他的redis操作会陷入阻塞状态
		bgsave:	开启后台运行 异步的操作,无法保证数据是最新的
	配置:
		dir ./ --持久化文件的位置 , 相对路径的写法
	RDB模式的持久化策略:
		save 900 1 		900秒内更新一次持久化一次
		save 300 10 	300秒内更新10次持久化一次
		save 60 10000	30秒内跟新10000次持久化一次
1
2
3
4
5
6
7
8
9
10
11
12
13

2.AOF模式:

	特点:AOF默认条件下是关闭的
	
	手动开启:开启之后就以这种模式为主
		redis.conf 文件中大约699 行 appendonly yes --开启 no--关闭
		appendonly .aof--持久化文件的名称.后缀
	异步操作:
		记录的是用户操作的过程--可以防止用户的数据丢失	
		这种模式记录的程序运行的状态,持久化文件会相对较大,恢复时间稍微长,
		需要人为优化redis 效率稍微低了一点
	配置:
		appendfsync always --用户操作一次持久化一次
		appendfsync everysec--每秒持久化一次
		appendfsync no --不持久化
		
如果数据重要不允许丢失--AOF
如果追求效率也稍微丢失文件使用--RDB
既要保证效率,又要保证数据不丢失--主机使用RDB--从机使用AOF	
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

三:redis的内存优化策略

redis的数据存储都在内存中,如果一直存储必然会造成内存溢出
解决策略一般分为两大类

1:尽量给数据添加超时时间

2:利用算法优化一些陈旧的数据

	LRU算法	最近最少使用
		特点:迄今为止最好用的优化算法,成功率接近100%
		维度:按照时间T删除数据
	LFU算法 最不经常使用的
		维度:按照使用次数删除数据
	RANDOM算法
		随机算法,随机到谁就是谁
	TTL算法: 将要即将超时的数据提前进行删除
1
2
3
4
5
6
7
8

四.redis的内存的配置

volatile-lru	--设定了超时的时间的数据采用lru算法
allkeys-lru		--所有的数据采用lru的算法

noeviction	--如果内存溢出,错误返回,不做任何操作

配置文件中配置maxmemory-policy  (具体算法)
1
2
3
4
5
6

五redis缓存

tomcat-服务器的运行速度在150~250之间(JVM调优之后)1000/秒
nginx–服务器的运行速度在3~5万/秒
redis–读11.2万/秒 写8.6万/秒 平均10万/秒
如果有海量的用户请求–但这时redis缓存出现问题 -可能导致整个系统奔溃

1.缓存穿透:

由于某些用户高并发环境下访问数据库不存在的数据时容易导致缓存穿透
解决策略--
	设定ip限流的操作
	nginx中或者微服务机制 API网关
1
2
3
4

2.缓存击穿:

由于用户高并发的环境下,由于某个数据之前存在于内存中,由于特殊原因(数据超时,数据意外删除)
导致redis缓存失效,从而使大量的请求访问数据库--趁他病要他命
解决策略-- 
	设置超时时间,不设置相同的时间
	设定多级缓存
1
2
3
4
5

3.缓存雪崩:

由于高并发条件下有大量的数据失效然后导致redis的命中率太低,从而使用户直接访问服务器
或者数据库	导致崩溃
解决策略--
	多级缓存 
	提高redis缓存的命中率--调整内存优化算法--lru
1
2
3
4
5

六:redis分片

如果需要存储海量的数据,只使用一台redis无法保证工作的效率,时间会浪费在寻找数据的时间中
redis的服务需要依赖redis.conf 多台就需要进行多个配置

1.redis一致性hash算法:

常识说明--
	一般的hash是8位16进制数
	如果对相同的数据进行hash运算,其结果相同
	一个数据1M和一个数据1G的hash运算的速度一致

一致性hash算法目的解决分布式缓存的问题
	特性--
		均衡性:hash结果应该尽可能的平均分配到各个节点上,形成负载均衡
		由于节点都是通过hash方式进行计算,从而导致不能平均
		引入虚拟节点,从而进行平衡性
		单调性:指在新增节点或者在删减节点是不会影响系统的运行
		分散性:节点数据尽可能分散保存
1
2
3
4
5
6
7
8
9
10
11
12

2.分片的实际作用

好处:
	Redis分片的主要的作用是实现内存数据的扩容,Redis分片如果宕机不能实现高可用!!!
	Redis的分片的计算发生在业务服务器中 将需要保存的数据存储到redis中.
	Redis分片的执行的效率是最高的.

影响:
	分片:实现内存的扩容
	如果有一个redis节点出现问题,可能导致整个redis宕机
	从而影响用户访问直接影响用户的体验
1
2
3
4
5
6
7
8
9

七.redis哨兵

1:实现redis高可用机制

配置redis主从的结构:
	检查redis分片的主从信息
		命令 info replication
哨兵启动时会监控当期主机,获取主机的详情信息(主从结构)
哨兵利用心跳检测机制,连续三次没有得到主机的反馈信息,则主机宕机
当哨兵发现主机宕机之后,开启选举机制,在当前的从机中选择一台当做新主机,
其他的redis节点设置成新主机的从
1
2
3
4
5
6
7

2:redis哨兵特点:

Redis哨兵可以实现Redis节点的高可用.但是哨兵本身没有实现高可用机制.
Redis哨兵有主从的结构 实现了内存数据的备份. 但是没有实现内存扩容的效果.
1
2

八.redis的集群:

redis分片--可以实现内存数据的扩容,没有高可用的效果,如果宕机将直接影响用户使用
redis哨兵--可以试想redis节点的高可用,但是哨兵本身没有实现高可用机制
需求--需要内存扩容并且实现高可用
使用redis集群
一台主机占用一个槽道 最多有16384个
1
2
3
4
5

redis集群进行选举时,连续三次进行选举时出现脑裂的现象–增加主节点的数量有效的降低脑裂的现象(当集群进行选举时,如果连续3次都出现了平票的结果的则可能出现脑裂的现象)