[每天向Kinesis发送数十亿条消息。
我们正在寻找一种允许我们以exactly-once保证将消息传递到Kinesis的实现。
我们的生产者框架要求流接收器对于一次交付保证是幂等的，而Kinesis并非如此。因此，我们目前正在至少一次]交付。 （当生产者方面出于某种原因必须重新启动流式微型批处理时，可能会出现重复，我们确实会看到它们）
我们开始查看Kinesis Producer库（KPL）回调函数
。基本上，我们将根据每条消息中存在的密钥来跟踪DynamoDB中传递了什么消息以及未传递什么消息的状态。如果我们知道已经发送了一条消息，我们将跳过该消息以重新尝试传递。然后似乎只有一次可能..有两个问题：1）我们唯一的问题-很有可能会丢失对回调函数的调用（例如，网络故障等），或者回调函数本身已经失败（例如，我们遇到了DynamoDB限制/中断等）-记录在案某处？我知道机会不高，但是我们希望设计一种能够对诸如此类的预期事物具有弹性的系统。
2）定时。假设是否出于某种原因Kinesis延迟调用了回调函数（5-15毫秒足以打破上述在DynamoDB中保持交付状态的回调函数中的某些假设）。尽管我们尚未收到有关交付的确认书，但我们的流媒体生产者框架已尝试重新交付它认为尚未交付的产品。此潜在问题有任何解决方法？
ps。我们知道一种解决方法是在应用程序端（来自该kinesis流的接收者）进行重复数据删除，但这在我们的项目之外，我们很难一次就可以完全进入该Kinesis流。
[每天向Kinesis发送数十亿条消息。我们正在寻找一种实现方式，使我们能够以一次保证的方式向Kinesis发送消息。我们的生产者框架要求...
对于＃1，如果您走下任何一条路，都会发现自己处于极端情况下，这可能会导致您丢失数据或重复通话。如果使用者未参与该协议，那么即使使用two phased commit protocol也无法在此处使用。