DynamoDB Streams 单Shard拆多子Shard的触发吞吐量阈值咨询

核心触发规则 #

翻遍官方公开文档都找不到“达到X吞吐量就100%触发Shard拆分”的固定条款，因为这个调度逻辑本身就不设置硬卡点，从大量生产环境的长期观察，判断逻辑完全围绕单Shard的设计容量基准展开：

• 单个Streams Shard的设计承载上限为：每秒1000次写入事件、或每秒2MB的事件payload
• 满足以下两个条件的持续窗口后，调度程序才会启动拆分流程：
  • 单个Shard的实际流量稳定维持在自身设计容量的75%以上，换算下来约750次/秒写入、或1.5MB/s的payload吞吐
  • 高负载状态连续保持15~30分钟，排除短时突发流量的干扰
• 调度程序不会在流量刚冲到阈值时立刻动手，会预留一段观察周期确认流量趋势，如果是几秒、几分钟的流量冲高后快速回落，会直接终止待执行的拆分计划，不会凭空生成子Shard

拆分机制的发生频率 #

• 这类拆分不是极少出现的异常机制，但确实需要较高的稳定吞吐才会触发，不属于日常低流量场景会碰到的操作
• 绝大多数中小规模业务的DynamoDB稳定写入吞吐在100~300次/秒的区间，离拆分触发的75%持续阈值差距较大，日常运维中很少能观察到拆分动作，容易让人误以为这个机制不存在
• 真到了频繁触发拆分的阶段，意味着单表的稳定写入已经达到数千次/秒的量级，属于中等以上规模的高写入负载场景

和已知“4小时规则”的边界 #

你之前查到的单Shard4小时写入跨度规则，和Shard拆分是完全独立的两套调度逻辑，不要混为一谈：

• 4小时规则是针对低负载场景下，Shard数据留存、过期合并压缩的判定标准，和高负载下的拆分逻辑没有关联
• 拆分生成的所有子Shard，同样适用相同的4小时留存调度规则，不需要额外适配

拆分场景的模拟与测试 #

日常测试环境很难通过短时间压测触发自动拆分：

• 拆分调度本身有数分钟到十几分钟的排队延迟，短时间压测结束后流量快速回落，调度程序会直接终止待执行的拆分流程，根本等不到实际拆分动作发生
• 完全不需要为了模拟拆分场景特意跑高强度压测：不管是用KCL还是自己实现的Streams消费者，原生设计就要求支持动态发现新生成的子Shard，只要在代码里把Shard ID的处理逻辑做成动态可发现的，不硬编码固定Shard ID，就算不等环境触发拆分，也能把兼容性做对

内容的提问来源于stack exchange，提问作者S4lesF0rce