RocketMQ学习笔记（基础篇）

news2024/11/13 21:40:28

目录

RocketMQ简介

单Master模式

多Master模式

多Master多Slave模式（异步）

多Master多Slave模式（同步）

双主双从集群

事务消息

事务消息发送及提交

事务补偿

事务消息状态

RocketMQ高级功能

消息存储

 存储介质

消息的存储和发送

消息存储

消息存储结构

刷盘机制

高可用性机制

消息消费高可用

消息发送高可用

消息主从复制

负载均衡

Producer负载均衡

Consumer负载均衡

集群模式

广播模式

消息重试

顺序消息的重试

无序消息的重试

重试次数

配置方式

死信队列

特性

消费幂等

消费幂等的必要性

处理方式

RocketMQ简介

RocketMQ是阿里巴巴2016年MQ中间件，使用Java语言开发，在阿里内部，RocketMQ承接了例如“双11”等高并发场景的消息流转，能够处理万亿级别的消息。

集群介绍：

  • Producer：消息的发送者；举例：发信者

  • Consumer：消息接收者；举例：收信者

  • Broker：暂存和传输消息；举例：邮局

  • NameServer：管理Broker；举例：各个邮局的管理机构

  • Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者可以订阅一个或者多个Topic消息

  • Message Queue：相当于是Topic的分区；用于并行发送和接收消息

集群特点： 

  • NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

  • Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。

  • Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。

  • Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

集群模式：

  • 单Master模式

    • 这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。

  • 多Master模式

    • 一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点如下：

      • 优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；

      • 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。

  • 多Master多Slave模式（异步）

    • 每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：

      • 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；

      • 缺点：Master宕机，磁盘损坏情况下会丢失少量消息。

  • 多Master多Slave模式（同步）

    • 每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：

      • 优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；

      • 缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

双主双从集群

消息高可用采用2m-2s（同步双写）方式

集群工作流程：

  1. 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。

  2. Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。

  3. 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。

  4. Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。

  5. Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。

事务消息

流程分析

上图说明了事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。

事务消息发送及提交

(1) 发送消息（half消息）。

(2) 服务端响应消息写入结果。

(3) 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）。

