SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

这篇具有很好参考价值的文章主要介绍了SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

1.服务配置中心

1.1 服务配置中心介绍

 1.2 Nacos Config 实践

1.2.1 Nacos config 入门案例

 1.2.2  Nacos 配置动态刷新

1.2.3 配置共享

1.2.4 nacos 几个概念

 文章来源地址https://www.toymoban.com/news/detail-441835.html

2.分布式锁

2.1 分布式锁介绍

 2.2 Redisson 

2.2.1 Redisson 实践

 2.2.2 Redisson 原理


 

1.服务配置中心

1.1 服务配置中心介绍

首先我们来看一下,微服务架构下关于配置文件的一些问题:
1.配置文件相对分散。在一个微服务架构下,配置文件会随着微服务的增多变的越来越多,而且分散在各个微服务中,不好统─配置和管理。
⒉.配置文件无法区分环境。微服务项目可能会有多个环境,例如︰测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的,一旦需要修改,就需要我们去各个微服务下手动维护,这比较困难。
3.配置文件无法实时更新。我们修改了配置文件之后,必须重新启动微服务才能使配置生效,这对一个正在运行的项目来说是非常不友好的。


基于上面这些问题,我们就需要配置中心的加入来解决这些问题。
配置中心的思路是:
1.首先把项目中各种配置全部都放到一个集中的地方进行统—管理,并提供—套标准的接口。
2.当各个服务需要获取配置的时候,就来配置中心的接口拉取自己的配置。
3..当配置中心中的各种参数有更新的时候,也能通知到各个服务实时的过来同步最新的信息,使之动态更新

当加入了服务配置中心之后,我们的系统架构图会变成下面这样:
SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 1.2 Nacos Config 实践

使用nacos作为配置中心,其实就是将nacos当做一个服务端,将各个微服务看成是客户端,我们将各个微服务的配置文件统一存放在nacos上,然后各个微服务从nacos上拉取配置即可。

1.2.1 Nacos config 入门案例

导入依赖

       <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>

在微服务中添加nacos config的配置,不能使用原来的application.yml作为配置文件,而是新建一个bootstrap.yml作为配置文件。

配置文件优先级从高到低为:

bootstrap.properties>bootstrap.yml>application.properties>application.yml

这里举例为订单微服务,首先新建个bootstrap.yml文件,然后配置如下:

spring:
  application:
    name: provider
  profiles:
    active: dev #环境标识
  cloud:
    nacos:
      server-addr: localhost:8848
      config:
        file-extension: yaml #配置文件格式
      discovery:
        cluster-name: BJ
    sentinel:
      transport:
        dashboard: localhost:8080

然后在nacos配置文件中配置Data ID为bootstrap中配置订单微服务名+环境标识+配置文件格式。如下图;

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 1.2.2  Nacos 配置动态刷新

实现在配置中心修改配置文件内容后,程序内部引用可以自动刷新,我们可以在自己创建的DataId配置文件中,更改项:

config: 
 
appName: product

硬编码方式

 @GetMapping("/test")
    public String test(){
        String property = configurableApplicationContext.getEnvironment().getProperty("config.appName");
        return property;
    }

注解方式

@RestController
@RefreshScope  /* 只需要在需要动态读取配置的类上添加此注解就可以 */

public class UserController {

    @Value("${config.appName}")
    private String appName;

    @GetMapping("/test")
    public String test(){
        return appName;
    }

}

1.2.3 配置共享

当配置越来越多的时候,我们就发现有很多配置是重复的,这时候就考虑可不可以将公共配置文件提取出来,然后实现共享。共享存在两种场景:同一微服务,不同场景(namespace)下共享;不同微服务之间共享。

 同一微服务,不同场景下共享配置

比如上面的订单微服务,开发环境的配置文件为provider-dev.yaml,测试环境的配置文件为provider-test.yaml,同一微服务在不同场景下共享可以配置provider.yaml文件。

 

 不同微服务之间共享共享配置

在nacos中新建all-service.yml文件作为共享配置,然后引入配置代码如下:

