vCPU 弹性云服务器的处理器运用超线程HT（Hyper-Threading）技术，允许在CPU的每个物理内核上公开两个执行上下文，即一个物理内核包含两个虚拟的“逻辑内核”，可以处理不同的软件线程。vCPU（virtual CPU）即为虚拟的“逻辑内核”。 规格名称展示vCPU数，即逻辑内核数。在弹性云服务器上可以查看实际的逻辑CPU内核数。 当前绝大多数规格已经默认开启了超线程，如果在创建弹性云服务器或者变更规格时关闭了超线程，则在弹性云服务器上查看到的CPU核数是规格的Flavor名称中展示的vCPU数量的一半。 例如，对于c7.xlarge.2，其vCPU数，即逻辑内核数为4，2核的物理CPU包含4个vCPU（线程）。若关闭了超线程，则在c7.xlarge.2弹性云服务器上查看到的CPU核数是2。 关于超线程的详细介绍，请参见开启/关闭超线程。

独享型实例和共享型实例 表6 独享型实例和共享型实例的区别 维度 独享型实例 共享型实例 CPU分配策略 当前实例独享CPU，实例间无CPU资源争抢。 多实例共享CPU，实例间可能出现CPU资源争抢。 特点 高性能 独享且稳定的计算、存储、网络资源 高成本 高负载时性能不稳定 共享的计算、存储、网络资源 低成本 适用场景 对业务稳定性有高要求的企业场景。 对建设成本有要求的中小网站或个人场景。 实例规格 除“通用计算型”和“通用入门型”之外的实例规格。 x86计算型： 通用计算型 通用入门型

网络QoS 网络QoS，指利用各种基础技术，为指定的网络通信提供更好的服务能力。配置了QoS的网络环境，增加了网络性能的可预知性，并能够有效地分配网络带宽，更加合理地利用网络资源。 可以通过规格清单（x86）查询指定规格的QoS数据，包括最大带宽/基准带宽（Gbps）、内网最大收发包能力（万PPS）、网卡多队列数、网卡个数上限。 弹性云服务器根据不同的规格限制网络能力。 内网基准带宽：指弹性云服务器在整机网络带宽存在争抢时，能稳定达到的保证带宽。 内网最大带宽：指弹性云服务器在整机网络带宽没有争抢（宿主机上其他虚拟机对网络带宽要求不高）时，可以达到的最大带宽。 内网最大收发包能力：指弹性云服务器能达到的最大收发包能力。 单位为PPS（Packets per Second），即每秒收发多少个分组数据包，常用于衡量网络的性能。 网卡多队列数：将弹性云服务器中的网卡中断分散给不同的CPU处理，以满足网卡的需求，从而提升网络PPS和带宽性能。 网卡个数上限：指弹性云服务器最多能挂载多少个网卡。 辅助网卡个数上限：指弹性云服务器最多能挂载多少个辅助网卡。 IPv6：指弹性云服务器是否支持IPv6。 不同区域、不同可用区支持IPv6的规格不同。规格是否支持IPv6，请选择区域、可用区后，以控制台的显示为准。 图3 查询支持IPv6的E CS 规格 网络收发包测试方法，请参见网络性能测试方法。 开启网卡多队列的方法，请参见开启网卡多队列功能。 最大带宽是实例维度的，即实例如果有多张网卡，所有网卡的最大带宽之和不超过实例的最大带宽。 网卡即弹性网卡，是一种虚拟网卡，您可以通过创建并配置弹性网卡，并将其附加到您的云服务器上，实现灵活、高可用的网络方案配置。 详细内容，请参见弹性网卡。 辅助网卡即辅助弹性网卡，是一种基于弹性网卡的衍生资源，用于解决单个云服务器实例挂载的弹性网卡超出上限，不满足用户使用需要的问题。 详细内容，请参见辅助弹性网卡。

