分布式缓存概述

转自：http://blog.csdn.net/dinglang_2009/article/details/8302258

本文将从理论的角度去介绍，让大家从宏观上对“分布式缓存、nosql”等技术有所了解，以便进一步学习和使用。在构建大规模的web应用时，缓存技术可以说是必备的，学习的必要性不言而喻。

分布式缓存概述

1.1 分布式缓存的特性

分布式缓存具有如下特性:

1) 高性能:当传统数据库面临大规模数据访问时,磁盘I/O 往往成为性能瓶颈,从而导致过高的响应延迟.分布式缓存将高速内存作为数据对象的存储介质,数据以key/value 形式存储,理想情况下可以获得DRAM 级的读写性能;

2) 动态扩展性:支持弹性扩展,通过动态增加或减少节点应对变化的数据访问负载,提供可预测的性能与扩展性;同时,最大限度地提高资源利用率;

3) 高可用性:可用性包含数据可用性与服务可用性两方面.基于冗余机制实现高可用性,无单点失效(single point of failure),支持故障的自动发现,透明地实施故障切换,不会因服务器故障而导致缓存服务中断或数据丢失.动态扩展时自动均衡数据分区,同时保障缓存服务持续可用;

4) 易用性:提供单一的数据与管理视图;API 接口简单,且与拓扑结构无关;动态扩展或失效恢复时无需人工配置;自动选取备份节点;多数缓存系统提供了图形化的管理控制台,便于统一维护;

5) 分布式代码执行(distributed code execution):将任务代码转移到各数据节点并行执行,客户端聚合返回结果,从而有效避免了缓存数据的移动与传输.最新的Java 数据网格规范JSR-347中加入了分布式代码执行与Map/reduce 的API 支持,各主流分布式缓存产品,如IBM WebSphere eXtreme Scale,VMware GemFire,GigaSpaces XAP 和Red Hat Infinispan 等也都支持这一新的编程模型.

1.2 典型应用场景

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

1) 页面缓存.用来缓存Web 页面的内容片段,包括HTML、CSS 和图片等,多应用于社交网站等;

2) 应用对象缓存.缓存系统作为ORM 框架的二级缓存对外提供服务,目的是减轻数据库的负载压力,加速应用访问;

3) 状态缓存.缓存包括Session 会话状态及应用横向扩展时的状态数据等,这类数据一般是难以恢复的,对可用性要求较高,多应用于高可用集群;

4) 并行处理.通常涉及大量中间计算结果需要共享;

5) 事件处理.分布式缓存提供了针对事件流的连续查询(continuous query)处理技术,满足实时性需求;

6) 极限事务处理.分布式缓存为事务型应用提供高吞吐率、低延时的解决方案,支持高并发事务请求处理,多应用于铁路、金融服务和电信等领域.

1.3 分布式缓存的发展

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

1) 本地缓存:数据存储在应用代码所在内存空间.优点是可以提供快速的数据访问;缺点是数据无法分布式共享,无容错处理.典型的,如Cache4j;

2) 分布式缓存系统:数据在固定数目的集群节点间分布存储.优点是缓存容量可扩展(静态扩展);缺点是扩展过程中需要大量配置,无容错机制.典型的,如Memcached;

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

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

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

随着云计算与 Web 2.0 的进一步发展,许多企业或组织时常会面对空前的需求:百万级的并发用户访问、每秒数以千计的并发事务处理、灵活的弹性与可伸缩性、低延时及7×24×365 可用性等.传统事务型应用面临极限规模的并发事务处理,出现了极限事务处理型应用,典型的有铁路售票系统.Wikipedia 认为,极限事务处理是每秒多于500 事务或高于10 000 次并发访问的事务处理.Gartner 将极限事务处理(extreme transactionprocessing,简称XTP)定义为一种为事务型应用的开发、部署、管理和维护供支持的应用模式,特点是对性能、可扩展性、可用性、可管理性等方面的极限需求.Gartner 在其报告中预测指出,极限事务处理型应用的规模将由2005 年的10%提升至2010 年的20%,极限事务处理技术是未来5 年~10 年的热点技术.极限事务处理的引入,无疑给传统Web 三层架构带来了新的挑战.即,如何在廉价的、标准化的硬件和软件平台之上,对大容量、业务关键型的事务处理应用提供良好的支撑.分布式缓存作为一种关键的XTP 技术,可为事务型应用提供高吞吐率、低延时的技术解决方案.其延迟写(write-behind)机制可提供更短的响应时间,同时极大地降低数据库的事务处理负载,分阶段事件驱动架构(staged event-driven architecture)可以支持大规模、高并发的事务处理请求.此外,分布式缓存在内存中管理事务并提供数据的一致性保障,采用数据复制技术实现高可用性,具有较优的扩展性与性能组合.

