异步处理通过允许每个上下文更高的限制来提高可扩展性。异步请求在后台执行在自己的线程中，因此当异步任务在后台执行时，用户可以继续在客户端工作。

Salesforce Lightning 平台提供各种异步技术，可用于解决给定的用例。在为每个用例选择方法时，每种技术都有需要考虑的好处和限制。

在选择实施技术时，请记住三个重要注意事项：

1. 异步处理不是解决每个问题的最佳方式。可以将任何不直接需要用户交互的进程视为异步处理的良好候选项，但也有一些缺点。首先，异步流程没有 SLA，这意味着无法保证异步流程将在规定时间内完成。其次，不能保证一致的响应延迟。如果异步进程在一定时间内完成，后续进程可能需要不同的时间才能完成。因此，即使用户没有直接等待响应，如果您的后续进程依赖于响应，或者如果您担心响应时间过长可能会导致您的数据与外部系统中的数据不同步，异步处理也可能不适合您的场景。
2. 在 Salesforce 平台上处理异步请求的方式多种多样，因此请确保您选择最佳方法。支持 Salesforce 平台上异步处理的技术在“幕后”的工作方式不同，一些技术专为非常具体的用例设计。
3. 如果技术在客户端异步，这不一定意味着所有端到端的处理都是并行执行的。根据您做出的选择，客户端的消息有时仍会在服务器端序列化。

如果您使用错误的技术或错误的作业技术组合，可能会出现抵消异步处理好处的意外后果。本指南提供了解释和建议，以及各种异步用例的潜在缺点和反模式，以及这些建议的理由。它还提供了关于各种异步实施技术如何在 Salesforce 平台上操作和监管的见解。

如果您决定使用什么技术，有一个重点的异步处理决策指南，可以快速地将典型用例映射到最合适的技术。

Salesforce Lightning 平台是一个人工智能驱动的综合平台,将员工、自主人工智能客服人员、公司数据和应用程序统一到一个可信的系统中,以提高生产率和客户体验。它通过连接 Customer 360 应用程序、Data Cloud 和 Slack 来实现端到端自动化，从而支持创建“代理企业”。

本文档未涵盖其他生态系统中的技术，例如 MuleSoft、Informatica、Commerce Cloud、Tableau 和 Marketing Cloud。

请注意，本指南仅关注 Salesforce Lightning 平台中的异步处理。如果您正在寻找有关异步集成模式的信息，请查看事件驱动架构。

• **在使用异步处理之前，请确保您的用例适合该模式。**异步模式没有 SLA，受多个调控器机制的约束，可以根据许可证定义容量限制，并且由于分配给 Salesforce Platform 中的异步基础设施的资源的有限性，可能会导致处理延迟。在用户需要系统响应才能继续工作的场景中使用异步处理时，请认真考虑这些限制。
• **与 Salesforce 异步处理不是满足无限扩展需求的解决方案。**Salesforce 平台并非无限扩展，异步模式仍受限制。异步处理使用线程，线程包含 CPU 执行指令流所需的上下文信息。线程可以并行运行。任何 CPU 中的可用线程数量都是有限的，因此平台拥有各种机制来确保尽可能高效地使用其可用线程。平台的流控制机制可以防止组织消耗过多线程并对其他组织产生负面影响。平台的公平使用算法控制组织对每个特定消息类型可用的线程数量。
• **了解事务何时真正异步。**一些架构模式端到端地异步运行。但是，其他进程在客户端或浏览器侧异步运行，而是序列化服务器端请求，这些请求随后受到同步调控器的限制。
• **要从 Salesforce Platform 构建大规模出站集成，请使用平台事件和强大的中间件，而不是通过异步 Apex 进行标注。**由于平台中可用的异步线程数量有限，因此通过异步 Apex 进行的出站集成可扩展性有限。如果贵组织的出站集成涉及大量消息，超出可用线程的数量，并且处理时间长，那么使用异步 Apex 将不可避免地引入延迟。
• **请确保在使用异步处理时纳入监控。**通过监控，您可以尽早发现问题，并在重大性能事件发生之前纠正它们。
• **考虑可能导致极端负载的事件。**在设计异步流程时，请确保可以预测地管理工作负荷高峰和平静。请考虑您的实施如何处理意外事件，例如断电，并设计保护措施来减轻数据丢失或功能损失。

