可扩展性模式

了解有关架构良好的可靠性的更多信息 → 可扩展性和容量规划

模式

何处查看好样的
SOQL 查询效率使用关系查询（联系人、Case__r）合并查询，而不是每个相关对象单独查询。每个事务查询一次所有需要的数据。目标在同步事务中<50个查询，在异步事务中<100个查询（限制：100 个同步，200 个异步）。保持 30-50% 的缓冲低于限制。
DML 操作批量化将记录收集到列表中，为每个事务的每个对象类型执行单个 DML 语句。使用 Database.insert/update/delete 与 allOrNone 参数控制部分成功行为。目标每个事务 <75 个 DML 语句（限制：150).批处理将 DML 消耗从 N 个语句减少到 1。
堆大小管理仅查询必填字段（避免选择 * 模式）。分块处理大型结果集。处理完后清除集合以释放内存。同步上下文中的目标 <4MB 堆（限制：6MB）、<8MB 异步（限制：12MB)。堆超出错误表示需要分块或流模式。
CPU 时间优化最小化循环中的计算复杂性。使用 Maps 进行查找 (O(1))，而不是嵌套列表迭代 (O(n²))。将繁重的计算转移到异步上下文。同步事务中的目标 CPU <7,000ms（限制：10,000ms)、异步 <40,000ms（限制：60,000ms)。
SOQL 查询行设计返回合理结果集大小的查询。使用 LIMIT 子句限定结果。在同步上下文中，目标为每个查询 <25,000 行（限制：50,000).接近限制的查询应使用分页，或使用批处理 Apex 或可查询转到异步处理。
API 调用分配通过系统概览监控 24 小时 API 限制消耗。批处理 API 操作，而不是逐个记录的调用。使用平台缓存缓存频繁访问的参考数据。目标为每日 API 限制的 70%，以适应峰值。API 限制因版本和许可证计数而异。
标注限制合并外部标注：在外部系统支持时，将多个记录批量转换为单个 API 请求。实施请求排队，以序列化标注。遵守每个事务 120 秒的总标注时间。限制：每个事务 100 个标注。为标注繁重的集成设计异步处理。
代码（Apex、Aura、LWC）实施批量化模式：处理集合而不是单个记录，查询一次并在地图中缓存，为每个对象类型执行单个 DML。使用关系查询，以最小化 SOQL 消耗。应用高效的算法，避免大型数据集上的嵌套循环。

反模式

何处查看什么不好的样子
循环中的 SOQL问题：为处理记录集合的循环执行内部 SOQL 查询。影响：超过 100 条记录的查询限制错误（限制：每个事务 100 个查询）。解决方法：在循环前查询一次，将结果存储在按关系键划分的映射字段中。从地图内部循环查找（批量化模式）。
循环中的 DML问题：为循环执行内部插入/更新/删除语句。影响：DML 限制超出 150 多条记录的错误（限制：每个事务 150 个 DML 语句）。解决方法：将记录收集到列表内部循环中，并在循环完成后执行单个 DML 语句。
无调控器限制缓冲问题：设计在正常条件下消耗调控器限制 95% 以上的事务。影响：在负载略有增加时出现生产故障，边缘个案没有容量。解决方法：将限制的 70% 作为运营上限。为峰值和边缘个案保留 30% 的缓冲空间。
嵌套循环笛卡尔积问题：嵌套循环迭代两个大集合，创建 O(n²) 操作。影响：CPU 限制超出错误，临时对象超出堆限制。解决方法：O(n ) : n(n ) : n(n ) : n(n)收集外循环密钥，查询一次相关记录，在内循环中查找。
堆积问题：将大型查询结果加载到内存中，而不进行分块处理。影响：堆限制超出错误（6MB 同步，12MB 异步）。解决方法：仅查询所需字段。在每个批次后分批次清除集合的过程。将 QueryLocator 与 Batch Apex 一起使用，以处理数百万条记录。
无字段级筛选问题：在仅需要子集时，选择所有字段（显式或隐式）。影响：堆消耗过多、查询执行缓慢、SOQL 行限制不必要地接近。解决方法：仅选择处理所需的字段。使用关系表示法在单个查询中获取相关数据，而不是单独的查询。
同步处理过度使用问题：在用户事务中同步处理大量数据。影响：用户等待多秒操作，CPU/堆限制超过了阻止用户。解决方法：将繁重的处理移到异步上下文（批次、可排队、平台事件）。通过状态轮询为用户提供即时响应。

模式

