Redission分布式锁详解

news2024/9/24 15:25:17

前言

​ 在分布式系统中，当不同进程或线程一起访问共享资源时，会造成资源争抢，如果不加以控制的话，就会引发程序错乱。而分布式锁它采用了一种互斥机制来防止线程或进程间相互干扰，从而保证了数据的一致性。

常见的分布式锁实现方案

  • 基于 Redis 实现分布式锁
  • 基于 Zookeeper 实现分布式锁

介绍

​ **Redission是一个基于Redis实现的Java分布式对象存储和缓存框架。它提供了丰富的分布式数据结构和服务。**例如：分布式锁、分布式队列、分布式Rate Limiter等。

分布式锁的特点

  • 互斥性是分布式锁的重要特点，在任意时刻，只有一个线程能够持有锁
  • **锁的超时时间。**一个线程在持锁期间挂掉了而没主动释放锁，此时通过超时时间来保证该线程在超时后可以释放锁，这样其他线程才可以继续获取锁；
  • 加锁和解锁必须是由同一个线程来设置
  • Redis 是缓存型数据库，拥有很高的性能，因此加锁和释放锁开销较小，并且能够很轻易地实现分布式锁。

特性

高性能

​ Redission是基于Redis的，因此它继承了Redis的高性能和低延迟的特性。同时，它采用了Netty的NIO框架，能够并发地处理大量的请求，使得应用程序的响应速度得到了极大的提升。

易用性

​ Redission提供了丰富的API和方法，同时还提供了文档和示例，让开发者易于上手和使用。此外，它支持自动配置和灵活的配置方式，使得开发者可以根据自己的需求进行配置和调整。

可扩展性

​ Redission的分布式架构使得它支持水平扩展，可以将数据和请求分散到更多的节点上进行处理。这也使得它具备了更好的容错能力和可靠性。

常用场景

缓存

​ Redission支持不同的数据存储类型，例如：String、List、Set、Map、BloomFilter、HyperLogLog等，它可以将这些数据存储在Redis中，以实现数据缓存的功能，从而提高应用程序的性能和响应速度。

分布式锁

​ Redission提供了可重入锁、公平锁等常用的分布式锁，还支持异步执行、锁的自动续期、锁的等待等特性。

分布式队列

​ Redission提供了分布式队列的实现，我们可以在不同的节点之间快速、可靠地实现任务的传递和处理。

Redis分布式锁命令

常用命令

​ Redis 分布式锁常用命令如下所示：

  • SETNX key val：仅当key不存在时，设置一个 key 为 value 的字符串，返回1；若 key 存在，设置失败，返回 0；
  • Expire key timeout：为 key 设置一个超时时间，以 second 秒为单位，超过这个时间锁会自动释放，避免死锁；
  • DEL key：删除 key。
    **上述 SETNX 命令相当于抢占锁操作，EXPIRE 是为避免出现意外用来设置锁的过期时间，也就是说到了指定的过期时间，该客户端必须让出锁，让其他客户端去持有。**

​ 但还有一种情况，如果在 SETNX 和 EXPIRE 之间服务器进程突然挂掉，也就是还未设置过期时间，这样就会导致 EXPIRE 执行不了，因此还是会造成“死锁”的问题。为了避免这个问题，Redis 作者在 2.6.12 版本后，对 SET 命令参数做了扩展，使它可以同时执行 SETNX 和 EXPIRE 命令，从而解决了死锁的问题。

直接使用 SET 命令实现，语法格式如下：

SET key value [expiration EX seconds|PX milliseconds] [NX|XX]
  • EX second：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
  • PX millisecond：设置键的过期时间为毫秒。SET key value PX millisecond 效果等同于 PSETEX key millisecondvalue 。
  • NX：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
  • XX：只在键已经存在时，才对键进行设置操作。

原理

使用

使用redisson实现分布式锁的操作步骤，三部曲

  • 第一步： 获取锁 RLock redissonLock = redisson.getLock(lockKey);
  • 第二步： 加锁，实现锁续命功能 redissonLock.lock();
  • 第三步： 释放锁 redissonLock.unlock();

在这里插入图片描述