spring:
  application:
    name: provider
  profiles:
    active: dev
  cloud:
    nacos:
      server-addr: localhost:8848
      config:
        file-extension: yaml
        shared-dataids: allservice.yaml #配置要引入的配置
        refreshable-dataids: allservice.yaml #配置要实现动态配置刷新的配置
      discovery:
        cluster-name: BJ
    sentinel:
      transport:
        dashboard: localhost:8080

1.2.4 nacos 几个概念

命名空间(Namespace)
命名空间可用于进行不同环境的配置隔离。一般一个环境划分到一个命名空间
配置分组(Group)
配置分组用于将不同的服务可以归类到同一分组。一般将一个项目的配置分到一组
配置集(Data ID)
在系统中,一个配置文件通常就是一个配置集。一般微服务的配置就是一个配置集
 

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 

2.分布式锁

2.1 分布式锁介绍

分布式锁:满足分布式系统或集群模式下多进程可见并且互斥的锁。

在单体的应用开发场景中,在多线程的环境下,涉及并发同步的时候,为了保证一个代码块在同一时间只能由一个线程访问,我们一般可以使用synchronized语法和ReetrantLock去保证,这实际上是本地锁的方式。也就是说,在同一个JVM内部,大家往往采用synchronized或者Lock的方式来解决多线程间的安全问题。但在分布式集群工作的开发场景中,在JVM之间,那么就需要一种更加高级的锁机制,来处理种跨JVM进程之间的线程安全问题.

总之,对于分布式场景,我们可以使用分布式锁,它是控制分布式系统之间互斥访问共享资源的一种方式。比如说在一个分布式系统中,多台机器上部署了多个服务,当客户端一个用户发起一个数据插入请求时,如果没有分布式锁机制保证,那么那多台机器上的多个服务可能进行并发插入操作,导致数据重复插入,对于某些不允许有多余数据的业务来说,这就会造成问题。而分布式锁机制就是为了解决类似这类问题,保证多个服务之间互斥的访问共享资源,如果一个服务抢占了分布式锁,其他服务没获取到锁,就不进行后续操作。如下图:

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 

分布式锁要具有一下特征:

  • 互斥性。在任意时刻,只有一个客户端能持有锁。
  • 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
  • 具有容错性。只要大部分的 Redis 节点正常运行,客户端就可以加锁和解锁。
  • 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。


SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 分布式锁的核心是实现多进程之间互斥,而满足这一点的方式有很多,常见的有三种:

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 2.2 Redisson 

Redisson是一个在Redis的基础上实现的Java驻内存数据网格(In-Memory Data Grid)。它不仅提供了一系列的分布式的Java常用对象,还提供了许多分布式服务,其中就包含了各种分布式锁的实现。

假如我们在微服务架构中,有个订单秒杀服务,要求同一个优惠券,一个用户只能下一单。在单机架构中,我们使用synchronized或者Lock的方式就可以解决这个问题,将查询数据库是否下过单和下单扣减库存过程锁在一块,只允许获得锁的一个线程进行访问。如果不加锁,假如高并发场景下,一百个线程同时访问并且都是同一个用户,然后就会出现多个线程先进行查询操作,如果数据库中没有该订单信息,然后这多个线程就会都符合要求进行下单扣减库存产生多个订单,就会违背一个用户只能下一单的情况。而在分布式中,因为多个服务都是以集群形式的存在存在多个jvm实例,synchronized或者Lock的方式只是针对的同一个JVM内部,这就需要分布式锁。这里使用Redission进行模拟,模拟在微服务集群高并发场景下多个用户线程下下单同一订单扣减库存情况。

2.2.1 Redisson 实践

导入依赖

      <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.19.0</version>
        </dependency>

代码如下:

