2026 预约排程系统服务器租用测评：Cal.com 时区、并发预占与通知投递配置 5 项对比全解

2026 预约排程系统服务器租用测评：Cal.com 时区、并发预占与通知投递配置 5 项对比全解

周一早上九点，一家做企业培训的公司在排程系统里同时放开了四十名顾问未来两周的档期。九点零二分，两位客户各自点下了同一个顾问、同一个十点整的时段，系统给两个人都回了确认邮件，两个人的日历上也各自出现了一条重叠的预约事件。运维的第一反应是"并发太高，机器扛不住"，于是把应用实例从两台扩到六台，结果同类工单在接下来一周里反而更多了。

这个反应很典型，也很危险。把预约排程当成一个"读接口"，会自然推导出"加机器就能扛"的结论；但排程系统的核心动作不是读，是"在确认之前先把一段时间从可用池里扣掉"，这本质上是一次写操作，而且必须是原子的写操作。多开一台实例，只是多开了一个能同时进入"先查后写"这段窗口的入口。

周一早上九点两条预订同时成功，暴露的是预占语义不是并发能力

把那次事故拆开看，两个请求各自走的路径几乎一样：读取顾问当天的可用区间，减去已被占用的区间，判断十点是否还在余量里，写入一条新的预订记录，然后触发通知。前后两个请求之间没有任何互斥，只要它们在同一瞬间都读到了"十点还空着"，就会都往下走。机器越多，两个请求落在不同进程、不同连接上的概率越高，这段窗口被同时踩中的机会就越大。

所以这不是容量问题，是一致性问题。容量问题的解法是加资源，一致性问题的解法是收缩事务边界，把"判断"和"占位"压进同一个不可分割的单元里。这两件事在运维动作上完全不同：前者买机器，后者改表结构和索引。搞错了方向，钱花了，故障率还上升。

判断依据也很直接：如果故障只在流量高峰出现、低峰期从不复现，多半是容量；如果故障跟流量无关、只在"两个人抢同一个整点"时出现，那就是语义。这类工单的另一个特征是"制造它很便宜"——用两个浏览器标签、同一个账号的两个会话，就能稳定复现。能稳定复现的问题，通常不该用扩容去掩盖。

一次档期查询背后是四层集合运算，时区不是显示层的装饰

很多人以为时区只是把 UTC 时间格式化成本地时间显示出来。在排程系统里，时区是参与计算的输入，而且是第一层输入。用户看到的是"我的上午十点"，顾问看到的是"我的上午十点"，这两个十点在数据库里对应的绝对时刻可能相差好几个小时，中间还可能夹着夏令时的切换点。

一次完整的可用性查询大致要过四层集合运算。第一层是把参与者的时区折算成统一的绝对时间轴；第二层是把每个参与者的工作日历（工作时间段、休息日、临时请假）投影到这条轴上；第三层是扣掉已有预订，以及预订前后需要预留的缓冲时间；第四层是套上最小提前量，把"现在起若干小时之内"的时段整体排除。四层做完，得到的是若干离散的可用区间，再做一次交集，才是最终能展示给用户的可选时段。

四层运算意味着一次查询的代价不是常量，而是随参与者数量、日历条目数量、缓冲规则复杂度一起增长的。三个人参与的会议，交集运算的次数比单人多出数倍；如果还叠加了"每个参与者各自的缓冲偏好"，那这一层就要在交集之前对每个人的区间做一次膨胀。这就是为什么同一个系统在单人预约场景下轻得像静态页，到了多方会议排期就明显吃力。

需要强调的是，这里讨论的是运算结构，不是具体耗时。单次查询要消耗多少计算资源，取决于参与人数、日历密度和规则条数，必须用真实数据集压测确认，任何凭经验给出的估算都只能当量级参考。规划机器时，正确的做法是把"参与者数 × 日历条目数 × 规则条数"当成负载因子，按这个因子做梯度压测，而不是按"每天多少个预约"这种业务指标去推。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

把时间按本地时区存进数据库，等于给每一次查询埋一颗雷

自建部署里最常见的一处结构性错误，是把预订的开始时间按用户所在时区存成"不带时区的时间戳"。表面上一切正常，因为开发和测试都在同一个时区里跑。等来了跨时区用户，或者遇上夏令时切换的那一周，问题会集中爆发：同一个十点，在切换日可能不存在，也可能出现两次。