Redis 实现分布式锁主要步骤

  1. 指定一个 key 作为锁标记，存入 Redis 中，指定一个 唯一的用户标识 作为 value。
  2. 当 key 不存在时才能设置值，确保同一时间只有一个客户端进程获得锁，满足 互斥性 特性。
  3. 设置一个过期时间，防止因系统异常导致没能删除这个 key，满足 防死锁 特性。
  4. 当处理完业务之后需要清除这个 key 来释放锁，清除 key 时需要校验 value 值，需要满足 只有加锁的人才能释放锁 。

注意：

​ 以上实现步骤考虑到了使用分布式锁需要考虑的互斥性、防死锁、加锁和解锁必须为同一个进程等问题，但是锁的续期无法实现。所以通常情况都是采用 Redisson 实现 Redis 的分布式锁，借助 Redisson 的 WatchDog 机制 能够很好的解决锁续期的问题。

​ Watch Dog 机制其实就是一个后台定时任务线程，获取锁成功之后，会将持有锁的线程放入到一个 RedissonLock.EXPIRATION_RENEWAL_MAP里面，然后每隔 10 秒 （internalLockLeaseTime / 3） 检查一下，如果客户端 1 还持有锁 key（判断客户端是否还持有 key，其实就是遍历 EXPIRATION_RENEWAL_MAP 里面线程 id 然后根据线程 id 去 Redis 中查，如果存在就会延长 key 的时间），那么就会不断的延长锁 key 的生存时间。

Redisson的锁机制

1）加锁机制

​ 加锁其实是通过一段 lua 脚本实现的。这里 KEYS[1] 代表的是你加锁的 key，比如你自己设置了加锁的那个锁 key 就是 “myLock”。

if (redis.call('exists', KEYS[1]) == 0) then " +
   "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
   "redis.call('pexpire', KEYS[1], ARGV[1]); " +
   "return nil; " +
   "end; " +
"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
    "redis.call('pexpire', KEYS[1], ARGV[1]); " +
    "return nil; " +
    "end; " +
"return redis.call('pttl', KEYS[1]);"

​ ARGV[1] 代表的是锁 key 的默认生存时间，默认 30 秒。ARGV[2] 代表的是加锁的客户端的 ID，类似于下面这样：285475da-9152-4c83-822a-67ee2f116a79:52。至于最后面的一个 1 是为了后面可重入做的计数统计.

​ 第一段 if 判断语句，就是用 exists myLock 命令判断一下，如果你要加锁的那个锁 key 不存在的话，你就进行加锁。如何加锁呢？使用 hincrby 命令设置一个 hash 结构。接着会执行 pexpire myLock 30000 命令，设置 myLock 这个锁 key 的生存时间是 30 秒。到此为止，加锁完成。

2）锁互斥机制

​ 第二个 if 判断，判断一下，myLock 锁 key 的 hash 数据结构中，是否包含客户端 2 的 ID，这里明显不是，因为那里包含的是客户端 1 的 ID。所以，客户端 2 会执行：

return redis.call('pttl', KEYS[1]);

返回的一个数字，这个数字代表了 myLock 这个锁 key 的剩余生存时间。

3）Watch dog 机制

​ 主要用于锁续费服务。只要客户端 1 一旦加锁成功，就会启动一个 Watch Dog。也就是说leaseTime 必须是 -1 才会开启 Watch Dog 机制，也就是如果你想开启 Watch Dog 机制必须使用默认的加锁时间为 30s。

4）可重入加锁机制

​ 当锁key已经存在，第二个 if 判断会成立，因为 myLock 的 hash 数据结构中包含的那个 ID 即客户端 1 的 ID，此时就会执行可重入加锁的逻辑，

5）锁释放机制

  1. 删除锁。
  2. 广播释放锁的消息，通知阻塞等待的进程（向通道名为 redisson_lock__channel publish 一条 UNLOCK_MESSAGE 信息）。
  3. 取消 Watch Dog 机制，即将 RedissonLock.EXPIRATION_RENEWAL_MAP 里面的线程 id 删除，并且 cancel 掉 Netty 的那个定时任务线程。

源码分析

​ 重点主要是依赖lua脚本的原子性，实现加锁和释放锁的功能。

实例化RedissonLock

  • super(commandExecutor, name); 父类name赋值，后续通过getName()获取
  • commandExecutor： 执行lua脚本的executor
  • id 是个UUID， 后面被用来当做和threadId组成 value值**，用作判断加锁和释放锁是否是同一个线程的校验。**
  • internalLockLeaseTime : 取自 Config#lockWatchdogTimeout，默认30秒，这个参数还有另外一个作用，锁续命的执行周期 internalLockLeaseTime/3 = 10秒

