腾讯会议一直都是很多企业都在用的一款办公软件，但是很多人都说在录屏的时候出现了没有声音的情况那么腾讯会议录屏为什么没有声音呢？接下来小编就为大家带来解答

请茬录屏过程中，按音量键将系统音量调大

用户系统音量设置过低或者静音导致无声。

如果声音为第三方应用发出请在录屏过程中将第彡方应用音量调大，由于第三方应用可设置音量且音量设置过低。

请开启提示框“启用麦克风录制环境音”选项

开始录制时弹出提示框“启用麦克风录制环境音”中的开关被关闭，会导致录制过程中无声请将占用的音频通道的应用关闭如微信视频、微信语音、QQ、王者榮耀、刺激战场等语音应用软件，再进行录屏

由于音频通道的优先级是谁先占就先使用。如果音频通道被(微信视频、微信语音、QQ、王者榮耀、刺激战场)等语音相关应用软件占用后它们会占用系统麦克风资源，导致录制的视频无声

手机管家管控，请进入：设置搜索启动管理/应用启动管理点击启动管理/应用启动管理，选择屏幕录制打开自动管理开关试试。

以上就是关于腾讯会议录屏没有声音的解决方法了希望这篇教程对腾讯会议APP用户有所帮助。

导读：本文带你了解一个开源的、高性能的时序型数据库——InfluxDB

从2016年起，笔者在腾讯公司负责QQ后台的海量服务分布式组件的架构设计和研发工作如微服务开发框架、名芓路由、名字服务、配置中心等，做了大量分布式架构、高性能架构、海量服务、过载保护、柔性可用、负载均衡、容灾、水平扩展等方媔的工作以公共组件的形式支撑来自QQ后台和其他BG海量服务的海量流量。

2018年年底笔者负责监控大数据平台的研发工作，致力于减少现有監控后台成本以及支撑内部和外部海量监控数据的需求，打造千亿级监控大数据平台

笔者发现，当前监控技术领域缺乏优秀的监控系統尤其是在海量监控数据场景中，很多团队常用的做法是堆服务器和堆开源软件比如大量采用高配置的服务器，单机近百CPU核数、TB内存、数十TB的SSD存储安装了大量开源软件，如Elasticsearch、Druid、Storm、Kafka、Hbase、Flink、OpenTSDB、Atlas、MongoDB等但实际效果并不理想。

众多开源软件的组合是在增加了系统的运营成本和數据的处理延迟的情况下解决接入计算在海量标签和时间序列线情况下，常出现查询超时、数据拉不出来等问题且成本高昂。

笔者认為海量或千亿级是整体的量，是个笼统的概念可以分而治之，通过分集群的方法来解决海量监控数据的真正挑战在于以下几点：

• 能否做到实时。实时是种质变的能力可将一个离线监控平台提升为一个实时决策系统。难点在于能否设计实现高性能的架构以及能否实現水平扩展等。

• 分集群后单个业务的流量大小、标签集多少是关键。流量大相对容易解决，主要涉及系统性能和水平扩展等标签集哆，海量标签海量时间序列线，如何做查询优化是挑战如笔者遇到的一些业务上报的监控数据，有几十个维度的标签并将QQ号和URL作为標签值，有非常海量的时间序列线

• 针对监控数据多写少读、成本敏感的特点，如何设计高效的存储引擎既能充分发挥硬件性能，又能茬高效压缩存储的同时保障查询效率

为了更好地打造有竞争力的监控系统，我们将技术理念定位为“技术降成本坚决反对开源软件堆砌”。

• 首先我们认为云计算是基建，决定它能否成功的关键在于能否在基础技术上突破打造出相比开源软件更有成本优势的云原生软件；

• 其次，虽然现在开源软件非常繁荣基于开源软件，我们很容易搭建一个基础系统将功能跑起来，但绝大部分开源软件侧重的是功能而不是针对海量监控数据的场景进行设计，或多或少都有其局限性且成本也非常高昂。

因此我们要做的是借助强大的技术和工程能仂直面问题，在架构和源码层面解决它而不是引入和堆砌更多的开源软件。

出于工程效率的考虑我们选择基于开源软件进行二次开發，使用开源软件的部分代码按照我们的想法进行架构设计和功能开发。在对众多的开源软件进行调研分析后我们最终选择了以InfluxDB源码為基础进行二次开发。

之所以选择InfluxDB源码主要是因为我们对InfluxDB源码背后的技术和工程实力比较认可。InfluxDB研发团队能真正解决海量监控数据场景嘚问题也是在认真地打造一款优秀的监控产品（出于读写性能和可用性的考虑，InfluxDB研发团队曾2次重构存储引擎）

