内容


WebSphere eXtreme Scale 初探,第 1 部分

了解 WebSphere eXtreme Scale 及其工作原理

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: WebSphere eXtreme Scale 初探,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:WebSphere eXtreme Scale 初探,第 1 部分

敬请期待该系列的后续内容。

简介

什么是 IBM WebSphere eXtreme Scale?它如何工作?我们将采用两步分析法回答这个问题。首先,您可以在 Information Center 找到以下说明:

WebSphere eXtreme Scale 以内存网格的方式运行,动态处理、分区、复制和管理成千上万服务器上的应用程序数据和业务逻辑。它提供事务完整性和透明的故障恢复功能确保高可用性、高可靠性和一致的响应时间。WebSphere eXtreme Scale 是 IBM 中一个必需的分布式缓存平台,以实现弹性的可扩展性和下一代云环境。

弹性意味着网格可以监控和管理自己,支持扩大和缩小,可以自动从故障恢复。扩大功能可以在网格运行时添加内存,无需重启。相反,缩小功能可以在运行时删除内存容量。

您明白了吗?如果还没有,请查看示例了解这个划时代的产品。

WebSphere eXtreme Scale 的目标非常简单,就是极大地提高应用程序性能。顾名思义,它的主要目标之一是极大地扩大应用程序可以支持的用户数量。这种扩大可以用更少的时间服务更多的用户,或者在合理的、可预测的响应时间内为更多用户提供服务。

图 1. 什么是 WebSphere eXtreme Scale?
图 1. 什么是 WebSphere eXtreme Scale?
图 1. 什么是 WebSphere eXtreme Scale?

例如,组织可以使用 WebSphere eXtreme Scale 将关键数据的访问时间从 60 ms(毫秒)减少到 6 ms —— 每秒 450,000 并发用户和 80,000 个请求。从概念到生产的实现和保存需要 6 周,可以减少以前由于数据库达到最大性能带来的限制。WebSphere eXtreme Scale 技术让它们能够处理 10 倍的负载,每秒钟扩展到一百万次请求,支持五百万以上的并发用户。

但 WebSphere eXtreme Scale 是如何做到这些的?本文剩下的部分将深入回答这个问题,首先从 WebSphere eXtreme Scale 的几个基本原理开始。

极限可扩展性的原理

WebSphere eXtreme Scale 理念包括以下基本原理:

接下来的几节详细描述这些原理。

将数据放入内存

数据通常存储在磁盘(可能位于磁盘的数据库中)。为了处理该数据,它必须放入计算机的内存供程序处理(图 2)。与访问已经在计算机内存中的数据相比,这种输入/输出 (I/O) 操作非常耗时。

例如,它需要 20 ms(或者说 0.02 秒,或 20 x 103 秒)才能从磁盘中读入数据块。而访问已经位于内存中的数据只需要几十纳秒(或者说 109 秒)。可见,访问内存中的数据要快一百万(或者说 106)倍。

图 2. 内存层次结构
图 2. 内存层次结构

如果大部分数据位于磁盘,您应该如何扩展应用程序使其不用等待从较慢的磁盘中获取数据?答案是将尽可能多的数据放入内存,以减少这些高成本的 I/O 操作。更快的数据访问可以让应用程序运行的更快,因此能获得更好的用户响应时间,更好的应用程序吞吐量,更强大的支持更多用户的能力。

听起来很简单。为什么大家不都这样做呢?

有两个原因:

  • 通常,重要的数据必须具有持久性,比如银行账户记录。计算机内存有一个问题,当关闭电源后,内存中的数据将丢失。磁盘存储是持久的,因为在断电后数据不会丢失。
  • 计算机内存装不下所有数据!计算机内存和地址空间变得更大;32 位 JVM 表示 2 GB 的可用内存。这样的数据已经很大了,但是您的中间件和应用程序逻辑也必须共享该空间。

可以考虑将数据放入内存的另一个地方是其他机器。从本地磁盘获取数据需要 20-40 ms,但通过高速网络从邻近机器获取数据只需要 2 ms。使用其他机器的内存进行扩展非常合适。除了放入数据之外,机器内存还可以用于操作系统、中间件和应用程序逻辑等。使用远程机器直接存储数据,可以为数据提供更多的内存,使您能获取更快的速度(与磁盘相比)。

使用其他机器对于可用性也很合适。如果在另一台机器上存储数据副本,您可以从第一台机器的失败中恢复。

分区数据以支持线性水平扩展

