分布式集群架构场景化解决⽅案

最新推荐文章于 2024-07-19 17:37:28 发布

淡画

最新推荐文章于 2024-07-19 17:37:28 发布

阅读量108

点赞数

分类专栏：随笔文章标签： java 分布式

本文链接：https://blog.csdn.net/wy491525030/article/details/118500591

版权

随笔专栏收录该内容

6 篇文章 0 订阅

订阅专栏

第⼀部分⼀致性Hash算法

第 1 节 Hash算法应⽤场景

Hash算法在很多分布式集群产品中都有应⽤，⽐如分布式集群架构Redis、Hadoop、ElasticSearch，Mysql分库分表，Nginx负载均衡等。

主要的应⽤场景归纳起来两个：

请求的负载均衡（⽐如nginx的ip_hash策略）
Nginx的IP_hash策略可以在客户端ip不变的情况下，将其发出的请求始终路由到同⼀个⽬标服务器上，实现会话粘滞，避免处理session共享问题如果没有IP_hash策略，那么如何实现会话粘滞？
可以维护⼀张映射表，存储客户端IP或者sessionid与具体⽬标服务器的映射关系<ip,tomcat1>
缺点
1）在客户端很多的情况下，映射表⾮常⼤，浪费内存空间
2）客户端上下线，⽬标服务器上下线，都会导致重新维护映射表，映射表维护成本很⼤
分布式存储
以分布式内存数据库Redis为例,集群中有redis1，redis2，redis3 三台Redis服务器，在进⾏数据存储时,针对key进⾏hash处理hash(key1)%3=index, 使⽤余数index锁定存储的具体服务器节点

普通Hash算法存在的问题
普通Hash算法存在⼀个问题，以ip_hash为例，假定下载⽤户ip固定没有发⽣改变，现在tomcat3出现了问题，down机了，服务器数量由3个变为了2个，之前所有的求模都需要重新计算。

第 2 节⼀致性Hash算法

⼀致性哈希算法思路如下：
⾸先有⼀条直线，直线开头和结尾分别定为为1和2的32次⽅减1，这相当于⼀个地址，对于这样⼀条线，弯过来构成⼀个圆环形成闭环，这样的⼀个圆环称为hash环。我们把服务器的ip或者主机名求hash值然后对应到hash环上，那么针对客户端⽤户，也根据它的ip进⾏hash求值，对应到环上某个位置，然后如何确定⼀个客户端路由到哪个服务器处理呢？按照顺时针⽅向找最近的服务器节点
在这里插入图片描述
假如将服务器3下线，服务器3下线后，原来路由到3的客户端重新路由到服务器4，对于其他客户端没有影响只是这⼀⼩部分受影响（请求的迁移达到了最⼩，这样的算法对分布式集群来说⾮常合适的，避免了⼤量请求迁移）
在这里插入图片描述
增加服务器5之后，原来路由到3的部分客户端路由到新增服务器5上，对于其他客户端没有影响只是这⼩部分受影响（请求的迁移达到了最⼩，这样的算法对分布式集群来说⾮常合适的，避免了⼤量请求迁移）
在这里插入图片描述
1）如前所述，每⼀台服务器负责⼀段，⼀致性哈希算法对于节点的增减都只需重定位环空间中的⼀⼩部分数据，具有较好的容错性和可扩展性。但是，⼀致性哈希算法在服务节点太少时，容易因为节点分部不均匀⽽造成数据倾斜问题。例如系统中只有两台服务器，其环分布如下，节点2只能负责⾮常⼩的⼀段，⼤量的客户端请求落在了节点1上，这就是数据（请求）倾斜问题
2）为了解决这种数据倾斜问题，⼀致性哈希算法引⼊了虚拟节点机制，即对每⼀个服务节点计算多个哈希，每个计算结果位置都放置⼀个此服务节点，称为虚拟节点。具体做法可以在服务器ip或主机名的后⾯增加编号来实现。⽐如，可以为每台服务器计算三个虚拟节
点，于是可以分别计算 “节点1的ip#1”、“节点1的ip#2”、“节点1的ip#3”、“节点2的ip#1”、“节点2的ip#2”、“节点2的ip#3”的哈希值，于是形成六个虚拟节点，当客户端被路由到虚拟节点的时候其实是被
路由到该虚拟节点所对应的真实节点
虚拟节点方案

第 3 节 Nginx 配置⼀致性Hash负载均衡策略

