首页 文章 精选 留言 我的

精选列表

搜索[意图智算]，共10000篇文章
优秀的个人博客,低调大师

Cadence 发布基于英伟达 Blackwell 芯片的全新 AI 超算

电子设计自动化技术提供商 Cadence 公司推出了一款新型超级计算机，可支持一整套由英伟达 Blackwell 系统和英伟达 CUDA-X 软件库加速的工程设计和生命科学应用。 这款超级计算机名为 Millennium M2000 ，配备了英伟达 HGX B200 系统和英伟达 RTX PRO 6000 Blackwell 服务器版 GPU，每台设备成本估算为 200 万美元。 与优化的软件相结合，该超级计算机在电子设计自动化、系统设计和生命科学工作负载方面的性能比上一代基于 CPU 的系统提高了 80 倍。 Cadence CEO 安尼鲁德・德夫甘（Anirudh Devgan）表示：“Millennium M2000 专为最先进的 AI 模型打造，通过可扩展求解器与 Blackwell 加速计算，突破工程设计的物理极限。"NVIDIA 创始人黄仁勋补充称：" 这种科学 AI 工厂将推动跨学科突破。” 据称，该设备提供云端与本地部署两种模式，已获联发科、超微电脑等客户采用。其市场定位介于中小企业适用的 TinyBox AI 加速器（1.5 万美元起）与马斯克 xAI 的孟菲斯超级计算集群（30-40 亿美元硬件投入）之间，企业可按需申请定制化服务。
2025-05-09
优秀的个人博客,低调大师

理解这八大优势，才算精通单元测试

在计算机编程中，单元测试是一种软件测试方法，通过该方法可以测试源代码的各个单元以确定它们是否适合使用。 单元是最小的可测试软件组件， 它通常执行单个内聚功能。单元测试就是是指对这个最小可测试组件——即单元进行检查和验证。 单元体量小，因此比大块代码更容易设计、执行、记录和分析测试结果。 通过单元测试发现的缺陷很容易定位，并且相对容易修复。单元测试的目标是将程序分离成各自独立的部分，并测试各个部分是否正常工作。它将可测试软件的最小部分与代码的其余部分隔离开来，并确定其行为是否与预期的完全一致。单元测试能在使用过程中发现很多缺陷，在这种过程中证明自身价值。它实现了测试过程的自动化，减少了发现应用程序中更复杂部分中包含的错误的困难，并且由于可以关注到每一个单元而提高测试覆盖率。 一、单元测试工具 常见单元测试框架有JUnit, TestNG, PHPUnit, PyTest, Jest, CppUnit, GTest, QTest 等八种，目前国产主流项目管理软件禅道全面集成这八种单元测试框架，打通持续集成闭环，将测试用例细分了单元测试用例和功能测试用例，可以直接在禅道页面上导入各种各样的单元测试框架的执行结果。这八种单元测试框架通过禅道ZTF与Jenkins持续集成功能打通。用户发起任务后，通过ZTF自动执行测试脚本，把单元测试的结果回传给禅道，二者合作打通了持续集成闭环，打通了项目管理工具和持续集成工具之间的沟壑。 二、为何单元测试是敏捷方法论 在Apiumhub，我们采用敏捷方法，并且大量应用单元测试。单元测试是极限编程（Extreme Programming，XP）的一个特征，极限编程是敏捷软件开发方法之一，它能带来快速的测试驱动开发。我们坚信敏捷就要做持续集成和测试驱动开发。通过测试驱动开发，开发人员在开发代码时会创建单元测试，以便每个单元测试通常在编写代码之前就测试一小段软件代码。 三、单元测试的优势 单元测试提供了许多好处，包括及早发现软件错误、促进变化、简化集成、提供文档来源以及许多其他优点，接下来将对其进行详细介绍。 （1）使流程更灵活 单元测试的主要好处之一是它使编码过程更加灵活，更遵循敏捷开发方法论。 当向软件中添加越来越多的功能时，一般需要更改旧的设计和代码。 但是，更改已经测试过的代码既冒险又高成本。 如果此时采用单元测试，那么就可以放心地进行重构。 单元测试实际上与各种类型的敏捷编程紧密结合，因为测试被内置在其中，让程序员可以更轻松地进行更改。 换句话说，单元测试有助于安全重构。 （2）保证代码质量 单元测试可以提高代码的质量。 它能够确定在进一步发送代码进行集成测试之前可能出现的每个缺陷，在实际编码之前编写测试让人更难以考虑到这种问题。 而单元测试可以暴露出极端情况，让人编写出质量更高的代码。 （3）尽早发现软件Bug 使用单元测试会让问题在早期就被识别发现。由于单元测试是由在集成之前测试单个代码的开发人员执行的，这样可以很早地发现问题，并在不影响其他代码片段的情况下解决问题。这既包括实施中的Bug，也包括单元规范中的缺陷或缺失部分。 （4）促进变化并简化集成 单元测试允许在将来重构代码或升级系统库，并确保该模块仍然正常工作。单元测试能监测到可能违反设计合同的变化，有助于维护和更改代码。单元测试还可以减少新开发功能中的缺陷，减少现有功能更改时出现的错误。 然后通过单元测试对应用程序的各个部分进行测试，验证每个单元的准确性，再将单元集成到应用程序中。由于已经对各个单元进行了验证，在之后的集成过程中对应用程序进行测试就变得更容易。 （5）提供文档 单元测试提供系统的文档。希望了解单元提供了哪些功能以及如何使用这些功能的开发人员可以查看单元测试，以获得对单元接口（API）的基本理解。 （6）简化调试过程 单元测试有助于简化调试过程。 如果测试失败，则仅需要调试代码中最新的更改，这样以往的冗长的调试过程将被大大缩减。 （7）设计 率先编写测试会迫使程序员在编写代码之前就仔细考虑设计和其他必须完成的工作。 这不仅可以让人专注，还可以创建更好的设计。 测试一段代码会迫使程序员定义该代码的责任。如果可以轻松做到这一点，则意味着代码的职责是被明确定义的，因此将具有很高的凝聚力。 （8）降低成本 单元测试会更早地发现错误，有助于降低错误修复的成本。想象一下在开发的后期阶段（比如在系统测试或验收测试中）才发现Bug的成本将有多高。当然，前期检测到的错误也更容易修复，因为后期检测到的错误通常是许多更改的结果，测试人员可能就不会真正知道是哪一个导致了错误。 单元测试是针对代码单元的独立测试，核心是“独立”，优势来源也是这种独立性，而所面临的不足也正是因为其独立性：既然是“独立”，就难以测试与其他代码和依赖环境的相互关系。单元测试与系统测试是互补而非代替关系。单元测试的优势，正是系统测试的不足，单元测试的不足，又恰是系统测试的优势。不能将单元测试当做解决所有问题的万金油，而需理解其优势与不足，扬长避短，与系统测试相辅相成，实现测试的最大效益。 参考文献：Ekaterina Novoseltseva.8 Benefits of Unit Testing[OL].(2019-08-30)
2024-08-06
优秀的个人博客,低调大师