性能分析和调试的基本方法是发现并减少瓶颈。假设处理器给您 X 吞吐量。如图 3 所示的绿色线性扩展线,每当向解决方案添加一个处理器时,您会多得到 X 的吞吐量。蓝色线显示非线性扩展,每添加一个处理器时多得的吞吐量少于 X 吞吐量。红色的瓶颈线表示资源为最大容量时的情况(本例为数据库),无法再增加大小。随着负载的增加,您的吞吐量保持不变,受限制的资源位于最高水平。

图 3. 性能、扩展和瓶颈
图 3. 性能、扩展和瓶颈
图 3. 性能、扩展和瓶颈

第一个解决该瓶颈的方法是用一个更大、更快的机器运行数据库。这是垂直扩展(vertical scaling)方法;就是让一个瓶颈机器更大、更高。垂直扩展只能帮助您这么多(即带到更高的饱和点),此外获取一流硬件是一个昂贵的解决方案。

如果需要更多的扩展怎么办?

很明显应该使用更多的机器来解决问题。这就是水平扩展(horizontal scale-out)。但是这能够帮助数据库吗?回答是大部分情况下不行。图 4 显示了可行设置中情况:

  • 应用服务器在水平方向上可以很好地扩展,因此可以很好地消除该层的瓶颈。
  • 垂直扩展适用于数据库,但是不足以将数据库作为瓶颈移除,以实现想要的扩展。
图 4. 传统三层应用程序中的扩展选项
图 4. 传统三层应用程序中的扩展选项
图 4. 传统三层应用程序中的扩展选项

第二个原则是分区数据:使用两台机器,每台机器放一半数据,将数据请求路由到包含数据的机器。如果在两台机器上以这种方式分区数据,那么每台机器可以承担一半的负载,因此您的性能和一台机器的吞吐量就翻了一倍。

并非所有的数据和应用程序都是可以分区的。有些可以很好地扩展,有些则无法扩展。

分区的好处是可以很好地扩展。如果使用两台机器分摊负载很好,那么使用 10、100 甚至 1,000 台机器怎么样呢?这就是 WebSphere eXtreme Scale 提供的功能,这就是它提供的可扩展性。

分区支持线性扩展(图 3 中的绿线)。请求可以有效地路由到寄存所需数据的机器。没有分区,将当前数据放到可以处理的正确位置需要许多开销,这种开销是随着机器的增加呈指数(不是线性)增长的。有了分区,您添加的每台机器都可以有效地处理自己的一部分,任何机器都不会产生额外的开销。随着机器的增多,所有机器都相等地共享整个处理负载。您可以根据需要添加任意数量的机器来处理工作负载。

在上例中,关键数据是用户配置文件,可以跨一组机器分布(分区)以进行并行处理。要将响应时间加快 10 倍,可以使用 10 个服务器。WebSphere eXtreme Scale 可以扩展到成千上万台机器,这意味着该解决方案可以扩展 100 到 1,000 倍,支持 50 到 500 百万用户,只需要 6 ms 的响应时间。内存中的数据和分区可以将响应时间从 60 ms 减少到 6 ms,分区功能本身就能让支持的用户增加 100 到 1,000 倍,响应时间同样为 6 ms。这就是所谓的线性扩展。

缓存

WebSphere eXtreme Scale 的关键功能是提供大型、可扩展、弹性的缓存。

缓存是用来保存数据的内存块。第一个查询项的位置就是缓存。如果存在数据,您就得到一次缓存命中(cache hit),并以内存速度获取项(几十纳秒)。如果缓存中没有数据,那么就是缓存未命中(cache miss),必须从磁盘中以磁盘速度(几十毫秒)获取项。从磁盘中获取项之后,将其放入缓存然后返回。基本的缓存用法在图 5 中的缓存演示。正如 后文 所讨论的,应用程序可以与 side cache 和磁盘对话。

图 5. 缓存
图 5. 缓存

缓存的有效性与命中率成正比关系,命中率是缓存中的项能满足请求的比例。如果所有数据都在缓存中,那么只需从磁盘读取一次数据;毕竟,所有的请求都可以用内存速度从缓存中得到满足。

使用缓存有两个主要好处:

  • 第一个好处是处理缓存中的数据请求。处理速度将大大提升,因为数据是以内存速度交付的。任何缓存命中都意味着不再需要从磁盘中获取数据的读取操作。因此,减少了磁盘上的负载。
  • 减少了磁盘负载是缓存的另一个好处。磁盘现在支持对其他数据的更多请求。在上例中,关键数据访问时间从 60 ms 减少到 6 ms 是该缓存带来的直接好处,同时还减少了后端数据库的负载。

