分布式开发最全的解决方案

1、分布式ID

1. 雪花算法

算法原理：

每家算法各有不同：
百度：只支持雪花算法，组件已无人维护。
滴滴：只支持数据库后端，适合对id有高可用需求。
美团leaf：号段模式和雪花算法，适合 多场景的分布式id。
SnowFlake算法的优点：
（1）高性能高可用：生成时不依赖于数据库，完全在内存中生成。
（2）容量大：每秒中能生成数百万的自增ID。
（3）ID自增：存入数据库中，索引效率高。
SnowFlake算法的缺点：
依赖与系统时间的一致性，如果系统时间被回调，或者改变，可能会造成id冲突或者重复。
SnowFlake可以保证：
所有生成的id按时间趋势递增
整个分布式系统内不会产生重复id（因为有datacenterId和workerId来做区分）

2.号段模式

是当下分布式ID生成器的主流实现方式之一，号段模式可以理解为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，具体的业务服务将本号段，生成1~1000的自增ID并加载到内存。

CREATE TABLE id_generator (
  id int(10) NOT NULL,
  max_id bigint(20) NOT NULL COMMENT '当前最大id',
  step int(20) NOT NULL COMMENT '号段的布长',
  biz_type    int(20) NOT NULL COMMENT '业务类型',
  version int(20) NOT NULL COMMENT '版本号',
  PRIMARY KEY (`id`)
) 

iz_type ：代表不同业务类型
max_id ：当前最大的可用id
step ：代表号段的长度
version ：是一个乐观锁，每次都更新version，保证并发时数据的正确性
idbiz_typemax_idstepversion1101100020000

2、分布式session

session不是服务器管理的，是tomact管理的。

session原理：

session保存信息，如何传递的。 set cookie 》携带cookie（cookie协议，浏览器标准） 》传给session》返回前端。

Spring-session +redis 可实现

JWT实现

Json web tocken jwt.io
Jwt :tocken 里面的内容可以被解析的，但是不能被篡改。

##jwt配置
#签发者
jwtconfig.issuer: xxx
# 密钥
jwtconfig.secret: xxx,xxx
# 接收jwt的一方
jwtconfig.audience: light-data
# 过期时间，时间戳
jwtconfig.expiresSecond: xxx

3、分布式任务调度

1、QuartZ的使用

1.引入依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-quartz</artifactId>
</dependency>

2、配置项

@Configuration
public class JobConfig {

    @Resource
    private UserService userService;

    @Bean("jobOneDetail")
    public JobDetailFactoryBean jobOneDetailFactoryBean(JobOne jobOne) {
        JobDetailFactoryBean jobDetailFactoryBean =new JobDetailFactoryBean();
        jobDetailFactoryBean.setJobClass(jobOne.getClass());
        //没有绑定触发器仍然保留在Quartz的JobStore中
        jobDetailFactoryBean.setDurability(true);
        jobDetailFactoryBean.setName("jobOneDetailName");
        jobDetailFactoryBean.setGroup("jobOneDetailGroup");

        JobDataMap jobDataMap = new JobDataMap ();
        jobDataMap.put ("userService",userService);
        jobDetailFactoryBean.setJobDataMap(jobDataMap) ;
        return jobDetailFactoryBean;
    }

    @Bean("jobOneTrigger")
    public CronTriggerFactoryBean cronTriggerOneFactoryBean(@Qualifier("jobOneDetail") JobDetailFactoryBean jobDetailFactoryBean){
        CronTriggerFactoryBean cronTriggerFactoryBean=new CronTriggerFactoryBean();
        cronTriggerFactoryBean.setJobDetail(Objects.requireNonNull(jobDetailFactoryBean.getObject()));
        cronTriggerFactoryBean.setCronExpression("0 0 0/1 * * ? *");
        cronTriggerFactoryBean.setName("jobOneTriggerName");
        cronTriggerFactoryBean.setGroup("jobOneTriggerGroup");
        return cronTriggerFactoryBean;
    }


    @Bean("jobTwoDetail")
    public JobDetailFactoryBean jobTwoDetailFactoryBean(JobTwo jobTwo) {
        JobDetailFactoryBean jobDetailFactoryBean =new JobDetailFactoryBean();
        jobDetailFactoryBean.setJobClass(jobTwo.getClass());
        jobDetailFactoryBean.setDurability(true);
        jobDetailFactoryBean.setName("jobTwoDetailName");
        jobDetailFactoryBean.setGroup("jobTwoDetailGroup");
        JobDataMap jobDataMap = new JobDataMap ();
        jobDataMap.put ("userService",userService);
        jobDetailFactoryBean.setJobDataMap(jobDataMap) ;
        return jobDetailFactoryBean;
    }

    @Bean("jobTwoTrigger")
    public CronTriggerFactoryBean cronTriggerTwoFactoryBean(@Qualifier("jobTwoDetail") JobDetailFactoryBean jobDetailFactoryBean){
        CronTriggerFactoryBean cronTriggerFactoryBean=new CronTriggerFactoryBean();
        cronTriggerFactoryBean.setJobDetail(Objects.requireNonNull(jobDetailFactoryBean.getObject()));
        cronTriggerFactoryBean.setCronExpression("0 0 0/1 * * ? *");
        cronTriggerFactoryBean.setName("jobTwoTriggerName");
        cronTriggerFactoryBean.setGroup("jobTwoTriggerGroup");
        return cronTriggerFactoryBean;
    }

}

