任务/工作流触发周期

如果任务或者工作流采用定时触发或周期触发，触发时间的间隔不允许小于 30 秒。

触发太过频繁的任务并不适用分布式任务调度系统，因为分布式任务调度系统主要解决任务的可靠执行（例如通过失败重试、故障转移），对任务执行的实时性没有严格的保证。分布式任务调度系统本身在进行可靠调度上就可能存在秒级的延迟（例如在性能较差的环境中），对于秒级触发周期的任务可能会产生任务积压以及乱序。对于实时性要求较高的任务，建议采用简单高效的方式实现，例如在应用中启用定时任务（如 Spring 中通过 @Scheduled 注解创建定时任务）。

任务/工作流触发时间

如果没有特殊需求，尽量不要让任务和工作流集中在同一个时间点触发。

例如我们创建了一堆任务，期望凌晨 00:00:00 进行触发，如果对时间没有严格的要求，我们可以将触发时间分散在一个时间周期内，如 00:00:00 - 00:10:00。这样做既可以避免 TCT 在某一个时候任务调度量激增加重系统负担，也可以避免执行器实例（客户端）同时出现大量并发任务出现性能问题。

任务/工作流优先级

TCT 支持任务/工作流的优先级配置，分为一般和重要两个优先级。使用时推荐根据任务/工作流的性质，合理设置优先级，简单地全部设置为重要或者一般并不是好的方式。一般优先级的任务/工作流在系统出现性能瓶颈的时候会被概率性地限流（直接标注某次触发为被限流，不进行调度），以确保重要优先级的任务/工作流能正确地执行，同时保护系统能够继续平稳运行不至于被拖垮。

默认部署组

TCT 提供了一个默认的部署组（名称和 ID 均为 default）以及 3 副本的执行器实例。该部署组是一个公共的部署组，所有的用户都可以查看该部署组以及该部署组下的任务和工作流，它的作用主要是为了执行一些简单轻量的 TCT 任务以及快速体验 TCT。对于复杂的生产任务以及需要做权限隔离的使用场景，不建议使用默认的部署组，用户需要创建自己的部署组并设置权限。

任务发现

用户在基于 SDK 开发任务时，建议将任务注册成 Bean 以便能被 SDK 自动发现并注册到 TCT 服务端，这样用户在创建任务时能够直接获取到任务以及任务相关的信息。

执行器实例 ID

TCT 是根据执行器实例注册时提供的执行器实例 ID 来标识该执行器实例的，以便执行器实例发生下线重新注册时 TCT 服务端能够识别出来，在执行器实例重启或者重建的时候，需要尽量保证执行器实例 ID 不变。

尤其需要注意的是在 Kubernetes 中容器化部署执行器的时候，通常我们会将 Pod 名称作为执行器实例 ID，如果我们采用 StatefulSet 方式部署，那么各个 Pod 的名称是固定的（格式为 xxx-0, xxx-1, xxx-2），即使 Pod 删除重建名称也不会变。但是如果采用的是 Deployment 方式部署，每次重建 Pod，Pod 名称就会改变，这样执行器实例 ID 也会发生变化。这里强烈建议采用 StatefulSet 方式部署执行器。

如果执行器实例 ID 发生变化，影响是什么呢？执行器 ID 变化主要会导致 TCT 无法下发指令（如停止执行）干预任务的执行，例如 TCT 下发了任务到执行器实例 A 中执行，如果这时候执行器实例 A 被重建了，并且实例 ID 变成了 A1，因为执行器实例重建了任务就不存在了，后续不会上报任何该任务相关进度信息到 TCT 中，而 TCT 也无法对执行的任务进行干预（如停止执行），因为 TCT 是将任务下发给了 A，而现在找不到 A 的连接，TCT 无法判断是 A 彻底下线了还是因为网络隔离暂时联系不上了。这样最终会导致任务在 TCT 中一直处于执行中的状态直到超时，并且正常的手动停止也不会成功，需要通过强制停止来扭转任务状态。