命中率与缓存大小、底层数据的数量和数据访问模式有关。如果应用程序的访问模式是持续的顺序读取所有缓存的数据,那么缓存将无法提供太多帮助,除非所有数据都位于缓存中。当缓存填满之后,在应用程序再次访问前数据将被删除。在这种情况下,缓存不但没有帮助,反而会更糟;因为它将数据放入缓存需要更多的开销,与没有缓存的情况相比,这种应用程序的性能更加糟糕。

在许多情况下,缓存与需要使用数据的处理位于同一个地址空间。这种做法提高了速度但是限制了缓存的大小。WebSphere eXtreme Scale 可以使用其他 JVM 用于缓存。这些 JVM 可以专门用作缓存 JVM,以便 JVM 的大部分内存可以用于应用程序数据——不与中间件、基础结构、应用程序代码或内存共享。

这些 JVM 可以位于同一个机器上。本地 JVM 提供对内存的快速访问,但是物理内存和 CPU 周期最终都必须共享机器上的操作系统、其他应用程序以及 JVM。因此,为了获得更大的缓存、平衡和并行访问负载,您应该在远程机器上使用 JVM 以访问更多的物理内存。物理内存是加快访问的关键。远程 JVM 提供更大的缓存,更具可扩展性。

缓存中的数据更改时会发生什么?

写入时如果有缓存会让事情变得更加复杂。确定缓存什么数据的重要因素是写入读取率。当数据没有变化(即没有写入,因而写入读取率为零)或者不经常变化(例如,如果缓存用户配置文件,它们将不会经常更改,因而写入读取率很低),缓存的效果最好。提到写入时,最好考虑内联缓存(in-line cache)(图 6)。我们将在 下文 介绍,应用程序仅与缓存对话,缓存则与磁盘对话。

图 6. 内联缓存
图 6. 内联缓存

有两个主要的写入用例:

  • 使用缓存更改数据的过程。
  • 不使用缓存更改数据的过程。

在第一个用例中,有两种选择:

  • write-through cache 模式下,在返回到写入流程并继续之前,数据将写入到缓存然后再写到磁盘。在这种情况下,写入以磁盘速度进行,这很糟糕。好消息是磁盘上的数据与缓存中的数据保持一致,这是好的方面。
  • write-behind cache 模式下,当数据位于缓存中时,请求将返回,并且处理继续进行。在这种情况下,写入过程以内存速度而不是磁盘速度进行,这是好的方面。但是磁盘上的数据暂时会过时,这是坏的方面。如果新的缓存副本没有在关机或缓存失败前写入磁盘,更新将丢失,这非常糟糕。但是,WebSphere eXtreme Scale 可以在其他机器上保存更多的缓存副本,以提供可靠的 write-behind cache。因此,write-behind 缓存在访问所有写入数据以及所有缓存命中读取时都能提供内存速度,而且还有一些其他好处,我们将在下文介绍。

如果另一个过程没有通过缓存而更改了底层数据,那么会出现问题。如果您无法让所有的过程都使用缓存,那么您将得到过时数据(暂时)。许多用户使用数据库的影子副本(图 4)支持基于操作数据的大型专用查询。这些影子副本很快就会过时,但这是可以理解和接受的。

解决缓存过时问题有两种方法:

  • 让所有缓存项过时。例如,在用户定义的间隔(如 10 分钟)过后,每个项都自动从缓存中删除。这将强迫缓存从磁盘重新加载数据,因此缓存数据的过时不会超过 10 分钟。
  • 检测底层数据的更改,然后从缓存删除更改的数据(使其根据需要重新加载),或者将更新的数据重新加载到缓存。

WebSphere eXtreme Scale 支持这两种方法。

图 7 展示了缓存如何满足 图 4 中所描述的整个画面。

图 7. 介绍缓存如何应对可扩展性挑战
图 7. 介绍缓存如何应对可扩展性挑战
图 7. 介绍缓存如何应对可扩展性挑战

实现详情

WebSphere eXtreme Scale 是非侵入式中间件。它打包为一个 15 MB 的 JAR 文件,不依赖 WebSphere Application Server Network Deployment,并且可以当前和较旧版本的 WebSphere Application Server Network Deployment、WebSphere Application Server Community Edition,以及一些非 IBM 应用服务器一起使用,比如 JBoss 和 WebLogic。WebSphere eXtreme Scale 还支持 J2SE™ Sun™、IBM JVM 和 Spring。由于这种独立性,一个缓冲或缓存网格可以扩展多个 WebSphere Application Server 单元格(如果必要)。