正确的口径是存储绝对时刻，时区只作为"展示与规则解释"的属性单独存一列。用户设定的"每周三上午九点可用"，这条规则本身要带时区标记；而由它生成的具体预订，落库时应该是绝对时刻。这两类数据混在一起存，后面的交集运算就没法做——因为你无法判断一个"九点"到底是哪个九点。

还有一个更隐蔽的坑：夏令时切换那一周，某些本地时间在物理上不存在。如果系统按"本地时间 + 时区名"去推算绝对时刻，推算函数遇到不存在的时刻会怎么办，各家实现并不一致，有的往前挪一小时，有的直接报错。排程系统在这一周产生的重复预订和错位预订，往往被误判成并发问题，实际上是数据模型问题。

判断一套自建排程是否踩了这个坑，有个成本很低的办法：把一个预订的时区改掉，看通知邮件里的时间、日历事件里的时间、导出报表里的时间是否同步变化。三者不一致，就说明绝对时刻和本地时刻在链路里被反复转换了。这种转换每多一层，错一层的概率就多一分。

并发预占必须落在数据库唯一约束上，应用层锁在跨进程场景里形同虚设

回到开头那两条同时成功的预订。要真正堵住它，靠的不是在应用代码里加一把锁，而是让数据库来裁决。做法是把"某个资源在某个时间段的占用"抽象成一条有唯一性的记录，占用时直接插入，重复插入会被唯一约束挡下来，插入失败的那一方拿到明确的冲突信号，转去提示用户换时段。

为什么应用层锁不可靠，原因有三层。第一层是进程边界：单机锁只在单进程内有效，多实例部署时每个实例各有一把锁，互不相识。第二层是生命周期：锁的持有者可能因为超时、重启、连接中断而没能释放，留下死锁或者锁泄漏。第三层是可见性：锁保护的是一段代码，而数据一致性需要保护的是一个数据状态，这两者之间隔着网络和事务提交，锁释放和事务提交不是同一时刻。

数据库唯一约束的好处是把裁决权交给唯一知道真相的那一层。它不依赖应用有几个实例，不依赖网络是否分区，也不依赖代码有没有写漏。代价是需要设计好唯一键：把资源标识与时间段起点组合成唯一键，只能防"起点完全相同"的冲突；如果时段长度可变，还要额外处理"部分重叠"的情况，这部分通常要靠事务内的一次范围检查加短事务来兜。

这里有个容易被忽略的取舍：事务越短越好，但范围检查必须在事务内完成。把检查放到事务外，等于把窗口又还回去了。合理的边界是"检查 + 插入"在同一个短事务里，事务之外的所有动作——生成日历邀请、发确认邮件、写审计日志——全部推到事务提交之后异步做。事务里塞进一次第三方 API 调用，会让事务的持有时间从毫秒级变成秒级，锁等待和连接占用都会成倍放大。

日历邀请外呼会把 Node 的请求链路挂住，异步化是底线不是优化

Cal.com 这类应用跑在 Node 上，请求处理是单线程事件循环模型。这个模型对 I/O 密集很友好，前提是 I/O 必须是异步的。一旦在请求链路里同步等待一个第三方日历服务的响应，占住的不只是一个连接，而是整条事件循环的处理能力——后面排队的请求全部被推迟。

日历同步恰恰是最容易拖时间的环节。Google、Microsoft 365、CalDAV 这三类外部系统，各自的响应特性不同，网络路径也不同，遇到对方限流、证书链异常、账号授权过期，请求可能长时间没有结果。如果代码里没有设超时上限，这个等待就没有边界。用户看到的是"点了确认按钮，页面一直转圈"，后台看到的是事件循环被一批挂起的请求占满。

工程上的处理是两条：一是所有外呼都必须有明确的超时上限，超时即失败，失败进重试；二是外呼本身不放在用户请求的同步路径里，而是作为提交后触发的异步任务。这样做的直接后果是"确认成功"和"日历已同步"变成两件事，产品上必须接受这个不一致窗口，并在界面上把状态区分开——已确认但同步中，和同步失败待重试，是两种不同的用户预期。

反过来说，如果业务要求"日历没写成功就不算预约成功"，那就必须把外部系统当成本系统的强依赖来设计，这时候要考虑的就不是异步化，而是外部系统不可用时的降级策略和人工补录通道。这两种取向没有优劣，但不能含糊：含糊的结果是产品说"要强一致"，工程做了"最终一致"，最后在客服那里对不上账。

通知投递必须进队列，同步发信是在拿事务时间换第三方的可用性