本代码模拟根据订单id查询到订单信息,然后根据订单信息中的goodsId传递到商品微服务,进行对应商品的库存减一,然后返回修改后的商品信息 存储到订单信息对应商品Goods属性上。加分布式锁是保证在同一集群中不同微服务进程中的这个方法只能由获得锁的线程进行处理业务,由于是代码模拟,所以在设计代码的时候相对随意。

    @GetMapping("/order/pay/{id}")
    public Orders1 pay(@PathVariable("id") Long id){
        RLock lock = redissonClient.getLock("lockorder" + id);
        boolean b = lock.tryLock();
        if(!b) {
            return null;
        }
        try {
            Orders1 orders1 = orders1Mapper.selectById(id);
            Goods goods = feign.goodsservice(orders1.getGoodsId());
            orders1.setGoods(goods);
            return orders1;
        }finally {
            lock.unlock();
        }
    }

debug验证结果如下:

下面订单微服务集群为8080端口和9202端口,先访问8080端口,再访问9202端口,在debug环境下验证了我们的猜想。

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 2.2.2 Redisson 原理

此章节引用网上相关描述

Redisson 这个框架对Redis分布式锁的实现原理图如下:

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

 1.获取锁
一个Redission客户端1要加锁,它首先会根据hash节点选择一台机器,紧接着就会发送一段lua脚本到redis上,比如加锁的那个锁key就是”mylock”,并且设置的时间是30秒,30秒后mylock锁就会被释放。
2.锁互斥机制
如果这个时候Redission客户端2来加锁,它也会会根据hash节点选择一台机器,然后执行了同样的一段lua脚本。
它首先回来判断《mylock》这个锁存在吗?如果存在则Redission客户端2会获得一个数字,这个数字就是mylock这个锁的剩余生存时间。
此时Redission客户端2就会进入到一个while循环,就是CAS不停的自旋尝试加锁,知道成功为止。
3.看门狗机制
如果负责储存这个分布式锁的Redisson节点宕机以后,而且这个锁正好处于锁住的状态时,这个锁会出现锁死的状态。
为了避免这种情况的发生,Redisson内部提供了一个监控锁的看门狗,它的作用是在Redisson实例被关闭前,不断的延长锁的有效期。线程A拿到锁需要处理2秒,但是锁的超时时间只有1秒,也就是说锁超时的时候,业务还没处理完。这时候线程B就进来了又拿到锁,导致加锁跟解锁的时候并不是同一线程。看门狗的作用就是当遇到这种情况的时候,看门狗会定时去查看一下这个线程A是否还在执行任务,如果还在执行则给他继续延长时间。

4.可重入加锁机制
我们知道ReentrantLock是可重入锁,它的特点就是:同一个线程可以重复拿到同一个资源的锁,Redisson也能很好的满足这点。
Redisson客户端1获得mylock锁时,里面会有一个hash结构的数据,如下图所示:

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解
 

SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解

上面这图的意思就是可重入锁的机制,它最大的优点就是相同线程不需要在等待锁,而是可以直接进行相应操作。

 


5.释放锁机制
如果发现加锁次数变为0了,那么说明这个Redisson客户端1不再持有锁了,Redisson客户端2就可以加锁了。

 

 

 

