WebSphere_eXtreme_Scale_初探.doc

简介 　　什么是 IBM WebSphereeXtreme Scale？它如何工作？我们将采用两步分析法回答这个问题。首先，您可以在 Information Center 找到以下说明： 　　WebSphereeXtreme Scale 以内存网格的方式运行，动态处理、分区、复制和管理成千上万服务器上的应用程序数据和业务逻辑。它提供事务完整性和透明的故障恢复功能确保高可用性、高可靠性和一致的响应时间。WebSphereeXtreme Scale 是 IBM 中一个必需的分布式缓存平台，以实现弹性的可扩展性和下一代云环境。 　　弹性意味着网格可以监控和管理自己，支持扩大和缩小，可以自动从故障恢复。扩大功能可以在网格运行时添加内存，无需重启。相反，缩小功能可以在运行时删除内存容量。 　　您明白了吗？如果还没有，请查看示例了解这个划时代的产品。 　　WebSphereeXtreme Scale 的目标非常简单，就是极大地提高应用程序性能。顾名思义，它的主要目标之一是极大地扩大应用程序可以支持的用户数量。这种扩大可以用更少的时间服务更多的用户，或者在合理的、可预测的响应时间内为更多用户提供服务。 图 1. 什么是WebSphereeXtreme Scale 例如，组织可以使用WebSphereeXtreme Scale 将关键数据的访问时间从 60 ms（毫秒）减少到 6 ms —— 每秒 450,000 并发用户和 80,000 个请求。从概念到生产的实现和保存需要 6 周，可以减少以前由于数据库达到最大性能带来的限制。WebSphereeXtreme Scale 技术让它们能够处理 10 倍的负载，每秒钟扩展到一百万次请求，支持五百万以上的并发用户 但WebSphereeXtreme Scale 是如何做到这些的？本文剩下的部分将深入回答这个问题，首先从WebSphereeXtreme Scale 的几个基本原理开始。 　　极限可扩展性的原理 　　WebSphereeXtreme Scale 理念包括以下基本原理： 　　将数据放入内存 　　分区数据以支持线性水平扩展 　　缓存 　　接下来的几节详细描述这些原理。 　　将数据放入内存 　　数据通常存储在磁盘（可能位于磁盘的数据库中）。为了处理该数据，它必须放入计算机的内存供程序处理（图 2）。与访问已经在计算机内存中的数据相比，这种输入/输出 (I/O) 操作非常耗时。 　　例如，它需要 20 ms（或者说 0.02 秒，或 20 x 103秒）才能从磁盘中读入数据块。而访问已经位于内存中的数据只需要几十纳秒（或者说 109秒）。可见，访问内存中的数据要快一百万（或者说 106）倍。 　　图 2. 内存层次结构 　　32 位与 64 位 JVM 　　32 和 64 表示底层硬件地址空间的位数： 　　大部分机器都有 32 位硬件，这表示地址空间最大可以是 232字节。 　　大部分机器都有 64 位硬件，这表示地址空间最大可以是 264字节。 　　如果 32 位 JVM 中 2 GB 不够，可以使用提供 4 Exa Bytes（或者说 4x1018字节）的 64 位 JVM 吗？JVM 内存是虚拟的。64 位 JVM 受到所运行服务器物理内存的限制。当机器的物理内存都被占用时，您必须以低磁盘速度从磁盘获取数据。机器物理内存的大小决定了您的性能，因此将所有数据放入 64 位 JVM 将创建一个服务器瓶颈，破坏了您尝试实现的水平扩大原则（见下一节）。 在Java? 垃圾收集 (GC) 时间上也存在一些限制；一般的经验是在一个 64 位 JVM 中数据保持在 5-6 GB 以下，否则 GC 可能会占用掉大量处理能力。最好使用更小的 32 位 JVM 进行扩大和分散负载，减少对 64 位 JVM 的使用。最近的研究验证了这个选择，它表明 64 位 JVM 存储相同的对象数量时使用的实际内存比 32 位 JVM 多 50%。 　　WebSphereeXtreme Scale 也支持 64 位 JVM，您应该在合适的地方使用它们，但是必须谨慎使用以防损失。64 位 JVM 可能带来一定的额外开销，即使避免了 GC 的占用也是如此。（如果对 GC 感兴趣，可以研究WebSphere Real Time）。 　　如果大部分数据位于磁盘，您应该如何扩展应用程序使其不用等待从较慢的磁盘中获取数据？答案是将尽可能多的数据放入内存，以减少这些高成本的 I/O 操作。更快的数据访问可以让应用程序运行的更快，因此能获得更好的用户响应时间，更好的应用程序吞吐量，更强大的支持更多用户的能力。 　　听起来很简单。为什么大家不都这样做呢？ 　　有两个原因： 　　通常，重要的数据必须具有持久性，比如银行账户记录。计算机内存