一次预约成功之后要发的通知通常不止一条：给预约人的确认信、给被约人的提醒、给团队的 webhook 回调、给外部日历的邀请。这四类通知走的通道完全不同，可靠性要求也不同。把它们串在请求链路里同步发，等于让一次预约的成功率取决于四个外部系统的当时状态。

邮件是最典型的不确定项。发信服务器的连接、对方的收信策略、灰名单延迟、退信处理，任何一环出问题都可能让一次 SMTP 交互拖上很久。webhook 更不可控，对端可能根本没起服务，也可能返回 5xx 然后无限重试。这些都应该被隔离在队列里，由独立的消费进程按自己的节奏处理，失败进重试，重试到上限再转人工。

队列的引入会带来一个新的设计问题：重复投递。任务重试、消费确认丢失、进程重启，都会导致同一条通知被发两次。对确认邮件来说，重复发一次的代价是用户困惑；对 webhook 来说，重复调用可能让对方重复记账。所以队列里的任务必须带幂等键，消费端要能识别"这条我已经处理过"。这个幂等键通常就用预订记录的主键，天然唯一。

还有个容量上的连带影响：通知队列堆积会反过来影响数据库。如果消费进程和 Web 进程共用同一个应用实例，队列一堆积，CPU 和时间片就被消费任务吃掉，用户侧的档期查询开始变慢。规模上去之后，消费进程必须和应用进程分开部署，这不一定需要两台机器，但至少要能在资源上划出独立配额。

这套系统的瓶颈位在数据库写路径，不在 Node 的 CPU 核数

排程系统的读写比例很悬殊，读远多于写。这种负载形态容易让人误判：既然读多，那就该加缓存、加 CPU。但真正会出问题的是写路径，因为写必须是强一致的，缓存帮不上忙，而写又被唯一约束和事务串行化了。

具体来说，一次预占写入要在唯一索引上做一次冲突判定，这个动作在同一个资源、相邻时间段上是会互相等待的。热门顾问的热门时段，本质上是一个高竞争的小热点。热点上的写入不会因为 CPU 核数增加而变快，反而会因为并发连接增多而加剧锁等待。这也是为什么扩应用实例会让问题变严重的另一个解释：更多的并发写入同一个热点，等待链更长。

数据库的资源配置要围绕这条写路径来定。连接数是最容易出问题的一项：应用侧连接池开得很大，数据库侧的并发工作线程却是有限的，多出来的连接只是在排队，同时每个连接都要占内存。合理做法是把连接池总量控制在数据库能有效并发的范围内，超出的部分在应用侧排队，而不是丢给数据库去排队。

磁盘这一项经常被低估。预订表的写入量本身不大，但索引维护、事务日志、自动清理都会持续产生 I/O。把这些和应用日志、通知附件放在同一块盘上，写放大会互相干扰。独立数据盘不是为了容量，是为了把 I/O 路径分开。这一点在云主机上尤其要注意，系统盘的 IOPS 配额通常远低于数据盘。

出口带宽和网络位置，往往比机型更早成为瓶颈

排程系统的单次请求体很小，一次档期查询来回也就几十 KB，很容易得出"带宽需求很低"的结论。这个结论在纯自建、用户集中在同一区域时基本成立。但只要涉及跨境访问，或者通知里带附件、带日历邀请文件，情况就变了：真正的问题不是总带宽不够，而是出口方向和链路质量不对。

跨境访问的典型表现是"服务端一切正常，用户侧就是慢"。查看服务端指标，CPU、内存、磁盘都平稳，请求处理时间也不长，但用户端的完整加载时间很长。差额在网络往返上。这类问题加 CPU 没有任何作用，加带宽也未必有用——如果链路要绕行，带宽再大，单次往返的固定开销也在那里。

判断方法很朴素：在目标用户所在的城市做一次真实访问测试，看首字节时间和完整加载时间的差距。如果差距远大于服务端处理时间，问题在网络上；如果首字节时间本身就长，问题在服务端。这个测试要在真实网络环境里做，机房内部的测试机测不出这个差额。

所以选机房位置时，应该先画出用户分布，再决定节点放在哪里。用户集中在华南，就把主节点放在华南；用户分散在全国，就要考虑多线接入，让不同运营商用户的路径都尽量短。用一台远离用户的机器去堆配置，是最常见的资源错配——钱花在了用户感受不到的地方。

压测该怎么设计：用负载因子而不是用人数