规格命名规则 规格的Flavor命名如图1所示，通常包含代系名称、vCPU核数、内存/vCPU比值三部分。 图1 Flavor命名规则 部分Flavor命名还包含附加标识部分，例如，c6h.22xlarge.2.physical中的“physical”即为附加标识。 代系名称 代系名称通常采用四段式命名规则：前缀+主系列+数字+后缀 如表2所示。 表2 四段式命名规则 四段式结构 说明 规则 示例 前缀 根据CPU架构进行分类 以小写英文字母表示 x86：默认无前缀 鲲鹏：前缀为k 主系列 根据典型场景进行分类 以小写英文字母表示 如表3所示 数字 根据规格的代系演进变化 以数字表示，随新硬件及架构更迭而增加 无 后缀 根据规格在同代次实例中增强的能力进行分类 以小写英文字母表示 如表4所示 表3 主系列类型 应用场景 细分场景 主系列 说明 通用场景 通用入门型 t Turbo 通用计算型 s Standard 通用计算增强型 c Compute 高性能计算场景 高性能计算型 h High Performance 大数据场景 磁盘增强型 d Disk 超高I/O型（大容量本地盘） i IOPS 超高I/O型（小容量本地盘） ir IOPS Raid 内存密集场景 内存优化型 m Memory 超大内存型 e Enhanced Memory 计算加速场景 GPU计算加速型 p Parallel GPU图像加速型 g Graphic GPU推理加速型 pi Parallel Inference FPGA加速型 fp FPGA Performance AI推理加速型 ai Ascend Inference 表4 后缀类型 后缀名 示例 说明 ne c3ne Network Enhanced s c6s Standard v p2v NVlink h c6h High performance t c7t Trust vCPU核数 通过small、medium、large、xlarge、Nxlarge表示，如表5所示。 例如，s6.2xlarge.4中的“2xlarge”表示vCPU核数为8（N为2，2 × 4 = 8）。 表5 与vCPU核数对应关系 规格 vCPU核数 small 1 medium 1 large 2 xlarge 4 Nxlarge N × 4，N值越大，vCPU核数越多 内存/vCPU比值 由具体数字表示。 例如，s6.2xlarge.4中的“4”表示内存和vCPU的比值为4，即vCPU核数为8，内存为32GiB。 附加标识 ECS和BMS的标准共池裸金属实例，以“physical” 作为附加标识。 例如，c6h.22xlarge.2.physical中的“physical”表示该规格为标准共池裸金属实例。

x86 CPU架构和鲲鹏CPU架构 弹性云服务器实例主要包含两种架构，x86 CPU架构和鲲鹏CPU架构。 x86 CPU架构 采用复杂指令集CISC（Complex Instruction Set Computer），CISC是一种计算机体系结构，其中每个指令可以执行一些较低阶的硬件操作，指令数目多而且复杂，每条指令的长度并不相同。由于指令执行较为复杂所以每条指令花费的时间较长。 鲲鹏CPU架构 采用精简指令集RISC（Reduced Instruction Set Computer），RISC是一种微处理器，旨在执行较少类型计算机指令，以便能够以更高的速度执行操作，使计算机的结构更加简单、合理地提高运行速度。 鲲鹏CPU架构相对于x86 CPU架构具有更加均衡的性能功耗比。 表1 x86 CPU架构和鲲鹏CPU架构差异对比 维度 x86 CPU架构 鲲鹏CPU架构 优势 生态好，支持几乎所有常用软件。 自研芯片，性价比更高。 适用场景 Windows系列、仅x86兼容的商业软件等强平台相关场景。 电商、大数据、科学计算等弱平台相关场景。 手机仿真等原生场景。

实例概述 实例即弹性云服务器，是由CPU、内存、操作系统、云硬盘组成的基础的计算组件。 弹性云服务器创建成功后，您就可以像使用自己的本地PC或物理服务器一样，在云上使用弹性云服务器，打造一个高效、可靠、安全的计算环境。弹性云服务器的开通是自助完成的，您只需要指定CPU、内存、操作系统、规格、登录鉴权方式即可，同时也可以根据您的需求随时调整您的弹性云服务器规格。 云平台提供了多种实例类型供您选择，不同类型的实例可以提供不同的计算能力和存储能力。同一实例类型下可以根据CPU和内存的配置选择不同的实例规格。 关于实例类型的信息，请参考实例类型 。 了解实例从创建到释放历经的各种状态请参考实例生命周期。 更多实例规格清单请参考规格清单（x86）。 父主题： 实例类型和规格