到了这里,关于SpringCloud Alibaba 之 Config配置中心,Redis分布式锁详解的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Java之SpringCloud Alibaba【三】【微服务Nacos-config配置中心】

    Java之SpringCloud Alibaba【一】【Nacos一篇文章精通系列】 跳转 Java之SpringCloud Alibaba【二】【微服务调用组件Feign】 跳转 Java之SpringCloud Alibaba【三】【微服务Nacos-config配置中心】 跳转 Java之SpringCloud Alibaba【四】【微服务 Sentinel服务熔断】 跳转 Java之SpringCloud Alibaba【五】【微服务

    2024年02月16日
    浏览(48)
  • config: 分布式配置中心 & bus: 消息总线

    每一个应用程序在运行时都需要相应的yml配置,分布式架构下多个服务器和应用服务面临着多个配置文件,在修改和发布上难度较大,需要有一个管理中心来统一管理,优雅的解决了配置的动态变更、持久化、运维成本等问题 流程: 分布式配置中心去远程仓库将创建好的yml文件

    2023年04月23日
    浏览(45)
  • 分布式事务 —— SpringCloud Alibaba Seata

    传统的单体应用中,业务操作使用同一条连接操作不同的数据表,一旦出现异常就可以整体回滚。随着公司的快速发展、业务需求的变化,单体应用被拆分成微服务应用,原来的单体应用被拆分成多个独立的微服务,分别使用独立的数据源,业务操作需要调用三个服务来完成

    2024年02月08日
    浏览(42)
  • SpringCloud Alibaba-Seata分布式事务

    维基百科:https://zh.wikipedia.org/wiki/X/Open_XA 分布式事务的实现有许多种,其中较经典是由Tuxedo提出的XA分布式事务协议,XA协议包含二阶段提交(2PC)和三阶段提交(3PC)两种实现。其他还有 TCC、MQ 等最终一致性解决方案。 1.1 DTP模型 https://www.ibm.com/docs/zh/db2/10.5?topic=managers-de

    2024年02月09日
    浏览(35)
  • 【SpringCloud Alibaba】Nacos Config配置管理与Gateway 网关

    目录 一、Config 远程配置 1.1 config 介绍 1.2 bootstrap.yml 配置文件 二、Gateway 网关 2.1 gateway 介绍 2.2 gateway 使用 2.2.1 方式一 2.2.2 方式二(动态路由)         微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大 量的服务。

    2024年02月02日
    浏览(57)
  • SpringCloud Alibaba 配置中心功能

    一、快速入门 1、创建工程nacos-client7777 pom application.yml bootstrap.yml 主启动类 @EnableDiscoveryClient controller 在Nacos中添加配置信息 https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html 测试:http://localhost:7777/config/name 注意:因为添加了@RefreshScope注解,所以我们更改配置信息内容,会动态刷新

    2024年02月04日
    浏览(35)
  • SpringCloud Alibaba——配置中心技术选型

    功能点 Spring Cloud Config ApolloNacos Nacos 版本管理 支持(Git) 支持 支持 配置实时推送 支持(Spring CloudBus) 支贸持(HTTP长轮询1s内) 支持(HTTP长轮询1s内或者grpc) 配置回滚 支持(Git) 支持 支持 灰度发布 支持(调用机器接口) 支持 不支持 权限管理 支持(依赖Git) 支持 支持 配置生效时间 重启

    2024年02月16日
    浏览(42)
  • 注册中心/配置管理 —— SpringCloud Alibaba Nacos

    Nacos 是一个易于使用的动态服务发现、配置和服务管理平台,用于构建云原生的应用程序 Nacos 的关键特性包括以下几项: 服务发现和服务健康监测:服务提供者使用原生 SDK、OpenAPI 等注册服务后,服务消费者可以使用 HTTPAPI 查找和发现服务。Nacos 提供对服务的实时健康检查

    2024年02月14日
    浏览(57)
  • SpringCloud Alibaba - Seata 四种分布式事务解决方案(XA、AT)+ 实践部署(上)

    目录 一、Seata 分布式事务解决方案 1.1、XA 模式 1.1.1、XA模式理论 第一阶段: 第二阶段: 1.1.2、Seata 框架中的 XA 模式 第一阶段: 第二阶段: 1.1.3、XA 模式的优缺点 1.2.4、实现Seata 的 XA 模式 a)修改 application 文件(每一个参与事务的微服务) b)给发起全局事务中的入口方法

    2024年04月14日
    浏览(40)
  • SpringCloud 配置中心【Nacos_Config】

    目录 1. SpringCloud Config 2. Nacos_Config 3. 使用 Nacos Config 添加/配置 外部配置文件 3.1 添加/配置命名空间 3.2 添加/配置 外部配置文件 3.3 外部文件克隆到其他空间 4. 新建子模块【config_client】 4.1 父模块pom文件依赖结构          4.2 子模块pom文件结构 4.3 配置子模块 bootstrap.yml文件

    2024年02月01日
    浏览(51)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包