ngx_http_upstream_consistent_hash 模块是⼀个负载均衡器，使⽤⼀个内部⼀致性hash算法来选择合适的后端节点。
该模块可以根据配置参数采取不同的⽅式将请求均匀映射到后端机器，
consistent_hash $remote_addr：可以根据客户端ip映射
consistent_hash $request_uri：根据客户端请求的uri映射
consistent_hash $args：根据客户端携带的参数进⾏映
ngx_http_upstream_consistent_hash 模块是⼀个第三⽅模块，需要我们下载安装后使⽤
1）github下载nginx⼀致性hash负载均衡模块 https://github.com/replay/ngx_http_consistent_hash

在这里插入图片描述
2）将下载的压缩包上传到nginx服务器，并解压
3）我们已经编译安装过nginx，此时进⼊当时nginx的源码⽬录，执⾏如下命令：
./configure —add-module=/root/ngx_http_consistent_hash-master
make
make install
4）Nginx就可以使⽤啦，在nginx.conf⽂件中配置
在这里插入图片描述

第⼆部分集群时钟同步问题

集群时钟同步配置

分布式集群中各个服务器节点都可以连接互联⽹

在这里插入图片描述

#使⽤ ntpdate ⽹络时间同步命令
ntpdate -u ntp.api.bz #从⼀个时间服务器同步时间

分布式集群中某⼀个服务器节点可以访问互联⽹或者所有节点都不能够访问互联⽹

在这里插入图片描述
操作⽅式：
1）选取集群中的⼀个服务器节点A(172.17.0.17)作为时间服务器（整个集群时间从这台服务器同步，如果这台服务器能够访问互联⽹，可以让这台服务器和⽹络时间保持同步，如果不能就⼿动设置⼀个时间）⾸先设置好A的时间把A配置为时间服务器（修改/etc/ntp.conf⽂件）

1、如果有 restrict default ignore，注释掉它
2、添加如下⼏⾏内容
 restrict 172.17.0.0 mask 255.255.255.0 nomodify notrap # 放开局
域⽹同步功能,172.17.0.0是你的局域⽹⽹段
 server 127.127.1.0 # local clock
 fudge 127.127.1.0 stratum 10
3、重启⽣效并配置ntpd服务开机⾃启动
 service ntpd restart
 chkconfig ntpd on

集群中其他节点就可以从A服务器同步时间了

ntpdate 172.17.0.17

第三部分分布式ID解决⽅案

UUID(可以⽤)
UUID 是指Universally Unique Identifier，翻译为中⽂是通⽤唯⼀识别码
Java中得到⼀个UUID，可以使⽤java.util包提供的⽅法

public class MyTest {
 public static void main(String[] args) {
 System.out.println(java.util.UUID.randomUUID().toString());
 }
}

独⽴数据库的⾃增ID
比如单独的创建⼀个Mysql数据库，在这个数据库中创建⼀张表，这张表的ID设置为⾃增，其他地⽅
需要全局唯⼀ID的时候，就模拟向这个Mysql数据库的这张表中模拟插⼊⼀条记录，此时ID会⾃
增，然后我们可以通过Mysql的select last_insert_id() 获取到刚刚这张表中⾃增⽣成的ID.
SnowFlake 雪花算法（可以⽤，推荐）
雪花算法是⼀个算法，基于这个算法可以⽣成ID，⽣成的ID是⼀个long型，那么在Java中⼀个long
型是8个字节，算下来是64bit，如下是使⽤雪花算法⽣成的⼀个ID的⼆进制形式示意：

另外，⼀切互联⽹公司也基于上述的⽅案封装了⼀些分布式ID⽣成器，⽐如滴滴的tinyid（基于数
据库实现）、百度的uidgenerator（基于SnowFlake）和美团的leaf（基于数据库和SnowFlake）
等，他们在。
借助Redis的Incr命令获取全局唯⼀ID（推荐）
Redis Incr 命令将 key 中储存的数字值增⼀。如果 key 不存在，那么 key 的值会先被初始化为 0，然后再执⾏ INCR 操作。

代码

Jedis jedis = new Jedis("127.0.0.1",6379);
try {
 long id = jedis.incr("id");
 System.out.println("从redis中获取的分布式id为：" + id);
} finally {
 if (null != jedis) {
 jedis.close();
 } }

第四部分分布式调度问题

第 1 节什么是分布式调度

