Redis分片的实现

最新推荐文章于 2024-09-25 02:00:00 发布

大超Bing

最新推荐文章于 2024-09-25 02:00:00 发布

阅读量760

点赞数 1

分类专栏： redis 文章标签：分布式 redis

本文链接：https://blog.csdn.net/weixin_47081743/article/details/107471501

版权

redis 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1.为什么使用分片

1.1 说明:

虽然redis可以扩展内存空间的大小,但是如果需要存储海量的数据,一味地去扩大内存,其实效率不高.

1.2 分片的介绍

准备多台redis,共同为用户提供缓存服务,在保证效率的前提下,实现了内存的扩容.
用户在使用分片机制时,将多台redis当做一个整体来用.

2. 分片的搭建

2.1 分片的规划

由3台redis构成端口号分别为6379/6380/6381, 如果需要准备多台redis则准备多个配置文件即可,注意其中的端口号.

2.1 准备多台redis

在这里插入图片描述

2.2 修改redis端口

说明:修改redis的配置文件的端口号
命令:vim 6380.conf
在这里插入图片描述

2.3 启动多台redis

可以建立sh脚本启动
在这里插入图片描述

3. 一致性hash算法

一致性哈希算法在1997年由麻省理工学院提出，是一种特殊的哈希算法，目的是解决分布式缓存的问题。在移除或者添加一个服务器时，能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。一致性哈希解决了简单哈希算法在分布式哈希表( Distributed Hash Table，DHT) 中存在的动态伸缩等问题.

3.2 一致性hash原理说明

目的:解决数据如何在分布式环境下进行存储.
hash取值区间:8位16进制,共有2^32种可能性.

数据如何存储
首先，对存储节点的哈希值进行计算，其将存储空间抽象为一个环，将存储节点配置到环上。环上所有的节点都有一个值。每个node节点都是由IP+port的值通过一致性哈希算法得到.
其次，对数据进行哈希计算，按顺时针方向将其映射到离其最近的节点上去。
当节点发生变化时带来哪些影响
当节点的数量发生了变化时,则节点中的对应的数据可以动态的迁移.
原则:当发生了节点变化时,应该尽可能小的影响其他节点.

3.3 一致性hash特性

一致性哈希算法是在哈希算法基础上提出的，在动态变化的分布式环境中，哈希算法应该满足的几个条件:平衡性、单调性和分散性 。
①平衡性是指hash的结果应该平均分配到各个节点，这样从算法上解决了负载均衡问题 ,利用虚拟节点实现数据平衡(相对平衡) 。
②单调性是指在新增或者删减节点时，不影响系统正常运行 ,可以实现动态的数据迁移。
③分散性是指数据应该分散地存放在分布式集群中的各个节点(节点自己可以有备份)，不必每个节点都存储所有的数据。

4. SpringBoot整合Redis分片

4.1 编辑分配配置文件

在这里插入图片描述

4.2 编辑配置类实现redis整合

@Configuration 	//我是一个配置类    一般都会与@Bean联用
@PropertySource("classpath:/properties/redis.properties")
public class RedisConfig {
	@value("${redis.nodes}")
	private String redisNodes;
	//整合分片实现redis内存扩容
	@Bean
	public ShardeJedis shardeJedis(){
		String[] nodes = redisNodes.split(",");
		//动态获取redis节点信息
		List<JedisShardInfo> list= new ArrayList<JedisShardInfo>();
		for(String node : nodes){
			String host = node.split(":")[0];
			int port = Integer.parseInt(node.split(":")[1]);
			list.add(new JedisShardInfo(host,port));
		}
		//返回分片对象
		return new ShardeJedis(list)
	}	
}

4.3 修改redisAOP中的注入

在这里插入图片描述

4.4 关于redis分片总结

当redis节点宕机之后,用户访问必然会收到影响
当redis服务宕机之后,该节点中的数据可能丢失
redis分片可以实现内存数据的扩容
redis分片机制中hash运算发生在业务服务器中,redis只负责存取,不负责计算,所有效率高

5. Redis属性说明

5.1 Redis持久化策略

5.11 redis持久化策略的说明

说明:redis的数据都保存在内存中,如果断电或者宕机,则内存数据将会檫除,导致数据丢失,为了防止数据丢失,redis内部有持久化机制,当第一次redis服务器启动时,根据配置文件中的持久化要求,进行持久化操作,如果不是第一次宕机,则在服务启动时会根据持久化文件的配置,读取指定的持久化文件.实现内存数据的恢复.

5.2 RDB模式

特点:

rdb模式是redis中默认的持久化策略.
rdb模式定期持久化,保存的是redis中的内存数据快照,持久化文件占用空间较小.
rdb模式可能导致内存数据丢失.

命令:
前提:需要在redis的客户端中执行.
1.save 命令 , 立即执行持久化,会导致其他操作陷入阻塞
2. bgsave 命令,开启后台运行,以异步方式进行持久化,不会造成其他操作的阻塞.
在这里插入图片描述

持久化周期:

save 900 1        900秒内,如果用户执行的1次更新操作,则持久化一次
save 300 10       300秒内,如果用户执行的10次更新操作,则持久化一次
save 60 10000     60秒内,如果用户执行的10000次更新操作,则持久化一次

持久化文件路径
持久化文件

5.3 AOF模式

特点:
1).AOF模式默认条件下是关闭状态,如果需要开启则要修改配置文件
2).AOF模式可以实现数据的实时持久化操作,AOF模式记录的是用户的操作过程.
3).只要开启了AOF模式,则持久化方式以AOF模式为主.
配置:

开启AOF持久化方式
持久化文件格式
持久化文件名称配置:
持久化文件策略说明:

appendfsync always 只要用户执行一次操作,则持久化一次.
appendfsync everysec 每秒持久化一次默认策略 效率略低于RDB
appendfsync no 不主动持久化

注:如果在生产环境下执行了flushall命令,则修改AOF文件,把flushall命令删除,之后重启即可.

5.4 持久化总结

如果用户允许少量的数据丢失,则可以选用RDB模式,效率更高.
如果用户不允许数据丢失,则选用AOF模式
可以2种方式都选,需要搭建主从结构,主机选用RDB模式,从机选用AOF模式,可以保证业务允许.

6. 配置多种持久化方式

6.1 设计 : 6379 当主机 7380当从机.

6.2 修改主机的配置文件:

要求: 主机使用RDB模式
从机使用AOF模式
.检查默认模式的状态
命令: info replication
实现主从挂载
编辑从服务器向主机进行挂载
命令: slaveof 192.168.126.129 6379

7.Redis内存策略

7.1 内存策略说明

redis服务器运行在内存中,数据也在内存中保存. 如果一直往里存,总有一天内存资源不够用,所以需要研究如何优化内存.

7.2 LRU 算法

维度: T 时间
LRU是Least Recently Used的缩写，即最近最少使用，是一种常用的页面(数据)置换算法，选择最近最久未使用的页面予以淘汰。该算法赋予每个页面(数据)一个访问字段，用来记录一个页面(数据)自上次被访问以来所经历的时间 t，当须淘汰一个页面时，选择现有页面(数据)中其 t 值最大的，即最近最少使用的页面(数据)予以淘汰。

7.3 LFU算法

维度:引用次数
LFU（least frequently used (LFU) page-replacement algorithm）。即最不经常使用页置换算法，要求在页置换时置换引用计数最小的页，因为经常使用的页应该有一个较大的引用次数。但是有些页在开始时使用次数很多，但以后就不再使用，这类页将会长时间留在内存中，因此可以将引用计数寄存器定时右移一位，形成指数衰减的平均使用次数。