尽管 WebSphere eXtreme Scale 是自含的,它需要外部框架来安装应用程序和启动/停止 JVM 寄存这些应用程序 —— 除非您希望通过命令行完成这些,如 WebSphere Application Server (也支持 WebLogic 和 JBoss 框架)。WebSphere eXtreme Scale 可以由 IBM Tivoli® Monitoring 以及 Hyperic HQ 和 Wily Introscope 管理和监控。

WebSphere eXtreme Scale 使用 TCP 进行通信,没有多播或 UDP。不需要特殊的网络技术(共享子网)或类似的先决条件。缓存副本可以使用地理上远程的节点。

分区

WebSphere eXtreme Scale 使用分区的概念扩展缓存。数据(Java 对象)存储在缓存中。每个数据都有一个独特的键。数据基于其键放入缓存及从中检索。

考虑这个简单(可能有点怪)的在文件柜中存储邮件的示例:键是名称,姓氏的首字母。可以想象一个带有两个抽屉的文件柜,一个标签为 A-L,另一个标签为 M-Z。每个抽屉都是一个分区。您可以添加一个文件柜来扩展邮件缓存。您将抽屉重新标记为 A-F、G-L、M-R、S-Z,然后必须重新整理邮件,将其放入合适的抽屉。您可以将邮件缓存的大小扩大一倍,可以继续扩展。

邮件缓存有一个问题,人名的分布是不均匀的。与 Q、X、Y 抽屉相比,您的 M、R 和 S 抽屉可能很快就填满了。这将在内存和处理上导致缓存负载的不均匀。

分区的工作方式是对键计算散列码。散列码是一个整数,应该对每个键返回唯一的数字。(例如,如果键是整数,该值应该作为散列码。在 Java 中,String 散列码方法将字符串视为 base-31 数字,以此计算其散列码)。在 WebSphere eXtreme Scale 中,您首先确定缓存分区的数字。要将项放入缓存,WebSphere eXtreme Scale 计算键的散列码,除以分区的编号,余数标识存储项的分区。例如,如果您有 3 个分区,键的散列码为 7,7 除以 3 得 2 余 1,所以项应该位于分区 1。分区数量是从 0 开始的。散列码应该在键空间上提供均匀的值分布,以便分区负载平衡。(WebSphere eXtreme Scale 自动为键计算散列码。如果需要可以提供自己的散列码)。

线性扩展的键是在分区上均匀分布的数据。这使您能选择足够多的分区数量,以便每个服务器节点都能稳定地处理每个分区上的负载。

WebSphere eXtreme Scale 如何扩展其缓存?

在上例中邮件缓存,抽屉为分区,您使用具有两个抽屉的文件柜。每个抽屉和文件柜的大小都是固定的。如果将这种类比应用到 WebSphere eXtreme Scale,您可以将文件柜看做在 JVM 中运行的容器服务器。这意味着文件柜可以保存最多 2 GB 的项(如果使用 64 位 JVM 则更大)。在 WebSphere eXtreme Scale 中,文件柜(容器服务器)可以保存许多抽屉(分区)。分区可以保存最多 2 GB 的项(假设是 32 位而不是 64 位 JVM)。(如果您的对象在每个存储器中使用 n 字节,那么每个分区最多可以包含 2 GB/n 个项)。

在 WebSphere eXtreme Scale 中,分区的数量在包含项数量之前设置。假设您使用许多分区,例如 101。这意味着您的邮件缓存可以存储仅 202 GB(101 个分区 * 每个分区 2 GB)的项。容器服务区可以在多个远程机器上分布,有些可以共享同一个机器。在具有一个容器服务器的简单示例中(对应于一个文件柜的情况),所有 101 个分区将位于一个容器服务器中,因此您只能保存 2 GB 的项。若要扩展,您只需要启动另一个容器服务器,最好在另一个机器上,以分担负载。

有了另一个可用的容器服务器,WebSphere eXtreme Scale 将自动在两个容器服务器之间平衡邮件缓存负载,101 个分区中有一半将移动到第二个容器服务器上。如果在第三台机器上添加第三个容器服务器,负载将会重新平衡 —— 从第一个容器服务器移动 17 个分区,从第二个容器服务器移动 16 个分区,一起放到新的容器服务器。新的服务器将有 33 个分区,前两个服务器各 34 个分区。

通过这种方式,WebSphere eXtreme Scale 提供线性扩展。在 101 个分区和一个容器服务器的情况下,最多能包含 2 GB 的项。在 101 个分区,101 个容器服务器的情况下,您以供可以保存 202 GB 的项。这些容器服务器应该分布在多台机器上。基本思想是,负载平均分布在分区上,WebSphere eXtreme Scale 在可用的机器上平均分布分区。因此,您可以获得线性扩展。如果同时运行 WebSphere Application Server,WebSphere eXtreme Scale 将随着容量和负载的变化,自动在不同的机器上启动和停止容器服务器。因此,您可以获得动态(自动管理)、弹性的缓存。

