主要功能

这个章节罗列了主要功能特性和关键功能点。

高吞吐读写

通过并行内存架构和高度优化的分布式基础架构提供读写吞吐。为了获得高吞吐读写，应用可以创建数据的动态副本，通过针对读的高吞吐进行同步和异步复制，或者通过在许多系统成员上分区数据。如果数据的访问在整个数据集合上基本平衡的话，数据分区可以加倍总吞吐。吞吐的线性增加只会被网络带宽所限制。

可预计的低延时

优化的缓存层把在进程之间和线程之间的上下文切换减少到了最小程度。通过在一个高分布的架构中最小化数据争抢的方式，管理数据。如果接收端可以跟上的话，对等成员之间的通信是同步的，这样会保证数据分发的延迟始终最小。为了减少GC（garbage collector）的压力，服务器以序列化的格式管理对象图。

为了保证一个订阅针对所有订阅的客户端只分发一次，订阅管理 (注册兴趣interest registration 和持续查询continuous queries) 在整个服务器的数据存储中分区管理。这样的机制改进了CPU的利用率和带宽的利用率，从而增加了吞吐，也减少了客户端订阅的延迟。

高延展性

通过在很多成员上的数据动态分区和将数据负载均匀地传播到服务器上，获得了延展性。针对“热”数据，你可以通过配置让数据创建更多的副本以获得动态展开。你也可以以分布式方式运行一个应用的操作，让它靠近所需要的数据。

如果你需要支持高且不可预测的客户端并发，你可以增加管理数据的服务器数量，同时在更多的服务器之间分发数据和相关的操作，来获得低且可预测的响应时间。基于各个服务器的负载情况，客户端的负载会被持续的均衡到服务器上。通过在服务器间的数据分区或者复制，客户端连接可以动态的移动到不同的服务器上，保证服务器获得据云的负载，客户端获得最好的响应时间。

你也可以通过应用异步的“后写”（write behind）把数据改变写到外部数据存储（例如数据库）上，获得更高的延展性。这可以避免把所有更新按照顺序和冗余的方式放入队列的瓶颈。你也可以压缩更新事件，或者通过批量的方式把他们存入数据库。

持续可靠性

除了在内存中保证一致的数据副本，应用可以通过“shared nothing 磁盘架构”，以同步或者异步的方式，在一个或多个成员上进行数据的持久化。所有的异步事件（存储转发事件）都会至少在两个成员上进行冗余副本管理，这样如果一个服务器宕机，则另一个服务器会进行接管。所有的客户端连接到逻辑服务器上，如果服务器宕机或者服务器不响应，客户端连接则会自动连接到其他服务器上。

可靠的事件通知

发布/订阅系统提供了一个数据分发服务，以稳定的方式，新的事件可以发布给系统，然后传输给所有感兴趣的订阅者。传统的信息平台关注于消息分发，但是经常导致接收应用需要在处理事件之前去访问相关数据。这要求接收应用在接受到一个事件的时候去访问一个标准的数据库，这样就会导致订阅会被数据库的速度限制。

数据和事件通过同一个系统被访问。数据以对象的方式保存在一个或多个分布式数据Region中， Region类似于数据库中的表。应用可以简单的插入，更新，删除数据Region中的对象，而由平台向订阅者来传播数据变化的事件。订阅者接收事件的同时，就可以直接访问在本机内存中关联的数据，或者通过单跳（single hop）直接从其他的一个成员上取得数据。

基于数据存储的并行应用操作

你可以在成员上并行的执行应用的业务逻辑。这样的数据依赖function执行服务允许直接执行，在各个成员上的数据依赖应用Function可以根据各个节点上的数据分区情况和延展情况来执行。

通过共协（Colocating）关联数据和并行化计算，可以提高总体吞吐量。计算的延迟与加入计算的节点数量成反比。