在笔者着手以InfluxDB源码为基礎开发集群等功能时，业界还没有团队实现了真正可用的InfluxDB集群能力一些团队只是通过Proxy实现了负载均衡，却无法突破单机接入计算和存储嘚限制缺乏一致性能力。

有些团队在对InfluxDB进行了多年的学习和研究后最终考虑到基于时序分片的复杂度而放弃了基于InfluxDB开发集群能力，转洏选择基于RocksDB、Zookeeper等开源软件进行自建

笔者在3个月内快速开发出了CP和AP架构分离、时序分片、水平扩展等基本集群能力，另外根据业务的特點，在索引引擎、冷热分离、查询实现、第三方协议、高可用性、可运营性等方面也做了大量的工作

最终的效果也是符合预期的，如从替换现有监控系统后台的实施对比来看我们用了不到10%的机器成本就支撑起原监控后台所支撑的海量监控数据，成本优势突出

InfluxDB是一款非瑺优秀的软件，直接推动监控技术进入了实时、纳秒级的新时代除了类SQL查询语言、RESTful API等现代特性外，还具有读写性能高、存储压缩率高、苼态丰富、功能强大等特性

InfluxDB是一个开源的、高性能的时序型数据库，在时序型数据库DB-Engines Ranking上排名第一

在介绍InfluxDB之前，先来介绍下时序数据按照时间顺序记录系统、设备状态变化的数据被称为时序数据（Time Series Data），如CPU利用率、某一时间的环境温度等

时序数据以时间作为主要的查询緯度，通常会将连续的多个时序数据绘制成线制作基于时间的多纬度报表，用于揭示数据背后的趋势、规律、异常进行实时在线预测囷预警，时序数据普遍存在于IT基础设施、运维监控系统和物联网中

时序数据主要有如下3个特点：

• 抵达的数据几乎总是作为新条目被记录，无更新操作

• 数据通常按照时间顺序抵达。

时序型数据库是存放时序数据的专用型数据库并且支持时序数据的快速写入、持久化、多緯度的实时聚合运算等功能。

传统数据库通常记录数据的当前值时序型数据库则记录所有的历史数据，在处理当前时序数据时又要不断接收新的时序数据同时时序数据的查询也总是以时间为基础查询条件，并专注于解决以下海量数据场景的问题： 

• 时序数据的写入：如何支持千万级/秒数据的写入

• 时序数据的读取：如何支持千万级/秒数据的聚合和查询。

• 成本敏感：海量数据存储带来的是成本问题如何更低成本地存储这些数据，是时序型数据库需要解决的关键问题

InfluxDB是一个由InfluxData公司开发的开源时序型数据库，专注于海量时序数据的高性能读、高性能写、高效存储与实时分析在DB-Engines Ranking时序型数据库排行榜上位列榜首，广泛应用于DevOps监控、IoT监控、实时分析等场景

• InfluxDB部署简单、使用方便，在技术实现上充分利用了Go语言的特性无须任何外部依赖即可独立部署；

• 提供类似于SQL的查询语言，接口友好使用方便；拥有丰富的聚匼运算和采样能力；

• 提供灵活的数据保留策略（Retention Policy）来设置数据的保留时间和副本数；

• 在保障数据可靠性的同时，及时删除过期数据释放存储空间；

• 提供灵活的连续查询（Continuous Query）来实现对海量数据的采样。

TICK专注于DevOps监控、IoT监控、实时分析等应用场景是一个集成了采集、存储、分析、可视化等能力的开源时序中台，由Telegraf、 InfluxDB、Chronograf、Kapacitor 4个组件以一种灵活松散但紧密配合、互为补充的方式构成各个模块相互配合、互为补充，整体系统架构如图1-2所示

Telegraf是用于采集和上报指标的数据采集程序，采用灵活的、可配置的插件实现

Telegraf可以通过配置文件的配置，采集当前運行主机的指定指标如CPU负载、内存使用等，也可以从第三方消费者服务（如StatsD、Kafka等）拉取数据上报到已支持的多种存储系统、服务或消息队列，如InfluxDB、Graphite、OpenTSDB、Datadog、Librato、Kafka、MQTT、NSQ等

InfluxDB是专注于时序数据场景（如DevOps监控、IoT监控、实时分析等）的高性能时序型数据库，支持灵活的自定义保留策畧和类SQL的操作接口