在您选择服务器端异步处理的方法时，请先评估贵组织的要求和可用资源。您的目标是选择一种方法来最小化实施和维护成本，同时仍然确保可扩展性并最小化违反限制的可能性。此目标取决于以下部分概述的技术注意事项，以及团队的组成。例如，考虑团队中是否有 Apex 开发人员可以维护您的专业代码解决方案。否则，声明性方法可能更有意义。此外，请记住，不同的限制集可以应用于不同的工具。

考虑 Salesforce 中异步订购流程的用例。保存订单时，它会触发一条消息给外部仓库管理系统，其中包含关于如何包装和运送商品的特殊说明。下订单的用户不需要仓库管理系统立即响应，因此请求可以异步发送。异步处理允许用户毫不拖延地继续工作。

架构的注意事项：

• 需要多少个并发进程？
• 并发进程将如何交互？
• 每个进程将执行多少 SOQL 查询？
• 每个进程将执行多少 DML 操作？
• 每个进程将运行多长时间？
• 进程对特定时间的敏感度如何？

Salesforce Platform 的多租户架构隔离并同时支持许多租户(组织)的不同需求。本指南涵盖的所有异步 Apex 方法都在 Salesforce Platform 的相同异步基础设施中执行。他们使用的消息队列框架由两个主要强制机制控制：流控制和公平使用。

流控制和公平使用机制防止单个租户使用过多服务器资源，并且没有为剩余租户保留足够的资源。虽然理解这些机制的工作方式很有帮助，但您的关键建议应该是，遵循异步处理最佳实践，例如以下章节中概述的最佳实践，将显著降低您遇到问题的可能性。

该平台的流控制机制可以防止一个组织泛滥给定消息类型，这会消耗过多线程并对其他组织产生负面影响。在框架将新条目添加到与消息类型关联的队列之前，它会检查队列中的前几千个现有条目。如果大多数现有条目都与该组织相关联，并且该组织已经在工作线程中拥有条目，那么新添加的条目将被移动到队列的后面。此过程称为重新排队。重新排队通常发生在批处理 Apex 和批量 API 流程中，因为它们经常同时将大量条目插入队列。

该平台的公平使用机制实施基于等级的系统。该系统确保 Salesforce 平台上的每个组织都能公平地分配给定消息类型的处理时间，包括未来、可排队和批处理消息类型。如果一个组织在其他组织等待执行相同消息类型工作的同时主导了给定消息类型，公平使用算法会减少该组织可用于该特定消息类型的线程数量。

使用异步 Apex 方法的一个好处是一些调控器限制更高，例如 SOQL 查询限制和堆大小限制。但是，不要过于依赖这些方法。由于分配给异步基础设施的资源有限，大量使用 Future、Quueable 和 Batch Apex 会导致处理延迟，这是因为基于公平使用和流控制的限制。

使用异步 Apex 的出站标注计入异步 Apex 限制。目前，每日限制是适用用户许可证数量的 250,000 或 200 倍，以较大者为准。对于高用量用例，此限制可能是一个问题。如果超过限制，异步 Apex 作业及其关联的出站标注将失败。

此外,由于平台可用的异步线程数量有限,因此通过异步 Apex 进行的出站集成可扩展性有限。任何超出可用线程数量的高用量出站集成都会有较长的处理时间并导致延迟。

对于高用量用例，请考虑这些替代方法。使用这些方法的 API 调用计入每日 API 请求限制，这明显高于每日异步 Apex 限制。因此，这些方法更具可扩展性。但请注意，任何 CPU 可以处理的并发请求数量仍存在物理限制。

• **中间件计划拉取。**通过使用中间件定期提取数据，而不是通过异步 Apex 推送数据，避免与高用量出站集成作业相关的延迟。中间件，例如 MuleSoft Anypoint 平台，可以同步使用本地 SOAP API 或 REST API，这样即使有延迟，也很少引入。中间件还可以对大数据量使用本地批量 API。

• **通过平台事件通知提取中间件。**您可以使用平台事件，而不是将 Future、Quueable 或 Batch 异步 Apex 排队以执行出站集成。平台事件可以传递出站信息，也可以指示中间件工具通过本地 API 提取所需信息，并将其传递到最终目的地。这两种方法都不受异步 Apex 延迟的影响。但平台事件限制仍适用。