这样的基础设定保证了对于应用来说Function是透明的，可以直接贴近需要参与计算的数据子集，避免了在网络上把数据的来回移动。应用Function可以只在一个成员上执行，也可以在一部分成员上执行，甚至也可以在所有的成员上执行。这个变成模型类似于大家比较熟悉的Map-Reduce模型。数据依赖Function比较适合需要应用逻辑遍历很多条数据的情况（类似于查询或者自定义的聚合功能）。

Shared-Nothing的磁盘持久化

每个分布式系统成员，在自己的磁盘上，独立的管理数据。在一个成员上的磁盘或者缓存的错误，不会影响另一个缓存实例在其磁盘文件上安全运行的能力。这样的"shared nothing"持久性体系结构，允许配置应用程序，使得不同类别的数据在整个系统上的不同成员上持久化，即使为应用程序对象配置了磁盘持久化，也会大大增加了应用程序的总体吞吐量。

不像传统的数据系统，分隔文件不用于管理数据和事务日志。类似于在传统数据库中事务日志，所有数据的更新都附加到文件后端。如果磁盘不被其他进程同时使用，则可以避免磁盘寻道时间，并且唯一的成本是磁盘旋转延迟。

减少拥有成本

可以配置缓存层。客户端应用进程可以部署一个本地缓存（在内存中且溢出到磁盘上），在miss的情况下去查询服务器端缓存集群。即使本地缓存只有30%的命中率，也会显著的节约成本。总体成本与每个事务对CPU计算周期的占用，网络占用，数据库的访问，甚至是不容易计算的数据库运维成本有关。通过按照业务对象的方式管理数据，可以避免类似于把SQL记录转换成对象这样不必要的成本（占用CPU计算周期）。

Client/Server间的单跳(Single-Hop)机制

客户端可以发送单独的数据请求，直接连到具有这个数据Key的服务器上，这样就避免了为了定位分区数据而在成员间进行多次跳跃。在客户端的元数据（Metadata）可以找到正确的服务器。这个功能改进了客户端访问在服务器层partitioned regions的性能。

Client/Server 安全

客户端应用可能会由多个不同用户。这个功能可以支持这样的安装方式，即在客户端嵌入到应用服务器中，每一个应用服务器支持大量用户的数据请求。每个用户都被授权只能访问服务器上全部数据的一个子集，类似于在一个客户系统中每个客户都只能访问子集的订单和送货信息。在客户端的每一个用户通过子集的认证信息连接到服务器，通过这个认证信息获得授权来访问服务器端缓存。

多站点数据分发

通过广域网搭建，基于地理分布数据站点会导致延展性问题。模型解决了这些拓扑，支持包括从简单的对等（peer-to-peer）集群，到在广域网上多个数据中心之间的可靠通信。这个模型允许分布式系统在一个非绑定松耦合的方式延展，而不会有性能，可靠性和数据一致性方面的损失。

这个架构的核心是用于分发Region事件到远方站点的网关发送器（Gateway Sender）。可以并行部署网关发送器（Gateway Sender）实例，这样会提高在广域网上分发Region事件的吞吐量。也可以配置网关发送器（Gateway Sender）的持久化和高可用，以避免因为一个成员的错误导致的数据丢失。

持续查询

在一个类似JMS（Java Message Service）的消息系统中，客户端订阅主题（topics）和队列（queues）。任何消息会通过主题分发给订阅者。通过使用OQL（Object Query Language）可以进行比较复杂的兴趣注册， Geode支持持续查询.

跨编程语言数据共享

不需要一个类似SOAP 或 XML的数据转化层， C#, C++ 和 Java 应用就可以分享应用业务对象。通过JAVA实现的服务器端操作，提供了一个针对 C++ 和 .NET应用的唯一的本机缓存。应用程序对象可以在C ++进程堆中进行管理，并使用对象的通用“在线”表示分发给其他进程。一个C++序列化的对象可以直接被反序列化成一个对等的Java或者C#对象。在一个编程语言中的一个业务对象上的变化，可以向其他支持的编程语言编写的应用激发一个可靠的通知。

Apache Geode主要功能