"两千人要用什么配置"这个问题没法直接回答，因为两千人可能是一天两百条预约，也可能是一天两万条。人数是组织规模，不是负载指标。真正决定资源的是负载因子：并发档期查询数、参与者平均数量、每人日历条目数、每日通知条数、日历外呼次数，这五项乘起来才是压力。

压测的设计要围绕这五项做梯度。准备一份贴近真实的数据集——日历条目要有真实的密度分布，不能全是空日历；参与者要按真实比例混合，单人预约和五人会议都要有；热门资源要人为设置成高竞争，否则压不出热点。用均匀分布的数据压出来的结果，会系统性低估写路径的竞争程度。

观察指标的选择也要改。不要只看平均响应时间，那会被大量轻请求稀释。要看的是分位值，以及事务等待时间、锁等待次数、队列积压深度。这几个指标比 CPU 使用率更能说明系统在哪一层达到了边界。CPU 跑到百分之八十但事务等待很短，说明还有余量；CPU 只有百分之四十但事务等待在涨，说明瓶颈已经出现。

压测结论要落到"某个负载因子下需要什么配置"，而不是"支持多少人"。前者可以随业务变化重新推算，后者一旦写进文档就会变成教条，下次业务变了还得重新猜。这也是为什么本文的表格里所有数字都带"起"和"需按压测确认"——它们是可以被推翻的起点，不是承诺。

五档规模的资源配置口径与各自的关键约束

下表给的是配置区间和约束条件，不是性能承诺。每一档的 CPU 与内存都按"参与者规模 × 日历密度 × 通知条数"这个负载因子推导，实际取值必须按压测确认。同一档位里，数据库独立与否往往比 CPU 多两核更影响稳定性。

读这张表的方式是先定位"关键约束"那一列，再回头看硬件。个人版和 20 人团队这两档，真正的天花板不是 CPU，是"应用和数据库同机"带来的相互干扰；200 人这一档的分水岭是事务边界有没有定清楚，定不清楚的话，给到 16 核也照样出双预订。2000 人以上，讨论的已经不是单机选型，而是热点资源怎么分散。

预算上只给口径：这五档的月付区间跨度很大，从一台入门独服到多台独立实例加独立数据盘，属于不同的量级。具体价格随地域、带宽、是否独享、是否含机柜托管而变化，需要按当期官网信息询价，任何一次性报出的固定数字都不具备参考价值。

诊所预约、销售排期与面试排期，三种业务的配置侧重完全不同

同样跑一套排程系统，诊所预约的负载形态和销售抢档几乎是两个物种。诊所的预约量平稳、可预测，一天几十到几百条，但要求"提醒必达"——患者错过提醒就是空诊，空诊就是直接损失。这类业务该把资源压在通知链路上：队列要有独立配额，重试要能跨小时级别，失败要有人工可见的补发入口。数据库反而不需要很高规格，因为写竞争很低。

销售抢档是另一种形态。平时几乎没有写入，一旦开放新档期，几秒钟内涌进大量写请求，全部集中在该团队最抢手的几个顾问身上。这种脉冲式写入，考验的不是平均吞吐，而是峰值时的锁等待控制。配置上该做的是把热点资源的写入串行化范围压到最小，同时保证应用侧的连接池不会在峰值时把数据库压垮。给这种业务加 CPU 收益很小，给数据库加连接反而有害。

面试排期介于两者之间，但多了跨时区和日历同步两个特征。候选人和面试官往往在不同时区，一次排期要同时读多个日历、写多个日历，外呼次数是前两种业务的好几倍。这类业务的配置侧重在"外呼隔离"：同步任务要有独立的并发上限，不能让日历同步把用户侧的查询拖慢。日历授权过期是常态，要有批量检测和提醒机制。

这三种业务如果放在同一套系统里跑（很多公司确实是这么干的），就必须在队列层面做隔离。共用一个队列的结果是销售抢档时的通知洪峰把诊所的提醒任务挤到后面，医生的提醒迟到，患者的空诊率上升。隔离不需要多套机器，但需要独立的队列通道和独立的消费配额，这是配置问题，不是采购问题。

缓冲时间与最小提前量是产品参数，也是实打实的资源参数

缓冲时间这个设置，产品经理通常按"两个会议之间要留十分钟喘口气"来定，工程侧看到的却是另一件事：缓冲时间会膨胀每一个已占用区间，占用区间变多、变长，可用区间的交集运算量就跟着涨。一个顾问如果一天有二十个预约、每个前后各留十五分钟缓冲，实际被占用的时间跨度可能远超预约本身的总时长。

