五大分布式集群架构问题解决方案

最新推荐文章于 2024-04-19 07:30:52 发布

2B青年小文

最新推荐文章于 2024-04-19 07:30:52 发布

阅读量1.6k

点赞数 2

分类专栏：分布式集群文章标签：分布式 java

本文链接：https://blog.csdn.net/u014379055/article/details/108392363

版权

分布式集群专栏收录该内容

6 篇文章 0 订阅

订阅专栏

前言

什么是分布式集群？

这里有两个概念：分布式和集群。

分布式：分布式是指将不同的业务分布在不同的地方或者同一个业务模块分拆多个子业务，部署在不同的服务器上，解决高并发的问题。分布式中的每一个节点，都可以做集群。

集群：同一个业务部署在多台机器上，提高系统可用性。而集群并不一定就是分布式的。

简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

集群是个物理形态，分布式是个工作方式。集群不一定是分布式，分布式一定是集群。

1 ⼀致性Hash算法

什么是Hash?

Hash任意长度的输入（又叫做预映射， pre-image），通过散列算法，变换成固定长度的输出，该输出就是散列值，这个过程叫做Hash，这个映射函数称做散列函数，存放记录的数组称做散列表(Hash Table),又叫哈希表。

Hash算法的应用场景多为数据安全、数据校验方面，⽐如说在安全加密领域MD5、SHA等加密算法，在数据存储和查找⽅⾯有Hash表等

为什么需要使⽤Hash?

它的查询效率⾮常之⾼，其中的哈希算法如果设计的⽐较ok的话，那么Hash表的数据查询时间复杂度可以接近于O(1)。

举个例子，现有数据是3，5，7，12306，⼀共4个数据，我们开辟任意个空间，⽐如5个，那么具体数据存储到哪个位置呢，我们可以对数据进⾏求模（对空间位置数5），根据求模余数确定存储位置的下标，⽐如3%5=3，就可以把3这个数据放到下标为3的位置上，12306%5=1，就把12306这个数据存储到下标为1的位置上

在这里插入图片描述上⾯对数据求模（数据%空间位置数）他就是⼀个hash算法，只不过这是⼀种⽐较普通⼜简单的hash算法，这种构造Hash算法的⽅式叫做除留余数法。
当然除了除留余数法，还有很多普通hash算法，比如直接寻址法、针对除留余数法出线的hash冲突、有开放寻址方式、还有拉链发等等。

Hash算法在分布式集群架构中的应⽤场景

Hash算法在很多分布式集群产品中都有应⽤，⽐如分布式集群架构Redis、Hadoop、ElasticSearch，Mysql分库分表，Nginx负载均衡等。
主要的应⽤场景归纳起来两个：

请求的负载均衡（⽐如nginx的ip_hash策略）
Nginx的IP_hash策略可以在客户端ip不变的情况下，将其发出的请求始终路由到同⼀个⽬标服务器上，实现会话粘滞，避免处理session共享问题
分布式存储
以分布式内存数据库Redis为例,集群中有redis1，redis2，redis3 三台Redis服务器
那么,在进⾏数据存储时,<key1,value1>数据存储到哪个服务器当中呢？针对key进⾏hash处理hash(key1)%3=index, 使⽤余数index锁定存储的具体服务器节点

普通Hash算法存在的问题

普通Hash算法存在⼀个问题，以ip_hash为例，假定下载⽤户ip固定没有发⽣改变，现在tomcat3出现了问题，down机了，服务器数量由3个变为了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”的哈希值，于是形成六个虚拟节点，当客户端被路由到虚拟节点的时候其实是被路由到该虚拟节点所对应的真实节点
在这里插入图片描述

2 集群时钟同步问题

时钟不同步导致的问题

如果集群中各个服务器时钟不⼀致势必导致⼀系列问题，试想 “集群是各个服务器⼀起团队化作战，⼤家⼯作都不在⼀个点上，岂不乱了套！”

集群时钟同步配置