2、XXL-JOB

3、SchedulerX

SchedulerX 是阿里中间件自研的基于 Akka 架构（Akka in SchedulerX 2.0）的新一代分布式任务调度平台，提供定时、任务编排、分布式跑批等功能，具有高可靠、海量任务、秒级调度及可运维等能力。

4、分布式限流

限流存在：负载不够用，所以限流，排队处理
常见限流原理
1.漏桶算法
2.令牌桶算法

5、分布式数据库

1.ShardingSphere是什么

ShardingSphere是Apache基金会下的一个孵化项目，它是由一套开源的分布式数据库中间件解决方案组成的生态圈，主要关注数据分片、分布式事务和数据库协调。它的前身是Sharding JDBC，Sharding JDBC是当当网发布的一款分布式数据库中间件。
ShardingSphere主要由以下3个产品构成：
●Sharding-JDBC：它的定位为一种轻量级框架，基于传统的JDBC层，并且在此基础上提供了额外的服务，所以他能够兼容其他的Java数据库技术，例如，连接池和ORM框架（如Hibernate和MyBatis等）。当前能够支持MySQL、Oracle、SQLServer和PostgreSQL。
●Sharding-Proxy：它的定位为透明化的数据库代理端，提供封装数据库二进制协议的服务端版本，目前最先提供的是MySQL版本，它可以使用任何兼容MySQL的协议访问客户端（如MySQL Command Client、MySQL Workbench等）操作数据。因为可以代理分布式数据库，所以它对数据库管理员（DBA）会更友好。
●Sharding-Sidecar：这是目前没有发布的组件，它的定位为Kubernetes或Mesos的云原生数据库代理，以DaemonSet的形式代理所有对数据库的访问，它属于新一代网格数据库.

ShardingSphere是一个能够支持分片和分库的轻量级框架，在使用它之前，需要了解它的一些重要概念。

逻辑表：

分表技术是将一个原本存储大量数据的表拆分为具有相同字段但表名不同的一系列表，我们把这一系列表统称为逻辑表。例如，当我们把产品表拆分为表t_product_1、t_product_2、t_product_3……时，把表t_product_1、t_product_2、t_product_3……统称为表t_product，它是一个逻辑概念，不是一个真实存在的表。

真实表：

是指在数据库中真实存在的表，例如，逻辑表概念中谈到的表t_product_1、t_product_2、t_product_3……这些就是真实表，它真实地存在于数据库中。

数据节点

它是ShardingSphere拆分的最小分片单位，它会定位到具体的某个数据库的某张真实表，格式为ds_name.t_product_x，其中ds_name为数据库名称，t_product_x为真实表的名称。

绑定表：

指分片规则下的主表和子表，这个概念有点复杂，后面再解释它。

2、 ShardingSphere的分片

ShardingSphere中存在分片键、分片算法和分片策略3种概念。
1．分片键分片键是指以表的什么字段进行分片。例如，之前我们使用用户编号（user_id）进行分片，那么user_id就是分片键。ShardingSphere还能支持多个字段的分片。
2．分片算法分片算法是我们的核心内容，在ShardingSphere中，定义了ShardingAlgorithm接口作为其底层接口，在此基础上，还定义了几个子接口，如图14-9所示。[插图]图14-9 ShardingAlgorithm接口及其子接口从图14-9中可以看出，ShardingSphere提供了以下4种分片的子接口。●PreciseShardingAlgorithm：精确分片策略，主要支持SQL中的“=”和“IN”。●RangeShardingAlgorithm：范围分片策略，主要支持SQL中的“BETWEEN…AND…”。
●ComplexKeysShardingAlgorithm：复合分片，可以支持多分片键，但是需要自己实现分片算法。
●HintShardingAlgorithm：如果非SQL解析方式进行分片的，可以实现这个接口，自定义自己的分片算法，如使用映射表的方式。
它们都是接口，没有实现类，为了更好地使用它们，ShardingSphere采用了策略（Strategy）模式，这便是下面要谈到的分片策略。
3．分片策略在上面，我们讨论了分片算法（ShardingAlgorithm），但是它们都只是定义接口，并无具体的实现。ShardingSphere的分片是通过策略接口ShardingStrategy来实现的，并且基于这个接口，它还提供了5个实现类，我们可以根据自己的业务需要来选择具体的分片策略，如图14-10所示。[插图]图14-10 分片策略从图14-10中可以看到，分片策略分为以下5种。●StandardShardingStrategy：标准分片策略。它只支持单分片键，不支持多分片键。它内含两种分片算法，即精确分片（PreciseShardingAlgorithm）和范围分片（RangeShardingAlgorithm）。●ComplexShardingStrategy：复合分片策略。它能支持多分片键，但是你需要自己编写分片逻辑。●HintShardingStrategy：提示分片策略。如果不依赖SQL层面的分片策略，你需要根据自己的业务规则进行编写分片策略。
●InlineShardingStrategy：行表达式分片策略。它主要支持那些简单进行分片的策略。例如，如果产品表分为t_product_0和t_product_1，那么可以写作t+prodcut$->{id % 2}，表示按照产品编号（id）对2取模，进行分片。●NoneShardingStrategy：不分片策略。它将返回所有可选择的数据库名或者表名。

6、分布式事务