加锁和锁的续命redissonLock.lock()

  • **Thread.currentThread().interrupt()。**当发生异常，则通知线程进行中断并释放锁。

  • lockInterruptibly(-1, null); 此环节会先获取当前线程的线程ID，之后会尝试获取锁的剩余时间。

    ​ 如果当前锁的剩余时间为null,说明没有线程持有该锁，直接返回让当前线程加锁成功。如果当前线程的剩余时间不为null,就会一直尝试获取锁。

    ​ Redisson 提供了一个续期机制， 只要客户端 1 一旦加锁成功，就会启动一个 Watch Dog。**也就是说leaseTime 必须是 -1 才会开启 Watch Dog 机制，也就是如果你想开启 Watch Dog 机制必须使用默认的加锁时间为 30s。**如果你自己自定义时间，超过这个时间，锁就会自定释放，并不会延长。

  • **tryAcquireAsync(leaseTime, unit, threadId)（自旋获取锁的方法）。**其内部专门创建异步任务用于尝试获取锁。其任务内部会注册监听事件，当剩余时间为null，就会再次去获取锁，并给锁延长过期时间。

  • tryLockInnerAsync 其内部实现是lua脚本。

  • scheduleExpirationRenewal(final long threadId)。又是lua脚本 判断是否存在，存在就调用pexpire

释放锁redissonLock.unlock()

  • unlock()。先获取锁状态，如果锁状态为null，则抛出异常。否则就释放锁，并删除key。
  • unlockInnerAsync(long threadId)。unlock的内部实现，也是lua脚本，用于获取当前线程的锁状态。

Redissson tryLock源码

@Override
    public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
        long time = unit.toMillis(waitTime);
        long current = System.currentTimeMillis();
        long threadId = Thread.currentThread().getId();
        // 1.尝试获取锁
        Long ttl = tryAcquire(leaseTime, unit, threadId);
        // lock acquired
        if (ttl == null) {
            return true;
        }

        // 申请锁的耗时如果大于等于最大等待时间，则申请锁失败.
        time -= System.currentTimeMillis() - current;
        if (time <= 0) {
            acquireFailed(threadId);
            return false;
        }

        current = System.currentTimeMillis();

        /**
         * 2.订阅锁释放事件，并通过 await 方法阻塞等待锁释放，有效的解决了无效的锁申请浪费资源的问题：
         * 基于信息量，当锁被其它资源占用时，当前线程通过 Redis 的 channel 订阅锁的释放事件，一旦锁释放会发消息通知待等待的线程进行竞争.
         *
         * 当 this.await 返回 false，说明等待时间已经超出获取锁最大等待时间，取消订阅并返回获取锁失败.
         * 当 this.await 返回 true，进入循环尝试获取锁.
         */
        RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
        // await 方法内部是用 CountDownLatch 来实现阻塞，获取 subscribe 异步执行的结果（应用了 Netty 的 Future）
        if (!subscribeFuture.await(time, TimeUnit.MILLISECONDS)) {
            if (!subscribeFuture.cancel(false)) {
                subscribeFuture.onComplete((res, e) -> {
                    if (e == null) {
                        unsubscribe(subscribeFuture, threadId);
                    }
                });
            }
            acquireFailed(threadId);
            return false;
        }

        try {
            // 计算获取锁的总耗时，如果大于等于最大等待时间，则获取锁失败.
            time -= System.currentTimeMillis() - current;
            if (time <= 0) {
                acquireFailed(threadId);
                return false;

              }

            /**
             * 3.收到锁释放的信号后，在最大等待时间之内，循环一次接着一次的尝试获取锁
             * 获取锁成功，则立马返回 true，
             * 若在最大等待时间之内还没获取到锁，则认为获取锁失败，返回 false 结束循环
             */
            while (true) {
                long currentTime = System.currentTimeMillis();

                // 再次尝试获取锁
                ttl = tryAcquire(leaseTime, unit, threadId);
                // lock acquired
                if (ttl == null) {
                    return true;
                }
                // 超过最大等待时间则返回 false 结束循环，获取锁失败
                time -= System.currentTimeMillis() - currentTime;
                if (time <= 0) {
                    acquireFailed(threadId);
                    return false;
                }

                /**
                 * 6.阻塞等待锁（通过信号量(共享锁)阻塞,等待解锁消息）：
                 */
                currentTime = System.currentTimeMillis();
                if (ttl >= 0 && ttl < time) {
                    //如果剩余时间(ttl)小于wait time ,就在 ttl 时间内，从Entry的信号量获取一个许可(除非被中断或者一直没有可用的许可)。
                    getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                } else {
                    //则就在wait time 时间范围内等待可以通过信号量
                    getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
                }

                // 更新剩余的等待时间(最大等待时间-已经消耗的阻塞时间)
                time -= System.currentTimeMillis() - currentTime;
                if (time <= 0) {
                    acquireFailed(threadId);
                    return false;
                }
            }
        } finally {
            // 7.无论是否获得锁,都要取消订阅解锁消息
            unsubscribe(subscribeFuture, threadId);
        }
