去年三月我们发布KeyDB时，我们对多线程可能带来的潜力感到非常兴奋。今天，通过KeyDB，我们正通过我们全新的FLASH功能延续这一愿景，该功能实现了接近RAM的性能，同时利用了FLASH存储所能提供的巨大成本节省。与所有KeyDB功能一样，FLASH支持继续提供与现有KeyDB和Redis客户端的完全兼容性。

为KeyDB选择EC2实例

在搜索有关使用哪种实例类型的信息时，答案通常是“视情况而定”。本文通过EC2类型的一般数据以及对KeyDB性能的深入分析和不同类型的选择，对实例类型进行了精简说明。

KeyDB是Redis的一个高性能分支，无需分片即可在单个节点上达到1,000,000次操作/秒。本文不仅讨论了其性能，还讨论了随之而来的好处。更强大的性能意味着完成同样的工作需要更少的活动部件，而这一说法的内在含义值得探讨。

本文讨论了我们对EXPIRE命令及其工作方式所做的几项更改。我们添加了使用EXPIREMEMBER命令为集合中的单个成员设置过期的功能，并且还使主动删除能够以近乎实时的方式运行，这对于那些在生产中严重依赖使用过期功能的用户来说具有巨大优势。在处理EXPIRE命令的过程中，我们实际上通过这些改进节省了5-10%的内存。

我们很高兴地推出5.1版本，该版本为RELEASE_5分支带来了新的稳定功能。如果您一直没有关注KeyDB，这里有一些您可以期待看到的新东西！

如果我告诉您，有一个Redis的分支，其运行速度可以快5倍，延迟降低近5倍，您会怎么想？如果您不再需要哨兵节点，并且您的副本可以同时接受读写操作呢？这有可能将您的分片数量减少10倍。

如今，ARM处理器正成为一种经济高效的计算方式，提供了极佳的性价比……现在它们已经进入了云端！这就引出了一个问题：您当前的设置是否仍然是为客户提供服务的最经济的方式？

主动复制消除了在高可用性设置中需要“监控哨兵节点”来决定何时执行故障转移的需要。这也使您的活动副本节点能够在与其他活动副本节点主动同步的同时接受读写操作。

我们与许多希望在AWS上优化成本的用户进行了交谈。虽然大多数用户已经尝试过许多可用的基于x86的实例类型，但我们惊讶地发现，很少有人尝试过基于Arm的Amazon EC2 A1实例。这些基于Arm的实例为多线程缓存服务器工作负载带来了独特的性能优势。要理解为什么缓存数据库，特别是KeyDB，特别适合Arm，我们首先需要对硬件有一点了解。

许多网站为实现服务器的高可用性而运行副本节点。这很有道理，但是这个副本是否被充分利用了？或者您只是为了高可用性而付费，却没有获得相当于将资源加倍所带来的性能提升？本文讨论了与Redis一起使用的选项，以及在与Redis兼容的数据库KeyDB中使用的“主动复制”选项。