何处查看好样的
异步处理使用批处理 Apex 处理大量记录（百万）。使用 Queueable Apex 进行具有链接的复杂多步骤编排。使用平台事件进行事件驱动的解耦。使用计划的 Apex 进行定期维护。将异步模式与用例匹配：批量批量、复杂性可排队、解耦事件。
批处理 Apex 实施设计开始方法返回选择性 QueryLocator，以最小化处理的记录。根据记录复杂性配置批处理大小（每次执行 200-2000 条记录）。仅在必要时实施有状态的接口，因为这会降低吞吐量。监视 AsyncApexJob 的成功/失败。批次提供每个区块的专用调控器限制。
平台事件架构为需要下游处理的状态更改发布事件。在平台事件对象上使用 Apex 触发器订阅，或通过 CometD 订阅外部订阅者。设计幂等订阅者（重放可能会多次提供事件）。使用 72 小时保留从临时订阅者失败中恢复。
基于日期的分区在时间窗口中处理数据：当月、上一季度、今年。将历史数据归档到大对象或外部存储。基于时间的分区支持同时处理不同日期范围的并行批处理作业。大多数查询自然会按日期筛选，因此效率很高。
记录类型分区独立处理不同的记录类型。为每个启用并行化的记录类型计划单独的批处理作业。记录类型通常与证明独立处理的合理性的不同业务流程相关联。每个组织最多 5 个并发批处理作业需要战略性分区。
基于地理位置的分区按所有人、分部或区域划分，以处理分发。在并行批处理作业中处理每个区域、业务部门或销售区域。基于地理位置的分区利用共享模式：每个批处理作业在特定用户组的上下文中运行，自然会筛选数据。
缓存策略对频繁访问的参考数据使用平台缓存（组织/会话分区）。缓存减少了查询和 API 消耗。以整数 MB 增量分配组织和会话分区；默认容量因版本而异，额外容量可以块为单位购买。缓存未命中应优雅地返回到查询。缓存 TTL 应匹配数据更改频率：静态参考数据的小时数，半动态数据的分钟数。
流批量化使用循环和集合变量设计处理记录集合的流。创建记录集合，执行单个获取记录，使用单个更新记录元素更新集合。避免循环中的单个记录操作。流批量化模式反映了 Apex 最佳实践。

反模式

何处查看什么不好的样子
仅顺序处理问题：单个批处理作业按顺序处理所有 5000 万条记录需要 24 小时以上。影响：阻止其他处理、维护时段耗尽、面向用户的延迟。解决方法：按日期、记录类型或地理位置对数据进行分区。同时运行并行批处理作业处理独立分区。
同步集成依赖性问题：用户事务已阻止通过同步标注等待外部系统响应。影响：用户体验与外部系统性能、外部中断期间的超时失败有关。解决方法：使用平台事件进行异步集成。将用户事务与外部系统可用性分离。
无缓存层问题：在事务中重复查询相同的参考数据。影响：SOQL 消耗过多，API 限制浪费，事务执行缓慢。解决方法：为频繁访问的参考数据实施平台缓存。缓存减少了调控器限制消耗，并提高了性能。
批处理作业堆叠问题：计划 20 多个批处理作业同时开始。影响：队列深度累积，5 个并发作业限制导致序列化，完成时间不可预测。解决方法：错开计划，将负载分配到不同时间。使用动态调度逻辑将类似的作业整合到单个批次中。
有状态的批次过度使用问题：在不需要时使用 Database.Stateful 实施批处理 Apex。影响：跨 execute() 调用对实例成员变量进行不必要的序列化和从保留状态进行潜在堆累积。解决方法：仅在状态必须跨执行调用持续存在时使用 stateful。首选无状态批处理，以避免不必要的状态序列化开销。
单线程流设计问题：在循环中逐个处理流记录，每次迭代都有单独的获取/更新记录元素。影响：与记录计数成比例的调控器限制消耗，大规模事务失败。解决方法：将记录收集到集合变量中，执行单个获取记录，使用循环外的单个更新记录元素更新集合。
无异步重试策略问题：失败的异步作业不会自动重试，需要手动干预。影响：数据不一致、手动操作负担、SLA 缺失。解决方法：使用指数回退实施自动重试。将平台事件用于持久队列，启用重放。监视 AsyncApexJob，并提醒持续失败。

模式

何处查看好样的
批次与可排队选择使用 Batch Apex 进行：分块处理数百万条记录、计划批量操作、数据迁移。将 Queueable Apex 用于：具有链接的多步骤集成工作流、需要复杂对象参数的操作、需要比 @future 更好的监控的作业。异步 Apex 在批次、可队列、未来和计划 Apex 之间共享每 24 小时 250,000 次执行的限制 (DailyAsyncApexExecutions)，而不是特定于可队列的分配。
可排队链接通过将下一个作业从当前作业的执行方法中排队来实施多步骤工作流。链启用顺序处理：标注 → 解析响应 → 排队跟进操作。每个可队列执行最多 1 个队列可以防止失控链。使用完成检测设计链，以避免无限循环。
@future 方法使用情况将 @future 用于简单的异步操作，无需复杂的参数（仅限原始参数）和链接。限制：每个 Apex 事务 50 次 @future 调用。 @future 提供最简单的异步模式，但缺乏可见性：没有作业监控、没有链接、没有复杂的参数。新开发的首选可排队。
计划 Apex 优化将计划操作合并为单个可计划类，调度到特定处理器。每个组织最多 100 个计划作业需要战略整合。安排在非工作时间，以减少与用户操作的竞争。使用 Scheduled Apex 进行编排，将繁重的处理委托给 Batch Apex。
平台事件重放设计处理重放场景的订阅者：订阅者失败后的重复事件、长期中断后的差距事件。维护每个订阅者上次处理的 ReplayId。使用 EventBus.getReplayId() 检测重放与新事件。实施幂等处理（两次处理相同事件会产生相同结果）。
继续模式对于需要 >5 秒响应时间的 Lightning 组件中长时间运行的标注，使用“继续”。继续启用多个同时 120 秒的标注，提高了并行操作的感知性能。限制：每个请求 3 个继续。实施超时处理和用户反馈。

有关内联示例和详细指导，请查看可靠性支柱，或浏览模式和反模式资源管理器。