分布式集群中各个服务器节点都可以连接互联⽹
```
#使⽤ ntpdate ⽹络时间同步命令
ntpdate -u ntp.api.bz #从⼀个时间服务器同步时间
```
windows有计划任务
Linux也有定时任务，crond，可以使⽤linux的定时任务，每隔10分钟执⾏⼀次ntpdate命令
分布式集群中某⼀个服务器节点可以访问互联⽹或者所有节点都不能够访问互联⽹
选取集群中的⼀个服务器节点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
```

3 分布式全局唯⼀ID解决⽅案

为什么需要分布式集群环境下的全局唯⼀ID?
在这里插入图片描述 分布式集群环境下的全局唯⼀ID解决方案：

UUID(可以⽤)
独⽴数据库的⾃增ID(不推荐用)
SnowFlake 雪花算法（可以⽤，推荐）
雪花算法是Twitter推出的⼀个⽤于⽣成分布式ID的策略。
雪花算法是⼀个算法，基于这个算法可以⽣成ID，⽣成的ID是⼀个long型，那么在Java中⼀个long型是8个字节，算下来是64bit，如下是使⽤雪花算法⽣成的⼀个ID的⼆进制形式示意：
借助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();
 } 
}

4 分布式调度问题

调度—>定时任务，分布式调度—>在分布式集群环境下定时任务这

定时任务的场景

定时任务形式：每隔⼀定时间/特定某⼀时刻执⾏
例如

订单审核、出库
订单超时⾃动取消、⽀付退款
礼券同步、⽣成、发放作业
物流信息推送、抓取作业、退换货处理作业
数据积压监控、⽇志监控、服务可⽤性探测作业
定时备份数据
⾦融系统每天的定时结算
数据归档、清理作业
报表、离线数据分析作业

什么是分布式调度？

什么是分布式任务调度？有两层含义
1）运⾏在分布式集群环境下的调度任务（同⼀个定时任务程序部署多份，只应该有⼀个定时任务在执⾏）
2）分布式调度—>定时任务的分布式—>定时任务的拆分（即为把⼀个⼤的作业任务拆分为多个⼩的作业任务，同时执⾏）
在这里插入图片描述 定时任务与消息队列(MQ)的区别

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

所以，定时任务作业更倾向于批处理，MQ倾向于逐条处理；

定时任务的实现⽅式
定时任务的实现⽅式有多种。早期没有定时任务框架的时候，我们会使⽤JDK中的Timer机制和多线程机
制（Runnable+线程休眠）来实现定时或者间隔⼀段时间执⾏某⼀段程序；后来有了定时任务框架，⽐
如⼤名鼎鼎的Quartz任务调度框架，使⽤时间表达式（包括：秒、分、时、⽇、周、年）配置某⼀个任
务什么时间去执⾏。
1、引入jar

<!--任务调度框架quartz-->
<!-- https://mvnrepository.com/artifact/org.quartz-scheduler/quartz -->
<dependency>
 <groupId>org.quartz-scheduler</groupId>
 <artifactId>quartz</artifactId>
 <version>2.3.2</version>
</dependency>

2、定时任务作业主调度程序

package quartz;
import org.quartz.*;
import org.quartz.impl.StdSchedulerFactory;
public class QuartzMain {
 // 创建作业任务调度器（类似于公交调度站）
 public static Scheduler createScheduler() throws SchedulerException {
	 SchedulerFactory schedulerFactory = new StdSchedulerFactory();
	 Scheduler scheduler = schedulerFactory.getScheduler();
	 return scheduler;
 }
 // 创建⼀个作业任务（类似于⼀辆公交⻋）
 public static JobDetail createJob() {
	 JobBuilder jobBuilder = JobBuilder.newJob(DemoJob.class);
	 jobBuilder.withIdentity("jobName","myJob");
	 JobDetail jobDetail = jobBuilder.build();
	 return jobDetail;
 }
 /**
 * 创建作业任务时间触发器（类似于公交⻋出⻋时间表）
 * cron表达式由七个位置组成，空格分隔
 * 1、Seconds（秒） 0~59
 * 2、Minutes（分） 0~59
 * 3、Hours（⼩时） 0~23
 * 4、Day of Month（天）1~31,注意有的⽉份不⾜31天
 * 5、Month（⽉） 0~11,或者
JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC
 * 6、Day of Week(周) 1~7,1=SUN或者 SUN,MON,TUE,WEB,THU,FRI,SAT
 * 7、Year（年）1970~2099 可选项
 *示例：
 * 0 0 11 * * ? 每天的11点触发执⾏⼀次
 * 0 30 10 1 * ? 每⽉1号上午10点半触发执⾏⼀次
 */
 public static Trigger createTrigger() {
	 // 创建时间触发器，按⽇历调度
	 CronTrigger trigger = TriggerBuilder.newTrigger()
	 .withIdentity("triggerName","myTrigger")
	 .startNow()
	 .withSchedule(CronScheduleBuilder.cronSchedule("0/2 *
	* * * ?"))
	 .build();
	 // 创建触发器，按简单间隔调度
	 /*SimpleTrigger trigger1 = TriggerBuilder.newTrigger()
	 .withIdentity("triggerName","myTrigger")
	 .startNow()
	 .withSchedule(SimpleScheduleBuilder
	 .simpleSchedule()
	 .withIntervalInSeconds(3)
	 .repeatForever())
	 .build();*/
	 return trigger;
 }
 // 定时任务作业主调度程序
 public static void main(String[] args) throws SchedulerException {
	 // 创建⼀个作业任务调度器（类似于公交调度站）
	 Scheduler scheduler = QuartzMain.createScheduler();
	 // 创建⼀个作业任务（类似于⼀辆公交⻋）
	 JobDetail job = QuartzMain.createJob();
	 // 创建⼀个作业任务时间触发器（类似于公交⻋出⻋时间表）
	 Trigger trigger = QuartzMain.createTrigger();
	 // 使⽤调度器按照时间触发器执⾏这个作业任务
	 scheduler.scheduleJob(job,trigger);
	 scheduler.start();
 }
}

3、定义⼀个job，需实现Job接⼝

package quartz;
import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
public class DemoJob implements Job {
 public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {
 	System.out.println("我是⼀个定时任务逻辑");
 }
}

分布式调度框架Elastic-Job

Elastic-Job是当当⽹开源的⼀个分布式调度解决⽅案，基于Quartz⼆次开发的，由两个相互独⽴的⼦项⽬Elastic-Job-Lite和Elastic-Job-Cloud组成， Elastic-Job-Lite，它定位为轻量级⽆中⼼化解决⽅案，使⽤Jar包的形式提供分布式任务的协调服务，⽽Elastic-Job-Cloud⼦项⽬需要结合Mesos以及Docker在云环境下使⽤。Elastic-Job可以有效解决分布式调度问题，解决方案有弹性扩容、失效转移、任务分片等。下面通过elastice-job-lite描述下分布式调度：

首先，elastice-job-lite作为jar包集成到业务系统当中, 每个业务系统同时也是一个任务执行器，通过zk来协调。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IZ9kdIjh-1599202814138)(C:\Users\12530\AppData\Roaming\Typora\typora-user-images\image-20200904143235895.png)]$

如上图所示，elastic-job-lite通过zk实现各服务的注册、控制及协调：

第一台服务器上线触发主服务器选举。主服务器一旦下线，则重新触发选举，选举过程中阻塞，只有主服务器选举完成，才会执行其他任务。
某服务节点(引入elastic-job-lite-jar包)上线时会自动将服务器信息注册到注册中心，下线时会自动更新服务器状态。
主节点选举，服务器上下线，分片总数变更均更新重新分片标记。
定时任务触发时，如需重新分片，则通过主服务器分片，分片过程中阻塞，分片结束后才可执行任务。如分片过程中主服务器下线，则先选举主服务器，再分片。
通过上一项说明可知，为了维持作业运行时的稳定性，运行过程中只会标记分片状态，不会重新分片。分片仅可能发生在下次任务触发前。
每次分片都会按服务器IP排序，保证分片结果不会产生较大波动。
实现失效转移功能，在某台服务器执行完毕后主动抓取未分配的分片，并且在某台服务器下线后主动寻找可用的服务器执行任务。

5 Session共享问题

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

Session问题原因分析

在这里插入图片描述出现这个问题的原因，从根本上来说是因为Http协议是⽆状态的协议。客户端和服务端在某次会话中产⽣的数据不会被保留下来，所以第⼆次请求服务端⽆法认识到你曾经来过， Http为什么要设计为⽆状态协议？早期都是静态⻚⾯⽆所谓有⽆状态，后来有动态的内容更丰富，就需要有状态，出现了两种⽤于保持Http状态的技术，那就是Cookie和Session。⽽出现上述不停让登录的问题。

解决Session⼀致性的⽅案

Nginx的 IP_Hash 策略（可以使⽤）
同⼀个客户端IP的请求都会被路由到同⼀个⽬标服务器，也叫做会话粘滞
优点：配置简单，不⼊侵应⽤，不需要额外修改代码
缺点：服务器重启Session丢失；存在单点负载⾼的⻛险；单点故障问题；
Session复制（不推荐）
多个tomcat之间通过修改配置⽂件，达到Session之间的复制

优点：
- 不⼊侵应⽤
- 便于服务器⽔平扩展
- 能适应各种负载均衡策略
- 服务器重启或者宕机不会造成Session丢失

缺点：
- 性能低
- 内存消耗
- 不能存储太多数据，否则数据越多越影响性能
- 延迟性

Session共享，Session集中存储（推荐）

使用Redis中间件缓存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）添加注解

@SpringBootApplication
@EnableCaching
@EnableRedisHttpSession //session共享
public class WorkprojectApplication extends SpringBootServletInitializer {

2B青年小文

关注

2
点赞
踩
12

收藏

觉得还不错? 一键收藏
0
评论
五大分布式集群架构问题解决方案

文章内容输出来源：拉勾教育Java高薪训练营。前言1 ⼀致性Hash算法2 集群时钟同步问题3 分布式ID解决⽅案4 分布式调度问题5 Session共享问题Session共享及Session保持或者叫做Session⼀致性。
复制链接

扫一扫