“集群和负载均衡”等的通俗解释

在“高并发，海量数据，分布式，NoSql，云计算......”概念满天飞的年代，相信不少朋友都听说过甚至常与人提起“集群，负载均衡”等，但不是所有人都有机会真正接触到这些技术，也不是所有人都真正理解了这些“听起来很牛的”技术名词。下面简单解释一下吧。
集群(Cluster)

　　所谓集群是指一组独立的计算机系统构成的一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。应用程序可以通过网络共享内存进行消息传送，实现分布式计算机。通俗一点来说，就是让若干台计算机联合起来工作(服务），可以是并行的，也可以是做备份。

　　负载均衡(Load Balance)

网络的负载均衡是一种动态均衡技术，常见的实现方式是通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。日常生活中到处都能看到“负载均衡”，一个超市的收营员高峰期只能服务10位顾客，当做活动时有20位顾客需要服务的话可能就会排长队，这样购物体验将会很差（就像客户抱怨系统/网站访问太慢）。最简单的办法就是再招个营业员，重新开通一个出口。负载均衡的核心就是“分摊压力”。

　　大规模集群，通常具备以下一些特点：
　　(1) 高可靠性 (HA)。
利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。
　　(2) 高性能计算 (HP)。
即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域，比如基因分析、化学分析等。
　　(3) 负载平衡 (LB)。
即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。

当然，以上的这些特点，在某些适应场合下是需要同时具备的。常用的集群又分以下几种：
　 　load balance cluster （负载均衡集群）
　　一共有四兄弟开裁缝铺，生意特别多，一个人做不下来，老是延误工期，于是四个兄弟商量：老大接订单, 三个兄弟来干活。 客户多起来之后，老大根据一定的原则(policy) 根据三兄弟手上的工作量来分派新任务.
　　 High availability cluster（高可用集群）
　　两兄弟开早餐铺，生意不大，但是每天早上7点到9点之间客户很多并且不能中断。为了保证2个小时内这个早餐铺能够保证持续提供服务，两兄弟商量几个方法:
　　方法一：平时老大做生意，老二这个时间段在家等候，一旦老大无法做生意了，老二就出来顶上，这个叫做 Active/Standby.（ 双机热备 ）
方法二：平时老大做生意，老二这个时候就在旁边帮工，一旦老大无法做生意，老二就马上顶上，这个叫做Active/Passive.（ 双机双工 ）
　　方法三：平时老大卖包子，老二也在旁边卖豆浆，老大有问题，老二就又卖包子，又卖豆浆，老二不行了，老大就又卖包子，又卖豆浆.这个叫做Active/Active (dual Active)（ 双机互备 ）
　　包子= application package, 互相照应叫做heartbeat, 顶替对方工作叫做 failover/takeover. 如果两个兄弟突然都瞎了聋了，不知道现在对方到底是否正在干活，都认为自己要顶对方的工作，这个叫做brain-split, 然后需要第三者，比如他们的老爹来解决问题，这个叫做tier-breaker, 或者让他们两个的媳妇过来拉走其中一个，这个叫做fency.
　　 high computing clustering （高性能计算集群）
　　10个兄弟一起做手工家具生意，一个客户来找他们的老爹要求做一套非常复杂的仿古家具，一个人做也可以做，不过要做很久很久，为了1个星期就交出这一套家具，10个兄弟决定一起做。
　　老爹把这套家具的不同部分分开交给儿子们作，然后每个儿子都在做木制家具的加工，最后拼在一起叫货.
　　老爹是scheduler任务调度器，儿子们是compute node. 他们做的工作叫做作业。

（其实，还有一种，分布式 存储 相关的集群，应用于超大规模网站，云计算平台等等。涉及点存储方面的，这里就不介绍了）

严格来讲，这些已经超过了一般开发人员的知识范畴了，想真正理解和掌握这些并不太容易，有时候需要真正的实践而不是闭门造车。从运维人员和系统架构师的角度来看，不仅需要具备丰富的操作系统配置和管理的经验，更要具备网络协议、存储等相关的知识（懂算法和底层的就更完美了）。从开发人员和软件架构师的角度来看，需要考虑的重点又不同了。当然，远远不止我所提到的这些。现在的Web应用一般都比较依赖于基础架构，而越来越脱离了”纯软件架构“的本质。集群不是万能的，但有时候确实相当有用。由于项目和工作关系，我本人目前主要使用的是微软的技术体系（当然，目前大都是基于windows平台的）。有机会的话，我可以将自己在这方面的研究和实践分享出来，更希望有兴趣的朋友在一块分享和交流。