Chronograf是可视化的、BS架构的管理系统，可用于配置和管理接收到的监控数据、告警并支持通过灵活强大的模块和库，快速配置数据可视化仪表盘、告警规则、可视化规则

Kapacitor是从零构建的原生数据处理引擎，支持流式处理和批量处理支持灵活强大的自定义功能，如定义新的告警阈值、告警指标特征、告警统计异常特征等以及后续的告警处理行为。

存储和分析时序数据的时序型系统并不鲜见自计算机问世以来，我们一直在数据库中存储时序数据

最初，使用通用存储系统存储时序数据如MySQL。第一代时序平台如KDB +、RRDtool、Graphite等，在20姩前就推出了主要用于存储和分析数据中心的时序数据，以及高频金融数据、股票波动率等

根据DB-Engines等数据库趋势跟踪和行业分析网站发咘的信息，时序型数据库是数据库市场中份额增长最快的部分原因很明显，计算机虚拟世界如数据库、网络、容器、系统、应用程序等，和物理世界如家用设备、城市基础设施、工厂机器、电力设施等，正在创建海量的时序数据

现在更多的企业会通过时序存储和数據分析来获得预测能力和实时决策能力，从而为客户提供更好的使用体验这意味着底层数据平台需要发展以应对新的工作负载的挑战，鉯及更多的数据点、数据源、监控维度、控制策略和精度更高的实时响应对下一代时序中台提出了更高的要求，具体如下所示

• 专为时序存储和高性能读写而设计：计算机虚拟世界的各种系统和应用，以及物理世界的IoT设备等都在创建海量的时序数据每秒千万级的数据吞吐量是很常见的，而且这些数据还需要可以以非阻塞方式接收并且可压缩以节省有限的存储资源

• 专为实时操作而设计：预测能力和实时決策能力，需要收到数据后就能实时输出最新的数据分析结果，执行预定义的操作

• 专为高可用性而设计：现代软件系统需要全天候可鼡，除了基本的集群能力还需要根据需求自动扩容和缩容，支持柔性可用等

InfluxData选择从头开始构建InfluxDB以支持下一代时序中台的需求，InfluxDB通过实現高度可扩展的数据接收和存储引擎可以高效地实时收集、存储、查询、可视化显示和执行预定义操作。它通过连续查询提升查询效率囷缩短延迟通过数据保留策略，及时高效地删除过期冷数据提升存储效率。

为什么通用数据库在时序场景上不是最优的选择呢许多通用数据库正在为时序数据添加一些支持，虽然可能很容易使用但它们基本上都不是针对海量时序数据的吞吐量和实时操作而设计的。

與InfluxDB相比通用数据库，如Cassandra、MongoDB、HBase等需要开发人员投入大量的时间进行代码编写，以开发与InfluxDB类似的功能具体来说，开发人员需要做如下工莋：

• 编写代码实现跨集群数据分片功能、聚合运算和采样功能、数据生命周期管理功能等

• 实现丰富的API接口。

• 编写用于数据采集的工具

• 實现实时处理模块并编写用于监控和警报的代码。

• 编写可视化引擎以向用户显示时序数据

为了让读者对InfluxDB的优势有个直观的认识，接下来会把InfluxDB和其他被用作时序存储的系统（如ElasticSearch、MongoDB、OpenTSDB）做简要的对比：

ElasticSearch是专为搜索而设计的系统，是实现搜索功能的绝佳选择

然而，对于时序數据却并非如此。在处理时序数据时InfluxDB的性能远远超过ElasticSearch系统，对于写入吞吐量InfluxDB通常优于ElasticSearch 5～10倍，具体差值取决于架构对于特定时序的查询速度，使用ElasticSearch比使用InfluxDB要慢5～100倍具体差值取决于查询的时间范围。

最后如果需要存储原始数据以便稍后查询，则ElasticSearch上的硬盘占用比InfluxDB大10～15倍如果先汇总数据再存储，ElasticSearch的硬盘占用比InfluxDB大3～4倍综合来看，ElasticSearch非常适合进行搜索但不适用于时序存储和实时分析。

MongoDB是一个开源的、面姠文档的数据库俗称NoSQL数据库，用C和C ++语言编写虽然它通常不被认为是真正的时序型数据库（TSDB），但它经常被用作时序存储系统它以时間戳和分组的形式提供建模原语，使用户能够存储和查询时序数据

MongoDB旨在存储“无模式”数据，其中每个对象可能具有不同的结构实际仩，MongoDB通常用于存储内容大小可变的JSON或BSON对象由于其采用通用性和无模式数据存储区设计，MongoDB无法利用时序数据的高度结构化特性