(4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）

事务补偿

(1) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”

(2) Producer收到回查消息，检查回查消息对应的本地事务的状态

(3) 根据本地事务状态，重新Commit或者Rollback

其中，补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。

事务消息状态

事务消息共有三种状态，提交状态、回滚状态、中间状态：

  • TransactionStatus.CommitTransaction: 提交事务，它允许消费者消费此消息。

  • TransactionStatus.RollbackTransaction: 回滚事务，它代表该消息将被删除，不允许被消费。

  • TransactionStatus.Unknown: 中间状态，它代表需要检查消息队列来确定状态。

RocketMQ高级功能

消息存储

分布式队列因为有高可靠性的要求，所以数据要进行持久化存储。

  1. 消息生成者发送消息

  2. MQ收到消息，将消息进行持久化，在存储中新增一条记录

  3. 返回ACK给生产者

  4. MQ push 消息给对应的消费者，然后等待消费者返回ACK

  5. 如果消息消费者在指定时间内成功返回ack，那么MQ认为消息消费成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新push消息,重复执行4、5、6步骤

  6. MQ删除消息

 存储介质

  • 关系型数据库DB

    • Apache下开源的另外一款MQ—ActiveMQ（默认采用的KahaDB做消息存储）可选用JDBC的方式来做消息持久化，通过简单的xml配置信息即可实现JDBC消息存储。由于，普通关系型数据库（如Mysql）在单表数据量达到千万级别的情况下，其IO读写性能往往会出现瓶颈。在可靠性方面，该种方案非常依赖DB，如果一旦DB出现故障，则MQ的消息就无法落盘存储会导致线上故障

  • 文件系统
    • 目前业界较为常用的几款产品（RocketMQ/Kafka/RabbitMQ）均采用的是消息刷盘至所部署虚拟机/物理机的文件系统来做持久化（刷盘一般可以分为异步刷盘和同步刷盘两种模式）。消息刷盘为消息存储提供了一种高效率、高可靠性和高性能的数据持久化方式。除非部署MQ机器本身或是本地磁盘挂了，否则一般是不会出现无法持久化的故障问题。

  • 性能对比
    • 文件系统>关系型数据库DB

消息的存储和发送

消息存储

磁盘如果使用得当，磁盘的速度完全可以匹配上网络 的数据传输速度。目前的高性能磁盘，顺序写速度可以达到600MB/s， 超过了一般网卡的传输速度。但是磁盘随机写的速度只有大概100KB/s，和顺序写的性能相差6000倍！因为有如此巨大的速度差别，好的消息队列系统会比普通的消息队列系统速度快多个数量级。RocketMQ的消息用顺序写,保证了消息存储的速度。

消息发送

Linux操作系统分为【用户态】和【内核态】，文件操作、网络操作需要涉及这两种形态的切换，免不了进行数据复制。

一台服务器把本机磁盘文件的内容发送到客户端，一般分为两个步骤：

  1. read；读取本地文件内容；
  2. write；将读取的内容通过网络发送出去。

这两个看似简单的操作，实际进行了4 次数据复制，分别是：

  1. 从磁盘复制数据到内核态内存；

  2. 从内核态内存复 制到用户态内存；

  3. 然后从用户态 内存复制到网络驱动的内核态内存；

  4. 最后是从网络驱动的内核态内存复 制到网卡中进行传输。

 RocketMQ充分利用了上述特性，也就是零拷贝技术，提高消息存盘和网络发送的速度。

这里需要注意的是，采用MappedByteBuffer这种内存映射的方式有几个限制，其中之一是一次只能映射1.5~2G 的文件至用户态的虚拟内存，这也是为何RocketMQ默认设置单个CommitLog日志数据文件为1G的原因

消息存储结构

RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成 的，消息真正的物理存储文件是CommitLog，ConsumeQueue是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每 个Topic下的每个Message Queue都有一个对应的ConsumeQueue文件。

  • CommitLog：存储消息的元数据

  • ConsumerQueue：存储消息在CommitLog的索引

  • IndexFile：为了消息查询提供了一种通过key或时间区间来查询消息的方法，这种通过IndexFile来查找消息的方法不影响发送与消费消息的主流程

刷盘机制

RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复， 又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时 候，有两种写磁盘方式，分布式同步刷盘和异步刷盘。

  • 同步刷盘
    • 在返回写成功状态时，消息已经被写入磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘， 然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写 成功的状态。
  • 异步刷盘
    • 在返回写成功状态时，消息可能只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写入。
  • 配置
    • 同步刷盘还是异步刷盘，都是通过Broker配置文件里的flushDiskType 参数设置的，这个参数被配置成SYNC_FLUSH、ASYNC_FLUSH中的 一个。

高可用性机制

RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。

Master和Slave的区别：在Broker的配置文件中，参数 brokerId的值为0表明这个Broker是Master，大于0表明这个Broker是 Slave，同时brokerRole参数也会说明这个Broker是Master还是Slave。

Master角色的Broker支持读和写，Slave角色的Broker仅支持读，也就是 Producer只能和Master角色的Broker连接写入消息；Consumer可以连接 Master角色的Broker，也可以连接Slave角色的Broker来读取消息。

消息消费高可用

在Consumer的配置文件中，并不需要设置是从Master读还是从Slave 读，当Master不可用或者繁忙的时候，Consumer会被自动切换到从Slave 读。有了自动切换Consumer这种机制，当一个Master角色的机器出现故障后，Consumer仍然可以从Slave读取消息，不影响Consumer程序。这就达到了消费端的高可用性。

消息发送高可用

在创建Topic的时候，把Topic的多个Message Queue创建在多个Broker组上（相同Broker名称，不同 brokerId的机器组成一个Broker组），这样当一个Broker组的Master不可 用后，其他组的Master仍然可用，Producer仍然可以发送消息。 RocketMQ目前还不支持把Slave自动转成Master，如果机器资源不足， 需要把Slave转成Master，则要手动停止Slave角色的Broker，更改配置文件，用新的配置文件启动Broker。

消息主从复制

如果一个Broker组有Master和Slave，消息需要从Master复制到Slave 上，有同步和异步两种复制方式。

  • 同步复制
    • 同步复制方式是等Master和Slave均写 成功后才反馈给客户端写成功状态；
    • 在同步复制方式下，如果Master出故障， Slave上有全部的备份数据，容易恢复，但是同步复制会增大数据写入 延迟，降低系统吞吐量。
  • 异步复制
    • 异步复制方式是只要Master写成功 即可反馈给客户端写成功状态。
    • 在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因为没有被写 入Slave，有可能会丢失；

配置

同步复制和异步复制是通过Broker配置文件里的brokerRole参数进行设置的，这个参数可以被设置成ASYNC_MASTER、 SYNC_MASTER、SLAVE三个值中的一个。

总结

实际应用中要结合业务场景，合理设置刷盘方式和主从复制方式， 尤其是SYNC_FLUSH方式，由于频繁地触发磁盘写动作，会明显降低 性能。通常情况下，应该把Master和Save配置成ASYNC_FLUSH的刷盘方式，主从之间配置成SYNC_MASTER的复制方式，这样即使有一台 器出故障，仍然能保证数据不丢，是个不错的选择。

负载均衡

Producer负载均衡

Producer端，每个实例在发消息的时候，默认会轮询所有的message queue发送，以达到让消息平均落在不同的queue上。而由于queue可以散落在不同的broker，所以消息就发送到不同的broker下，如下图：

图中箭头线条上的标号代表顺序，发布方会把第一条消息发送至 Queue 0，然后第二条消息发送至 Queue 1，以此类推。

Consumer负载均衡

集群模式

在集群消费模式下，每条消息只需要投递到订阅这个topic的Consumer Group下的一个实例即可。RocketMQ采用主动拉取的方式拉取并消费消息，在拉取的时候需要明确指定拉取哪一条message queue。

而每当实例的数量有变更，都会触发一次所有实例的负载均衡，这时候会按照queue的数量和实例的数量平均分配queue给每个实例。

默认的分配算法是AllocateMessageQueueAveragely，如下图：

还有另外一种平均的算法是AllocateMessageQueueAveragelyByCircle，也是平均分摊每一条queue，只是以环状轮流分queue的形式，如下图：

需要注意的是，集群模式下，queue都是只允许分配只一个实例，这是由于如果多个实例同时消费一个queue的消息，由于拉取哪些消息是consumer主动控制的，那样会导致同一个消息在不同的实例下被消费多次，所以算法上都是一个queue只分给一个consumer实例，一个consumer实例可以允许同时分到不同的queue。

通过增加consumer实例去分摊queue的消费，可以起到水平扩展的消费能力的作用。而有实例下线的时候，会重新触发负载均衡，这时候原来分配到的queue将分配到其他实例上继续消费。

但是如果consumer实例的数量比message queue的总数量还多的话，多出来的consumer实例将无法分到queue，也就无法消费到消息，也就无法起到分摊负载的作用了。所以需要控制让queue的总数量大于等于consumer的数量。

广播模式

由于广播模式下要求一条消息需要投递到一个消费组下面所有的消费者实例，所以也就没有消息被分摊消费的说法。

在实现上，其中一个不同就是在consumer分配queue的时候，所有consumer都分到所有的queue。

消息重试

顺序消息的重试

对于顺序消息，当消费者消费消息失败后，消息队列 RocketMQ 会自动不断进行消息重试（每次间隔时间为 1 秒），这时，应用会出现消息消费被阻塞的情况。因此，在使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。

无序消息的重试

对于无序消息（普通、定时、延时、事务消息），当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的结果。

无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。

重试次数

消息队列 RocketMQ 默认允许每条消息最多重试 16 次，每次重试的间隔时间如下：

第几次重试与上次重试的间隔时间第几次重试与上次重试的间隔时间
110 秒97 分钟
230 秒108 分钟
31 分钟119 分钟
42 分钟1210 分钟
53 分钟1320 分钟
64 分钟1430 分钟
75 分钟151 小时
86 分钟162 小时

如果消息重试 16 次后仍然失败，消息将不再投递。如果严格按照上述重试时间间隔计算，某条消息在一直消费失败的前提下，将会在接下来的 4 小时 46 分钟之内进行 16 次重试，超过这个时间范围消息将不再重试投递。

注意： 一条消息无论重试多少次，这些重试消息的 Message ID 不会改变。

配置方式

消费失败后，重试配置方式

集群消费方式下，消息消费失败后期望消息重试，需要在消息监听器接口的实现中明确进行配置（三种方式任选一种）：

  • 返回 Action.ReconsumeLater （推荐）

  • 返回 Null

  • 抛出异常

public class MessageListenerImpl implements MessageListener {
    @Override
    public Action consume(Message message, ConsumeContext context) {
        //处理消息
        doConsumeMessage(message);
        //方式1：返回 Action.ReconsumeLater，消息将重试
        return Action.ReconsumeLater;
        //方式2：返回 null，消息将重试
        return null;
        //方式3：直接抛出异常， 消息将重试
        throw new RuntimeException("Consumer Message exceotion");
    }
}

消费失败后，不重试配置方式

集群消费方式下，消息失败后期望消息不重试，需要捕获消费逻辑中可能抛出的异常，最终返回 Action.CommitMessage，此后这条消息将不会再重试。

public class MessageListenerImpl implements MessageListener {
    @Override
    public Action consume(Message message, ConsumeContext context) {
        try {
            doConsumeMessage(message);
        } catch (Throwable e) {
            //捕获消费逻辑中的所有异常，并返回 Action.CommitMessage;
            return Action.CommitMessage;
        }
        //消息处理正常，直接返回 Action.CommitMessage;
        return Action.CommitMessage;
    }
}

自定义消息最大重试次数

消息队列 RocketMQ 允许 Consumer 启动的时候设置最大重试次数，重试时间间隔将按照如下策略：

  • 最大重试次数小于等于 16 次，则重试时间间隔同上表描述。

  • 最大重试次数大于 16 次，超过 16 次的重试时间间隔均为每次 2 小时。

Properties properties = new Properties();
//配置对应 Group ID 的最大消息重试次数为 20 次
properties.put(PropertyKeyConst.MaxReconsumeTimes,"20");
Consumer consumer =ONSFactory.createConsumer(properties);

注意：

  • 消息最大重试次数的设置对相同 Group ID 下的所有 Consumer 实例有效。

  • 如果只对相同 Group ID 下两个 Consumer 实例中的其中一个设置了 MaxReconsumeTimes，那么该配置对两个 Consumer 实例均生效。

  • 配置采用覆盖的方式生效，即最后启动的 Consumer 实例会覆盖之前的启动实例的配置

获取消息重试次数

消费者收到消息后，可按照如下方式获取消息的重试次数：

public class MessageListenerImpl implements MessageListener {
    @Override
    public Action consume(Message message, ConsumeContext context) {
        //获取消息的重试次数
        System.out.println(message.getReconsumeTimes());
        return Action.CommitMessage;
    }
}

死信队列

当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

在消息队列 RocketMQ 中，这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。

特性

死信消息具有以下特性

  • 不会再被消费者正常消费。

  • 有效期与正常消息相同，均为 3 天，3 天后会被自动删除。因此，请在死信消息产生后的 3 天内及时处理。

死信队列具有以下特性：

  • 一个死信队列对应一个 Group ID， 而不是对应单个消费者实例。

  • 如果一个 Group ID 未产生死信消息，消息队列 RocketMQ 不会为其创建相应的死信队列。

  • 一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。

一条消息进入死信队列，意味着某些因素导致消费者无法正常消费该消息，因此，通常需要您对其进行特殊处理。排查可疑因素并解决问题后，可以在消息队列 RocketMQ 控制台重新发送该消息，让消费者重新消费一次。

消费幂等

消息队列 RocketMQ 消费者在接收到消息以后，有必要根据业务上的唯一 Key 对消息做幂等处理的必要性。

消费幂等的必要性

在互联网应用中，尤其在网络不稳定的情况下，消息队列 RocketMQ 的消息有可能会出现重复，这个重复简单可以概括为以下情况：

  • 发送时消息重复

    当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。

  • 投递时消息重复

    消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次，消息队列 RocketMQ 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容相同并且 Message ID 也相同的消息。

  • 负载均衡时消息重复（包括但不限于网络抖动、Broker 重启以及订阅方应用重启）

    当消息队列 RocketMQ 的 Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消费者可能会收到重复消息。

处理方式

因为 Message ID 有可能出现冲突（重复）的情况，所以真正安全的幂等处理，不建议以 Message ID 作为处理依据。 最好的方式是以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息 Key 进行设置：

Message message = new Message();
message.setKey("ORDERID_100");
SendResult sendResult = producer.send(message);

订阅方收到消息时可以根据消息的 Key 进行幂等处理：

consumer.subscribe("ons_test", "*", new MessageListener() {
    public Action consume(Message message, ConsumeContext context) {
        String key = message.getKey()
        // 根据业务唯一标识的 key 做幂等处理
    }
});

相关文章：

RocketMQ学习笔记（实操篇）_Cat凯94的博客-CSDN博客

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

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

相关文章

vue upload 下载

vue upload 下载

目录 上传 下载 get post 对象/文件流 download处理返回 文件流 axios.post 封装axios 后端直接返回文件流，打开下载文件是 [object Object]，将res改成res.data即可 1.请求设置类型responseType: blob（如果没有设置，打…
阅读更多...
14_Linux设备树下的platform驱动编写

14_Linux设备树下的platform驱动编写

目录 设备树下的platform驱动简介 运行测试 设备树下的platform驱动简介 platform驱动框架分为总线、设备和驱动,其中总线不需要我们这些驱动程序员去管理，这个是Linux内核提供的,我们在编写驱动的时候只要关注于设备和驱动的具体实现即可。在没有设备树的Linux内…
阅读更多...
1770_VirtualBox下安装Debian

1770_VirtualBox下安装Debian

全部学习汇总： GreyZhang/little_bits_of_linux: My notes on the trip of learning linux. (github.com) 作为我自己的日常使用，Debian基本上没有出现过。最多是让它运行在某个设备上作为一个服务的平台，因为很多东西我懒得去配置。 Debia…
阅读更多...
前端 | （二）各种各样的常用标签 | 尚硅谷前端html+css零基础教程2023最新

前端 | （二）各种各样的常用标签 | 尚硅谷前端html+css零基础教程2023最新

学习来源：尚硅谷前端htmlcss零基础教程，2023最新前端开发html5css3视频 文章目录 📚HTML排版标签📚HTML语义化标签📚块级元素与行内元素📚文本标签🐇常用的文本标签🐇不常用的文本标…
阅读更多...
模版模式在Spring中的应用

模版模式在Spring中的应用

前言 模式模式在Spring中的应用较多，这里结合JdbcTemplate的源码来和大家一起学习下，更加深刻滴认识下模版模式，以便在日常开发中，能灵活运用模版模式，来减少重复代码，增强代码的可拓展性。 何为模版模式…
阅读更多...
Python学习（七）

Python学习（七）

#字典 #字典的定义，同样是使用{}，不过存储的元素是一个个的：键值对。如下语法： my_dict{"周杰伦":99,"林俊杰":99} print(f"字典的内容是：{my_dict},类型是：{type(my_dict)}"…
阅读更多...
Vue条件渲染

Vue条件渲染

v-if 和 v-show <body> <div id"root"><!--用v-show做条件渲染--> <!-- <h2 v-show"false">欢迎来到{{name}}</h2>--><!--使用v-if做条件渲染--><h2 v-if"false">欢迎来到{{name}}</h2&g…
阅读更多...
一文读懂STM32芯片总线

一文读懂STM32芯片总线

目录 一、前言 二、总线基础知识概述 (1)、总线在芯片中的角色 (2)、总线的类型 (3)、总线的指标 (4)、AHB和APB 三、总线框架结构 (1)、结构类型 (2)、总线模块 (3)、总线交互 四、总结 一、前言 本篇介绍STM32芯片内部的总线系统结构&#xff0c;嵌入式芯片内部的…
阅读更多...
C++11左值和右值、左值引用和右值引用浅析

C++11左值和右值、左值引用和右值引用浅析

从字面意思来讲&#xff0c;左值就是“能用在赋值语句等号左侧的内容&#xff08;它得代表一个地址&#xff09;”&#xff1b;右值就是不能作为左值的值&#xff0c;即右值不能出现在赋值语句中等号的左侧。C中的一条表达式&#xff0c;要么就是右值&#xff0c;要么就是左值&…
阅读更多...
钉钉监控Hippo4j线程池通知报警

钉钉监控Hippo4j线程池通知报警

&#x1f680; 线程池管理工具-Hippo4j &#x1f680; &#x1f332; AI工具、AI绘图、AI专栏 &#x1f340; &#x1f332; 如果你想学到最前沿、最火爆的技术&#xff0c;赶快加入吧✨ &#x1f332; 作者简介&#xff1a;硕风和炜&#xff0c;CSDN-Java领域优质创作者&#…
阅读更多...
软考03海明校验码

软考03海明校验码

文章目录 前言一、练习一二、练习二总结 前言 海明校验码可以用来纠正错误 公式&#xff1a; 2k-1≥nk n为数据位&#xff0c;k为校验位 编码规则&#xff1a;校验位为2的次方&#xff0c;其他为数据位。 一、练习一 数据位为4&#xff0c;校验位最小为多少位&#xff1f; 答&…
阅读更多...
《微服务架构设计模式》第十二章 部署微服务应用

《微服务架构设计模式》第十二章 部署微服务应用

内容总结自《微服务架构设计模式》 部署微服务应用 一、部署模式分类二、编程语言特定的发布包格式1、概述2、利弊 三、将服务部署为虚拟机1、概览2、利弊 四、将服务部署为容器1、概述2、利弊3、K8S部署 五、Serverless部署1、概述2、利弊3、示例 六、总结 一、部署模式分类 …
阅读更多...
计算机丢失msvcp140.dll是什么意思？哪个修复方法更推荐

计算机丢失msvcp140.dll是什么意思？哪个修复方法更推荐

打开photoshop软件的时候&#xff0c;计算报错丢失msvcp140.dll是什么意思&#xff1f;软件也无法正常启动运行&#xff0c;这个主要的原因就是电脑系统中的msvcp140.dll文件丢失或者损坏了&#xff0c;运行需要该文件的程序或应用程序时&#xff0c;操作系统无法找到该特定的动…
阅读更多...
低代码都做了什么？怎么实现 Low-Code？

低代码都做了什么？怎么实现 Low-Code？

前言 低代码的概念早在很多很多年前就已经出现了&#xff0c;比如最早期的Dreamweaver 1.0&#xff0c;使用这种可视化编辑工具根本不需要投入较高的学习成本就可以轻松实现一个Web页面。而低代码最大的初衷也正是让开发者或用户减少编码时间&#xff0c;从而把更多的时间和精力…
阅读更多...
Python应用实例（二）数据可视化（五）

Python应用实例（二）数据可视化（五）

数据可视化&#xff08;五&#xff09;制作全球地震散点图&#xff1a;JSON格式 1.地震数据2.查看JSON数据3.创建地震列表4.提取震级5.提取位置数据6.绘制震级散点图7.另一种指定图表数据的方式 下载一个数据集&#xff0c;其中记录了一个月内全球发生的所有地震&#xff0c;再…
阅读更多...
Unity3d-路径巡逻

Unity3d-路径巡逻

使用U3D实现的简单巡逻方法 游戏对象逐个向组成路径的节点进行直线移动两种巡逻方案 根据列表顺序移动&#xff0c;到达最后一个后&#xff0c;直接返回第一个&#xff0c;重新开始循环根据列表顺序移动&#xff0c;到达最后一个后&#xff0c;根据顺序反向移动到第一个&#…
阅读更多...
用 Pytest+Appium+Allure 做 UI 自动化的那些事~(有点干)

用 Pytest+Appium+Allure 做 UI 自动化的那些事~(有点干)

目录 前言&#xff1a; Appium 不常见却好用的方法 Appium 直接执行 adb shell 方法 Appium 直接截取元素图片的方法 Appium 直接获取手机端日志 Appium 直接与设备传输文件 Pytest 与 Unittest 初始化上的区别 1.Pytest 与 unitest 类似&#xff0c;有些许区别&#x…
阅读更多...
【嘉立创EDA】客户端版本嘉立创专业版半离线版更新方法

【嘉立创EDA】客户端版本嘉立创专业版半离线版更新方法

文章路标👉 文章解决问题主题内容工程文件备份保护问题新版本更新通知文章解决问题 1️⃣ 嘉立创EDA专业版，是时下越发常用的PCBA设计软件之一。该环境除了在规划的设计开发过程中，为响应各用户的建议、需求，其迭代更新速度也是很快。为了使用最新的功能，用户需要使用最…
阅读更多...
C++学习——类和对象（一）

C++学习——类和对象（一）

C语言和C语言最大的区别在于在C当中引入了面向对象的编程思想&#xff0c;想要完全了解c当中的类和对象&#xff0c;就要从头开始一点一点的积累并学习。 一&#xff1a;什么是面向对象编程 我们之前学习的C语言属于面向过程的编程方法。举一个简单的例子来说&#xff1a;面向过…
阅读更多...
Linux地盘上AMD处理器称王了

Linux地盘上AMD处理器称王了

近日资讯&#xff0c;尽管从全局来看&#xff0c;Linux系统份额远不及Windows&#xff0c;但在程序员、开发者、硬核玩家圈子&#xff0c;Linux则备受推崇。 来自Steam的最新数据显示&#xff0c;在Linux游戏用户中&#xff0c;AMD处理器的份额占据绝对优势&#xff0c;达到了…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023