Fiware：数据丢失预防

Question

我正在使用0.27.0版本的上下文代理。我正在使用Cygnus通用启动器，我已经建立了一个MQTT代理，将外部设备连接到上下文代理。

我现在主要担心的是如何防止数据丢失。我将上下文代理和Cygnus mongodb数据库建立为副本集，但这并不能确保所有数据都会持久保存到数据库中。我看到Cygnus使用Apache水槽。查看其配置，可以配置重新注入重试：

# Number of channel re-injection retries before a Flume event is definitely discarded (-1 means infinite retries) 
cygnusagent.sources.http-source.handler.events_ttl = -1

¿将重试值设置为-1是个好主意？我已经读过永远重新注入频道的事件。 ¿可以采取哪些措施来确保所有数据都能保留下来？ ¿是否有任何功能进入面向该目的的软件生态系统？

Answer 1

关于Cygnus，TTL肯定是在发生错误后控制持久性重试的方法。重试意味着数据被重新注入通信源（接收Orion通知）和接收器（将数据保留在最终存储中）的内部通道中，以便将来进行持久性尝试。

此TTL的可能值为：

• TTL = 0：没有重试，即如果第一次通知数据无法在最终存储中持久存在（由于网络故障，存储错误等），则数据将被丢弃。
• TTL＆gt; 0：重试次数与配置的TTL相同。一旦耗尽TTL，数据就会被丢弃。
• TTL = -1：无限重试，即数据将永久重新注入通道，直到它被持久化或通道变满为止。

如评论所述，如果最终存储永远不会正常，则-1 TTL可能消耗信道容量，从而避免将新接收的数据放入信道。然而，如果最终存储永远不会好，那么这个缺点并不重要，对吗？ ：）

因此，我们可以说选择TTL的规则是：

• 如果您不想重试，只需配置0。
• 如果您想重试，但不要忘记丢失数据以保留一定数量的重试次数，那么请配置正值。
• 如果您想重试，但又不想丢失数据，请配置-1和大通道容量，因为最终存储可能会在未知时间内停机。

在任何情况下，TTL功能在此冲刺期间都会发生变化。行为将是相同的，但它不会应用于单个事件，而是应用于批量事件（批次当然可以是大约1个单个事件）。您将在下一版Cygnus（0.13.0）中看到此更改，并将于2016年2月底（在撰写本文时，下周发布:)）。我建议如果你想要广泛使用TTL功能，请等待这样的版本。