但是， 扩展这样的任务关键型系统是一项严峻挑战。万事达卡既需要大量数据，也需要快速响应。如果您无法牺牲数量换取性能(反之亦然)，势必会遇到增长方面的问题。

万事达卡最终利用Apache Geode的基于内存的技术实现了数量与性能的平衡。此外，万事达卡的工程师使用设计模式来扩展数据密集型应用的数据量和交易吞吐量，同时不会增加延迟。

针对TB级数据设计Geode

像DMP这样有广度的决策平台需要TB级的共享数据。由于系统必须处理数百个时间感知型的聚合或计算变量，情况变得更加复杂。这些附加数据用于运行风险模型和数百个决策规则。 据万事达卡估计，他们拥有超过300亿项时间感知型聚合！

在处理这种大规模数据方面，Zolotov和Low提到了很多注意事项和最佳实践。

垂直和水平缩放的节点

万事达卡试验了这两种方法，发现它们都非常有效。垂直缩放(每个节点的堆大小较大)与无中断JVM配合进行垃圾收集，效果很好。水平缩放的优势在于与并行性相关的性能优化。

通过共置实现数据访问可扩展性

万事达卡会尽可能对相关数据进行共置。例如，与客户帐户相关的所有数据都位于同一个节点上。这样一来，针对某客户数据的请求只需发送到一个节点。这一简单的设计方案将读取性能提高到了每秒800万次读取。另一个好处是，万事达卡可以在不增加网络呼叫数量的前提下横向扩展网络。

均衡的数据分布

用于数据分区的键(含义与键-值存储中的“键”相同)应该产生均匀的分布。为什么呢？很简单：因为不均衡的工作负载会阻碍可扩展性。Andrey安排了足够的时间努力确定正确的数据分布方法，即采用均衡分区的方式，将工作负载均衡地分布到集群中的节点上。

使用字节数组存储

使用字节数组存储可以降低Java对象图的复杂性。而这恰好也是Geode的默认存储模型。事实证明，Geode是一个了不起的高效字节数组管理器！字节数组可以更轻松地扩展，因为Java堆更易于处理。简单的字节数组还可以加快垃圾回收工作负载。

运用这些概念，万事达卡能够将其Geode集群提升到40TB，并实现可持续的性能。他们又是如何解决延迟问题的呢？请继续阅读。

大规模优化Geode性能

万事达卡的目标是将平均交易延迟保持在50毫秒内。这个基准为他们提供了一些余地，以应对意外出现的减速。他们希望在吞吐量为每秒60,000笔交易的情况下达到这个延迟目标。 要达到这样的性能水平，需要亚毫秒级读取速度，也就是每秒数百万次读取。

万事达卡充分利用了Geode的内置性能优化来实现这一目标。随着DMP处理的可用数据的增加，对数据的请求数量也会相应增加。客户对数据的请求通常涉及通过网络传递的大量数据，这是不受欢迎的性能瓶颈。另外，以很高的每秒交易数(TPS)反序列化许多条目会占用大量CPU周期。

那么万事达卡是如何应对的呢?Andrey和Gideon再次介绍了四个相关领域：

聚合

DMP针对每笔交易使用数以百亿计的实时更新和使用的聚合。是的，这会增加数据量。但在性能上获得了丰硕的回报！

将代码移至数据

“实施上下文感知的功能让客户端和服务器节点之间的网络流量减少了95%，而且Geode服务器上的延迟减少了50%，CPU使用率减少了40%。Delta传播使对等网络流量又减少了50%...”

- Andrey Zolotov，万事达卡软件工程师

基于内存的争用管理(contension management)

万事达卡在DMP中更新数据的速度引发了有关争用和一致性的问题。当多笔交易尝试同时更新同一数据时，就会发生争用。在这种情况下，交易将自动序列化并完成。一致性与同时更新所有副本或相关数据有关，同时更新是为了让所有应用和用户都能看到数据的最新值。

万事达卡面临的挑战是，在处理快速、原子化的增量更新的同时，管理争用并保持数据一致性。当然，Geode可以存储复杂的对象，但对象属性的更新也可以作为增量更新处理。这样一来，就不会影响(即锁定)对未更新的其他属性的访问。

此外，每笔交易都会涉及数百次读取和写入。高效的争用管理可让Geode以每秒成千上万次的速度，以原子化方式将小的更改应用到大的条目。

性能和可扩展性至关重要时，企业选择了Geode

当然，在实际应用中，可以对上述介绍的方法稍加改动。Andrey和Gideon在SpringOne Platform大会的分组会议期间详细探讨了这些话题(以及其他话题)。

希望了解更多？请观看有关Geode性能基准的Geode Summit会议。

关于作者

Jagdish Mirani

Pivotal 企业软件部门主管

Jagdish Mirani是企业软件部门的主管，在产品管理和产品营销方面拥有丰富的经验。目前他负责Pivotal数据服务(Cloud Cache、MySQL、Redis、PostgreSQL)的产品营销。加入Pivotal之前，Jagdish在Oracle的数据仓库和商业智能部门工作了10年。