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> 0：重试次数与配置的TTL一样多。 一旦耗尽TTL，数据就会被丢弃。
• TTL = -1：无限重试，即数据被永久重新注入通道，直到它被持久化或通道变满为止。

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

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

• 如果您不想重试，只需配置0即可。
• 如果您想重试但是不介意丢失数据以进行一定数量的重试，则配置正值。
• 如果您想重试但不想丢失数据，则配置-1和大通道容量，因为最终存储可能会在未知时间内停机。

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