Anna 使用了一个核心对应一个线程的无共享线程架构，通过避免线程间的协调来实现闪电般的速度。Anna还使用晶格组合来实现多样的无协调一致性级别。第一个版本的Anna吊打现有的内存KV存储系统：它的性能优于Masstree 700倍，优于TBB 800倍。

阅读完整的论文（）。

我们将第一个Anna版本称为“Anna v0”。在这篇文章中，我们介绍如何将这个最快的KV存储系统变得极具成本效益和适应性。

现如今，公共基础设施云用户可选择的存储系统真是太多了。AWS提供两种对象存储服务（S3和Glacier）和两种文件系统服务（ EBS和EFS），另外还有七种不同的数据库服务，从关系数据库到NoSQL键值存储。真是花样繁多，令人眼花缭乱，用户自然会问，哪个服务才适合他们。最直接（然而并不乐观）的答案是，把它们全都用起来就对了。

这些存储服务都提供了非常有限的成本与性能之间的权衡。例如，AWS ElastiCache速度很快，但很贵，而AWS Glacier虽然便宜，但速度较慢。因此，用户门面对一个窘境：他们必须要么放弃节约成本的目标，大规模部署高性能存储集群，要么放弃性能，利用低成本的系统例如DynamoDB或者S3。

更糟糕的是，大多数实际应用展现出偏斜的数据访问模式。频繁被访问的数据是“热”数据，其他则为“冷”数据，而这些服务要么是专门为“热数据”而设计，要么专门为“冷数据”而设计。因此，不想在性能或成本上妥协的用户必须手动将这些解决方案拼凑在一起，跟踪服务间的数据和请求，以及管理不同的API，并做出一致性保证。

更糟糕的是，高性能的云存储产品不具备弹性：向集群添加资源或从集群中移除资源都需要人工干预。这意味着云开发者们设计并实现自定义解决方案来监控工作负载变化、修改资源分配以及在存储引擎之间移动数据。

这是非常糟糕的。应用程序开发人员不断被迫重新发明轮子，而不是把精力放在他们最关心的指标上：性能和成本。我们想要改变这种现状。

Anna v1

我们借助Anna v0这个内存存储引擎来解决上述的云存储问题。我们的目标是将最快的Anna同时发展成为最具适应性和成本效益的KV存储系统。我们向Anna中添加了3个关键的机制：垂直分层、水平弹性和选择性复制。

Anna v1的核心组件是监控系统和策略引擎，可实现工作负载的响应性和适应性。为了满足用户定义的性能目标（ 请求延迟）和成本，监控服务对工作负载变化进行监控和调整。存储服务器会收集请求和数据的统计信息。监视系统定期搜索和处理这些数据，策略引擎基于这些统计信息执行上述的三个操作。操作的触发规则很简单：

• 弹性：为了让系统适应变化的工作负载，系统需要能够根据工作量自动扩展和收缩。当一个层达到计算或存储容量最大值时添加节点，当某个节点明显得不到未充分利用时将其移除。
• 选择性复制：在实际工作环境下，访问量很大的key需要被广泛的复制到多个节点和CPU核从而提高性能。Anna v0启用了key的多主复制，但在复制所有key时提供了一个固定的复制因子。正如读者们想象的，这是一个成本很大的设计。在Anna v1中，监控服务仅选择性的复制访问次数高的“热”key而不复制“冷”key，从而减小存储成本。
• 升级和降级：与传统的内存层次结构中一样，热数据应该保存在更快的存储介质中提高访问效率，冷数据应该保存在较慢的存储介质中节约成本。我们的监测服务会根据数据的热度变化自动将它们移至合适的存储介质。

为了实现这些机制，我们不得不对Anna的设计做出两个重大变更。首先，我们让存储引擎支持多种存储介质——目前是内存和闪存。与传统的存储层次结构类似，这些存储层的成本与性能权衡是不一样的。我们还实现了一个路由服务，它将用户请求发送到目标层的服务器上。无论数据存储在什么地方，都可以为用户提供统一的API。这些层都从第一版Anna继承了同等丰富的一致性模型，因此开发者可以灵活挑选并自定义合适的一致性模型。

我们的实验表明，无论是在性能还是成本效益方面，Anna都达到了令人印象深刻的水平。在同一成本下，Anna提供优于AWS ElastiCache8倍的吞吐量和优于DynamoDB 355倍的吞吐量。Anna还能够通过添加节点和恰到好处的数据复制来应对工作负载的变化：

这篇文章只提供了Anna的设计概述，如果你有兴趣了解更多，

论文: 

源码: 

查看英文原文：