使用 Queueable Apex，您可以异步运行涉及大量数据库操作或外部 Web 服务标注的 Apex 流程。要使用 Queueable Apex，实施 Queueable 界面，然后将作业添加到 Apex 作业队列。这种方法确保异步 Apex 作业在其自己的隔离线程中在后台运行，并且不会延迟主 Apex 逻辑的执行。每个已排队作业会在系统资源可用时运行。

Queueable Apex 代表异步 Apex 的演变。它提供了 Apex 未来方法不可用的功能，包括：

• **作业 ID：**当您通过调用 System.enqueueJob 方法提交作业时，该方法会返回新作业的 ID。您可以使用此 ID 来标识您的作业。要监控进度，请在 Salesforce 设置中查看 Apex 作业页面，或查询 AsyncApexJob 对象。
• **支持非原始类型：**可排队类可以包含非原始数据类型的成员变量，例如 sObjects 或自定义 Apex 类型。
• **支持作业链接：**您可以通过从正在运行的作业启动第二个作业来将可排队作业链接在一起。此技术可以帮助您解决涉及进程依赖性的场景。
• **最大深度控制：**您可以使用最大堆栈深度配置可排队作业，以确保作业链不会以意外的递归结束。
• **重复数据消除签名：**可排队作业提供可选签名，以检测并移除重复作业。
• **可配置延迟：**在“可排队”作业执行前，您可以定义最多 10 分钟的延迟。
• **交易完成者：**您可以将操作后序列附加到可排队作业，并根据其结果采取相关操作。例如，事务完成者可以将由于未处理的异常而失败的可排队作业重新排队最多五次。

Salesforce 使用基于队列的框架来处理异步流程。此队列用于平衡组织之间的请求工作量。为确保贵组织尽可能高效地使用此队列：

• 避免直接从大量最终用户活动或集成 API 调用生成的操作中排队未来或可排队方法。这种方法可以快速耗尽每日异步 Apex 限制，从而造成严重的业务影响。
• 避免将每个同步操作中的多个异步操作排队。当多个异步方法从单个同步操作中排队时，异步活动通常会同时执行，并导致行锁定争用和/或行锁定超时错误。
• 避免将大量未来或可排队方法添加到异步队列。
• 确保未来和可排队方法尽快执行。未来方法的执行时间越长，队列中其后面的请求就越有可能被延迟。要确保快速执行批处理作业，最大限度地减少 Web 服务标注时间，调整未来方法中使用的查询，并优化任何其他对象自动化，包括进程构建器流程、工作流规则、流和 Apex 触发器。
• 大规模测试异步方法。使用生成您预期处理的最大数量方法的环境。此测试有助于确定您是否会在生产环境中遇到性能或限制问题。还要考虑对累计每日限制的影响。
• 使用批处理 Apex，而不是未来或可排队方法来处理大量记录。Batch Apex 可以处理针对数千条记录执行的复杂、长时间运行的进程，并且可以安排在资源可用时的非工作时间运行。

使用计划的 Apex 以 Cron 表达式定义的指定时间和重复频率执行。虽然通过 Cron 表达式计划 Apex 的行为是一个异步过程，但底层代码会在作业开始时同步执行。计划 Apex 是日常或每周维护任务的理想选择。

• 您一次只能有 100 个计划的 Apex 作业。为避免此限制，请考虑使用调用 Apex 代码的计划触发流，而不是使用计划的 Apex。
• 如果您计划从触发器计划类，请格外小心。您必须能够保证触发器添加的计划类不会超过限制。特别是考虑 API 批量更新、导入向导、通过用户界面批量更改记录，以及一次可以更新多个记录的所有情况。
• 对于未来最多需要计划 10 分钟的一次性任务，使用延迟可排队作业。此方法不计入 100 个计划作业的限制。
• 计划 Apex 在具有同步限制的同步上下文中执行。
• 考虑计划作业将执行多长时间。长时间运行的作业可能与下一个计划作业的开始时间重叠。
• Salesforce 计划类在指定时间执行。根据服务可用性，实际执行可能会延迟。计划在服务维护停机期间运行的作业将计划在服务恢复后运行。
• 使用 System.scheduleBatch 计划批处理作业，而不是仅以将批处理作业排队为目的的计划作业。

从历史上看,从在同步 Apex 事务上下文中运行的 Apex 方法进行的同步标注,例如 Visualforce 控制器或 Lightning 组件控制器,受到关于长时间运行的请求的 Apex 并发限制。从 Winter ’19 开始，同步标注不再计算为长时间运行。虽然 Apex 继续最初是作为导致长时间运行的请求的同步标注的解决方案创建的，但它们也提供了一些额外的好处。