RESP3协议 在Redis 6.0中，推出了下一代Redis协议-RESP3，相比于RESP2协议，增加了一部分新的数据类型。 Null：空值，替代RESP2中的*-1、$-1 Array：有序集合 Simple string：节省空间的安全字符串（非二进制） Blob string：二进制格式的安全字符串 Simple error：节省空间的安全错误码/错误信息（非二进制） Blob Error：二进制格式的安全错误码/错误信息 Boolean：True/False，布尔类型 Number：有符号的64位整数 Big Number：大数字类型 Double：浮点数 Verbatim string：二进制格式的安全字符串，带文本格式 Map：无序的键值对 Set：无序的不重复元素集合 Attribute：属性键值对，类似于Map PUSH：带外数据，类似于Array，用于Redis服务端主动向客户端推送数据 Hello：hello命令返回的响应类型，用于客户端、服务端建立连接时使用

客户端缓存 Redis 6.0中通过TRACKING模块实现了主动通知客户端刷新缓存的机制，根据协议类型，实现方式如下： RESP3 普通模式 广播模式 RESP2 转发模式 开启客户端缓存通知的格式如下： CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN][OPTOUT] [NOLOOP] 在RESP3协议中，主要是借助了PUSH类型的消息来实现服务端的主动推送通知。在普通模式中，Redis会记住每个客户端请求的key，当该key所对应的value发生变化时，将会发送失效消息（invalidation message）通知对应的客户端集合，但对于每个客户端仅会通知一次，即使后续该key所对应的value有其他操作改动，除非客户端在接收到失效消息后，再次通过读取该key的方式开启通知。开启普通模式的track功能命令如下 : CLIENT TRACKING ON 对于广播模式，则根据所track的key prefix来决定在符合key prefix的key所对应的value有所变化时，通知给所有的客户端，如key prefix所匹配的key数量较多，或改动较多，将会导致服务端发送大量的失效广播消息，消耗网络带宽。开启广播模式的track功能命令如下: CLIENT TRACKING ON BCAST PREFIX key-prefix 如客户端SDK不支持RESP3协议，只能采用RESP2协议的转发模式来实现客户端缓存主动更新通知，需要准备一个专门支持RESP3协议的客户端来作为中转节点，转发来自Redis的失效消息（invalidation message）至特定的订阅频道。工作原理如下: 图1 工作原理

支持SSL Redis 6.0开始支持SSL/TLS方式的加密连接及加密传输，可通过在服务控制台上开启SSL服务，生成实例的SSL/TLS证书及密钥，在使用客户端连接时，指定该证书/密钥即可，连接示例如下： redis-cli --tls --cert /etc/redis/ssl/redis.crt --key /etc/redis/ssl/redis.key --cacert /etc/redis/ssl/redis.crt 详情请参见：SSL设置。

实例架构设计 DCS的Redis单机实例架构，如图1所示。 Redis 3.0和Redis 6.0企业版实例不支持定义端口，端口固定为6379，Redis 4.0及以上版本的基础版实例支持自定义端口，如果不自定义端口，则使用默认端口6379。以下图中以默认端口6379为例，如果已自定义端口，请根据实际情况替换。 不支持Redis版本的升级，例如，不支持Redis 4.0单机升级为Redis 5.0单机实例。如果需要使用高版本Redis单机实例，建议重新创建高版本Redis单机实例，然后将原有Redis实例的数据迁移到高版本实例上。 图1 Redis单机实例示意图 示意图说明： VPC 虚拟私有云。实例的内部所有服务器节点，都运行在相同VPC中。 客户应用 运行在ECS上的客户应用程序，即实例的客户端。 Redis实例兼容开源协议，可直接使用开源客户端进行连接，关于多语言客户端连接示例，请参考用户指南的连接缓存实例。 DCS缓存实例 DCS单机实例只有1个节点，1个Redis进程。

RDB支持存储LFU、LRU Redis 5.0开始，RDB快照文件中增加存储key逐出策略LRU和LFU： FIFO：先进先出。最早存储的数据，优先被淘汰。 LRU：最近最少使用。长期未使用的数据，优先被淘汰。 LFU：最不经常使用。在一段时间内，使用次数最少的数据，优先被淘汰。 Redis 5.0的RDB文件格式有变化，向下兼容。因此如果使用快照的方式迁移，可以从Redis低版本迁移到Redis 5.0，但不能从Redis 5.0迁移到低版本。

