# spring-sesssion-app

**Repository Path**: shawnisacoder/spring-sesssion-app

## Basic Information

- **Project Name**: spring-sesssion-app
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2020-06-22
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

## Spring Session App

`Spring Boot` 集成 `Spring Session`

视频介绍在[这里](视频介绍.mp4)

`Nginx`配置文件见[这里](nginx.conf)

`Redis`配置文件见[这里](redis.conf)

## 理解`Elastic-Job-Lite`分布式调度

任何的业务中，都有可能存在**定时调度**的任务，例如：数据归档、离线数据处理等等。

随着业务量的增大，我们的应用走向分布式结构，同一个服务可能部署了多份。
但我们不期望服务中的定时调度任务在多台机器上同时运行，这是完全没有必要的。

因此，如何合理的使用多台机器运行定时调度任务，就变得非常重要了，这就是**分布式调度**的由来。
而`Elastic-Job-Lite`就是一款比较优秀的分布式调度框架。

`Elastic-Job-Lite`是通过`Zookeeper` + **任务分片**来完成机器的合理利用的。

![Elastic-Job-Lite向Zookeeper注册](images/Elastic-Job-Lite向Zookeeper注册.jpg)

每一个`Elastic-Job-Lite`的工作节点都会向`Zookeeper`注册自己的信息。`Zookeeper`中每当有节点变动，
例如增加和减少时，都会要求当前存活的节点竞选`Leader`。
竞选过程实际上就是向`Zookeeper`中某个特定的目录上写入数据，哪个节点写入成功，则该节点成为`Leader`。

具体的任务执行由`Leader`来完成。

![Elastic-Job-Lite任务分片](images/Elastic-Job-Lite任务分片.png)

为了避免`Leader`一个节点工作，而其他节点空闲的情况，`Elastic-Job-Lite`还提供了**分片**的机制。

**分片**实际上就是按照某种规则，将一个大的任务划分成多个小任务，每个工作节点负责执行一个或多个小的任务，
从而利用到空闲的工作节点。`Elastic-Job-Lite`中，可以根据实际的情况自定义分片策略。例如轮训或加权等，
非常灵活易用。

而在分布式的环境中，节点的数量是很容易发生变动的。例如，有某个节点下线，或者是增加了新的节点。
这种时候，都会导致`Zookeeper`中存储节点信息的目录数据发生变化，从而重新选举`Leader`并重新规划分片任务的执行，
始终保证了工作节点的高效运作。