• 单个同步操作最多可以执行三个继续操作。上一个继续必须在执行新的继续操作之前完成。
• 每个继续操作最多可以执行三个并行执行的标注。
• 当继续操作执行的所有标注完成时，平台会调用继续回调方法来处理结果。

虽然继续相对于原始同步操作异步执行，但 Apex 继续与其他异步 Apex 技术（例如未来方法、可排队或批处理）之间存在关键差异。关键区别是：

• 继续不会以任何方式排队。
• 继续不会影响每日异步 Apex 执行限制。
• 继续将应用程序服务器上的线程上下文从重量级 Apex 平台线程切换到仅执行标注的轻量级线程。对于执行最多 120 秒的标注，继续可以节省大量应用程序服务器的内存。
• 最初，只能从 Visualforce JavaScript 远程调用执行继续。然而,在 Summer '19 中,续集被正式添加到 Lightning 组件框架中,从而消除了对 Visualforce 的需求。

平台事件是 Salesforce Platform 对纯事件驱动架构的实施。您可以在架构师事件驱动架构指南中找到有关与此类架构关联的组件的更多详细信息。

平台事件和平台事件触发器/流通常是运行异步 Apex 的绝佳替代方案。它们也是调用平台外处理的有效方式。例如，您可以使用 Amazon Web Services (AWS) 事件中继和平台事件的组合来调用 AWS Lambda 中的无服务器计算功能。相对快速执行且没有任何标注的工作（从平台事件触发器或流中无法完成）是平台事件/触发器或事件/流组合的理想候选项。

提交后通过发布发布发布到总线的事件按顺序交付，可以由触发器或流在单独的同步上下文中批量处理。上下文是同步的，并强制执行所有同步调控器限制。请谨慎选择平台事件触发器/流批处理大小，以避免达到限制。

• 由于事件在事件总线上发布，因此可供消费者使用。在事件触发器（Apex 或流）的情况下，这些事件被分派到应用程序层上的可用同步线程（每个事件触发器/流一个线程）。请注意，此流程没有 SLA。
• 在将发布操作添加到队列时，队列过程的结果将存储在 Database.SaveResult 对象中。这些条目仅表示排队操作是否成功。要获得通过事件总线发布的事件的最终结果，请实施 Apex 发布回调。通过这些附加信息，您可以决定进一步的操作，例如尝试重新发布失败的事件。
• 虽然平台事件不受异步 Apex 的限制,但它们有自己的调控器限制。如果您遇到限制问题，您可以启用增强事件使用度量，以确定特定事件是否超出预期地消耗了您的分配。如果您需要事件触发器的更大吞吐量，请考虑使用并行订阅同时处理事件，而不是在一个流中。通过并行订阅，您可以扩展 Apex 平台事件触发器以处理大量事件。并行订阅可用于自定义高用量平台事件，但不适用于标准事件或更改事件。
• 平台事件有两个发布行为的选项：
  • 立即发布：在事务期间，在最终数据库提交之前，立即发布事件。以这种方式发布的事件不保证按顺序发布。
  • 提交后发布：事件会在数据库事务成功提交时发布。以这种方式发布的事件保证按顺序发布。

将“立即发布”用于日志记录等用例很有帮助，在这些用例中，您希望发布日志记录事件，而不管事务是成功并提交，还是失败并回滚。可以立即发布平台事件触发器消耗的平台事件。然后，平台事件触发器与发布数据库行锁的事务竞争数据库行锁。在立即发布平台事件之前，请彻底检查所有设计，以确保避免这种情况。

异步流提供了异步 Apex 的低代码替代方案。与其他形式的异步处理一样，它们在资源可用时在后台执行。异步流也没有 SLA，并且等待时间不可预测。

计划路径基于时间触发器，在特定时间执行。它们在创建、更新或删除记录时执行，并允许您精确控制何时运行与记录更改相关的自动化。（例如：在任务到期前一小时向用户发送电子邮件。）与 Apex 未来方法不同，后者限制为同步事务中最多 50 个排队的方法，计划流操作目前没有每个事务的最大队列限制。但在计划路径的定义中有一个批处理大小配置，允许对计划路径流执行处理的记录数量进行一些控制。