//        return get(tryLockAsync(waitTime, leaseTime, unit));
    }

流程分析：

  1. 尝试获取锁，返回 null 则说明加锁成功，返回一个数值，则说明已经存在该锁，ttl 为锁的剩余存活时间。
  2. 如果此时客户端 2 进程获取锁失败，那么使用客户端 2 的线程 id（其实本质上就是进程 id）通过 Redis 的 channel 订阅锁释放的事件，。如果等待的过程中一直未等到锁的释放事件通知，当超过最大等待时间则获取锁失败，返回 false，也就是第 39 行代码。如果等到了锁的释放事件的通知，则开始进入一个不断重试获取锁的循环。
  3. 循环中每次都先试着获取锁，并得到已存在的锁的剩余存活时间。如果在重试中拿到了锁，则直接返回。如果锁当前还是被占用的，那么等待释放锁的消息，具体实现使用了 JDK 的信号量 Semaphore 来阻塞线程，当锁释放并发布释放锁的消息后，信号量的 release() 方法会被调用，此时被信号量阻塞的等待队列中的一个线程就可以继续尝试获取锁了。

特别注意：

​ 以上过程存在一个细节，这里有必要说明一下，也是分布式锁的一个关键点：当锁正在被占用时，等待获取锁的进程并不是通过一个 while(true) 死循环去获取锁，而是利用了 Redis 的发布订阅机制,通过 await 方法阻塞等待锁的进程，有效的解决了无效的锁申请浪费资源的问题。

优缺点

方案优点

  1. Redisson 通过 Watch Dog 机制很好的解决了锁的续期问题。
  2. 和 Zookeeper 相比较，Redisson 基于 Redis 性能更高，适合对性能要求高的场景。
  3. 通过 Redisson 实现分布式可重入锁，比原生的 SET mylock userId NX PX milliseconds + lua 实现的效果更好些，虽然基本原理都一样，但是它帮我们屏蔽了内部的执行细节。
  4. 在等待申请锁资源的进程等待申请锁的实现上也做了一些优化，减少了无效的锁申请，提升了资源的利用率。

方案缺点

​ **使用 Redisson 实现分布式锁方案最大的问题就是如果你对某个 Redis Master 实例完成了加锁，此时 Master 会异步复制给其对应的 slave 实例。**但是这个过程中一旦 Master 宕机，主备切换，slave 变为了 Master。接着就会导致，客户端 2 来尝试加锁的时候，在新的 Master 上完成了加锁，而客户端 1 也以为自己成功加了锁，此时就会导致多个客户端对一个分布式锁完成了加锁，这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。

​ 所以这个就是 Redis Cluster 或者说是 Redis Master-Slave 架构的主从异步复制导致的 Redis 分布式锁的最大缺陷（在 Redis Master 实例宕机的时候，可能导致多个客户端同时完成加锁）。

​

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/798396.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

【低代码】对低代码未来发展方向的思考

【低代码】对低代码未来发展方向的思考

写在前面 看似不起波澜&#xff0c;日复一日的努力&#xff0c;会突然在某一天&#xff0c;让你看到坚持的意义。 1 基础介绍 1.1 什么是低代码 低代码开发是一种软件开发方法&#xff0c;它允许开发人员使用图形界面和少量代码来快速构建应用程序。开发人员可以使用预定义的…
阅读更多...
Docker 之 Consul容器服务更新与发现

Docker 之 Consul容器服务更新与发现