复制

扩展很好,但要是机器失败和服务器失败时怎么办?

WebSphere eXtreme Scale 在失败时提供可用性,因为它允许数据复制。缓存分区存储在一个或多个碎片中。第一个碎片称为主碎片(primary shard)。定义 WebSphere eXtreme Scale 缓存时,您通过指定复制碎片(replica shard)缓存指定复制水平。复制碎片是主碎片中所有数据的备份副本,它们的主要目的是从主碎片失败中恢复,提供高可用性。在某些情况下,它们可以用来满足读取请求卸载主碎片。

分区和碎片之间的不同一开始可能很容易混淆:

  • 分区是一个逻辑概念。它表示缓存数据的 1/nth,其中缓存被分为 n 个部分或分区。
  • 碎片是一个实际的物理内存块,它存储分区的内容。

为了确保容错和高可用性,WebSphere eXtreme Scale 碎片分布算法确保主碎片和复制碎片绝不会位于同一个容器中。当主碎片失败时,复制碎片将提升为主碎片,同时在另一个容器中创建一个新的复制碎片。

复制可以是同步或异步的;将数据写入 WebSphere eXtreme Scale 缓存时区别很重要。事务用于所有的 WebSphere eXtreme Scale 缓存读取和写入。在所有同步复制碎片确定新数据的接收之后,写入事务才算完成。异步复制碎片在事务完成之后更新,因此它们提供更快的事务性能(至少 6 倍),但是增加了失败时丢失数据的风险。

根据应用程序的性能和可用性需求选择同步和移除复制的数量。例如,您可以在同一个数据中心的另一台机器上选择同步复制,而在另一个数据中心的机器上选择异步复制。在 WebSphere eXtreme Scale 中,使用区域定义数据中心的概念,WebSphere eXtreme Scale 自动处理这一点。通过选择同步和异步复制的数量及其区域放置,您可以在失败时平衡性能、可用性和弹性。

让我们重新看看带有 A-L 和 M-Z 邮件抽屉的文件柜示例。这一次,假设您定义一个复制碎片。图 8 展示了一个示例,尽管只有 3 个分区。最初,在一个容器中有 101 个主碎片,没有任何复制碎片。(复制碎片位于一个容器中是没有意义的)。添加第二个容器时,将 50 个主碎片移动到第二个容器。另外 51 个复制碎片也移动到第二个容器以便平衡,对于每个碎片,它的主碎片和复制碎片都位于不同的容器中。添加第三个容器时也是一样。因此,每个机器有 33 或 34 个主碎片,以及 33 或 34 个不同的复制碎片。

图 8. 展示碎片位置的分区示例
图 8. 展示碎片位置的分区示例
图 8. 展示碎片位置的分区示例

现在,如果有一个容器失败或关闭,WebSphere eXtreme Scale 将重新配置您的缓存,以便每个服务器都有 50 或 51 主碎片和复制碎片,对于每个碎片,它的主碎片和复制碎片都位于不同的容器中。在这种服务器失败/关机场景中,失败的服务器有 33 或 34 个主碎片,以及 33 或 34 个复制碎片。对于主碎片,存活的复制碎片将提升为主碎片,并在另一个服务器上创建新的复制碎片 —— 从新提升的主碎片复制数据。对于失败的复制碎片,必须创建新的复制碎片 —— 从主碎片复制数据并将其放在主碎片之外的机器上。对于这些,WebSphere eXtreme Scale 都是自动完成的,同时保证服务器上数据和负载的平衡。这需要的时间自然很少,但是在该过程中使用了原碎片,因此没有宕机。

API

应用程序代码使用什么 API 访问数据?

这有许多选择。例如,数据通常存储在数据库中。JDBC (Java Database Connectivity) 是确定的选择,JPA (Java Persistence API) 是新标准。JPA 是 Java 对象的持久性规范,可用于任何关系数据存储库,常用的数据库,比如 IBM DB2®。许多用户都用自己的数据访问层,使用自己的 API 编写业务逻辑。这种访问层可以使用 JDBC 或 JPA 获取数据。这些底层数据调用整合到数据访问层中,对于业务逻辑是不可见的。

在 side cache 中,有两种 API 正在使用:从磁盘获取数据的接口,以及从缓存获取数据的接口。因此,如上文所述,您通常需要更改应用程序代码才能使用 side cache。对于读取请求,首先查看缓存。如果数据未命中,将从磁盘获取数据,并将其放入缓存。分区必须使用磁盘接口或缓存接口表现这种逻辑。如果使用数据访问层,代码将整合到其中,对于使用的应用程序是不可见的。