异步路径可以添加到记录触发的流中。它们在后台运行，不会延迟最初触发流的事务的执行。您可以使用异步路径来执行长时间运行的操作或您想要自行运行的任何操作。当您需要更新相关记录上不属于触发流的记录的值时，异步路径可以帮助避免出现混合 DML 错误。

**注意：**出站消息传递是一项传统功能，平台事件（在上一节中描述）是一种更现代的方法，并提供更大的灵活性。平台事件是 Salesforce 为事件驱动的集成推荐的模式。

出站消息提供了一种通过 SOAP API 进行异步出站通信的方式。在 Salesforce 中配置时，出站消息定义会生成可由外部 Web 服务提供商使用的 SOAP WSDL。出站消息可以从工作流规则、进程构建器进程或 Lightning 保存后流触发器触发。出站 SOAP 消息最多可包含 100 个通知。每个通知都包含对象 ID 和对关联 sObject 数据的引用。如果基础对象中的信息在通知排队后但在发送前发生变化，则只传递最新的数据，而不传递中间数据。

当出站消息侦听器（您使用生成的 WSDL 配置的 Web 服务）收到消息时，它会使用包含的会话 ID 信息来调用 Lightning 平台 API，以更新 Salesforce 中触发出站消息的记录。

• 出站消息不会通过 Salesforce 中运行未来方法、Quueable Apex、Batch Apex、批量 API 等活动的基于队列的异步基础设施来处理。相反，记录本地存储在 OutboundMessage 对象中。消息通过本地计划的后台进程进行分派和重试。
• 当发起自动化执行出站消息操作时（例如，保存后流触发器），消息不会同步发送。相反，它们会保留在 OutboundMessage 对象中，直到发送成功，或者在 24 小时不成功传递后丢弃。
• 为避免出站消息无限循环，请确保更新对象的用户没有发送出站消息权限。

电子邮件转个案通常以同步方式工作。处理入站电子邮件转个案请求的限制是 4 个同步线程。处理程序的同步表单保持与接收电子邮件的入站 Salesforce 邮件服务器 (MTA) 的连接。但电子邮件转个案可以异步处理的原因如下：

• 电子邮件转个案受线程限制，特别是每个应用程序服务器总共 10 个处理器线程：4 个线程用于同步处理，6 个线程用于异步处理。
• 如果同步电子邮件处理器的执行时间超过 15 秒，则该特定电子邮件服务地址将在 30 分钟内标记为异步。对该服务地址的后续处理程序请求会导致一条消息，该消息被排队等待 MessageTypeName = MAILCATCHER_Email_TO_CASE，以及对电子邮件内容的引用。
• 如果同步线程已经用于特定组织和服务地址，则对该服务地址的其他请求将异步排队。
• 如果同步处理的电子邮件遇到错误，例如行锁定超时，请求将被异步保存并排队。
• 如果没有可用的同步处理器线程，请求将异步排队。

• 当您配置电子邮件转个案时，有一个重复数据消除选项，但它不会对附件进行重复数据消除，直到处理完电子邮件。这种重复数据消除可以节省数据库的空间，但不会减少电子邮件处理时间。但是，您可以通过实施用于消息处理的自定义 Apex 电子邮件转个案处理器来提高性能。此实施不会影响任何调控器限制，但在向数据库提交任何内容之前，它授予处理程序对电子邮件消息及其所有附件的访问权限。此访问权限允许您计算所有包含的附件的校验和，并丢弃任何您认为不必要的附件，包括重复、众所周知的签名图片或不需要的文件类型。
• 将电子邮件附件提交到 Salesforce Files 负责大部分电子邮件处理时间。随着回复联系人或来自联系人的回复增加，电子邮件链变大，每封电子邮件的处理时间也会变长。如果未选择电子邮件选项“仅使用新内容回复”，则电子邮件链会随着每次回复而增长。因此，我们建议您使用 Apex 电子邮件转个案处理器，其逻辑可在处理时实施附件重复数据消除。
• 尽管作为处理的一部分调用了 Apex 触发器，但电子邮件转个案处理器不受并发 Apex 限制。

要异步处理大量记录，请考虑使用以下方法之一。

您可以使用批处理 Apex 构建涉及数千条记录的复杂、长时间运行的流程。Batch Apex 通过划分记录集并在可管理的块中处理来操作。例如，您可以构建夜间运行的归档解决方案，并将超过特定日期的记录添加到归档中。或者，您可以构建数据清理操作，该操作每晚查看所有客户和业务机会，并根据一组预定义的条件执行任何必要的更新。