最小提前量同理。它把"未来若干小时"整体从可用池里切掉，看起来只是少显示几个时段，实际影响的是缓存命中率——因为这条规则随时间滑动，任何基于时间窗口的缓存都会很快失效。把最小提前量设得很短（比如十五分钟），意味着用户看到的就是几乎实时的可用性，缓存基本不起作用，每次查询都要回源计算。

这两个参数的取舍要摊开讲。缓冲时间设长了，顾问的日程更从容，但可售时段变少，转化率下降；设短了，可售时段多，但顾问疲于奔命。最小提前量设长了，运营排班更容易，但临时需求接不住；设短了，体验好，但系统压力大。这些是业务决策，工程的责任是把代价说清楚：某些参数组合会让查询成本上升一个量级，这时候要么接受更长的响应时间，要么多买资源。

有一种常见误判是把这两个参数当成纯展示层的过滤条件，在查询结果出来之后再筛。这样做的后果是所有下游逻辑都要重算一遍过滤后的边界，容易出边界错误，也浪费了计算。正确的做法是把它们作为交集运算的输入层，在生成可用区间的阶段就参与计算。

定时提醒任务扫的是全表，它的峰值往往出现在整点

提醒任务是这套系统里最不像高负载、实际却最容易制造峰值的部分。它的工作方式通常是周期性扫描：找出未来某个时间窗口内需要提醒的预订，逐条发出通知。这个扫描的时间窗口如果是滑动的一小时，那每分钟都要跑一次，每次都要按时间条件去查预订表。数据量小的时候毫无感觉，等预订表有了几十万行，这个查询本身就成了负担。

更麻烦的是峰值的形状。很多实现会把扫描周期对齐到整点或整五分钟，于是所有实例、所有任务在同一秒醒来，同时发起查询、同时写队列、同时触发外呼。这一秒内的负载可能是平均值的许多倍，而监控上的分钟级平均值会把这个尖峰抹平，让人误以为系统很闲。等到提醒开始延迟，才发现是整点的那一下挤住了。

处理办法有三个方向。一是把扫描周期打散，按实例或按资源做抖动，避免同时醒来；二是给扫描条件配上合适的索引，让每次扫描只读它需要的那一段，而不是全表扫；三是把"找出待提醒"和"发出提醒"分开，扫描只负责把任务写进队列，发放在队列里按自己的能力消费。第三个方向最有效，因为它把峰值从数据库转移到了可缓冲的地方。

还要注意提醒的幂等。任务重跑、实例重启、扫描窗口重叠，都会让同一条预订被提醒两次。对患者和客户来说，重复提醒比不提醒更伤信任。幂等键同样可以用预订主键加提醒类型，写入时靠唯一性挡掉重复。

备份与恢复：预订数据的一致性点比备份频率更值得讨论

排程系统的数据量不大，但恢复难度不低，原因是它和外部世界有状态耦合。数据库里的一条预订，在外部对应一条日历事件、若干条已发出的通知、可能还有一个 webhook 已推给下游系统。把数据库回滚到两小时前，这些外部状态不会跟着回滚，于是系统里"没有这条预订"，用户的日历里"有这条事件"。

所以备份策略要回答的第一个问题不是"多久备一次"，而是"恢复到某个时间点之后，怎么处理外部状态的不一致"。可行的做法是保留一份外呼记录，记录每条通知和每次日历写入的目标、时间、结果，恢复后按这份记录做对账，把多出来的外部事件清掉，把缺的补上。这份记录本身也要进备份集，而且要和数据库在同一个一致性点上。

备份频率取决于能承受丢多少数据。对预约类业务，丢一条预订的直接后果是双人到场或者一人空等，属于必须人工介入的事故，所以频率通常按小时级设计，同时配合事务日志做时间点恢复。但要注意，时间点恢复的粒度受日志归档间隔限制，间隔太长，实际能恢复到的点会比预期粗。

还有一件常被忽略的事：备份要能恢复才算备份。定期做一次真实恢复演练，把备份还原到一台独立机器上，跑一遍关键查询，看数据是否完整、索引是否重建、应用能否正常连上。演练中发现的问题——比如备份里缺了某个扩展、某个序列的当前值没跟上——在真事故里都是致命的。

七种会在半年内拖垮排程系统的配置误判