内联缓存看起来好一些,您只有一个接口:到缓存的接口。但是,通常应用程序最开始使用的是到磁盘的接口,必须转换为内联的缓存接口。同样,如果使用数据访问层,代码将整合到其中,对于使用的应用程序是不可见的。

WebSphere eXtreme Scale 提供三种 API 访问保存的数据:

  • ObjectMap API 是一个较低级的、高性能的 API。它很像常规的 Java (Hash) Map,使用简单的创建、读取、更新和删除操作。
  • EntityManager API 是一个较高级的、易于使用的接口。它类似于 JPA 接口。如果您的代码使用 JPA 接口,使用 EntityManager API 将让转换变得更加容易。
  • REST 数据服务 使 HTTP 和 Microsoft .NET 客户端能够使用 ADO.NET Data Services Protocol 访问 WebSphere eXtreme Scale 数据网格。

从 API 角度看,有三种使用 WebSphere eXtreme Scale 的一般方法:

  • 不需要任何代码更改,只需要配置更改。在这种情况下,WebSphere eXtreme Scale 为现有基础设施提供插件,应用程序将使用 WebSphere eXtreme Scale 的这些插件扩展基础设施的缓存功能。WebSphere eXtreme Scale 用作 side cache。以下以用例 A、B 和 C 为示例。
  • 使用 WebSphere eXtreme Scale 作为 side cache 减缓压力。在这种情况下,您需要在一些关键区域插入一小部分代码,并使用 ObjectMap API 缓存数据。下文的用例 D 是示例。
  • 将应用程序的数据接口更改为 WebSphere eXtreme Scale 将带来大量扩展改进,它将变成记录系统。在这种情况下,WebSphere eXtreme Scale 是一个内联缓存。如果目前使用 JPA,您可能使用 WebSphere eXtreme Scale EntityManager API 让转换更加轻松。用例 E 描述这种方法。

side cache 利用内存数据(data-in-memory)和缓存原则,内联缓存也支持利用分区/水平扩展原则。

WebSphere eXtreme Scale 提供 Data Grid API 作为有效利用分区的另一种方法。它的思想是,将处理带到数据,而不是将数据带给处理器。业务逻辑可以完全并行运行,或者仅仅是数据分区的一个子集。并行处理的结果可以整合到一个位置。处理通过网格分配存储器和检索数据加载,该数据的处理还可以通过网格分区服务器分配,它本身也能分区,以提供更加线性的扩展。

其他实现元素

到目前为止,本文重点介绍了缓存,根据键存储 Java 对象的容器。在 WebSphere eXtreme Scale 术语中,缓存被看做映射(map)。在引用 WebSphere eXtreme Scale 时还存在一些其他条款和术语:

  • mapSet 保存映射集合,共享所有通用分区算法。分区数量和复制在 mapSet 中设置。
  • 网格(grid)保存一个或多个 mapSet 组成的集合。
  • 容器(container)保存一个或多个网格组成的集合。
  • (容器)服务器[(container) server] 保存和管理一个或多个容器组成的集合。
  • JVMJava 进程(process)可以包含零个或一个服务器。

用例示例

成功的关键在于确定应用程序中的弱点和瓶颈,然后使用 WebSphere eXtreme scale 按照内存数据、缓存和水平扩展(分区)的原则缓解或消除它们。以下是一些用作演示的用例。

A. WebSphere Application Server 动态缓存服务增强

WebSphere Application Server 动态缓存服务(常常称为 DynaCache)是一个使用 side cache 提高性能的绝佳示例。DynaCache 是一项 WebSphere Application Server 功能,第一次出现在 IBM 为 1998 年奥运会托管网站时。为了给全世界的观众提供最大的可扩展性,它采取网页数据生成后在内存中缓存的方法;这就是熟悉的内存数据模式。缓存不仅保存磁盘 I/O,而且减少了将 HTML 页面放到一起的时间。

使用大型动态缓存要注意几件事情。有些缓存可以增加到 2 GB,甚至 30 或 40 GB。这超出了虚拟内存的处理容量;因此许多数据位于磁盘中,访问磁盘的开销很大。此外,这些缓存位于每台机器上。动态缓存也是应用程序地址空间的一部分。。

