1、数据存放
1）每个PutRecords请求最多可支持500条记录。
2）请求中的每条记录可以大到1 MiB，整个请求的最大限制为5 MiB，包括分区键。
3）每个分片可以支持每秒最多1,000条记录的写入，最大数据写入总量为每秒1 MiB。
2、数据处理
1）每个分片均提供 2 MiB/秒的读取吞吐量。
2）每个分片每秒可支持多达 5 个读取事务。每个读取事务可提供多达 10,000 个记录，每个事务的上限为 10 MiB。
3）每个分片可以通过 GetRecords 支持每秒 2 MiB 的最大总数据读取速率。如果对 GetRecords 的调用返回 10 MiB，则在接下来的五秒内发出的后续调用将会引发异常。因4）此将 idleTimeBetweenReadsInMillis 属性设置为少于 200ms 可能导致您的应用程序观察到 ProvisionedThroughputExceededException 异常。
5）在使用 KCL 时，您应确保实例的数量不超过分片的数量（故障待机除外）。每个分片正好由一个 KCL 工作程序处理并且正好有一个对应的记录处理器，因此您永远不需要多个实例来处理一个分片。但是，一个工作程序可处理任意数量的分片，因此分片的数量超过实例的数量没有关系。
3、使用者应用程序的读取速率比预期的慢，读取吞吐量低于预期的最常见原因如下：
1）多个使用者应用程序的总读取量超过每个分片的限制。有关更多信息，请参阅 Kinesis Data Streams 限制。在这种情况下，请增加 Kinesis data stream 中的分片数。
2）指定每个调用的最大 GetRecords 数的 limit 可能已配置为较低的值。如果您正在使用 KCL，您可能已经使用一个较低的 maxRecords 属性值配置了工作程序。一般来说，我们推荐对此属性使用系统默认值。
3）出于很多可能的原因，您的 processRecords 调用内的逻辑花费的时间可能超过预期；该逻辑可能是 CPU 使用率高、I/O 阻止或同步出现瓶颈。要测试是否如此，请对空的记录处理器进行测试运行并比较读取吞吐量。有关如何跟踪传入数据的信息，请参阅重新分片、扩展和并行处理。
4、重新分片、扩展和并行处理
1）例如，如果您的应用程序正在 1 个 EC2 实例上运行，并且正在处理 1 个包含 4 个分片的 Kinesis data stream。这 1 个实例包含 1 个 KCL 工作程序和 4 个记录处理器（每个分片有 1 个记录处理器）。这 4 个记录处理器在同一进程内并行运行。
2）接下来，如果您扩展应用程序以使用其他实例，您将有 2 个处理 1 个包含 4 个分片的流的实例。当 KCL 工作程序在第二个实例上启动时，它会与第一个实例进行负载均衡，以便让每个实例现在处理两个分片。
3）如果您随后决定将 4 个分片拆分为 5 个分片。KCL 会再次跨实例协调处理：一个实例处理 3 个分片，另一个实例处理 2 个分片。类似协调在合并分片时出发生。
4）当重新分片增加了流中的分片数时，记录处理器的数量的相应增加会增加托管处理器的 EC2 实例上的负载。如果实例为 Auto Scaling 组的一部分，并且负载增加得足够多，则 Auto Scaling 组会添加更多实例来处理增加的负载。您应在启动时配置用来启动 Amazon Kinesis Data Streams application的实例，以便让其他工作程序和记录处理器在新实例上立即激活。
5）重新分片通常是由监控分片数据处理指标的管理应用程序执行的。尽管 KCL 本身不启动重新分片操作，但它能够适应由于重新分片而生成的分片的数量的变化。
5、要扩展您的应用程序中的处理，您应测试以下方法的组合：
1）增加实例大小（因为所有记录处理器都在进程内并行运行）
2）增加实例的数量，最多为开放分片的最大数量（因为分片可以单独处理）
3）增加分片的数量（这会提高并行机制的级别）
6、其他建议
1）建议针对每个应用程序每秒轮询每个分片一次。这使您能够具有并行处理流的多个使用者应用程序，而不会达到每秒 5 次 GetRecords 调用的 Amazon Kinesis Data Streams 限制。流的吞吐量在分片级别进行配置。每个分片具有一个 最多 每秒 5 次交易 可用于读取，最多可达的最大总数据读取速率为 每秒 2 MB 的读取吞吐量。如果您发现您的应用程序一直受到限制，则应考虑增加流的分片的数量。
2）若要处理大批量的数据，降低您的应用程序中的网络和其他下游延迟时往往更高效。