redis与jedis下

数据分片的计算

单节点的redis提供了user系统的数据处理
的能力
物理瓶颈上限很有限:一个节点的内存不
够的

一旦宕机:用户登录逻辑彻底完蛋了

可以通过横向扩展解决总体容量扩容

在这里插入图片描述

在使用一定的计算逻辑处理数据的切分
存储的过程后,每个节点都会保存整体数
据的一部分

在这里插入图片描述

数据分配切分逻辑:

来一条给第一个节点,第二条给第二
个节点 第三条给第三个节点 第四条。。

给第一个节点(物理平均的切分算法)
这种形成切分目的的计算逻辑–数据分片
的计算方法;
hash取余(取模有关) jedis中使用的
hash一致性

hash取余的分片计算方法

模拟系统生成了大量key-value;
for循环大量生成随机 uuid的key value
随便
hash取余的计算公式
(key.hashCode()&Integer.MAX_VALUE)%N
key:生成的业务逻辑对应的redis的key
key.hashCode():Object的方法
hashCode(),结果是可正可负int范围的
整数
(key.hashCode()&Integer.MAX_VLAUE):
一个整数(可正可负)做位的与运算 31个
1,保真31位运算,会将前面可正可负的整
数二进制保留后31位,第一位永远是0,导
致取正运算,计算结果正整数.
(key.hashCode()&Integer.MAX_VLAUE)%N
:n=分片个数(n个节点) 正整数取余n得
到的结果区间[0,n-1]
0–>第一个节点
1–>第二个节点
2–>第三个节点
n-1–>第n个节点

结论:

1 key的取值只要是java的Object就
可以对应一个[0,n-1]区间的整数
2 key值不变(equals方法判断不变),取
值结果不变

@Test
//模拟生成大量的数据,存储6379 6380
6381
//准备3个连接对象
Jedis jedis1=new Jedis(“xx.xx.xx.xx”,6379);
Jedis jedis2=new Jedis(“xx.xx.xx.xx”,6380);
Jedis jedis3=new Jedis(“xx.xx.xx.xx”,6381);
String key=“key_”+i;
String value=“value_”+i;
int
result=(key.hashCode()&Integer.MAX_V
ALUE)%3;
jedis1.set(key, value);
if(result0){//6370
//6380
jedis2.set(key, value);
}else if(result
1){
//6381
jedis3.set(key, value);
}else{
for(int i=0;i<100;i++){
public void hashN(){
}}}

jedis客户端封装的数据分片的对象ShardedJedis

jedis客户端可以通过传递的所有节点信息,封
装创建一个分片对象,这个分片对象对底层
jedis试下你了set,get,exists,expire的分片
计算方法的封装

@Test
//使用jedis客户端实现将大量数据存储在
6379 6380 6381
//收集的所有节点
List list=new
ArrayList();
list.add(new JedisShardInfo(“xx.xx.xx.xx”,
6379));
list.add(new JedisShardInfo(“xx.xx.xx.xx”,
6380));
list.add(new JedisShardInfo(“xx.xx.xx.xx”,
6381));
//通过节点信息 创建分片对象
ShardedJedis sJedis=new ShardedJedis(list);
sJedis.set(“name”, “liulaosih”);
System.out.println(sJedis.get(“name”));
public void shardedJedis(){
}

hash一致性

分布式结构中常用的分片计算方法.对比hash
取余介绍hash一致性

hash取余分片计算redis当前结构中的问题
会导致集群扩容,缩容数据的迁移量过大,不
迁移就会造成数据未命中过大–雪崩

在这里插入图片描述

当集群节点越多的时候,hash取余算法的结
果:扩容缩容时数据的未命中的概率范围越大
hash一致性是目前分布式分片计算方法
中比较流行的一种算法,基于一种hash散
列计算(CRC16计算),1997麻省理工大学大
二学生研究发明的算法.将内存数据映射
到一个整数区间 0-(2^32-1)43亿

hash一致性能够解决hash取余在扩容缩
容时的迁移量过大的问题

hash一致性的具体原理
hash环 ○
基于hash散列算法得到的0-43亿整数区
间–hash环