• 批处理 Apex 最适合处理大量数据，因为异步 Apex 的限制高于同步 Apex。当批处理每个批次处理更多项目时，Batch Apex 的性能也更高，因为它使用的批量操作减少了队列管理的开销。因此，为了避免通过队列泛滥触发流控制机制，并避免耗尽每日异步 Apex 限制，请勿创建范围小或处理时间快的批次。
• 避免直接从大量最终用户活动或集成 API 调用生成的操作中排队批处理作业。这种方法可以快速耗尽弯曲队列。如果您计划从触发器调用批处理作业，则必须保证触发器添加的批处理作业不会超过限制。
• Batch Apex 限制为最多 5 个同时线程，这比未来方法或 Queueable Apex 限制其吞吐量更多。
• 理想情况下，涉及大量数据的批处理作业应安排在非高峰时段运行，以便为需要实时或近乎实时响应的进程释放资源。
• 在您调用 System.scheduleBatch 时，平台会计划在您指定的时间执行作业。实际执行发生在该时间或之后，这取决于服务可用性。
• 计划程序在系统上下文中运行。执行所有类，无论计划执行的用户是否有权执行类。
• 所有计划的 Apex 限制适用于使用 System.scheduleBatch 计划的批处理作业。在批次作业排队后（状态为“等待”或“已排队”），所有批次作业限制均适用，并且作业不再计入计划的 Apex 限制。
• 对于具有重复计划的批处理作业，如果在新作业开始运行时上一个作业仍在执行，请考虑正确的行为。
• 从同步 Apex 事务中排队的批处理作业使用弯曲队列。弯曲队列限制为任何时间点最多 100 个项目。如果事务尝试添加更多条目，平台会生成错误，并且不会提交批处理作业。
• 批处理作业中的标注和其他非事务性操作必须遵循幂等设计注意事项。在 Salesforce 服务维护停机前排队的批处理作业保留在队列中。在服务停机结束并且系统资源可用后，将执行排队的批处理作业。如果在停机时批处理作业正在运行，批处理执行将在服务恢复后回滚并重新启动。由于执行方法可以多次运行，因此可以重试任何非事务性操作，例如标注。
• 请考虑配置批处理作业，以引发 BatchApexErrorEvent 事件，从而处理错误和异常情况。

计划触发的流是计划在指定时间和重复频率（每天、每周或一次）执行的流，用于对一批记录执行操作。（例如：在每晚凌晨 2 点更新所有状态为“未处理”的字段。）计划流通过 Cron 触发机制执行，并批量处理。

• 计划触发的流每次调用执行 200 条记录，但如果存在 200 多条记录，将使用多个并发线程执行。
• 计划触发的流在具有同步限制的同步上下文中执行。
• 目前，无法控制每个计划流调用处理的记录数量。如果执行的记录超过 200 条，则存在并发 Apex 错误的真实危险。

批量 API 基于 REST 原则，并针对大型数据集进行了优化。您可以使用它异步插入、更新、更新插入、查询或删除许多记录，并在以后处理结果。Salesforce 平台在后台处理请求。相反，SOAP API 和 REST API 使用同步请求，并针对一次更新几个记录的实时客户端应用程序进行了优化。您可以使用这两个 API 来处理许多记录，但是当数据集包含成千上万条记录时，它们就不那么实用了。批量 API 的异步框架旨在简化和高效地处理数千到数百万条记录中的数据。

使用批量 API 的最简单方法是启用它，以使用 CSV 文件处理 Data Loader 中的记录。使用 Data Loader，您无需编写自己的客户端应用程序。但有时，独特的要求需要编写自定义应用程序。

Salesforce 平台中有两个批量 API。

• 批量 API 2.0 是更新的 API。它提供了一个简化和易于使用的工作流，并且是增强功能的重点。
• 原始批量 API 仍受完全支持，但不再增强。我们建议您尽可能使用批量 API 2.0。

有关 API 限制的更多信息，请查看批量 API 限制和批量 API 2.0 限制。

在 Salesforce 平台上构建或考虑异步处理时，请参考本指南。了解您可用的选项的全部范围，以及它们如何与您的特定用例相适应始终是一个好主意。在更改任何现有架构之前，请确保彻底评估您当前的环境，特别是如果当前解决方案运行良好。