弹性扩缩容是云原生数据库的招牌能力之一。传统数据库扩容意味着停机、迁移数据、重启，少则几小时多则几天。云原生数据库宣称可以在线扩容，业务无感知，听起来很美好。但"无感知"到底能做到什么程度，不测一下是不知道的。这篇文章通过实际的扩缩容测试，验证TeleDB的弹性能力是否名副其实，以及在什么条件下业务确实无感、什么条件下还是有感知的。

扩容测试

测试从一个三节点集群开始，每个节点8核16G。在集群上持续运行混合负载（读写比7:3），模拟正常业务流量。扩容操作是在不停业务的情况下增加两个新节点，使集群变为五节点。

扩容过程从管理控制台发起，选择"在线扩容"，指定新的节点规格和数量，点击确认。系统开始自动执行扩容流程：分配新节点、初始化、加入集群、数据重分布。

从业务侧观察，扩容过程中QPS和延迟指标有一定波动但未出现中断。数据重分布阶段，部分查询的延迟有所上升，增幅约20%到30%，但都在可接受范围内。没有出现连接断开或请求失败的情况。整个扩容过程约持续了20分钟，完成后QPS能力提升了约60%（从三节点到五节点，考虑到协调开销，线性扩展约60%到70%是合理的）。

从资源使用来看，扩容过程中CPU使用率有一个明显的上升期，对应数据重分布时的数据搬运和重新分片。新节点加入后，数据从老节点迁移到新节点以实现负载均衡，这个过程会消耗网络带宽和磁盘IO。

缩容测试

缩容是扩容的反向操作，把五节点缩回三节点。缩容的逻辑是先把即将移除节点上的数据迁移到剩余节点，然后安全移除节点。

缩容测试同样在业务运行中进行。从控制台发起缩容，选择移除两个节点。系统开始数据迁移，将待移除节点上的数据分片转移到剩余三个节点上。

缩容过程中业务表现比扩容时差一些。原因是数据迁移导致剩余节点的负载增加——既要承接迁移过来的数据，又要继续处理业务请求。在数据迁移高峰期，延迟上升约40%，有几秒钟出现了短暂的请求排队。虽然没有请求失败，但严格来说这不算完全"无感"。

缩容完成后，集群恢复三节点状态，QPS能力回到扩容前的水平。整个缩容过程约25分钟，比扩容稍长，因为数据迁移需要更加谨慎地保证一致性。

什么条件下真正无感

根据测试结果，TeleDB的弹性扩缩容在以下条件下能做到基本无感：第一，业务负载不高，系统有充足的资源余量来应对数据重分布的额外开销。第二，数据量适中，重分布可以在较短时间内完成。第三，扩容操作而非缩容操作，扩容时新节点加入增加了总资源，对现有业务影响较小。

以下条件下业务会有感知：第一，业务处于高峰期，系统资源接近饱和，数据重分布的额外开销会导致延迟明显上升。第二，数据量很大（TB级以上），重分布耗时长，影响窗口也长。第三，缩容操作，因为剩余节点要同时处理业务和接收迁移数据，负载压力更大。第四，有长事务在运行，数据重分布需要等待长事务结束，可能导致延迟。

实际使用建议

基于测试结果，给出几条实际使用建议。

第一，扩缩容操作尽量在业务低峰期进行。虽然TeleDB支持在线扩缩容，但低峰期操作可以把对业务的影响降到最低。如果必须在高峰期操作，建议先做小范围验证。

第二，规划好扩容节奏。与其等到资源紧张时一次性扩容很多节点，不如提前规划，分批扩容。每次扩容一两个节点，对业务的影响更小。

第三，缩容要比扩容更谨慎。缩容意味着减少资源，如果业务流量没有真正下降，缩容后可能导致资源不足。确保缩容前有充分的数据支撑（如持续一周以上的低资源利用率）。

第四，扩缩容后做一轮性能验证。确认新的集群配置下业务性能正常，资源分布均衡。有时候扩容后数据分布不均匀，需要手动触发一次负载均衡操作。

TeleDB的弹性扩缩容能力整体来说是可靠的，在合理使用条件下确实能做到业务基本无感。但"基本无感"不等于"完全无感"，理解它的工作原理和边界条件，才能在合适的时机用合适的方式使用这个能力。