浅谈分布式缓存那些事儿

在前面的一些文章中，我们从实战角度讲解了 Memcached 的应用、容灾、监控等内容，但缺乏对理论层面的讲解和原理性的剖析。本文将从理论角度出发，介绍分布式缓存与 NoSQL 等技术，帮助大家从宏观上建立认知，以便进一步学习和使用。在构建大规模 Web 应用时，缓存技术可谓是必备组件，其学习必要性不言而喻。

1.1 分布式缓存的特性

分布式缓存主要具备以下特性：

高性能：当传统数据库面临大规模数据访问时，磁盘 I/O 往往成为性能瓶颈，从而导致过高的响应延迟。分布式缓存将高速内存作为数据对象的存储介质，数据以 Key/Value 形式存储，理想情况下可以获得 DRAM 级的读写性能。
动态扩展性：支持弹性扩展，通过动态增加或减少节点应对变化的数据访问负载，提供可预测的性能与扩展性；同时，最大限度地提高资源利用率。
高可用性：可用性包含数据可用性与服务可用性两方面。基于冗余机制实现高可用性，无单点失效（Single Point of Failure），支持故障的自动发现，透明地实施故障切换，不会因服务器故障而导致缓存服务中断或数据丢失。动态扩展时自动均衡数据分区，同时保障缓存服务持续可用。
易用性：提供单一的数据与管理视图；API 接口简单，且与拓扑结构无关；动态扩展或失效恢复时无需人工配置；自动选取备份节点；多数缓存系统提供了图形化的管理控制台，便于统一维护。
分布式代码执行（Distributed Code Execution）：将任务代码转移到各数据节点并行执行，客户端聚合返回结果，从而有效避免了缓存数据的移动与传输。最新的 Java 数据网格规范 JSR-347 中加入了分布式代码执行与 Map/Reduce 的 API 支持，各主流分布式缓存产品，如 IBM WebSphere eXtreme Scale、VMware GemFire、GigaSpaces XAP 和 Red Hat Infinispan 等也都支持这一新的编程模型。

1.2 典型应用场景

分布式缓存的典型应用场景可分为以下几类：

页面缓存：用来缓存 Web 页面的内容片段，包括 HTML、CSS 和图片等，多应用于社交网站等。
应用对象缓存：缓存系统作为 ORM 框架的二级缓存对外提供服务，目的是减轻数据库的负载压力，加速应用访问。
状态缓存：缓存包括 Session 会话状态及应用横向扩展时的状态数据等。这类数据一般是难以恢复的，对可用性要求较高，多应用于高可用集群。
并行处理：通常涉及大量中间计算结果需要共享。
事件处理：分布式缓存提供了针对事件流的连续查询（Continuous Query）处理技术，满足实时性需求。
极限事务处理：分布式缓存为事务型应用提供高吞吐率、低延时的解决方案，支持高并发事务请求处理，多应用于铁路、金融服务和电信等领域。

1.3 分布式缓存的发展

分布式缓存经历了多个发展阶段，由最初的本地缓存到弹性缓存平台直至弹性应用平台，目标是朝着构建更好的分布式系统方向发展（如下图所示）。

本地缓存：数据存储在应用代码所在内存空间。优点是可以提供快速的数据访问；缺点是数据无法分布式共享，无容错处理。典型的，如 Cache4j。
分布式缓存系统：数据在固定数目的集群节点间分布存储。优点是缓存容量可扩展（静态扩展）；缺点是扩展过程中需要大量配置，无容错机制。典型的，如 Memcached。

弹性缓存平台：数据在集群节点间分布存储，基于冗余机制实现高可用性。优点是可动态扩展，具有容错能力；缺点是复制备份会对系统性能造成一定影响。典型的，如 Windows Appfabric Caching。

弹性应用平台：弹性应用平台代表了云环境下分布式缓存系统未来的发展方向。简单地讲，弹性应用平台是弹性缓存与代码执行的组合体，将业务逻辑代码转移到数据所在节点执行，可以极大地降低数据传输开销，提升系统性能。典型的，如 GigaSpaces XAP。

1.4 分布式缓存与 NoSQL

NoSQL 又称为 Not Only SQL，主要是指非关系型、分布式、支持水平扩展的数据库设计模式。NoSQL 放弃了传统关系型数据库严格的事务一致性和范式约束，采用弱一致性模型。相对于 NoSQL 系统，传统数据库难以满足云环境下应用数据的存储需求，具体体现在以下 3 个方面：

根据 CAP 理论，一致性（Consistency）、可用性（Availability）和分区容错（Partition Tolerance）这 3 个要素最多同时满足两个，不可能三者兼顾。对云平台中部署的大量 Web 应用而言，数据可用性与分区容错的优先级通常更高，所以一般会选择适当放松一致性约束。传统数据库的事务一致性需求制约了其横向伸缩与高可用技术的实现。
传统数据库难以适应新的数据存储访问模式。Web 2.0 站点以及云平台中存在大量半结构化数据，如用户 Session 数据、时间敏感的事务型数据、计算密集型任务数据等，这些状态数据更适合以 Key/Value 形式存储，不需要 RDBMS 提供的复杂的查询与管理功能。
NoSQL 提供低延时的读写速度，支持水平扩展，这些特性对拥有海量数据访问请求的云平台而言是至关重要的。传统关系型数据库无法提供同样的性能，而内存数据库容量有限且不具备扩展能力。分布式缓存作为 NoSQL 的一种重要实现形式，可为云平台提供高可用的状态存储与可伸缩的应用加速服务，与其他 NoSQL 系统间并无清晰的界限。平台中应用访问与系统故障均具有不可预知性，为了更好地应对这些挑战，应用软件在架构时通常采用无状态设计，大量状态信息不再由组件、容器或平台来管理，而是直接交付给后端的分布式缓存服务或 NoSQL 系统。

1.5 分布式缓存与极限事务处理

随着云计算与 Web 2.0 的进一步发展，许多企业或组织时常会面对空前的需求：百万级的并发用户访问、每秒数以千计的并发事务处理、灵活的弹性与可伸缩性、低延时及 7×24×365 可用性等。传统事务型应用面临极限规模的并发事务处理，出现了极限事务处理型应用，典型的有铁路售票系统。

Wikipedia 认为，极限事务处理是每秒多于 500 事务或高于 10,000 次并发访问的事务处理。Gartner 将 极限事务处理（Extreme Transaction Processing，简称 XTP）定义为一种为事务型应用的开发、部署、管理和维护提供支持的应用模式，特点是对性能、可扩展性、可用性、可管理性等方面的极限需求。Gartner 在其报告中预测指出，极限事务处理型应用的规模将由 2005 年的 10% 提升至 2010 年的 20%，极限事务处理技术是未来 5 年~10 年的热点技术。

极限事务处理的引入，无疑给传统 Web 三层架构带来了新的挑战，即如何在廉价的、标准化的硬件和软件平台之上，对大容量、业务关键型的事务处理应用提供良好的支撑。分布式缓存作为一种关键的 XTP 技术，可为事务型应用提供高吞吐率、低延时的技术解决方案。其延迟写（Write-Behind）机制可提供更短的响应时间，同时极大地降低数据库的事务处理负载；分阶段事件驱动架构（Staged Event-Driven Architecture）可以支持大规模、高并发的事务处理请求。此外，分布式缓存在内存中管理事务并提供数据的一致性保障，采用数据复制技术实现高可用性，具有较优的扩展性与性能组合。