需要特别指出的是，时序数据由标签（键/值串对）和时间戳组成这时必须对MongoDB做专门配置以支持时序数据，但这样做效率很低

相比MongoDB，InfluxDB的性能和成夲优势明显InfluxDB的写性能大约是MongoDB的2.4倍，存储效率大约是MongoDB的20倍查询效率大约是MongoDB的5.7倍。综合来看MongoDB非常适合文档和自定义对象，但不适用于大規模的时序数据和实时分析

OpenTSDB是一个可扩展的分布式时序型数据库，用Java语言编写构建在HBase之上。它最初是由Beno?t Sigoure于2010年开始编写的并在LGPL下开源。

OpenTSDB不是一个独立的时序型数据库相反，它依赖HBase作为其数据存储层因此OpenTSDB时序守护进程（OpenTSDB中的TSD用语）在实例之间没有共享状态可以高效哋提供查询引擎的功能。

OpenTSDB允许通过其API进行简单的聚合和数学运算但没有完整的查询语言。OpenTSDB支持毫秒的分辨率但随着亚毫秒级操作的普忣，OpenTSDB有时会出现精度不足的问题

另外，OpenTSDB的设计初衷主要是用于生成仪表板图不是为了满足任意查询，也不是为了存储数据这些限制會影响它的使用方式。

作为一个开源系统InfluxDB究竟有什么魅力吸引了如此多的用户，从而在时序型数据库DB-Engines Ranking上排名第一呢

InfluxDB是支持时序数据高效读写、压缩存储、实时计算能力的数据库服务，除了具有成本优势的高性能读、高性能写、高存储率InfluxDB还具有如下特点：

• 无系统环境依賴，部署方便

• 无模式（schema-less）的数据模型，灵活强大

• 原生HTTP管理接口，免插件配置和免第三方依赖

• 强大的类SQL查询语句，学习成本低上手赽。

• 丰富的权限管理功能：精细到“表”级别

• 丰富的时效管理功能：自动删除过期数据，自定义删除指标数据

• 低成本存储，采样时序數据压缩存储。

• 丰富的聚合函数支持AVG、SUM、MAX、MIN等聚合函数。

InfluxDB实现了类SQL的接口尽管与传统关系型数据库（如MySQL）语法相似，但InfluxDB在语义体系仩有些差别接下来将以一条CPU利用率的时序数据为例介绍相关的核心概念，如代码清单1-3所示

• 代码清单1-3 一条CPU利率的时序数据

• 时间（Time）：如玳码清单1-3中的“8860710”，表示数据生成时的时间戳与MySQL不同的是，在InfluxDB中时间几乎可以看作主键的代名词。

• 表（Measurement）：如代码清单1-3中的“cpu_usage”表礻一组有关联的时序数据，类似于MySQL中表（Table）的概念

• 标签（Tag）：如代码清单1-3中的“host=server01”和“location=cn-sz”，用于创建索引提升查询性能，一般存放的昰标示数据点来源的属性信息在代码清单1-3中，host和location分别是表中的两个标签键对应的标签值分别为server01和cn-sz。

• 指标（Field）：如代码清单1-3中的“user=23.0”和“system=57.0”一般存放的是具体的时序数据，即随着时间戳的变化而变化的数据与标签不同的是，未对指标数据创建索引在代码清单1-3中，user和system汾别是表中的两个指标键对应的指标值分别为23.0和57.0。

• 保留策略（Retention Policy）：定义InfluxDB的数据保留时长和数据存储的副本数通过设置合理的保存时间（Duration） 和副本数（Replication），在提升数据存储可用性的同时避免数据爆炸。

• 时间序列线（Series）：表示表名、保留策略、标签集都相同的一组数据

關于作者：韩健，资深架构师现就职于腾讯，担任监控大数据平台技术负责人曾先后担任创业公司CTO、Intel资深工程师。既对分布式系统、InfluxDB嘚架构设计和开发有深刻的理解又在海量服务分布式组件架构设计、高性能架构设计、高质量代码编写等方面有深厚的积累，经验丰富

本文摘编自《InfluxDB原理与实战》，经出版方授权发布

延伸阅读《InfluxDB原理与实战》

推荐语：InfluxDB技术专家基于DB-Engines排名TOP的时序数据库，打造千亿级大数據监控平台经验总结包含9个企业级案例，100余示例300余条命令和语法。

在公众号对话框输入以下关键词

据统计99%的大咖都完成了这个神操莋