在这里插入图片描述

edis实现的hash一致性 ○
利用提供的节点信息做hash环的对应整
数映射,利用节点信息 “xx.xx.xx.xx:6379”

在这里插入图片描述

key值和节点对应寻找原则

key值做hash散列计算得到整数映射结果

在这里插入图片描述

key值的整数顺时针寻找最近的节点整数
做对应关系 上图的映射结果
6379: key 2,4,6
6380:key 1,5
6381:key 3
hash环的扩容

在这里插入图片描述

上图为例,本来映射在6379处理的数
据,key6由于扩容10001,迁移到10001
当节点越多时,映射切分的整数环弧线越
小,导致迁移数据越少
hash取余扩容:节点越多迁移量越大
hash一致性:节点越多迁移量越小,小道一
定程度时,这种未命中微不足道
数据平衡性权重 ○
jedis通过引入虚拟节点概念
xx.xx.xx.xx:6379:真实节点信息,模拟生

成大量的虚拟节点,与真实节点有相关关

xx.xx.xx.xx:6379#1:6379第一个虚拟节点
(虚拟出一个与真实节点字符串有关的不
同字符串)
xx.xx.xx.xx:6379#2
xx.xx.xx.xx6379#3
xx.xx.xx.xx:6379#4

在这里插入图片描述

key值在引入的虚拟节点的hash环上依然顺
时针寻找最近节点整数,一旦对应虚拟节点,
就会将该虚拟节点的真实节点作为处理者绑
定key-node的关系
如何使用虚拟节点完成权重? ○
jedis在创建分片对象封装hash一致性
时,将虚拟节点的个数设置为160
*weight;weight默认是1

总结点:
基础:hash散列计算 把内存数据映射到0-43
整数区间 对象不变 结果不变

key-node对应关系:

node映射整数,key映射的整数,key的整
数顺时针寻找最近节点整数

平衡新和权重:

虚拟节点:与真实节点信息有关的假的节点(可以实现hash一致性的计算)
jedis实现160*weight权重个虚拟节点

分片连接池

@Test
public void pool(){
//收集节点信息
List list=new
ArrayList();
list.add(new JedisShardInfo(“xx.xx.xx.xx”,
6379));
list.add(new JedisShardInfo(“xx.xx.xx.xx”,
6380));
list.add(new JedisShardInfo(“xx.xx.xx.xx”,
6381));
//使用连接池的配置对象,配置连接池的
各种属性
//最大空闲,最小空闲,最大连接数量…
new GenericObjectPoolConfig();
GenericObjectPoolConfig config=
config.setMaxIdle(8);
config.setMinIdle(3);
config.setMaxTotal(200);
//list config 构造一个包装了多个分片连
接对象的连接池对象
new ShardedJedisPool(config, list);
ShardedJedisPool pool=
//从池子中获取连接资源
ShardedJedis sJedis = pool.getResource();
sJedis.set(“location”, “北京”);}

springboot整合分片连接池

使用spring框架维护当前连接池对象的IOC,注
入到需要的位置使用,一个框架容器中只存在
一个连接池对象

做一个配置类

import
org.springframework.context.annotation.C
onfiguration;
@Configuration
public class PoolConfigRedis {
}

读取属性,配合配置类使用

@ConfigurationProperties(prefix=“redis.19
06”)
@Configuration
@ConfigurationProperties(prefix=“redis.19
06”)
private List nodes;
//10.9.39.13:6379,10.0.39.13:6380,10.9
.39.13:6381
private Integer maxTotal;
private Integer maxIdle;
private Integer minIdle;
getter&&setter
public class PoolConfigRedis {
}
application.properties
redis.1906.nodes=
xx.xx.xx.xx:6379,xx.xx.xx.xx:6380,xx.xx.xx.xx:6381
redis.1.maxTotal=200
redis.2.maxIdle=8
redis.3.minIdle=3

初始化对象(ShardedJedisPool)