大写的服，看完这篇你还不懂RocketMQ算我输

目录 RocketMQ介绍 RocketMQ概念 为什么要用RocketMQ？ 异步解耦 削峰填谷 分布式事务最终一致性 数据分发 RocketMQ架构 RocketMQ消息类型 普通消息 顺序消息 定时消息 事务消息 最佳实践 消息重试 消息过滤 消费模式 消费幂等 本地事务消息封装 参考代码 RocketMQ 介绍 Apache RocketMQ 是一款 低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。 RocketMQ 概念 Topic：消息主题，用于将一类的消息进行归类，比如订单主题，就是所有订单相关的消息都可以由这个主题去承载，生产者向这个主题发送消息。 生产者：负责生产消息并发送消息到 Topic 的角色。 消费者：负责从 Topic 接收并消费消息 的角色。 消息：生产者向 Topic 发送的内容，会被消费者消费。 消息属性：生产者发送的时候可以为消息自定义一些业务相关的属性，比如 Message Key 和 Tag 等。 Group：一类生产者或消费者，这类生产者或消费者通常生产或消费同一类消息，且消息发布或订阅的逻辑一致。 为什么要使用 RocketMQ？ 异步解耦 随着微服务架构的流行，服务之间的关系梳理非常重要。异步解耦可以降低服务之间的耦合程度，同时也能提高服务的吞吐量。 使用异步解耦的业务场景非常多，因为每个行业的业务都会不太一样，以一些比较通用的业务来说明相信大家都能理解。 比如电商行业的下单业务场景，以最简单的下单流程来说，下单流程如下： 锁库存 创建订单 用户支付 扣减库存 给用户发送购买短信通知 给用户增加积分 通知商家发货 我们以下单成功后，用户进行支付，支付完成会有个逻辑叫支付回调，在回调里面需要去做一些业务逻辑。首先来看下同步处理需要花费的时间，如下图： 同步流程 上面的下单流程从 3 到 5 都是可以采用异步流程进行处理，对于用户来说，支付完成后他就不需要关注后面的流程了。后台慢慢处理就行了，这样就能简化三个步骤，提高回调的处理时间。 异步流程 削峰填谷 削峰填谷指的是在大流量的冲击下，利用 RocketMQ 可以抗住瞬时的大流量，保护系统的稳定性，提升用户体验。 在电商行业，最常见的流量冲击就是秒杀活动了，利用 RocketMQ 来实现一个完整的秒杀业务还是与很多需要做的工作，不在本文的范围内，后面有机会可以单独跟大家聊聊。想告诉大家的是像诸如此类的场景可以利用 RocketMQ 来扛住高并发，前提是业务场景支持异步处理。 削峰填谷 分布式事务最终一致性 众所周知，分布式事务有 2PC，TCC，最终一致性等方案。其中使用消息队列来做最终一致性方案是比较常用的。 在电商的业务场景中，交易相关的核心业务一定要确保数据的一致性。通过引入消息队列 RocketMQ 版的分布式事务，既可以实现系统之间的解耦，又可以保证最终的数据一致性。 数据分发 数据分发指的是可以将原始数据分发到多个需要使用这份数据的系统中，实现数据异构的需求。最常见的有将数据分发到 ES, Redis 中为业务提供搜索，缓存等服务。 除了手动通过消息机制进行数据分发，还可以订阅 Mysql 的 binlog 来分发，在分发这个场景，需要使用 RocketMQ 的顺序消息来保证数据的一致性。 数据分发 RocketMQ 架构 图片来源阿里云官方文档 Name Server：是一个几乎无状态节点，可集群部署，在消息队列 RocketMQ 版中提供命名服务，更新和发现 Broker 服务。就是一个注册中心。 Broker：消息中转角色，负责存储消息，转发消息。分为 Master Broker 和 Slave Broker，一个 Master Broker 可以对应多个 Slave Broker，但是一个 Slave Broker 只能对应一个 Master Broker。Broker 启动后需要完成一次将自己注册至 Name Server 的操作；随后每隔 30s 定期向 Name Server 上报 Topic 路由信息。 生产者：与 Name Server 集群中的其中一个节点（随机）建立长链接（Keep-alive），定期从 Name Server 读取 Topic 路由信息，并向提供 Topic 服务的 Master Broker 建立长链接，且定时向 Master Broker 发送心跳。 消费者：与 Name Server 集群中的其中一个节点（随机）建立长连接，定期从 Name Server 拉取 Topic 路由信息，并向提供 Topic 服务的 Master Broker、Slave Broker 建立长连接，且定时向 Master Broker、Slave Broker 发送心跳。Consumer 既可以从 Master Broker 订阅消息，也可以从 Slave Broker 订阅消息，订阅规则由 Broker 配置决定。 RocketMQ 消息类型 RocketMQ 支持丰富的消息类型，可以满足多场景的业务需求。不同的消息有不同的应用场景，下面为大家介绍常用的四种消息类型。 普通消息 普通消息是指 RocketMQ 中无特性的消息。当没有特殊的业务场景，使用普通消息就够了。如果有特殊的场景，就可以使用特殊的消息类型，比如顺序，事务等。 同步发送 同步发送：消息发送方发送出去一条消息，会同步得到服务端返回的结果。 异步发送 异步发送：消息发送方发出去一条消息，不用等待服务端返回结果，可以接着发送下一条消息。发送方可以通过回调接口接收服务端响应，并处理响应结果。 单向发送 单向发送：消息发送方只负责发送消息，发送出去后就不管了，这种方式发送速度非常快，存在丢失消息的风险。 顺序消息 顺序消息是指生产者按照一定的先后顺序发布消息；消费者按照既定的先后顺序订阅消息，即先发布的消息一定会先被消费者接收到。 比如数据分发的场景，如果我们订阅了 Mysql 的 binlog 来进行数据异构。消息要是没有顺序，就会出现数据错乱问题。 比如新增一条 id=1 的数据，然后马上删除。这样就产生了两条消息。正常的消费顺序是先新增，然后删除，此时数据是没有的。如果消息没有顺序，删除的先被消费了，然后消费新增的，此时数据还在，没被删除掉，就会导致不一致。 定时消息 定时消息是指消息具备定时发送的功能，当消息发送到服务端后，不会立即投递给消费者。而是要等到消息指定的时间后才会投递给消费者进行消费。 延迟消息也就是定时消息，定时消息是定在某个时间点进行发送，比如 2020-11-11 12:00:00 发送。 延迟消息一般是在当前发送时间的基础上延迟多久进行发送，比如当前时间是 2020-09-10 12:00:00，延迟 10 分钟，那么消息发送成功后将在 2020-09-10 12:10:00 进行投递给消费者。 定时消息可以在订单超时未支付自动取消等场景使用。 事务消息 RocketMQ 提供类似 X/Open XA 的分布式事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致。 交互流程： 图片来源阿里云官方文档 发送方首先发送半事务消息到 RocketMQ 服务端。 RocketMQ 服务端接收到消息，然后将消息持久化成功之后，向发送方返回 Ack 确认消息已经发送成功，此时消息为半事务消息，不会投递给消费方。 收到半事务消息的 Ack 后，发送方开始执行本地事务逻辑。 发送方根据本地事务执行结果向服务端提交二次确认，如果本地事务执行成则进行消息的 Commit，如果执行失败则进行消息的 Rollback，服务端收到 Commit 状态则将半事务消息标记为可投递，消费方最终将收到该消息；服务端收到 Rollback 状态则删除半事务消息，消费方将不会收到该消息。 如果出现意外情况，步骤 4 没有进行消息的二次确认，等待固定时间后服务端将对该消息发起消息回查。 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行操作。 最佳实践 消息重试 消息在消费方消费失败后，RocketMQ 服务端会重新进行消息的投递，知道消费者成功消费消息，当然重试有次数限制，默认 16 次。 消息重试在一定程度上保证了消息不丢失，通过重试来达到最终被消费的目的。需要注意的是消费者在消费的时候一定要等本地业务成功后才能进行 ACK(消费确认)，不然就会出现消费失败，但是已经 ACK，消息将不会重复投递。 如果采取异步消费的方式，需要进行异步转同步，等异步操作完才进行 ACK，具体可以参考我之前写的一篇文章https://mp.weixin.qq.com/s/Bbh1GDpmkLhZhw5f0POJ2A。 最后需要做好对应的监控，如果重试了 4，5 次还是失败的，基本上后面重试也是失败的。这个时候需要让开发人员知道，该人工处理的就人工介入。或者直接监控死信队列。 消息过滤 消息主题，一般用于一类消息的统一分类。比如订单主题，但是订单下的消息会分为很多种。比如创建订单，取消订单等。 不同类型的消息有不同的业务处理，我们可以统一定义消息格式，然后通过一个字段去区分消息类型来做不同的业务逻辑。不好的点在于所有消息都会推送到消费方，不能按需消费。 在 RocketMQ 中可以给消息指定 tag，通过 tag 来区分消息类型。消费者可以根据 Tag 在 RocketMQ 服务端完成消息过滤，以确保消费者最终只消费到其关注的消息类型。 我曾经遇到过一个 tag 没有正确使用的方式，只有一个 MQ 实例，用 tag 来区分环境。所有消息都在一个主题中，测试环境消费测试环境的 tag，线上消费线上的 tag。 这种方式的问题在于消息没做隔离，线上线下的消息都在一起。另一个就是 tag 被固定成了环境的区分，无法用于消息类型场景，导致只能建多个 topic 来承载多个业务消息类型。 消息过滤 消费模式 RocketMQ 消费模式有两种，集群消费和广播消费。 集群消费： 集群消费 消费者部署了多个实例我们称之为一个集群，集群消费只会被其中的某一个实例进行消费。 适合大部分的业务场景，大部分的场景我们的消息只允许被消费一次，而且只能有一个消费者去消费，比如支付回调场景，如果一个消息被多个实例同时消费，那么就会出现同时去修改订单状态，同时去扣减库存的情况。 广播消费： 广播消费 广播消费会让集群中每个实例都消费一次。 比如我们使用了本地缓存，当数据变更的时候，我们需要刷新每个节点本地的缓存，所以每个节点都需要收到消息。 消费幂等 幂等问题，无论是在 API 请求场景还是在消息消费场景，都会遇到。一条消息不能重复消费多次这个肯定是要保证的，因为我们不能保证消息发送方不发送多次，也不能保证消息不重复投递。 RocketMQ 的 Exactly-Once 投递语义，就是用于解决幂等问题。Exactly-Once 是指发送到消息系统的消息只能被消费端处理且仅处理一次，即使生产端重试消息发送导致某消息重复投递，该消息在消费端也只被消费一次。 最佳的幂等处理方式还是需要有一个唯一的业务标识，虽然每条消息都有 MessageId，但是不建议用 MessageId 来做幂等判断，在发送消息的时候，可以为每条消息设置一个 MessageKey，这个 MessageKey 就可以用来做业务的唯一标识。 关于幂等怎么处理，就不细讲了。可以参考我之前写的一篇文章https://mp.weixin.qq.com/s/9fhqnbeXPz7-7x0Eadd8DA，通用的幂等实现方案。 消费幂等 本地事务消息封装 上面介绍了事务消息，RocketMQ 的事务消息采用了二阶段提交的方式。并且结合了消息反查的机制来确保最终一致性。 从使用层面来说，每个业务场景都要去实现一个反查的逻辑，有点烦。 下面介绍另一种经常被使用的方式，就是本地事务消息。本地消息表这个方案最初是 ebay 提出的，本地事务消息需要在服务对应的数据库中创建一个消息表，发送消息的时候不是真正的将消息发送给 MQ，而是往消息表中插入一条消息数据。 插入的动作跟本地的业务逻辑是同一个事务，如果本地事务执行成功，消息才会落表成功，才会发送给 MQ, 本地事务失败，消息数据回滚。 然后需要有一个专门的程序去拉取消息表中未发送的消息投递给 MQ，如果投递失败，可以一直重试，直到成功或者人工介入。 本地事务消息 消息写到消息表，然后会一直给 MQ 发送，这个步骤没问题。如果 MQ 收到消息后，消息还在 PageCache 中的时候，Broker 宕机了，这个时候是会出现消息丢失。当然你也可以使用同步刷盘等方式来避免丢失。假如我们就是异步刷盘，有办法保证消息不丢失吗？ 前面我们提到，RocketMQ 的事务消息会有回查的机制，消息表的方式，也需要有一个机制来保证消息被消费了，否则就需要不断的重试去发送消息，直到消息被消费。 在消息表中需要有一个字段来标识当前这条消息的状态，比如 未发送，已发送，已消费。当消息还是未发送的时候就会被发送到 MQ, 如果发送成功了，状态就是已发送。但是过了几分钟，状态还是已发送，这个时候就要去做一些动作了。 这个场景下，有可能是消费者跟不上生产的速度，消息堆积了，导致消息一直没被消费。另一种可能就是消息是不是丢失了？ 可以获取对应的消息堆积数据来判断是否消息堆积了，如果不是就重新发送消息给 MQ，知道消息被消费。 问题是消息被消费了，我怎么知道？ 像我是用的云服务，是有对应的 Open API 可以直接查询消息轨迹。开源的应该也有，没有仔细去研究，跟商业版应该差不多。 根据消息轨迹就可以知道消息有没有被消费，到此为止流程结束。消息发送给 MQ 如果失败会重试，消息如果长时间没消费，也会重新发送，即使最后进入了死信队列，也可以通过死信队列的监控来人工干预，一定会是最终一致性。 跟自带的事务消息比，本地消息表的方式不需要实现回查逻辑，但是要增加消息表，同时也要配套各种发送，检查等逻辑，也挺麻烦了。特别是当消息量大的时候，如何快速的将消息表中的消息发送出去，也需要做很多处理，简单的查表轮询在量大的情况下不太适用。 两种方式都可以使用，能实现我们要的目的即可。 参考代码 本地事务消息相关的代码可以微信搜索「猿天地」，回复关键字「kitty」获取即可。 码字不易，可以的话来个三连击，感谢！ 关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud 微服务-全栈技术与案例解析》, 《Spring Cloud 微服务 入门 实战与进阶》作者, 公众号猿天地发起人。 我整理了一份很全的学习资料，感兴趣的可以微信搜索「猿天地」，回复关键字 「学习资料」获取我整理好了的 Spring Cloud，Spring Cloud Alibaba，Sharding-JDBC 分库分表，任务调度框架 XXL-JOB，MongoDB，爬虫等相关资料。 后台回复学习资料领取学习视频 如有收获，点个在看，诚挚感谢 本文分享自微信公众号 - 猿天地（cxytiandi）。如有侵权，请联系 support@oschina.cn 删除。本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
2020-09-15

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册