内存使用优化 Redis 5.0在上一版本基础上，在内存使用上做了进一步优化。 主动碎片整理 当key被频繁修改，value长度不断变化时，Redis会为key分配新的内存空间。由于Redis追求高性能，实现了自己的内存分配器来管理内存，因此并不会将原有内存释放给OS，从而导致出现内存碎片。当used_memory_rss/used_memory高于1.5，一般认为内存碎片占比过高，内存利用率低。 因此，合理规划和使用缓存数据，规范数据写入，有助于减少内存碎片的产生。 Redis 3.0及以下：可以通过定期重启服务解决内存碎片问题。建议实际缓存数据不超过配置可用内存的50%。 Redis 4.0：支持主动整理内存碎片，服务在运行期间进行自动内存碎片清理。同时Redis 4.0支持通过memory purge命令手动清理内存碎片。 Redis 5.0：增强版主动碎片整理，配合Jemalloc版本更新，更快更智能，延时更低。 HyperLogLog算法优化 HyperLogLog是一种基数计数方法，使用少量的内存空间完成海量数据的计数统计，在Redis 5.0中，HyperLogLog算法得到改进，优化了计数统计时的内存使用效率。 举个例子：B树计数效率非常高，但是内存消耗也比较多。而HyperLogLog可节省大量存储空间。当B树需要1M内存统计，HyperLogLog只需要1kb。 内存信息统计报告能力增强 INFO命令返回信息更加详实。

Stream数据结构 Stream是Redis 5.0引入的一种新数据类型，它是一个全新的支持多播的可持久化消息队列。 Redis Stream的结构示意图如图1所示，它是一个可持久化的数据结构，用一个消息链表，将所有加入进来的消息都串起来。 Stream数据结构具有以下特性： Stream中可以有多个消费者组。 每个消费组都含有一个Last_delivered_id，指向消费组当前已消费的最后一个元素（消息）。 每个消费组可以含有多个消费者对象，消费者共享消费组中的Last_delivered_id，相同消费组内的消费者存在竞争关系，即一个元素只能被其中一个消费者进行消费。 消费者对象内还维持了一个Pending_ids，Pending_ids记录已发送给客户端，但是还没完成ACK（消费确认）的元素id。 Stream与Redis其他数据结构的比较，见表1。 图1 Stream数据结构示意图 表1 Stream与Redis现有数据结构比较 比较项 Stream List、Pub/Sub、Zset 复杂度 获取元素高效，复杂度为O(logN) List获取元素的复杂度为O(N) offset 支持offset，每个消息元素有唯一id。不会因为新元素加入或者其他元素淘汰而改变id。 List没有offset概念，如果有元素被逐出，无法确定最新的元素 持久化 支持消息元素持久化，可以保存到AOF和RDB中。 Pub/Sub不支持持久化消息。 消费分组 支持消费分组 Pub/Sub不支持消费分组 消息确认 支持ACK（消费确认） Pub/Sub不支持 性能 Stream性能与消费者数量无明显关系 Pub/Sub性能与客户端数量正相关 逐出 允许按时间线逐出历史数据，支持block，给予radix tree和listpack，内存开销少。 Zset不能重复添加相同元素，不支持逐出和block，内存开销大。 删除元素 不能从中间删除消息元素。 Zset支持删除任意元素 Stream相关命令介绍 接下来按照使用流程中出现的顺序介绍Stream相关命令。详细命令见表2 首先使用XADD添加流元素，即创建Stream，添加流元素时可指定消息数量最大保存范围。 然后通过XGROUP创建消费者组。 消费者使用XREADGROUP指令进行消费。 客户端消费完毕后使用XACK命令确认消息已消费成功。 图2 Stream相关命令介绍 表2 Stream的详细命令 命令 说明 语法 XACK 从流的消费者组的待处理条目列表（简称PEL）中删除一条或多条消息。 XACK key group ID [ID ...] XADD 将指定的流条目追加到指定key的流中。 如果key不存在，作为运行这个命令的副作用，将使用流的条目自动创建key。 XADD key ID field string [field string ...] XCLAIM 在流的消费者组上下文中，此命令改变待处理消息的所有权， 因此新的所有者是在命令参数中指定的消费者。 XCLAIM key group consumer min-idle-time ID [ID ...] [IDLE ms] [TIME ms-unix-time] [RETRYCOUNT count] [FORCE] [JUSTID] XDEL 从指定流中移除指定的条目，并返回成功删除的条目的数量，在传递的ID不存在的情况下， 返回的数量可能与传递的ID数量不同。 XDEL key ID [ID ...] XGROUP 该命令用于管理流数据结构关联的消费者组。使用XGROUP你可以： 创建与流关联的新消费者组。 销毁一个消费者组。 从消费者组中移除指定的消费者。 将消费者组的最后交付ID设置为其他内容。 XGROUP [CREATE key groupname id-or-$] [SETID key id-or-$] [DESTROY key groupname] [DELCONSUMER key groupname consumername] XINFO 检索关于流和关联的消费者组的不同的信息。 XINFO [CONSUMERS key groupname] key key [HELP] XLEN 返回流中的条目数。如果指定的key不存在，则此命令返回0，就好像该流为空。 XLEN key XPENDING 通过消费者组从流中获取数据。检查待处理消息列表的接口，用于观察和了解消费者组中哪些客户端是活跃的，哪些消息在等待消费，或者查看是否有空闲的消息。 XPENDING key group [start end count] [consumer] XRANGE 返回流中满足给定ID范围的条目。 XRANGE key start end [COUNT count] XREAD 从一个或者多个流中读取数据，仅返回ID大于调用者报告的最后接收ID的条目。 XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...] XREADGROUP XREAD命令的特殊版本，指定消费者组进行读取。 XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...] XREVRANGE 与XRANGE相同，但显著的区别是以相反的顺序返回条目，并以相反的顺序获取开始-结束参数 XREVRANGE key end start [COUNT count] XTRIM XTRIM将流裁剪为指定数量的项目，如有需要，将驱逐旧的项目（ID较小的项目）。 XTRIM key MAXLEN [~] count 消息（流元素）消费确认 Stream与相比Pub/Sub，不仅增加消费分组模式，还支持消息消费确认。 当一条消息被某个消费者调用XREADGROUP命令读取或调用XCLAIM命令接管的时候， 服务器尚不确定它是否至少被处理了一次。 因此，一旦消费者成功处理完一条消息，它应该调用XACK知会Stream，这样这个消息就不会被再次处理， 同时关于此消息的PEL（pending_ids）条目也会被清除，从Redis服务器释放内存。 某些情况下，因为网络问题等，客户端消费完毕后没有调用XACK，这时候PEL内会保留对应的元素ID。待客户端重新连上后，XREADGROUP的起始消息ID建议设置为0-0，表示读取所有的PEL消息及自last_id之后的消息。同时，消费者消费消息时需要能够支持消息重复传递。 图3 ACK机制解读