1）运⾏在分布式集群环境下的调度任务（同⼀个定时任务程序部署多份，只应该有⼀个定时任务在执
⾏）
2）分布式调度—>定时任务的分布式—>定时任务的拆分（即为把⼀个⼤的作业任务拆分为多个⼩的作
业任务，同时执⾏）
在这里插入图片描述

第 2 节定时任务与消息队列的区别

共同点
异步处理
⽐如注册、下单事件
应⽤解耦
不管定时任务作业还是MQ都可以作为两个应⽤之间的⻮轮实现应⽤解耦，这个⻮轮可以中转数据，当然单体服务不需要考虑这些，服务拆分的时候往往都会考虑
流量削峰
双⼗⼀的时候，任务作业和MQ都可以⽤来扛流量，后端系统根据服务能⼒定时处理订单或者从MQ抓取订单抓取到⼀个订单到来事件的话触发处理，对于前端⽤户来说看到的结果是已经下单成功了，下单是不受任何影响的
本质不同
定时任务作业是时间驱动，⽽MQ是事件驱动；
时间驱动是不可代替的，⽐如⾦融系统每⽇的利息结算，不是说利息来⼀条（利息到来事件）就算⼀下，⽽往往是通过定时任务批量计算；所以，定时任务作业更倾向于批处理，MQ倾向于逐条处理；

第 3 节分布式调度框架Elastic-Job

Elastic-Job是当当⽹开源的⼀个分布式调度解决⽅案，基于Quartz⼆次开发的，由两个相互独⽴的⼦项⽬Elastic-Job-Lite和Elastic-Job-Cloud组成。我们要学习的是 Elastic-Job-Lite，它定位为轻量级⽆中⼼化解决⽅案，使⽤Jar包的形式提供分布式任务的协调服务，⽽Elastic-Job-Cloud⼦项⽬需要结合Mesos以及Docker在云环境下使⽤

主要功能介绍

分布式调度协调
在分布式环境中，任务能够按指定的调度策略执⾏，并且能够避免同⼀任务多实例重复执⾏
丰富的调度策略
基于成熟的定时任务作业框架Quartz cron表达式执⾏定时任务
弹性扩容缩容
当集群中增加某⼀个实例，它应当也能够被选举并执⾏任务；当集群减少⼀个实例时，它所执⾏的任务能被转移到别的实例来执⾏。
失效转移
某实例在任务执⾏失败后，会被转移到其他实例执⾏
错过执⾏作业重触发若因某种原因导致作业错过执⾏，⾃动记录错过执⾏的作业，并在上次作业完成后⾃动触发。
⽀持并⾏调度
⽀持任务分⽚，任务分⽚是指将⼀个任务分为多个⼩任务项在多个实例同时执⾏。作业分⽚⼀致性当任务被分⽚后，保证同⼀分⽚在分布式环境中仅⼀个执⾏实例。

3.2 Elastic-Job-Lite应⽤

引⼊Jar包

<dependency>
 <groupId>com.dangdang</groupId>
 <artifactId>elastic-job-lite-core</artifactId>
 <version>2.1.5</version>
</dependency>

定时任务实例
需求：每隔两秒钟执⾏⼀次定时任务（resume表中未归档的数据归档到resume_bak表中，
每次归档1条记录）
1）resume_bak和resume表结构完全⼀样
2）resume表中数据归档之后不删除，只将state置为"已归档"
程序开发
- 定时任务类
- 主类

package elasticjob;
import com.dangdang.ddframe.job.api.ShardingContext;
import com.dangdang.ddframe.job.api.simple.SimpleJob;
import util.JdbcUtil;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.List;
import java.util.Map;
public class BackupJob implements SimpleJob {
 // 定时任务每执⾏⼀次都会执⾏如下的逻辑
 @Override
 public void execute(ShardingContext shardingContext) {
 /*
 从resume数据表查找1条未归档的数据，将其归档到resume_bak
表，并更新状态为已归档（不删除原数据）
 */
 // 查询出⼀条数据
 String selectSql = "select * from resume where
state='未归档' limit 1";
 List<Map<String, Object>> list =
JdbcUtil.executeQuery(selectSql);
 if(list == null || list.size() == 0) {
 return;
 }
 Map<String, Object> stringObjectMap = list.get(0);
 long id = (long) stringObjectMap.get("id");
 String name = (String) stringObjectMap.get("name");
 String education = (String)
stringObjectMap.get("education");
 // 打印出这条记录
 System.out.println("======>>>id：" + id + " name：" +
name + " education：" + education);
 // 更改状态
 String updateSql = "update resume set state='已归档'
where id=?";
 JdbcUtil.executeUpdate(updateSql,id);
 // 归档这条记录
 String insertSql = "insert into resume_bak select *
from resume where id=?";
 JdbcUtil.executeUpdate(insertSql,id);
 }
}