WebSphere eXtreme Scale 提供易于访问的插件,使用分布式动态内存网格替换动态 (side) 缓存的 in-process-memory 和磁盘系统。您无需编码即可指定 XML 文件中的配置参数。好处包括:

  • 从应用程序地址空间中移除缓存,并放入 WebSphere eXtreme Scale 容器的地址空间。
  • 缓存可以轻松扩展到 40 GB,可在多台机器上分布,因此整个缓存可以位于内存中,只需要很少的访问时间。
  • 所有应用程序以及需要缓存的 WebSphere Application Server 实例可以共享(单个)缓存。

WebSphere eXtreme Scale 是一个大赢家,并且易于使用。更多详细信息,请参见 Replacing Dynacache Disk Offload with Dynacache using IBM WebSphere eXtreme Scale

B. Hibernate 和 OpenJPA 的二级缓存

WebSphere eXtreme Scale 包括二级 (L2) 缓存插件,可以用于 OpenJPA 和 Hibernate JPA 提供商。Hibernate 和 OpenJPA 都在 WebSphere Application Server 中得到支持。JPA 使您能配置一个 side cache(如图 5 所示)来改进性能。这也是一个进程内缓存,因此大小有限。

由于磁盘很慢,它从二级缓存中获取数据的速度快于磁盘。正如您所见,WebSphere eXtreme Scale 可以提供很大的缓存。大量分布的 WebSphere eXtreme Scale 缓存可以供多个 OpenJPA 或 Hibernate 使用的处理实例共享。JPA 缓存有一个很好的特性,即使用时不需要任何代码更改;仅需在 persistence.xml 文件中修改一些配置属性(比如缓存的大小和对象类型)。更多详细信息,请参见 Using eXtreme Scale with JPA

C. HTTP 会话复制

HTTP 会话数据很适合用于 WebSphere eXtreme Scale。该数据本质上是短暂的,没有在磁盘上保存的持久性要求。根据内存数据原则,您可以通过将数据从磁盘移动到内存极大地提高性能。该数据一开始保存在磁盘上(或者数据库中),以提供失败事件时的可用性 —— 如果第一个服务器失败,则允许另一个 web 服务器访问会话数据。