第一种是用应用层锁防重复预订。单机部署时看不出问题，一上多实例就失效，而且失效得很隐蔽——大部分请求正常，只有同时抵达的那一小撮出问题，测试很难覆盖。第二种是把日历同步做成同步调用，用户点确认后页面转圈，第三方一慢，整个实例的请求队列跟着堵。

第三种是把通知同步发。这条在预约量小的时候完全没问题，等通知量涨到每天几千条，发信环节的任何抖动都会直接变成用户看到的失败。第四种是把时区按本地时间入库，问题会在夏令时切换和跨境用户同时出现时才爆发，那时候改数据模型的成本已经很高了。

第五种是把数据库和应用合置还开大连接池。合置本身不是错，错在连接池开得比数据库能有效并发的数量还大，多出来的连接只是把排队从应用侧搬到数据库侧，还额外占用了内存。第六种是给定时提醒任务和应用共用一个进程，提醒任务一旦集中触发（比如整点批量扫描待发提醒），用户侧的查询就会被拖慢。第七种是不做外呼超时上限，这条最致命，因为它的表现是"偶发整体卡顿"，很难定位到具体代码。

这七种做法的共同点是把不确定性留在了请求链路上。排程系统的可用性，很大程度上取决于"用户点击确认之后，系统承诺了什么、又把什么推到了后台"。承诺越窄，系统越稳；承诺越宽，越需要靠资源去填。把界线划清楚之后，选型才有意义：机器是用来承载确定性负载的，不是用来吸收不确定性的。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付，机型规格与带宽档位以官网实时信息为准，预约类业务的数据库独立机型与独享带宽需单独询价。

双预订的真正来源是事务边界而不是并发量

把整篇文章的线索收一下：那两条同时成功的预订，不是因为两台机器不够，而是因为"判断有没有空"和"把这段空占掉"被放在了两个可以被打断的动作里。并发量只是把这两个动作错开的概率放大了，它放大的是一段本来就存在的窗口，而不是创造了这段窗口。窗口在，一台机器也能复现；窗口不在，二十台机器也不会出问题。

所以处理这类故障的顺序应该是先看事务边界，再看索引与唯一约束，最后才看资源。具体到操作层面，就是问三个问题：判断和写入是否在同一个事务里；事务内有没有第三方调用；事务的隔离级别是否足以支撑那次范围检查。这三个问题里任何一个答不上来，加机器都是无效动作，甚至会因为并发入口变多而让问题更频繁。

对自建部署的人来说，还有一个更实用的推论：先花时间把数据模型和事务边界做对，再决定买什么机器。因为做对之后，你会发现同一套业务量需要的资源比预想的少；做错之后，资源投入会变成一个没有底的黑洞，而且每次扩容都伴随一次故障率上升。这个顺序搞反，是排程系统上最常见的浪费。

从二十人到两千人，先加数据库还是先拆队列

这个问题的答案取决于当前卡在哪一段，而不是取决于人数。二十人规模时，最常见的卡点是应用和数据库抢同一台机器的资源，以及提醒任务和 Web 请求抢同一个进程。这时候该做的是把数据库拆出去，把定时任务拆成独立进程，而不是换更贵的 CPU。人数只是背景，卡点才是决策依据。

两百人规模时，卡点通常转移到写路径的竞争和日历外呼的堆积上。这时候要分两种情况：如果故障表现为"某些时段提交变慢"，先看事务边界和唯一索引的设计，这是数据库侧的问题；如果故障表现为"确认之后通知延迟很久"，先看队列消费的并发上限和外呼超时，这是队列侧的问题。两种情况可能同时存在，但修复顺序应该是先数据库后队列，因为数据库的问题会掩盖队列的问题。

两千人以上，队列必须独立，数据库必须独立，而且要考虑热点资源的分片——把最抢手的那些顾问或资源的写入分散到不同的表或不同的库，避免所有写竞争挤在同一个索引页上。这一步的代价是查询要跨分片聚合，复杂度上升明显，所以在两千人以下不建议提前做。提前分片的团队，往往会发现运维成本涨了三倍，而实际并发根本没到那个量级。

回到最初那个问题：先加数据库还是先拆队列。判断标准是看延迟出现在提交时刻还是提交之后。提交时刻慢，加数据库、改事务；提交之后慢，拆队列、加消费配额。两个都慢，先修数据库，因为提交时刻的慢会让用户重试，重试又制造更多写入，形成自我放大的循环。这个循环一旦形成，任何单点优化都追不上。