- 主类

package elasticjob;
import com.dangdang.ddframe.job.config.JobCoreConfiguration;
import
com.dangdang.ddframe.job.config.simple.SimpleJobConfiguration;
import com.dangdang.ddframe.job.lite.api.JobScheduler;
import com.dangdang.ddframe.job.lite.config.LiteJobConfiguration;
import
com.dangdang.ddframe.job.reg.base.CoordinatorRegistryCenter;
import
com.dangdang.ddframe.job.reg.zookeeper.ZookeeperConfiguration;
import
com.dangdang.ddframe.job.reg.zookeeper.ZookeeperRegistryCenter;
public class ElasticJobMain {
 public static void main(String[] args) {
 // 配置注册中⼼zookeeper，zookeeper协调调度，不能让任务重复执⾏，
通过命名空间分类管理任务，对应到zookeeper的⽬录
 ZookeeperConfiguration zookeeperConfiguration = new
ZookeeperConfiguration("localhost:2181","data-archive-job");
 CoordinatorRegistryCenter coordinatorRegistryCenter = new
ZookeeperRegistryCenter(zookeeperConfiguration);
 coordinatorRegistryCenter.init();
 // 配置任务
 JobCoreConfiguration jobCoreConfiguration =
JobCoreConfiguration.newBuilder("archive-job","*/2 * * * *
?",1).build();
 SimpleJobConfiguration simpleJobConfiguration = new
SimpleJobConfiguration(jobCoreConfiguration,BackupJob.class.getNam
e());
 // 启动任务
 new JobScheduler(coordinatorRegistryCenter,
LiteJobConfiguration.newBuilder(simpleJobConfiguration).build()).i
nit();
 }
}

第五部分 Session共享问题

Session共享及Session保持或者叫做Session⼀致性

解决Session⼀致性的⽅案

Nginx的 IP_Hash 策略（可以使⽤）
同⼀个客户端IP的请求都会被路由到同⼀个⽬标服务器，也叫做会话粘滞
- 优点
  配置简单，不⼊侵应⽤，不需要额外修改代码
- 缺点
  服务器重启Session丢失
  存在单点负载⾼的⻛险
  单点故障问题
Session复制（不推荐）
也即，多个tomcat之间通过修改配置⽂件，达到Session之间的复制
优点
不⼊侵应⽤
便于服务器⽔平扩展
能适应各种负载均衡策略
服务器重启或者宕机不会造成Session丢失
- 缺点
  性能低
  内存消耗
  不能存储太多数据，否则数据越多越影响性能
  延迟性
Session共享，Session集中存储（推荐）
- 优点
  能适应各种负载均衡策略
  服务器重启或者宕机不会造成Session丢失
  扩展能⼒强
  适合⼤集群数量使⽤
- 缺点
  对应⽤有⼊侵，引⼊了和Redis的交互代码

Spring Session使得基于Redis的Session共享应⽤起来⾮常之简单：
1）引⼊Jar

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency> <dependency>
 <groupId>org.springframework.session</groupId>
 <artifactId>spring-session-data-redis</artifactId>
</dependency>

2）配置redis

spring.redis.database=0
spring.redis.host=127.0.0.1
spring.redis.port=6379

3）添加注解
在这里插入图片描述

淡画

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分布式集群架构场景化解决⽅案

第⼀部分⼀致性Hash算法第 1 节 Hash算法应⽤场景Hash算法在很多分布式集群产品中都有应⽤，⽐如分布式集群架构Redis、Hadoop、ElasticSearch，Mysql分库分表，Nginx负载均衡等。主要的应⽤场景归纳起来两个：请求的负载均衡（⽐如nginx的ip_hash策略）Nginx的IP_hash策略可以在客户端ip不变的情况下，将其发出的请求始终路由到同⼀个⽬标服务器上，实现会话粘滞，避免处理session共享问题如果没有IP_hash策略，那么如何实现会话粘滞？
复制链接

扫一扫