一、Consul介绍 1、什么是服务注册与发现 服务注册与发现是微服务架构中不可或缺的重要组件。起初服务都是单节点的&#xff0c;不保障高可用性&#xff0c;也不考虑服务的压力承载&#xff0c;服务之间调用单纯的通过接口访问。直到后来出现了多个节点的分布式架构&#xff…
阅读更多...
你们公司的【前端项目】是如何做测试的？字节10年测试经验的我这样做的...

你们公司的【前端项目】是如何做测试的？字节10年测试经验的我这样做的...

前端项目也叫web端项目&#xff08;通俗讲就是网页上的功能&#xff09;是我们能够在屏幕上看到并产生交互的体验。 前端项目如何做测试&#xff1f; 要讲清楚这个问题&#xff0c;先需要你对测试流程现有一个全局的了解&#xff0c;先上一张测试流程图&#xff1a; 测试流程…
阅读更多...
QT--day3(定时器事件、对话框)

QT--day3(定时器事件、对话框)

头文件代码&#xff1a; #ifndef WIDGET_H #define WIDGET_H#include <QWidget> #include <QTimerEvent> //定时器事件处理时间头文件 #include <QTime> //时间类 #include <QtTextToSpeech> #include <QPushButton> #include <QLabel&g…
阅读更多...
AXI协议之AXILite开发设计（二）

AXI协议之AXILite开发设计（二）

微信公众号上线&#xff0c;搜索公众号小灰灰的FPGA,关注可获取相关源码&#xff0c;定期更新有关FPGA的项目以及开源项目源码&#xff0c;包括但不限于各类检测芯片驱动、低速接口驱动、高速接口驱动、数据信号处理、图像处理以及AXI总线等 二、AXI-Lite关键代码分析 1、时钟与…
阅读更多...
Bootstrap框架（组件）

Bootstrap框架（组件）

目录 前言一&#xff0c;组件1.1&#xff0c;字体图标1.2&#xff0c;下拉菜单组件1.2.1&#xff0c;基本下拉菜单1.2.2&#xff0c;按钮式下拉菜单 1.3&#xff0c;导航组件1.3.1&#xff0c;选项卡导航1.3.2&#xff0c;胶囊式导航1.3.3&#xff0c;自适应导航1.3.4&#xff…
阅读更多...
【LeetCode】114.二叉树展开为链表

【LeetCode】114.二叉树展开为链表

题目 给你二叉树的根结点 root &#xff0c;请你将它展开为一个单链表&#xff1a; 展开后的单链表应该同样使用 TreeNode &#xff0c;其中 right 子指针指向链表中下一个结点&#xff0c;而左子指针始终为 null 。展开后的单链表应该与二叉树 先序遍历 顺序相同。 示例 1&…
阅读更多...
【黑马头条之图片识别文字审核敏感词】

【黑马头条之图片识别文字审核敏感词】

本笔记内容为黑马头条项目的图片识别文字审核敏感词部分 目录 一、需求分析 二、图片文字识别 三、Tess4j案例 四、管理敏感词和图片文字识别集成到文章审核 一、需求分析 产品经理召集开会&#xff0c;文章审核功能已经交付了&#xff0c;文章也能正常发布审核。对于上次…
阅读更多...
【已解决】React Antd Form.List 表单校验无飘红提示的问题

【已解决】React Antd Form.List 表单校验无飘红提示的问题

背景 我想对 Form.List 构建的表单进行校验&#xff0c;比如下拉框中的内容应当至少有一个 XX&#xff0c;表单的长度不能少于多少等等对 List 内容进行校验&#xff0c;并给出飘红提示 问题 比如我有这样一段代码来实现对 list 具体内容的校验&#xff0c;但是写完后发现没有…
阅读更多...
专科程序员，想要面试获胜必须要做的两个点

专科程序员，想要面试获胜必须要做的两个点

这两天看到一篇关于专科程序员找工作的文章&#xff0c;感受到了其中的坎坷 那么作为专科程序员&#xff0c;我们应该如何获胜&#xff0c;获得工作机会呢&#xff1f; 根据我的经验&#xff0c;以下两点一定会给你带来更多的机会。 一个是学好英语 另外一个是构建自己的…
阅读更多...
高层金属做power mesh如何避免via stack

高层金属做power mesh如何避免via stack

