华为云用户手册

步骤3：用户登录并验证权限 用户创建完成后，可以使用新用户的用户名及身份凭证登录华为云验证权限，即“DDS ReadOnlyAccess”权限。更多用户登录方法请参见用户登录华为云方法。 在华为云登录页面，单击左下角的“ IAM 用户”。 图10 IAM用户登录 在“IAM用户登录”页面，输入账号名、用户名及用户密码，使用新创建的用户登录。 账号名为该IAM用户所属华为账号的名称。 用户名和密码为账号在IAM创建用户时输入的用户名和密码。 如果登录失败，您可以联系您的账号主体，确认用户名及密码是否正确，或是重置用户名及密码，重置方法请参见忘记IAM用户密码。 登录成功后，进入华为云控制台，请先切换至授权区域。 图11 切换至授权区域 在“服务列表”中选择文档数据库服务，进入DDS主界面，单击右上角“购买数据库实例”，若提示权限不足，表示“DDS ReadOnlyAccess”已生效。 在“服务列表”中选择除文档数据库服务外的任一服务，如“弹性云服务器”，若提示权限不足，表示“DDS ReadOnlyAccess”已生效。

分析DDS数据库正在执行的请求 通过Mongo Shell连接DDS实例。 开通公网访问的实例 具体请参见： 通过公网连接集群实例 通过公网连接副本集实例 通过公网连接单节点实例 未开通公网访问的实例 具体请参见： 通过内网连接集群实例 通过内网连接副本集实例 通过内网连接单节点实例 执行以下命令，查看数据库当前正在执行的操作。 db.currentOp() 回显如下： { "raw" : { "shard0001" : { "inprog" : [ { "desc" : "StatisticsCollector", "threadId" : "140323686905600", "active" : true, "opid" : 9037713, "op" : "none", "ns" : "", "query" : { }, "numYields" : 0, "locks" : { }, "waitingForLock" : false, "lockStats" : { } }, { "desc" : "conn2607", "threadId" : "140323415066368", "connectionId" : 2607, "client" : "172.16.36.87:37804", "appName" : "MongoDB Shell", "active" : true, "opid" : 9039588, "secs_running" : 0, "microsecs_running" : NumberLong(63), "op" : "command", "ns" : "admin.", "query" : { "currentOp" : 1 }, "numYields" : 0, "locks" : { }, "waitingForLock" : false, "lockStats" : { } } ], "ok" : 1 }, ... } client：发起请求的客户端。 opid：操作的唯一标识符。 secs_running：该操作已经执行的时间，单位：秒。如果该字段返回的值特别大，需要查看请求是否合理。 microsecs_running：该操作已经执行的时间，单位：微秒。如果该字段返回的值特别大，需要查看请求是否合理。 op：操作类型。通常是query、insert、update、delete、command中的一种。 ns：操作目标集合。 其他参数详见db.currentOp()命令官方文档。 根据命令执行结果，分析是否有异常耗时的请求正在执行。 如果业务日常运行的CPU使用率不高，由于执行某一操作使得CPU使用率过高，导致业务运行缓慢，该场景下，您需要关注执行耗时久的请求。 如果发现异常请求，您可以找到该请求对应的opid，执行db.killOp(opid)命令终止该请求。

分析服务能力 经过前面数据库正在执行的请求和慢请求的分析和优化，所有的请求都使用了合理的索引，CPU的使用率相对趋于稳定。如果经过前面的分析排查，CPU使用率仍然居高不下，则可能是因为当前实例已达到性能瓶颈，不能满足业务需要，此时您可以通过如下方法解决。 通过查看监控信息分析实例资源的使用情况，详情请参见查看监控指标。 对DDS进行规格变更或者添加分片数量。具体操作请根据当前的实例类型参考如下文档。 添加集群实例的节点数量 变更集群实例的CPU和内存 添加副本集实例的节点数量 变更副本集实例的CPU和内存 变更单节点实例的CPU和内存

规避建议 MongoDB官方建议：在每次删除数据库或集合后，在所有mongos节点上，通过命令db.adminCommand("flushRouterConfig")，刷新路由。 参考链接： https://docs.mongodb.com/manual/reference/method/db.dropDatabase/index.html#replica-set-and-sharded-clusters https://jira.mongodb.org/browse/SERVER-17397 其他规避建议： 对于集群模式，建议开启数据库的分片功能，再对其中的集合进行分片。 对于未开启分片功能的数据库。在删除数据库或集合之后，不建议创建同名的数据库或集合。 如果因业务需求，需要创建同名的数据库或集合，请在删除数据库或集合之后，创建同名的数据库或集合之前，登录到所有的mongos节点上，执行刷新路由表的操作。

使用场景 当未对数据进行分片时，若系统中存在多个dds mongos，通过不同的dds mongos进行数据访问时，可能出现不同dds mongos上本地缓存的路由信息不一致的情况。场景示例： 通过mongos1创建A数据库，未开启分片。写入数据1后，数据1被全部分到shard server1上存储。然后，在mongos2上对数据进行查询。此时，mongos1和mongos2上，均存在缓存的A数据库的路由信息。 通过mongos2执行了A数据库的删除操作。此时，config server和shard server1中的A数据库信息都被删掉。而mongos1无法识别数据1已经被删除。 通过mongos1向A数据库中写入数据2时，由于存在缓存，所以无法识别A数据库已经被删除的场景。参照已经存在的路由信息，数据2被存储到shard server1上。然后，通过mongos2向A数据库中写入数据3时，由于能够识别出A数据库已经被删除，所以会在config server和shard server2中生成新的A数据库的信息。 此时，mongos1和mongos2中缓存的路由信息不一致，关联不同的shard server，且仅能看到部分数据，导致数据异常。 图2 mongos缓存缺陷的场景 客户端通过不同mongos，所查询到的数据不同： mongos1：可以查到数据2，无法查询到数据3。 mongos2：可以查询到数据3，无法查询到数据2。

分片概念 分片是指将一个集合的数据，根据指定的shard key，相对均匀地分布保存在多个shard server上。这种指定了shard key的集合，称为分片集合。但是，如果并未对集合进行分片，则该集合的数据，只会全部存储在某一个shard server上。DDS集群模式允许分片集合和未分片集合在数据库中同时存在。 未分片的集合可以通过命令sh.shardCollection转为分片集合。对集合进行分片之前，需确保集合所属的数据库开启了分片功能，您可以通过命令sh.enableSharding开启分片功能。

dds mongos路由缓存机制 用户数据存储在shard server中，元数据存储在config server中。路由信息属于元数据信息，即存储在config server中。当用户通过dds mongos对集群进行数据访问时，dds mongos会根据config server中的路由信息，将用户请求发送到对应的shard server上，进行数据访问。 但是，如果dds mongos在每次处理数据访问时，都从config server获取路由信息，很大程度上会影响性能。因此，在实现机制上，添加了缓存机制：将config server的路由信息缓存在dds mongos本地。该场景下，不但在config server中会存储路由信息，dds mongos的本地缓存中也可能会缓存路由信息。 dds mongos中并不是一定会存在缓存的路由信息，如果dds mongos上没有进行过任何数据操作，就没有缓存信息。并且，dds mongos上缓存的路由信息，也不一定是最新的config server的路由信息。因为dds mongos上缓存的路由信息，不是实时或者定时刷新的，而是lazy模式，是在特定的场景下被动触发的，包含但可能不限于如下几种触发场景： dds mongos启动时，从config server获取最新的路由信息，并缓存在本地。 dds mongos第一次处理相关数据的请求：由于mongos本地没有缓存该相关数据的路由信息，将会触发更新相关的config server路由信息到dds mongos本地缓存的逻辑，在继续处理后续请求时，dds mongos已经缓存了相关数据的路由信息，会直接使用缓存中的路由信息来访问shard server。 在dds mongos上手工执行路由刷新命令。 被动触发dds mongos的路由缓存刷新，只是刷新用户请求涉及到的元数据信息，而非刷新缓存中的全部内容。 缓存刷新的范围以DB为单位。

数据库和集合的创建 使用短字段名，以节约存储空间。文档数据库与关系型数据库不同，集合中的每个文档都存储字段名，使用短字段名可以有效的节约存储空间。 有效的控制集合中的文档数量，避免影响查询性能。如果有必要，可以进行定期归档。 每条文档都提供默认的“_id”值，禁止向“_id”中保存自定义值。 固定集合相较其他集合，插入速度快，并且能够自动删除旧数据。用户可以根据业务需要，选择创建固定集合以提高性能。 更多规范建议请参见《文档数据库服务开发指南》中“使用规范”章节。

查询操作 索引 根据业务需求，对经常查询的数据字段创建适当的索引。需注意，索引会占用一些空间，并且插入操作和索引更新会消耗资源。因此，建议每个集合的索引数量不超过5个。 案例：出现数据查询缓慢，如果没有创建索引，建议对经常查询的数据字段创建适当的索引，优化查询速度。 对于包含多个键的查询，建议创建包含这些键的复合索引。复合索引的键值顺序很关键，需遵循索引最左前缀原则，查询应包含最左索引字段，以索引创建顺序为准，与查询字段顺序无关。 给索引添加TTL属性，自动筛选过期文档并删除。创建TTL的索引必须是日期类型。TTL索引是单字段索引，而非复合索引。 需要在集合中某个字段上创建索引，但当集合中大量文档不包含该键值时，建议创建稀疏索引。 创建文本索引时，字段指定text，而不是1或者-1。每个集合只有一个文本索引，但它可以为任意多个字段建立索引。 命令使用 使用findOne方法，在数据库中查询匹配多个项目，将会在自然排序文件集合中返回第一个项目。如果需要返回多个文档，则使用find方法。 如果查询无需返回整个文档，或只是用来判断键值是否存在，可以通过投影$project来限制返回字段，减少网络流量和客户端的内存使用。 除了前缀样式查询，正则表达式查询执行的时间比大多数选择器更久，不建议使用索引。 查询中的某些含“$”的操作符可能会降低使用性能。在业务中尽量不要使用该类操作符：$or、$nin、$not、$ne、$exists。 $or：有多少个条件就会查询多少次，最后合并结果集，建议替换为$in。 $nin：可能会匹配到大多数的索引，此时，查询优化器会退化为全表扫描。 $not：可能会导致查询优化器无法匹配到具体的索引，退化为全表扫描。 $ne：选择字段值不等于指定值的文档，如果多数为取相反值的文档，将会扫描整个索引。 $exists：对于松散的文档结构，查询必须遍历每一个文档。 更多信息，请参见MongoDB官方文档。

选择合适的分片键 背景 分片集群中数据的分片以集合为基础单位，集合中的数据通过分片键被分成多个部分。分片键是在集合中选择的一个合适的字段，数据拆分时以该分片键的值为依据均衡地分布到所有分片中。如果您没有选择到合适的的分片键，可能会降低集群的使用性能，出现执行分片语句时执行过程卡住的问题。 分片键一旦设置后不能再更改。如果未选取到合适的分片键，需要使用正确的分片策略，将数据迁移到新的集合后重新执行分片。 合适的分片键的特点 所有的插入、更新以及删除操作，将会均匀分发到集群中的所有分片中。 key的分布足够离散。 尽量避免scatter-gather查询。 如果所选分片键不具备以上所有特点，将会影响集群的读写扩展性。例如，通过find()操作读取的工作量在分片中非均匀分布，最终会产生查询热分片。同样，如果写工作量（插入、更新和修改）在分片中非均匀分布，最终会产生写热分片，严重限制分片的优势。因此，您需要根据应用读写状态（重读取还是重写入）、经常查询及写入的数据等业务需求，调整您的分片键。 需要注意，对已有数据分片后，如果update请求的filter中未携带片键字段并且选项upsert:true或者multi:false，那么update 请求会报错，并返回“An upsert on a sharded collection must contain the shard key and have the simple collation.” 判断标准 您可以通过表2中的几个维度，判断所选分片键是否能够满足业务需求。 表2 合理分片键的判断依据 判断依据 说明 片键基数 片键基数是指划分数据块的能力。例如，要记录某个学校的学生信息，由于学生的年龄比较集中，如果选择年龄作为分片键，同一个数据段中将存储很多同龄学生的数据，影响集群的性能以及可管理性。由于学生的学号唯一，如果选择学号作为分片键，分片基数较大，有利于数据的均匀分布。 写分布 若用户业务在同一时间段有大量写操作，则希望这些写操作能够均匀分布到各个分片上。如果数据分布策略为范围分片，并以一个单调递增的值作为分片键，此时，大量写入的数据同样是片键字段递增，数据将写入同一个分片。 读分发 若用户业务在同一时间段有大量读操作，则希望这些读操作能够均匀分布到各个分片上，以充分利用各分片节点的计算性能。 定向读 dds mongos查询路由器可以执行定向查询（只查询一个分片）或scatter/gather查询（查询所有分片）。只有查询中存在分片键，dds mongos才能定位到单一分片，因此，您需要选择在业务运行时可用于普遍查询的分片键。如果您选择合成的分片键，将无法在定向查询中使用该片键，所有的查询方式将变成scatter/gather查询，从而限制扩展读数据的能力。

选择合适的数据分布策略 分片集群支持将单个集合的数据分散存储在多个分片上，用户可以根据集合内文档的分片键来分布数据。 目前，主要支持两种数据分布策略，即范围分片（Range based sharding）和Hash分片（Hash based sharding），设置方式请参见4。 下面分别介绍这两种数据分布策略以及各自的优缺点。 范围分片 基于范围进行分片，即集群按照分片键的范围把数据分成不同部分。假设有一个数字分片键，为一条从负无穷到正无穷的直线，每一个片键的值均在直线上进行标记。可以理解为将该直线划分为更短的不重叠的片段，并称之为数据块，每个数据块包含了分片键在一定的范围内的数据。 图1 数据分布示意图 如上图所示，x表示范围分片的片键，x的取值范围为[minKey,maxKey]，且为整型。将整个取值范围划分为多个chunk，每个chunk（通常配置为64MB）包含其中一小段的数据。其中，chunk1包含x值在[minKey, -75]中的所有文档，每个chunk的数据都存储在同一个分片上，每个分片可以存储多个chunk，并且chunk存储在分片中的数据会存储在config服务器中，dds mongos也会根据各分片上的chunk的数据自动执行负载均衡。 范围分片能够很好的满足范围查询的需求，例如，查询x的取值在[-60,20]中的文档，仅需dds mongos将请求路由到chunk2。 范围分片的缺点在于，如果分片键有明显递增（或递减）趋势，新插入的文档很大程度上会分布到同一个chunk，从而无法扩展写的能力。例如，使用“_id”作为分片键，集群自动生成id的高位值将是递增的时间戳。 Hash分片 根据用户的分片键值计算出Hash值（长度64bit且为整型），再按照范围分片策略，根据Hash值将文档分布到不同的chunk中。基于Hash分片主要的优势为保证数据在各节点上分布基本均匀，具有“相近”片键的文档很可能不会存储在同一个数据块中，数据的分离性更高。 图2 数据分布示意图 Hash分片与范围分片互补，能将文档随机分散到各个chunk，充分扩展写能力，弥补范围分片的不足。但所有的范围查询要分发到后端所有的分片，才能获取满足条件的文档，查询效率低。

连接副本集实例（非友好方式） 通过连接地址连接副本集实例 mongodb://rwuser:****@192.168.0.148:8635/test?authSource=admin&replicaSet=replica 其中，“192.168.0.148:8635”为暂时的主节点IP及端口号。当发生主备切换而更换了主节点，客户端将无法连接到副本集实例主节点，因为客户端无法知道新选举出的主节点的IP及端口号信息，导致整个数据库服务发生故障。同时，只提供主节点IP及端口号，读写只能在固定的主机上操作，无法扩展数据库的读写性能，如图下图所示： 图4 数据读写示意图

2024年07月 序号 功能名称 功能描述 阶段 相关文档 1 支持TaurusDB标准版 云数据库 TaurusDB标准版是一种基于 云计算平台 的稳定可靠、弹性伸缩、便捷管理的在线数据库。采用MySQL经典主备架构，并基于MySQL内核进行深度自研，在100%兼容MySQL的同时提供了更多更强的内核能力，如16K原子写、字段压缩、分区增强等能力。TaurusDB标准版为中小企业提供简化的数据库管理体验和强大的运维功能，助力中小企业在数字化转型中释放数据潜力。 商用 什么是云数据库 TaurusDB标准版

业务场景 客户有按照各业务单元分析成本的诉求，通常情况下会通过标签、企业项目作为业务单元的标识。 资源包是华为云提供的常见权益，所以很多客户需要单独分析资源包成本。实际上，客户是需要分析按需资源抵扣的资源包部分的成本。请注意，业务单元的标识（标签、企业项目）是打在资源实例上的，而不是资源包这个权益上。 从2024年12月1日之后，新购/续订的OBS套餐包中包含多个用量类型，开始支持按实际使用情况进行成本分摊。支持的资源包服务范围详情请参见：资源包分摊规则。

步骤一：查看异常成本记录 前提条件：接收异常成本通知，跳转至异常成本监控页。 系统自动为客户创建全局监控器后，会为客户发送自动创建成功通知。此通知并非异常成本告警。 异常成本监控为免费功能。 查看异常成本邮件通知。 点击邮件内容操作列的“查看详情”，跳转“异常成本详情”。 如下图所示，2024.12.3产生了包年/包月的异常成本，与上月同期的成本相比，实际增加了8.16元，持续时间为30天，主要涉及的产品是云硬盘。 侧边栏弹出的异常成本详情，可以查看异常成本的基础信息和异常潜在原因。

步骤二：分析异常成本原因 您可在“异常潜在原因”中进行初步分析。例如，示例中以包年/包月异常为例，对于有些客户而言，包年/包月产品的续费属于正常的业务增加，此时，客户可以直接反馈不是异常，帮助我们完善异常判断模型。 若您认为这笔新购的包年/包月费用，属于意料之外，建议您进一步分析原因。在“异常潜在根因”操作列点击“查看成本分析”来进一步查看。 如图所示，表示2024.12.2云硬盘产生了额外的新购，消费了8.16元，您可确认该新购是否为异常消费。 您可以按照特定的视角，来分析异常潜在原因。如，您需要按照业务视角去分析归属方，您可以在汇总维度中选择“企业项目”、“成本标签”、“成本分组”等方式汇总成本。 如图所示，表示2024.12.2云硬盘产生异常新购消费中，default的消费为8.16元。 若您需要定位具体产生费用的资源，请在汇总维度中选择资源名称/ID。 如图所示，表示2024.12.8、2024.12.9云硬盘产品异常新购消费中，volume-4c2a b9ef14be-8f1e-46a5-a31d-6c5196082937的消费分别为0.26元、6.38元。

了解成本监控 异常成本监控引入机器学习，基于您历史的按需消费和包年包月消费，建立特定的消费模型，并参考预测值，识别成本异常飙升的场景，同时给出Top潜在根因。了解异常成本检测规则。 指定类型（全部产品、关联账号、成本标签、成本分组、企业项目）的监控器和监控通知创建后，成本中心将定时把影响成本超过通知阈值的异常记录通知给指定联系人。当前，系统自动为部分用户创建了异常成本监控器和通知。了解自动创建异常成本监控器。 您可查看监控器下的所有异常记录，并对异常成本的潜在原因进行分析，以此来帮助您更好的分析异常原因。建议您对异常成本结果进行反馈，帮助我们完善消费模型，更好地识别异常成本。

场景示例 客户需要将成本在部门A、B、C之间分配。 大部分成本可以通过客户标记在资源上的标签来标识归属的部门；另外，A部门还单独使用了内容分发网络服务（假设内容分发网络服务不支持标签管理）；所有部门共用了云手机。 已知：客户已使用成本标签来标记成本，标签键：Group；标签值：部门A，部门B，部门C。 成本分组创建4小时之后，定义拆分规则，把共同成本在组织内进行分配。 拆分未分配成本时，采用自定义拆分方式，部门A拆分50%，部门B拆分30%，部门C拆分20%。 拆分共同成本时，采用自定义拆分方式，部门A拆分30%，部门B拆分30%，部门C拆分40%。

步骤二：查看成本分配详情 登录成本中心。 选择“成本分组”。 单击成本分组名称链接，查看成本分配详情。 如上图所示，查看成本占比的摊销成本净值： 摊销成本净值：按规则分配后的摊销成本净值。 拆分金额：公共成本拆分的金额，拆分金额为负数时，表示是“拆分源”。 最终分配成本：实际分配到的金额。最终分配成本=摊销成本净值+拆分金额。 最终占比：最终分配成本占总分配成本的百分比。 各部门分拆金额解读： 部门A 按照标签维度摊销的成本净值为5.94元； 分摊到的公共成本和未分配成本为30%*1251.51+50%*2452416.75=1,226,583.828元； 合计的最终分配成本为5.94+1,226,583.828=1,226,589.768元。 部门B 按照标签维度摊销的成本净值为0元； 分摊到的公共成本和未分配成本为30%*1251.51+30%*2452416.75=736,100.478元； 合计的最终分配成本为0+736,100.478=736,100.478元。 部门C 按照标签维度摊销的成本净值为0元； 分摊到的公共成本和未分配成本为40%*1251.51+20%*2452416.75=490,983.954元； 合计的最终分配成本为0+490,983.954=490,983.954元。 公共成本和未分配成本 已全部分摊到部门A、部门B和部门C，因此最终分配成本均为0。 根据成本分组查看成本明细数据。 选择“成本明细导出”，在“文件导出”页签中导出的成本明细文件，在导出的原始成本或摊销成本（文件名标识为%账号名%_AmortizedCostDetailByUsage_YYYY-MM）的成本明细文件中，可以根据成本分组过滤成本明细数据。

约束与限制 2023年7月30日前创建的实例，不支持运行日志功能。 运行日志默认保留时间为七天，如果需要延长保留天数，可以在LTS控制台修改日志组的存储时间。 运行日志开启后会在LTS控制台创建对应的日志组、日志流和仪表盘。使用期间按照日志量收费，收费标准请参考LTS价格详情。 频繁产生运行日志，可能会影响RabbitMQ实例性能。 RabbitMQ AMQP-0-9-1版本实例不支持查看运行日志。

删除Vhost（RabbitMQ WebUI） 登录RabbitMQ WebUI。 在顶部导航栏选择“Admin”，进入Admin页面。 在右侧导航栏选择“Virtual Hosts”，进入Virtual Hosts页面。 图1 Virtual Hosts页面 单击待删除的Vhost名称，进入Vhost详情页。 图2 待删除的Vhost 在“Delete this vhost”区域，单击“Delete this virtual host”，弹出确认删除对话框。 图3 删除Vhost 单击“确定”，完成Vhost的删除。

创建RabbitMQ Vhost（RabbitMQ WebUI） 登录RabbitMQ WebUI。 在顶部导航栏选择“Admin”，进入Admin页面。 在右侧导航栏选择“Virtual Hosts”，进入Virtual Hosts页面。 图4 Virtual Hosts 在“Add a new virtual host”区域，输入Vhost名称，单击“Add virtual host”。 图5 创建Vhost（WebUI） 创建成功后，在“All virtual hosts”区域，显示创建成功的Vhost。 图6 Vhost列表（WebUI）

配置仲裁队列的长度 通过配置Policy或者队列属性的方式可以限制仲裁队列的长度和在内存中保存的长度。 x-max-length：仲裁队列最大消息数。如果超过则丢弃消息，或者发送到死信交换器。 x-max-length-bytes：仲裁队列最大总消息大小（字节数）。如果超过则丢弃消息，或者发送到死信交换器。 x-max-in-memory-length：限制仲裁队列的内存中最大消息数量。 x-max-in-memory-bytes：限制仲裁队列的内存中的最大总消息大小（字节数）。

仲裁队列与镜像队列的差异 仲裁队列是RabbitMQ 3.8版本引入的队列类型，它与镜像队列拥有类似的功能，为RabbitMQ提供高可用的队列。镜像队列有一些设计上的缺陷，这也是RabbitMQ提供仲裁队列的原因。 镜像队列主要的缺陷在于消息同步的性能低。 镜像队列包含一个主队列和多个从队列，当生产者向主队列发送一条消息，主队列会将消息同步给从队列，所有的从队列都保存消息后，主队列才会向生产者发送确认。 RabbitMQ使用集群部署时，如果其中一个节点故障下线，待它消除故障重新上线后，它保存的所有从队列的数据都会丢失。此时运维人员需要选择是否同步主队列的数据到从队列中，如果不同步数据，会增加消息丢失的风险。如果同步数据，同步时队列是阻塞的，无法对其进行操作。当队列中存在大量堆积消息时，同步会导致队列几分钟、几小时或者更长时间不可用。

预取值设置建议 如果您只有一个或很少几个消费者在处理消息，建议一次预取多条消息，尽量让客户端保持忙碌。如果您的处理时间和网络状态稳定，则只需将总往返时间除以每条消息在客户端的处理时间即可获得估计的预取值。 在消费者多且处理时间短的情况下，建议使用较低的预取值。过低的预取值会使消费者闲置，因为消费者在处理完消息后需要等待下一批的消息到达。过高的值可能会使单个消费者忙碌，其他消费者处于空闲状态。 在消费者多且处理时间很长的情况下，建议您将预取值设置为1，以便消息在所有消费者间均匀分布。

设置预取值 以下示例演示在Java客户端为单个消费者设置预取值为10。 ConnectionFactory factory = new ConnectionFactory(); Connection connection = factory.newConnection(); Channel channel = connection.createChannel(); //设置预取值为10。 channel.basicQos(10, false); QueueingConsumer consumer = new QueueingConsumer(channel); channel.basicConsume("my_queue", false, consumer); 在Java客户端中，global的默认值为false，因此以上示例可以简单地写为channel.basicQos(10)。 global取值的含义如下： false：分别作用于通道上的每个新消费者。 true：在通道上的所有消费者之间所共享。

生产者确认 生产者确认，即服务端在收到来自生产者的消息时进行确认。 以下示例演示在Java客户端配置生产者确认： try { channel.confirmSelect() ; //将信道置为publisher confirm模式 //之后正常发送消息 channel.basicPublish("exchange", "routingKey" , null , "publisher confirm test" .getBytes()); if (!channel.waitForConfirms()) { System.out.println( "send message failed " ) ; // do something else.... } } catch (InterruptedException e) { e.printStackTrace() ; } 调用channel .waitForConfirms方法之后，会等待服务端确认，这是一种同步等待的方式，会对性能产生影响。如果生产者要满足at least once，就必须使用同步等待方式。

消费者确认 消费者确认是指服务端通过确认消息是否成功被消费者接收，来判断是否删除队列中的此消息。 消费者确认对数据可靠性十分重要，接收重要消息的消费应用程序在未处理完消息前不应确认消息，以便消费者有足够的时间处理消息，无需担心消息处理过程中由于消费者进程异常（如工作程序崩溃、重启等）导致消息丢失。 消费者确认在客户端上配置，通过配置basicConsume方法启用确认。在channel中启用消费者确认适用于大多数场景。 以下示例演示在Java客户端配置消费者确认（使用Channel#basicAck设置basic.ack为肯定）： // this example assumes an existing channel instance boolean autoAck = false; channel.basicConsume(queueName, autoAck, "a-consumer-tag", new DefaultConsumer(channel) { @Override public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException { long deliveryTag = envelope.getDeliveryTag(); // positively acknowledge a single delivery, the message will // be discarded channel.basicAck(deliveryTag, false); } }); 未确认的消息缓存在内存中，如果未确认的消息过多，会导致内存使用率过高，此时可以在客户端配置预取值来限制消费者预取的消息数量，具体方法请参见配置RabbitMQ消息预取值。

设置Exchange持久化 在RabbitMQ WebUI页面设置Exchange持久化。 创建Exchange时，设置“durable”为“true”，如图1所示。 图1 设置Exchange持久化（WebUI） 设置成功后如图2所示。 图2 持久化的Exchange（WebUI） 在RabbitMQ实例控制台设置Exchange持久化。 创建Exchange时，设置Exchange持久化，如图3所示。 图3 设置Exchange持久化（控制台） 设置成功后如图4所示。 图4 持久化的Exchange（控制台）

设置Queue持久化 在RabbitMQ WebUI页面设置Queue持久化。 创建Queue时，设置“durable”为“true”，如图5所示。 图5 设置Queue持久化（WebUI） 设置成功后如图6所示。 图6 持久化的Queue（WebUI） 在RabbitMQ实例控制台设置Queue持久化。 创建Queue时，设置Queue持久化，如图7所示。 图7 设置Queue持久化（控制台） 设置成功后如图8所示。 图8 持久化的Queue（控制台）