WebSphere eXtreme Scale 在失败时提供故障恢复和可用性,它的执行和扩展比磁盘解决方案要好得多,因此它是这种数据的理想解决方案。WebSphere eXtreme Scale 对于该应用程序非常容易使用。不需要对应用程序进行任何代码更改。只需要在 web 应用程序 .war 文件的 META-INF 目录下放一个 XML 文件用来配置,使 WebSphere eXtreme Scale 成为 HTTP 会话数据的存储库(内联缓存的记录系统。在失败发生时,对会话数据的访问将更快,因为它位于内存中,数据本身也高度可用。更多详细信息,请参见 Scalable and robust HTTP session management with WebSphere eXtreme Scale

D. SOA ESB 缓存中介

220 万在线用户的零售银行将客户配置文件存储在 System z® 主机的 CICS Enterprise Information System (EIS) 上。有些应用程序访问这些配置文件。主机是一个大型计算机,配置文件存储在该计算机的数据库中。每个应用程序使用 SOA 服务通过 Enterprise Service Bus (ESB) 获取配置文件数据。在 WebSphere eXtreme Scale 之前,每个应用程序都有字节的配置文件缓存,但是这些缓存位于每个应用程序的地址空间中,没有共享。缓存减少了从主机 EIS 获取配置文件的负载,但是更大的共享缓存能够减少更多的负载。

在此,使用 WebSphere eXtreme Scale 作为网络附加的 side cache,保存近 8 GB 的配置文件(4 GB + 4 GB 用于高可用性的副本)。在 ESB 中插入一个中介用于记录配置文件获取服务调用。服务名称和参数用作键,值是配置文件本身。如果配置文件不在缓存中,中介将从主机获取它并将结果存储到缓存。移除 30 分钟以上的旧项,以防止过时并限制缓存的大小。不需要任何应用程序代码更改,插入的中介对于 ESB 是透明的。

在 WebSphere eXtreme Scale 之前,登录需要 700 ms,两次后端调用。使用 WebSphere eXtreme Scale 时,带配置文件缓存访问的登录只需要 20 ms,速度提高了 35 倍。此外,EIS 的负载也降低了,因为可以从缓存得到满足,它对配置文件的获取调用减少了。这种负载降低每个月可以节省很多成本。

SOA ESB 是一个有效添加缓存成本的好位置。它可以轻松使用服务创新点,以及服务中介,它使用可以轻松插入的一致缓存,无需修改上游(客户端)和下游(源服务器)应用程序。

E. 客户配置文件服务

回到本文描述的第一个示例,其中数据库被放大,用户需要支持 10 倍于当前的负载。实际用户的峰值率为每秒 8K 页面查看。应用程序使用 SQL 数据库查询和更新配置文件。每个应用程序页面每 60 ms 从数据库执行 10 次配置文件查询,峰值每秒共 80K 次请求。每个用户配置文件为 10 KB,当前用户注册人数为 1000 万人,即 100 GB 的配置文件数据。如果数据库损坏或者全局出现大范围的网络访问问题,那么应用程序将宕机。在内存中保存数据能解决这些问题。

应用程序现在不再写入数据库,而是写入 WebSphere eXtreme Scale 内联缓存作为系统记录;插入 WebSphere eXtreme Scale 作为数据库的前端。WebSphere eXtreme Scale 缓存配置为写入后缓存。在 HTTP 会话复制情况下,您将看到 WebSphere eXtreme Scale 被用作性能的备份存储器。在这种情况下,数据是暂时的。在这里,您需要将数据保存回数据库以便长期存储。正如您看到的那样,WebSphere eXtreme Scale 进行复制以保证可用性和事务支持。这些功能使您能将 WebSphere eXtreme Scale 缓存放在数据库前面以提高性能。

正如上文讨论的一样,使用写入后缓存,事务在数据写入缓存时完成,这样速度更快。之后数据将写入数据库。这意味着写入后缓存必须可靠地在缓存中保存数据,直到写入磁盘位置。WebSphere eXtreme Scale 通过复制提供了这种可靠性。您可以配置写入延迟,包括写入数量或写入时间。如果后端数据库失败,或者您的网络连接失败或较慢,您的应用程序可以继续运行,这种失败对于应用程序是透明的,不会产生任何影响。WebSphere eXtreme Scale 缓存所有更改,当数据库恢复时,将更改应用到数据库备份复制(如果在线)。

这种写入后延迟写入有几个好处,不仅仅是增加了用户对写入的响应时间。后端数据库本身也会降低许多负载并且更加高效:

使用写入后模式的 WebSphere eXtreme Scale 分布式、网络附加的缓存安装到 SQL 数据的前端。缓存的服务器容器部署 10 个 8 核的 x86 机器,服务用户配置文件和接受更改。同步复制通过良好的可用性实现最高的性能。每个机器每秒执行 8K 的请求,在 6 ms 的响应时间内提供 80K 请求的总吞吐量,是以前的 10 倍。

该解决方案需要每秒扩展到 100 万次请求,响应时间仍然为 6 ms。WebSphere eXtreme Scale 可以使用线性扩展实现这一点,它可以增加约 120 个服务器。每个服务器每秒执行约 110 MB(每秒 8k 请求,10 KB 记录大小)的总通信量(请求 90 MB,复制 20 MB)。每台服务器需要多个 GB 以太网卡。有了小型服务器的处理能力以及 WebSphere eXtreme Scale 的性能,现在每台服务器只需要多个网卡。使用 300 个 32 位的 1 GB 堆 JVM。

结束语

WebSphere eXtreme Scale 以内存网格的方式运行,动态处理、分区、复制和管理成千上万服务器上的应用程序数据和业务逻辑。它提供事务完整性和透明的故障恢复功能确保高可用性、高可靠性和一致的响应时间。WebSphere eXtreme Scale 是 IBM 中一个必要的分布式缓存平台,用于实现弹性的可扩展性和下一代云环境。

弹性意味着网格可以监控和管理自己,支持扩大和缩小,可以自动从故障中恢复。扩大功能可以在网格运行时添加内存,并且无需重启。相反,缩小功能可以在运行时删除内存容量。

再次读到这些文字时,我们希望您现在能够真正理解它们的含义!WebSphere eXtreme Scale 实现这些应用程序的扩展性,以支持大量用户和事务。对于较小的应用程序也很有用,它能提高吞吐量和响应时间。

有了这些知识,您现在可以开始利用 WebSphere eXtreme Scale 的功能帮助您解决当前虚拟应用程序中的互操作性问题。WebSphere eXtreme Scale 有许多好处,包括自动增长管理、持续的可用性、现有数据库的优化使用、更快的响应时间、线性扩展和利用商业硬件的能力。WebSphere eXtreme Scale 带来的业务结果包括通过更加有效的资源利用和扩展性实现更快地响应客户、更低的总拥有成本 (TCO),以及更高的投资回报率 (ROI)。

致谢

我要感谢 Veronique Moses、Art Jolin、Richard Szulewski 和 Lan Vuong 评审了本文并做出贡献。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=468937
ArticleTitle=WebSphere eXtreme Scale 初探,第 1 部分: 了解 WebSphere eXtreme Scale 及其工作原理
publish-date=02252010