作者：Srini Srinivasan 是企业级非关系数据库开发商 Aerospike 的首席产品官兼创始人。他在设计、开发和运营大规模基础设施方面有着 20 年的丰富经验，并持有数据库、互联网、移动和分布式系统技术方面的 30 余项专利。
数字经济经常上演这一幕：出现闪电般的连锁反应，将数据转化为洞察力，将机会转化为商业价值。由于数据的速度和数量增加，支持这种增长的常见做法就是增加更多缓存。
但是基于缓存的数据库架构从来不是为满足当今的交互系统在数量和延迟方面的要求而设计的。数据数量一庞大，缓存就变得费用高、不可靠且不稳定。
这就需要一种更好的数据架构，而不是求助于更多的内存或更好的缓存。为了实现即时决策，数字化企业需要一种新的混合内存架构，可以实时处理事务数据和分析数据，以抓住商机。
据 Forrester 研究公司的一份报告「1」称，“混合内存架构是一种新方法，充分利用易失性存储器（DRAM）和非易失性存储器（比如 SSD 和闪存），以提供一致、可信、可靠、低延迟的访问，从而支持新老一代的事务应用、运营应用和分析应用。实施这类架构让企业组织得以从双层内存架构转为单层结构，从而简化数据的移动和存储，无需缓存层。早期采用者已看到它给公司带来的几个好处，比如降低拥有成本、大幅减少服务器占用空间、简化管理以及提高可扩展性。”
这五个迹象表明基于缓存的数据库架构可能已过时，是时候改而采用混合内存架构了：
缓存节点不受控制地增加
随着贵公司不断发展，你的数据和缓存大小也会相应增加。随着交互的价值不断增加，新的应用软件和项目要求访问数据库，增加事务量和缓存工作集大小。服务器数量需要增加，即使年初就编制好了预算。增长超预期时，必须解决这个问题，否则你的交互系统就跟不上步伐。
不断投入资金以应对这种增长不具有可持续性。业务增长意味着数据呈非线性增长，因为要整理或查询每个客户和每个事务的更多信息。加上使用另外的数据源以便更好地分析，你的缓存会迅速增加，从而消耗可用的预算。你可以将缓存数据重新平衡到 SSD，短期内降低成本，但此举会加大管理这些数据的复杂性。
重新填充缓存需要数小时甚至数天
故障是不可避免的事实。你的数据中心或云越庞大，故障的频率越高。对于大多数公司来说，在云和 DevOps 时代配置新的缓存服务器现在只需几分钟。但这不适用于缓存层中的数据。数据必须“还原”到达到命中率可以接受的水平，然后才能获得减轻数据库负载的预期影响。对于大多数数据密集的公司而言，这个过程可能需要数小时甚至数天——迫使它们处理有限的性能、不准确的数据、甚至更严重的过度配置带来的不必要成本以及应用软件复杂性。
不妨看一个实际例子。全球第六大经纪公司在基于缓存的传统关系数据库管理系统（RDBMS）架构上运行其当天交易系统。由于每天交易量庞大，这家经纪公司在缓存和数据库方面都面临挑战。由于担心导致基于缓存的系统过载，它无法每天多次执行准确的风险计算。因此，这家公司在交易期间在做出财务决策（比如保证金贷款等）方面如同两眼抹黑。若使用混合存储系统，可以每隔几分钟重新评估风险指标，帮助做出更合理的业务决策。当客户在一天内多次交易时，遇到了另一个问题：客户的头寸（账户中的股票和资金）必须始终准确。如果备用缓存里面是旧数据，客户因头寸显示不足或没有资金而无法进行另外的交易，会发生什么？客户的头寸最终会准确，但这需要多长时间、面临多大的损失？往好里说，客户在等待屏幕刷新几次时遇到糟糕的体验。往坏里说，经纪公司可能要对错失或不准确的交易承担责任。
你仍无法使用缓存优先的架构符合 SLA
如果你使用面向知名在线支付系统的欺诈检测系统，不符合服务级别协议（SLA）可能意味着每天因错失交易或欺诈交易而损失数百万美元。RDBMS 和第一代 NoSQL 数据库本身都不够快，无法满足亚毫秒级的响应时间，因此你必须在其前面放置缓存。但实际情况却很少这么简单；而且面对增长，这种架构也无法保证符合 SLA。
以全球最大的支付处理公司之一为例。由于支付领域迅速发生变化，该公司需要为 10 倍增长作好规划。扩展架构以满足这种增加的负载意味着，少则从 300 台服务器增加到 3000 台，多则扩展到 10000 台服务器。改用混合内存架构为这家公司带来了显著的成效。服务器数量从 300 台减少到 20 台，消除了缓存层和双数据库集群，节省了数百万美元的运营成本。在峰值负载下，欺诈算法的性能从 175 毫秒提高至不足 80 毫秒。即使欺诈检测没有及时返回，混合系统也继续处理交易。这意味着以前算法未符合 SLA 导致每天数额高达数百万美元（相当于一年超过 10 亿美元）的交易面临欺诈风险。
你的数据足够大，需要集群
贵公司终于开始壮大，你的缓存大小逐渐变成了分布式内存数据库，需要面对分片、集群及其他新技术带来的更大负担。又很难找到拥有这些技能的人员。
你可能已经在应用软件中使用分片技术来创建更多容量，毕竟这是最佳实践。然而，如果公司发展够快，分片可能不再管用，这就需要集群管理。集群机制通常比分片更先进，但带来了一系列新的限制和不足，需要了解清楚。比如说，一些命令在集群环境中可能得不到支持，可能不支持多个数据库，程序员需要知道哪个节点服务于哪个子集的密钥，跨集群的密钥查找可能成问题。
缓存踩踏经常发生
缓存踩踏（cache stampede）是一种级联故障，可能由单单一个节点的随机性故障引发。这可能归咎于依赖糟糕的集群/分片算法，导致其余节点上的负载不均衡。
从用户角度来看，缓存踩踏意味着他们想要查看或购买的商品无法加载，最终超时中断。不耐烦的用户会放弃请求，或者尝试刷新页面，这会加剧问题。无论怎样，结果对你的声誉或收入而言都是灾难性的。
处理缓存踩踏有三种方法：锁定、外部重新计算和概率提前到期。而所有方法都需要在应用软件层面更改代码，然后要“推销”给开发团队，以便它们将更改后的代码集成到原有代码中，以防问题再次出现。到头来，这些方法都没有解决问题。
那么，为什么你的应用软件开发人员当初要承受缓存和数据库管理这个负担呢？这带来了不必要的复杂性，影响质量和上市时间，并使客户体验面临更大的风险。为什么不完全丢弃缓存层，依赖管理所有这些问题的分布式数据库，又不需要更改应用软件？
重新评估外部缓存的需求
上述的服务器增长、架构复杂性、不稳定性和缓存踩踏等问题表明，外部缓存层并不总是最佳的成功策略，对于突发式或繁重、不断加大的数据负载的系统而言更是如此。
外部缓存层作为确保性能和规模的事实架构的时代早已一去不复返。数据的增长以及对响应时间的持续下行压力使得这项技术对许多使用场合而言已过时。是时候质疑最佳实践和公认架构方面的当前思路了。混合内存架构是正在进行数字化转型的企业目前和未来取得成功的关键。
「1」：Forrester 报告：混合内存架构驱动实时交互系统
