NDB 引擎支持完整的内存缓存协议命令集。当新安装的服务器以默认服务器角色和配置模式启动时，您应该能够运行memcapable，一个内存缓存服务器验证工具，并看到所有测试通过。然而，在配置被定制后——例如，通过禁用 FLUSH_ALL 命令——一些 memcapable测试预计会失败。

GET、SET、ADD、REPLACE 和 DELETE 操作。  这些操作中的每一个始终根据与内存缓存键前缀关联的缓存策略执行。它可以对本地缓存的项目、存储在数据库中的项目或两者进行操作。如果前缀的操作已被禁用，开发人员应确保测试禁用的操作，因为它可能会静默失败，或带有误导性的响应代码。

CAS。  CAS，在 memcache 协议中，指的是一个“比较和设置”值，它被用作缓存值的一种版本号，并启用一些乐观的应用程序行为

如果容器包含CAS列，ndb引擎在每次写入数据值时都会生成一个唯一的CAS ID，并存储在CAS列中。

一些内存缓存操作包括 CAS 检查，例如 ASCII CAS 更新，其语义为“更新此值，但前提是其 CAS id 与请求中的 CAS id 匹配”。NDB 引擎支持这些操作。存储的 CAS ID 与应用程序的 CAS ID 的检查是在 NDB 数据节点上的原子操作中执行的。这允许 CAS 检查即使在多个 memcached 服务器访问相同的键值对时也能正常工作。

如果正在使用 CAS ID 检查，并且使用除 memcached 之外的其他 NDB Cluster API 来操作数据，那么使用这些 API 的应用程序负责在更新数据时使存储的 CAS ID 无效。他们可以通过将存储的 CAS ID 值设置为 0 或 来做到这一点NULL。

CAS ID 是使用一种试图防止不同服务器生成重叠 ID 的方案生成的。该方案可以被认为是尽力而为，但不能保证唯一性。该方案构造一个初始CAS如下：

在 memcached 启动时来自主集群的部分 32 位集群 GCI 用于 64 位 CAS ID 的高位

获取配置时使用的主集群中唯一的集群节点id的一部分用于CAS ID的中间位

CAS ID 低位中的递增计数器至少为 28 位宽。

NDB 引擎生成一个 CAS ID 序列，而默认引擎（用于在本地 memcached 服务器中缓存值）生成一个不同的序列。并非所有 CAS 行为和缓存策略的组合都经过测试，因此任何希望使用 CAS 的应用程序开发人员都应该彻底测试特定配置的行为是否符合预期。

FLUSH_ALL。  FLUSH_ALL 实现如下：首先，NDB 引擎迭代所有配置的键前缀。对于其缓存策略启用数据库刷新 ( flush_from_dbis true) 的任何前缀，它会对该前缀的容器表中的每一行执行扫描删除。其他前缀将被忽略。DELETE如果表很大，这可能是一个缓慢的操作，并且一些内存缓存客户端可能会在操作完成之前超时。在所有数据库删除完成后，该 FLUSH_ALL命令被转发到标准缓存引擎，该引擎设置一个使所有缓存数据无效的标志。

增量和减量。  所有INCR和DECR 操作都被下推到 NDB 数据节点并在那里以原子方式执行。这允许多个 memcached 服务器递增或递减相同的键，并保证每次都有唯一的值。

和操作在二进制内存缓存协议中比在 ASCII 协议中具有更清晰INCR和DECR更有用的语义。建议使用二进制协议。

INCRmemcached ASCII 协议在处理和时 引入了一些歧义DECR，并强制 NDB 引擎在 dup_numbers模式下工作，在这种模式下， value_column和 math_column必须相互镜像。

dup_numbers为满足以下所有条件的键前缀启用模式：

在dup_numbers模式下，以下特殊行为适用：

附加和前置。  内存缓存APPEND和 PREPEND操作作为单个事务实现，其中涉及使用独占锁读取现有值，然后写入新值。读取和写入以原子方式分组到一个事务中，但与INCR和不同DECR，后者可以在数据节点上本地运行， APPEND并PREPEND在 memcached 服务器内部执行。这意味着多个 memcached 服务器可以争用APPEND相同 PREPEND的值，并且不会丢失任何更新，但这种争用依赖于可能导致延迟显着增加的锁定行为。

统计数据。  Memcached 服务器可以提供多组统计信息；从登录 shell 使用 。STATS KEYWORD

通常可以从 memcached 1.6 核心和默认引擎获得所有统计信息。例如， STATS、STATS SLABS和 STATS SETTINGS目前都受支持，如 memcached 文档中所述。使用以下列表中描述 NDB的命令，可以从引擎获得一些特殊的统计数据集：STATS