Amazon web services 即使在有足够的碎片后，也能通过超感觉提供运动

在将数据写入运动流时，我们面临着被排除的异常异常问题

案例1: 我们使用单个m4.4XL（16核，64GB内存）实例在Jmeter的3k请求流上写入数据，EC2实例每秒为我们提供1100个请求，因此我们选择2个碎片流（即2000个eps）。 结果，我们能够在流中成功地写入数据，而不会有任何损失

案例2: 为了进一步测试，我们创建了10个EC2 m4.4XL（16核，64GB内存）集群和11个分片流（基于一个分片的简单计算1000eps，所以10个分片+1供应）。 当我们测试EC2集群时，使用来自Jmeter的不同请求案例，比如3、10、30百万。我们通过日志文件上的PutteExceedeDexception错误接收到ProvisionedThrough

在Jmeter端，EC2集群为我们提供7500eps，我相信7500eps流的11000eps容量不应该返回这样的错误

---

您能帮我理解这个问题背后的原因吗。

请检查您的制作人，您确定要将数据插入到不同的碎片中吗？PutRecordRequest调用中的“PartitionKey”值可能会对您有所帮助。

听起来，Kinesis并没有在您的碎片上均匀地散列/分布您的数据-一些碎片是“热的”（通过PutExceedexception获取

配置的数据），而另一些碎片是“冷的”

要解决这个问题，我建议

使用
ExplicitHashKey
参数可以控制数据进入的碎片。有一些关于这方面的基本信息（但没有它应该提供的那么多）
此外，确保碎片在散列空间中均匀分割（适当的起始/结束散列键）
最简单的模式是只为每个碎片定义一个预定义的显式密钥，并让您的PutRecords逻辑对每个记录进行迭代-完全均匀分布。在任何情况下，请确保您的记录哈希算法将记录均匀地分布在碎片上

另一种基于使用ExplicitHashKey的替代/扩展是将hashspace的一个子集专用于“溢出”shard（在您的情况下，1个特定的ExplicitHashKey值映射到一个shard），当您开始限制正常shard时，将记录发送到那里以供重试。
我认为您需要传递不同的值用于记录在不同“碎片”之间共享数据的“分区键”。
即使您创建了多个分片，并且所有记录都使用相同的分区键，那么您仍然在写入单个分片，因为它们都具有相同的哈希值。请在此处查看更多信息