随着工艺精进&#xff0c;pr要处理的层次也越来越多&#xff0c;如何选择power plan的层次尤为关键&#xff0c;一方面决定ir drop的大小&#xff0c;影响着芯片的功能&#xff0c;一方面决定绕线资源&#xff0c;影响面积。 选择高层metal做power mesh的关键在于厚金属&#…
阅读更多...
微信小程序开发之配置菜单跳转到自定义页面

微信小程序开发之配置菜单跳转到自定义页面

需求: 用户点击公众号菜单跳转到自定义带引流码的链接 公众号相关文档: 网页授权 | 微信开放文档 大致流程: 1.在公众号菜单配置链接: https://open.weixin.qq.com/connect/oauth2/authorize?appidXXXXXXXXXXXX&redirect_urihttps%3A%2F%2F测试域名%2Fws_dabai%2Fwe…
阅读更多...
i.MX6ULL(二十) linux platform 设备驱动

i.MX6ULL(二十) linux platform 设备驱动

Linux 系统要考虑到驱动的可重用性&#xff0c;因 此提出了驱动的分离与分层这样的软件思路&#xff0c;在这个思路下诞生了我们将来最常打交道的 platform 设备驱动&#xff0c;也叫做平台设备驱动。 1 Linux 驱动的分离与分层 1.1 驱动的分隔与分离 对于 Linux 这样一…
阅读更多...
查看电脑上NET Framework最高版本

查看电脑上NET Framework最高版本

1、使用CMD工具 1、进入路径&#xff1a; cd %WINDIR%\Microsoft.NET\Framework\v4.0.303192、查看版本 MSBuild /version2、效果
阅读更多...
【Github】自动监测 SSL 证书过期的轻量级监控方案 - Domain Admin

【Github】自动监测 SSL 证书过期的轻量级监控方案 - Domain Admin

在现代的企业网络中&#xff0c;网站安全和可靠性是至关重要的。一个不注意的SSL证书过期可能导致网站出现问题&#xff0c;给公司业务带来严重的影响。针对这个问题&#xff0c;手动检测每个域名和机器的证书状态需要花费大量的时间和精力。为了解决这个问题&#xff0c;我想向…
阅读更多...
NAT详解（网络地址转换）

NAT详解（网络地址转换）

一句话说清楚它是干什么的&#xff1a; 网络地址转换&#xff1a;是指通过专用网络地址转换为公用地址&#xff0c;从而对外隐藏内部管理的IP地址&#xff0c;它使得整个专用网只需要一个全球IP就可以访问互联网&#xff0c;由于专用网IP地址是可以重用的&#xff0c;所以NAT大…
阅读更多...
基于机器学习的供水管网水力模型

基于机器学习的供水管网水力模型

大数据、人工智能、物联网等前沿技术正推动人类社会发展发生深刻变革。2021年12月12日&#xff0c;国务院印发了《“十四五”数字经济发展规划》&#xff0c;进一步指明了各行业数字化转型发展的方向。作为传统的民生保障行业&#xff0c;供水行业也面临着向数字化智慧化转型的…
阅读更多...
2023年的前端开发还好找工作么

2023年的前端开发还好找工作么

首先可以明确写在前面的是&#xff0c;前端的确是不像之前一样&#xff0c;只会简单的基础就能轻轻松松的找到工作的&#xff0c;随着学习的人不断增多&#xff0c;市场自然会逐步提高对就业人员的要求&#xff0c;那么再以之前的要求来看待前端的话的确是不可取的 互联网在&a…
阅读更多...
机器学习深度学习——多层感知机的从零开始实现

机器学习深度学习——多层感知机的从零开始实现

&#x1f468;‍&#x1f393;作者简介&#xff1a;一位即将上大四&#xff0c;正专攻机器学习的保研er &#x1f30c;上期文章&#xff1a;机器学习&&深度学习——多层感知机 &#x1f4da;订阅专栏&#xff1a;机器学习&&深度学习 希望文章对你们有所帮助 为…
阅读更多...
计算机二级Python基本操作题-序号41

计算机二级Python基本操作题-序号41

1. 输入字符串s&#xff0c;按要求把s输出到屏幕&#xff0c;格式要求&#xff1a;宽度为30个字符&#xff0c;星号字符*填充&#xff0c;居中对齐。如果输入字符串超过30位&#xff0c;则全部输出。 例如&#xff1a;键盘输入字符串s为"Congratulations”&#xff0c;屏幕…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023