单机实例特点 系统资源消耗低，支持高QPS 单机实例不涉及数据同步、数据持久化所需消耗的系统开销，因此能够支撑更高的并发。Memcached的单机实例QPS达到10万以上。 进程监控，故障后自动恢复 DCS部署了业务高可用探测，单机实例故障后，30秒内会重启一个新的进程，恢复业务。 即开即用，数据不做持久化 单机实例开启后不涉及数据加载，即开即用。如果服务QPS较高，可以考虑进行数据预热，避免给后端数据库产生较大的并发冲击。 低成本，适用于开发测试 单机实例各种规格的成本相对主备减少40%以上。适用于开发、测试环境搭建。 总体说来，单机实例支持读写高并发，但不做持久化，实例重启时不保存原有数据。单机实例主要服务于数据不需要由缓存实例做持久化的业务场景，如数据库前端缓存，用以提升数据读取效率，减轻后端并发压力。当缓存中查询不到数据，可穿透至磁盘数据库中获取，同时，重启服务、缓存实例时，可从磁盘数据库中获取数据进行预热，降低后端服务在启动初期的压力。

实例架构设计 DCS的Memcached单机实例架构，如图1所示。 图1 Memcached单机实例示意图 示意图说明： VPC 虚拟私有云。实例的内部所有服务器节点，都运行在相同VPC中。 Memcached单机实例不支持公网访问，客户端需要与实例处于相同VPC，并且配置安全组访问规则。 相关参考：如何选择和配置Redis实例以及客户端的安全组。 客户应用 运行在ECS上的客户应用程序，即实例的客户端。 Memcached实例兼容开源协议，可直接使用开源客户端进行连接，关于多语言客户端连接示例，请参考用户指南的连接缓存实例。 DCS缓存实例 DCS实例，单机实例只有1个节点，1个Memcached进程。 DCS实时探测实例可用性，当Memcached进程故障后，DCS为实例重新拉起一个新的Memcached进程，恢复业务。 Memcached实例访问端口为11211。