public ShardedJedisPool initShardPool(){
//收集节点信息
List list=
new ArrayList();
//node=“10.9.39.13:6379”
String host=node.split("?[0];
int port=Integer.
parseInt(node.split("?[1]);
list.add(new
JedisShardInfo(host,port));
for (String node : nodes) {
}
//配置对象

GenericObjectPoolConfig config=new GenericObjectPoolConfig();

config.setMaxIdle(maxIdle);
config.setMaxTotal(maxTotal);
config.setMinIdle(minIdle);
return new
ShardedJedisPool(config,list);
public ShardedJedisPool initShardPool(){
}

user的登录功能版本二

@Autowired
private ShardedJedisPool pool;
public *** 方法(){
try{
ShardedJedis jedis = pool.getResource();

try{
xxxxxxx
e.printStackTrace();
return null;
}catch(Exception e){
pool.returnResource(jedis);
}finally{
}
}

高可用集群

三个节点分布式集群的问题

单节点故障,导致的集群不可用的问题.
当前的分布式结构,单节点结构不是高可用(high
avalibility)

哨兵集群

高可用的结构

在这里插入图片描述

主从结构的故障转移:主节点故障宕机,从节点顶替 •
主从的数据备份:主从关系一旦搭建,从节点时刻备份主节点
的数据.高可用的基础(mycat es)

redis支持一主多从,支持多级主从

在这里插入图片描述

主从结构过于复杂回导致数据复制备份的不稳定,一级,
每个主节点6个从节点

准备一主二从的配置文件

6382 主节点 
6383,6384 挂接在6382的从节点

拷贝redis.conf的模板文件 修改与端口相关的内容
[root@10-9-39-13 redis-3.2.11]# cp redis.conf
redis6382.conf
[root@10-9-39-13 redis-3.2.11]# cp redis.conf
redis6383.conf
[root@10-9-39-13 redis-3.2.11]# cp redis.conf
redis6384.conf
:%s/6379/6382/g
:%s/6379/6383/g
:%s/6379/6384/g
启动三个节点,看主从状态 ○
[root@10-9-39-13 redis-3.2.11]# redis-server
redis6382.conf
[root@10-9-39-13 redis-3.2.11]# redis-server
redis6383.conf
[root@10-9-39-13 redis-3.2.11]# redis-server
redis6384.conf

ps-ef|grep redis查看是否启动成功

调用>info replication
调用命令挂接主从 ○
登录到从节点,执行挂接的命令.
slaveof 主节点ip 主节点端口号
127.0.0.1:6384> slaveof 10.9.39.13 6382

测试验证

数据同步
主节点中新增一些数据 观察从节点是否能读取数据
从节点写入数据
默认情况丛节点是只读 read-only

故障转移
杀掉主节点进程,观察2个从节点的状态
结论:主从 主节点,从节点只关心主从的任务.没有故障转移
替换的机制.高可用个结构单独使用主从的复制无法完成.

哨兵进程

哨兵进程是一个单独的,特殊的redis进程,和redis-
server相互独立运行,可以实现对主从结构的监听和管
理,实现故障转移的控制

原理

监听原理:初始化时访问主节点,调用info命令从主节
点获取所有从节点的信息,维护在内存中进行监控管
理,所有节点的状态都会通过哨兵进行维护.

心跳机制:每秒钟通过rpc(远程通信协议)心跳检测
访问集群的所有节点,一旦发现心跳响应是空的,达
到一定时间判断节点故障宕机

投票机制:主节点宕机,选举一个从节点为新的主节点,
通过管理的权限,将这个节点的角色转化为master,将
其他集群节点挂接到这个心的主节点,必须通过投票
完成(哨兵也是集群),必须过半,投票的结果才能执行,
否则将会进入到重新判断循环

在这里插入图片描述

哨兵的基本配置就先不发了,比较基本

redis-cluster
-redis中高可用–sentinel
高可用分布式集群–redis-cluster
redis-cluster的结构和机制解决了前面技术架构的各种问

1 key-node强耦合(key可以从一个节点迁移到另一个节点不
影响数据的命中)
2 客户端代码不需要连接获取所有节点信息就可以操作分
布式集群(节点通信管理)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值