目前，我们使用Redis作为内存中的快速缓存。它运作良好。问题是，一旦Redis重新启动，我们需要通过从持久性存储中获取数据来重新填充它。这使我们的持久存储超出其容量，因此恢复需要很长时间。
我们研究了Redis持久性选项。最佳选择（不影响性能）是将AOF与'appendfsync everysec'一起使用。但是通过这个选项，我们可以放弃最后的第二个数据。这是不可接受的。将AOF与'appednfsync always'一起使用会产生相当大的性能损失。
所以我们正在评估单节点Aerospike。是否保证在电源故障时不会丢失数据？即，响应写入操作，一旦Aerospike向客户端发送成功，即使我拉动服务器机器的电源线，数据也不会丢失。正如我上面提到的，我相信Redis可以使用'appednfsync always'选项来提供此保证。但我们没有考虑它，因为它有相当大的性能损失。
如果Aerospike可以做到这一点，我想详细了解Aerospike中的持久性是如何工作的。请分享一些解释相同的资源。
我们不是在寻找分布式系统，因为强大的一致性对我们来说是必须的。在节点故障或裂脑情景中不应丢失数据。
如果不是airospike，你能指点我另一个可以帮助实现这个目标的工具吗？
这不是数据库问题，而是硬件和风险问题。
所有数据库（具有持久性）都以相同的方式工作，有些数据库将数据直接写入物理磁盘，而其他数据库则告诉操作系统写入数据。确保每次写入都是安全的唯一方法是等到磁盘确认写入数据。
没有办法解决这个问题，正如您所见，它大大降低了吞吐量。这就是为什么数据库使用内存缓冲区并在短时间内将批量数据从缓冲区写入磁盘的原因。但是，这意味着在将数据写入缓冲区之后但在将数据写入磁盘之前发生机器问题（电源，磁盘故障等）的风险很小，这将导致数据丢失。
在单个服务器上，您可以通过多个电源，备用电池和其他安全措施购买保护，但这很快就会变得棘手和昂贵。这就是分布式架构如今在可用性和冗余方面如此普遍的原因。分布式系统并不意味着您失去一致性，而是通过保护您的数据来帮助确保它。
解决问题的最简单方法是使用允许复制的数据库，以便每次写入至少2台不同的计算机。这样，一台机器断电不会影响到另一台机器的写入，您的数据仍然是安全的。
您仍然需要防止可能影响所有服务器的更高级别的停电（例如您的整个数据中心断电），但您可以通过分布更多边界来解决此问题。这一切都取决于您可接受的风险程度。
在调整数据库中的磁盘写入间隔和使用适当的分布式体系结构之间，您可以获得所需的一致性和性能要求。
我在Aerospike工作。您可以选择使用磁盘持久性将命名空间存储在内存，磁盘或内存中。在所有这些场景中，与现实世界基准测试中的Redis相比，我们的表现更为出色。
在写入发生时考虑磁盘上的存储，它会在刷新到磁盘之前到达缓冲区。在成功写入缓冲区之前，ack不会返回到客户端。有理由认为，如果在缓冲区刷新之前拉动电源线，则在单个节点群集中，写入可能已被激活到客户端并随后丢失。
答案是在集群中有多个节点，并且replication-factor> = 2.然后写入到客户端和副本上的缓冲区，并且在成功获取客户端之前必须成功。如果从一个节点拉出电源，则另一个节点上仍然存在副本，并且不会丢失任何数据。
所以，是的，有可能使Aerospike具有弹性，因为它可以合理地以低成本和最小的延迟进行。最好的办法是下载社区版，看看你的想法。我怀疑你会喜欢它。
我相信aerospike可以满足您的需求，您可以将其配置为aerospike.conf中名称空间（即DB）级别的混合存储，该存在于/etc/aerospike/aerospike.conf中
有关详细信息，请参阅此处的官方文档：http://www.aerospike.com/docs/operations/configure/namespace/storage/
我相信无论你使用什么样的DBMS技术，如果你必须保证存储介质是存储介质的延迟，或者在集群的情况下网络结构的延迟，你都会受到影响。数据不会丢失。 （注意如果有可能整个物理设备失去电力，那么Ben Bates的解决方案就不会起作用，即两个节点都会失去电力。但是，我认为廉价的UPS会大大地（如果不是完全的话）减轻这种担忧。）与独立的内存数据库实例相比，这些延迟会导致显着的插入/更新/删除性能下降。
另一个需要考虑的选择是将NVDIMM存储用于内存数据库或用于从中恢复的预写事务日志。它具有绝对最低的延迟（与传统DRAM相当）。而且，如果您的内存数据库适合可用的NVDIMM内存，您将获得最快的恢复速度（无需从事务日志中重放），并且性能与原始IMDB性能相当，因为您已经回归到单个数据库写入与2+写入，用于添加预写日志和/或复制到群集中的另一个节点。但是，您的内存数据库系统必须能够支持直接恢复内存数据库（而不仅仅是从事务日志中）。但是，同样有两个要求：1。整个数据库必须适合NVDIMM内存2.数据库系统必须能够在系统重启后直接恢复数据库，而无需事务日志。
更多在本白皮书http://www.odbms.org/wp-content/uploads/2014/06/IMDS-NVDIMM-paper.pdf