数据库
简述NoSQL是什么?
NoSQL,指的是非关系型的数据库。NoSQL 有时也称作 Not Only SQL(意即”不仅仅是SQL”) 的缩写,其显著特点是不使用SQL作为查询语言,数据存储不需要特定的表格模式。
简述NoSQL(非关系型)数据库和SQL(关系型)数据库的区别?
NoSQL和SQL的主要区别有如下区别:
- 存储方式:
- 关系型数据库是表格式的,因此存储在表的行和列中。他们之间很容易关联协作存储,提取数据很方便。
- NoSQL数据库则与其相反,它是大块的组合在一起。通常存储在数据集中,就像文档、键值对或者图结构。
- 存储结构
- 关系型数据库对应的是结构化数据,数据表都预先定义了结构(列的定义),结构描述了数据的形式和内容。预定义结构带来了可靠性和稳定性,但是修改这些数据比较困难。
- NoSQL数据库基于动态结构,使用与非结构化数据。由于NoSQL数据库是动态结构,可以很容易适应数据类型和结构的变化。
- 存储规范
- 关系型数据库的数据存储为了更高的规范性,把数据分割为最小的关系表以避免重复,获得精简的空间利用。
- NoSQL数据存储在平面数据集中,数据经常可能会重复。单个数据库很少被分隔开,而是存储成了一个整体,这样整块数据更加便于读写 。
- 存储扩展
- 关系型数据库数据存储在关系表中,操作的性能瓶颈可能涉及到多个表,需要通过提升计算机性能来克服,因此更多是采用纵向扩展
- NoSQL数据库是横向扩展的,它的存储天然就是分布式的,可以通过给资源池添加更多的普通数据库服务器来分担负载。
- 查询方式
- 关系型数据库通过结构化查询语言来操作数据库(即通常说的SQL)。SQL支持数据库CURD操作的功能非常强大,是业界的标准用法。
- NoSQL查询以块为单元操作数据,使用的是非结构化查询语言(UnQl),它是没有标准的。
- 关系型数据库表中主键的概念对应NoSQL中存储文档的ID。
- 关系型数据库使用预定义优化方式(比如索引)来加快查询操作,而NoSQL更简单更精确的数据访问模式。
- 事务
- 关系型数据库遵循ACID规则(原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability))。
- NoSQL数据库遵循BASE原则(基本可用(Basically Availble)、软/柔性事务(Soft-state )、最终一致性(Eventual Consistency))。
- 由于关系型数据库的数据强一致性,所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制,并且易于回滚事务。
- NoSQL数据库是在CAP(一致性、可用性、分区容忍度)中任选两项,因为基于节点的分布式系统中,不可能同时全部满足,所以对事务的支持不是很好。
简述NoSQL(非关系型)数据库和SQL(关系型)数据库的各自主要代表?
SQL:MariaDB、MySQL、SQLite、SQLServer、Oracle、PostgreSQL。
NoSQL代表:Redis、MongoDB、Memcache、HBASE。
简述MongoDB及其特点?
MongoDB是一个开源的、基于分布式的、面向文档存储的非关系型数据库。是非关系型数据库当中功能最丰富、最像关系数据库的。其主要特点如下:
查询丰富
:MongoDB最大的特点是支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。面向文档
:文档就是存储在MongoDB中的一条记录,是一个由键值对组成的数据结构。模式自由
:MongoDB每一个Document都包含了元数据信息,每个文档之间不强迫要求使用相同的格式,同时他们也支持各种索引。高可用性
:MongoDB支持在复制集(Replica Set)通过异步复制达到故障转移,自动恢复,集群中主服务器崩溃停止服务和丢失数据,备份服务器通过选举获得大多数投票成为主节点,以此来实现高可用。水平拓展
:MongoDB支持分片技术,它能够支持并行处理和水平扩展。支持丰富
:MongoDB另外还提供了丰富的BSON数据类型,还有MongoDB的官方不同语言的driver支持(C/C++、C#、Java、Node.js、Perl、PHP、Python、Ruby、Scala)。
简述MongoDB的优势有哪些?
- 面向文档的存储:以 JSON 格式的文档保存数据。
- 任何属性都可以建立索引。
- 复制以及高可扩展性。
- 自动分片。
- 丰富的查询功能。
- 快速的即时更新。
简述MongoDB适应的场景和不适用的场景?
MongoDB属于典型的非关系型数据库。
- 主要适应场景
- 网站实时数据:MongoDB 非常适合实时的插入,更新与查询,并具备网站实时数据存储所需的复制及高度伸缩性。
- 数据缓存:由于性能很高,MongoDB 也适合作为信息基础设施的缓存层。在系统重启之后,由 MongoDB 搭建的持久化缓存层可以避免下层的数据源过载。
- 高伸缩性场景:MongoDB 非常适合由数十或数百台服务器组成的数据库。
- 对象或 JSON 数据存储:MongoDB 的 BSON 数据格式非常适合文档化格式的存储及查询。
- 不适应场景
- 高度事务性系统:例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
- 传统的商业智能应用:针对特定问题的 BI 数据库会对产生高度优化的查询方式。对于此类应用,数据仓库可能是更合适的选择。
- 需要复杂 SQL 查询的场景。
简述MongoDB中的库、集合、文档?
库
:MongoDB可以建立多个数据库,MongoDB默认数据库为”db”。MongoDB的单个实例可以容纳多个独立的数据库,每一个都有自己的集合和权限,不同的数据库也放置在不同的文件中。集合
:MongoDB集合就是 MongoDB 文档组,类似于 RDBMS (关系数据库中的表格)。集合存在于数据库中,集合没有固定的结构。文档
:MongoDB的Document是一组键值(key-value)对(即 BSON),相当于关系型数据库的行。且不需要设置相同的字段,并且相同的字段不需要相同的数据类型。
简述MongoDB支持的常见数据类型?
MongoDB支持丰富的数据类型,常见的有:
- String:字符串。存储数据常用的数据类型。
- Integer:整型数值。用于存储数值。
- Boolean:布尔值。用于存储布尔值(真/假)。
- Array:用于将数组或列表或多个值存储为一个键。
- Date:日期时间。用 UNIX 时间格式来存储当前日期或时间。
- Binary Data:二进制数据。用于存储二进制数据。
- Code:代码类型。用于在文档中存储 JavaScript 代码。
- Regular expression:正则表达式类型。用于存储正则表达式。
简述MongoDB索引及其作用?
索引通常能够极大的提高查询的效率,如果没有索引,MongoDB在读取数据时必须扫描集合中的每个文件并选取那些符合查询条件的记录。
这种扫描全集合的查询效率是非常低的,特别在处理大量的数据时,查询可能要花费几十秒甚至几分钟,这对网站的性能是非常致命的。
索引是特殊的数据结构,索引存储在一个易于遍历读取的数据集合中,索引是对数据库表中一列或多列的值进行排序的一种结构。
简述MongoDB常见的索引有哪些?
MongoDB常见的索引有:
- 单字段索引(Single Field Indexes)
- 符合索引(Compound Indexes)
- 多键索引(Multikey Indexes)
- 全文索引(Text Indexes)
- Hash索引(Hash Indexes)
- 通配符索引(Wildcard Indexes)
简述MongoDB复制(本)集原理?
mongodb的复制至少需要两个节点。其中一个是主节点,负责处理客户端请求,其余的都是从节点,负责复制主节点上的数据。
mongodb各个节点常见的搭配方式为:一主一从、一主多从。
主节点记录在其上的所有操作oplog,从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作,从而保证从节点的数据与主节点一致。
简述MongoDB的复制过程?
Primary节点写入数据,Secondary通过读取Primary的oplog(即Primary的oplog.rs表)得到复制信息,开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败,则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了,当重新启动后,就会自动从oplog的最后一个操作开始同步。同步完成后,将信息写入自己的oplog,由于复制操作是先复制数据,复制完成后再写入oplog,有可能相同的操作会同步两份,MongoDB设定将oplog的同一个操作执行多次,与执行一次的效果是一样的。
当Primary节点完成数据操作后,Secondary的数据同步过程如下:
- 1、检查自己local库的oplog.rs集合找出最近的时间戳。
- 2、检查Primary节点local库oplog.rs集合,找出大于此时间戳的记录。
- 3、将找到的记录插入到自己的oplog.rs集合中,并执行这些操作。
简述MongoDB副本集及其特点?
MongoDB副本集是一组Mongod维护相同数据集的实例,副本集可以包含多个数据承载点和多个仲裁点。在承载数据的节点中,仅有一个节点被视为主节点,其他节点称为次节点。
主要特点:
- N 个节点的集群,任何节点可作为主节点,由选举产生;
- 最小构成是:primary,secondary,arbiter,一般部署是:primary,2 secondary。
- 所有写入操作都在主节点上,同时具有自动故障转移,自动恢复;
- 成员数应该为奇数,如果为偶数的情况下添加arbiter,arbiter不保存数据,只投票。
简述MongoDB有哪些特殊成员?
MongoDB中Secondary角色存在一些特殊的成员类型:
- Priority 0(优先级0型):不能升为主,可以用于多数据中心场景;
- Hidden(隐藏型):对客户端来说是不可见的,一般用作备份或统计报告用;
- Delayed(延迟型):数据比副集晚,一般用作 rolling backup 或历史快照。
- Vote(投票型):仅参与投票。
简述MongoDB分片集群?
MongoDB分片集群(Sharded Cluster):主要利用分片技术,使数据分散存储到多个分片(Shard)上,来实现高可扩展性。
分片是将数据水平切分到不同的物理节点。当数据量越来越大时,单台机器有可能无法存储数据或读取写入吞吐量有所降低,利用分片技术可以添加更多的机器来应对数据量增加以及读写操作的要求。
简述MongoDB分片集群相对副本集的优势?
MongoDB分片集群主要可以解决副本集如下的不足:
- 副本集所有的写入操作都位于主节点;
- 延迟的敏感数据会在主节点查询;
- 单个副本集限制在12个节点;
- 当请求量巨大时会出现内存不足;
- 本地磁盘不足;
- 垂直扩展价格昂贵。
简述MongoDB分片集群的优势?
MongoDB分片集群主要有如下优势:
- 使用分片减少了每个分片需要处理的请求数:通过水平扩展,群集可以提高自己的存储容量。比如,当插入一条数据时,应用只需要访问存储这条数据的分片。
- 使用分片减少了每个分片存储的数据:分片的优势在于提供类似线性增长的架构,提高数据可用性,提高大型数据库查询服务器的性能。当MongoDB单点数据库服务器存储成为瓶颈、单点数据库服务器的性能成为瓶颈或需要部署大型应用以充分利用内存时,可以使用分片技术。
简述MongoDB分片集群的架构组件?
MongoDB架构组件主要有:
- Shard:用于存储实际的数据块,实际生产环境中一个shard server角色可由几台机器组成一个replica set承担,防止主机单点故障。
- Config Server:mongod实例,存储了整个 ClusterMetadata,其中包括 chunk信息。
- Query Routers:前端路由,客户端由此接入,且让整个集群看上去像单一数据库,前端应用可以透明使用。
简述MongoDB分片集群和副本集群的区别?
副本集不是为了提高读性能存在的,在进行oplog的时候,读操作是被阻塞的;
提高读取性能应该使用分片和索引,它的存在更多是作为数据冗余,备份。
简述MongoDB的几种分片策略及其相互之间的差异?
MongoDB的数据划分是基于集合级别为标准,通过shard key来划分集合数据。主要分片策略有如下三种:
- 范围划分:通过shard key值将数据集划分到不同的范围就称为基于范围划分。对于数值型的shard key:可以虚构一条从负无穷到正无穷的直线(理解为x轴),每个shard key 值都落在这条直线的某个点上,然后MongoDB把这条线划分为许多更小的没有重复的范围成为块(chunks),一个chunk就是某些最小值到最大值的范围。
- 散列划分:MongoDB计算每个字段的hash值,然后用这些hash值建立chunks。基于散列值的数据分布有助于更均匀的数据分布,尤其是在shard key单调变化的数据集中。
- 自定义标签划分:MongoDB支持通过自定义标签标记分片的方式直接平衡数据分布策略,可以创建标签并且将它们与shard key值的范围进行关联,然后分配这些标签到各个分片上,最终平衡器转移带有标签标记的数据到对应的分片上,确保集群总是按标签描述的那样进行数据分布。标签是控制平衡器行为及集群中块分布的主要方法。
差异
:
- 基于范围划分对于范围查询比较高效。假设在shard key上进行范围查询,查询路由很容易能够知道哪些块与这个范围重叠,然后把相关查询按照这个路线发送到仅仅包含这些chunks的分片。
- 基于范围划分很容易导致数据不均匀分布,这样会削弱分片集群的功能。
- 基于散列划分是以牺牲高效范围查询为代价,它能够均匀的分布数据,散列值能够保证数据随机分布到各个分片上。
简述MongoDB分片集群采取什么方式确保数据分布的平衡?
新加入的数据及服务器都会导致集群数据分布不平衡,MongoDB采用两种方式确保数据分布的平衡:
拆分
拆分是一个后台进程,防止块变得太大。当一个块增长到指定块大小的时候,拆分进程就会块一分为二,整个拆分过程是高效的。不会涉及到数据的迁移等操作。
平衡
平衡器是一个后台进程,管理块的迁移。平衡器能够运行在集群任何的mongd实例上。当集群中数据分布不均匀时,平衡器就会将某个分片中比较多的块迁移到拥有块较少的分片中,直到数据分片平衡为止。
分片采用后台操作的方式管理着源分片和目标分片之间块的迁移。在迁移的过程中,源分片中的块会将所有文档发送到目标分片中,然后目标分片会获取并应用这些变化。最后,更新配置服务器上关于块位置元数据。
简述MongoDB备份及恢复方式?
mongodb备份恢复方式通常有以下三种:
文件快照方式
:此方式相对简单,需要系统文件支持快照和mongod必须启用journal。可以在任何时刻创建快照。恢复时,确保没有运行mongod,执行快照恢复操作命令,然后启动mongod进程,mongod将重放journal日志。复制数据文件方式
:直接拷贝数据目录下的一切文件,但是在拷贝过程中必须阻止数据文件发生更改。因此需要对数据库加锁,以防止数据写入。恢复时,确保mongod没有运行,清空数据目录,将备份的数据拷贝到数据目录下,然后启动mongod。使用mongodump和mongorestore方式
:在Mongodb中我们使用mongodump命令来备份MongoDB数据。该命令可以导出所有数据到指定目录中。恢复时,使用mongorestore命令来恢复MongoDB数据。该命令可以从指定目录恢复相应数据。
简述MongoDB的聚合操作?
聚合操作能够处理数据记录并返回计算结果。聚合操作能将多个文档中的值组合起来,对成组数据执行各种操作,返回单一的结果。它相当于 SQL 中的 count(*) 组合 group by。对于 MongoDB 中的聚合操作,应该使用aggregate()方法。
简述MongoDB中的GridFS机制?
GridFS是一种将大型文件存储在MongoDB中的文件规范。使用GridFS可以将大文件分隔成多个小文档存放,这样我们能够有效的保存大文档,而且解决了BSON对象有限制的问题。
简述MongoDB针对查询优化的措施?
MongoDB查询优化大致可能从如下步骤着手:
第一步:找出慢速查询
如下方式开启内置的查询分析器,记录读写操作效率:
db.setProfilingLevel(n,{m}),n的取值可选0,1,2;
- 0:默认值,表示不记录;
- 1:表示记录慢速操作,如果值为1,m必须赋值单位为ms,用于定义慢速查询时间的阈值;
2:表示记录所有的读写操作。
查询监控结果:监控结果保存在一个特殊的集合system.profile里。
第二步:分析慢速查询
找出慢速查询的原因,通常可能的原因有:应用程序设计不合理、不正确的数据模型、硬件配置问题、缺少索引等
第三部:根据不同的分析结果进行优化,如建立索引。
简述MongoDB的更新操作是否会立刻fsync到磁盘?
不会,磁盘写操作默认是延时执行的,写操作可能在两三秒(默认在60秒内)后到达磁盘,可通过syncPeriodSecs参数进行配置。
简述MySQL索引及其作用?
是数据库管理系统中一个排序的数据结构,根据不同的存储引擎索引分为Hash索引、B+树索引等。常见的InnoDB存储引擎的默认索引实现为:B+树索引。
索引可以协助快速查询、更新数据库表中数据。
简述MySQL中什么是事务?
事务是一系列的操作,需要要符合ACID特性,即:事务中的操作要么全部成功,要么全部失败。
简述MySQL事务之间的隔离?
MySQL事务支持如下四种隔离:
未提交读
(Read Uncommitted):允许脏读,其他事务只要修改了数据,即使未提交,本事务也能看到修改后的数据值。也就是可能读取到其他会话中未提交事务修改的数据。提交读
(Read Committed):只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。可重复读
(Repeated Read):可重复读。无论其他事务是否修改并提交了数据,在这个事务中看到的数据值始终不受其他事务影响。串行读
(Serializable):完全串行化的读,每次读都需要获得表级共享锁,读写相互都会阻塞。
简述MySQL锁及其作用?
锁机制是为了避免,在数据库有并发事务的时候,可能会产生数据的不一致而诞生的的一个机制。锁从类别上分为:
共享锁
:又叫做读锁,当用户要进行数据的读取时,对数据加上共享锁,共享锁可以同时加上多个。排他锁
:又叫做写锁,当用户要进行数据的写入时,对数据加上排他锁,排他锁只可以加一个,他和其他的排他锁,共享锁都相斥。
简述MySQL表中为什么建议添加主键?
主键是数据库确保数据行在整张表唯一性的保障,即使数据库中表没有主键,也建议添加一个自增长的ID列作为主键,设定了主键之后,在后续的删改查的时候可能更加快速以及确保操作数据范围安全。
简述MySQL所支持的存储引擎?
MySQL支持多种存储引擎,常见的有InnoDB、MyISAM、Memory、Archive等。通常使用InnoDB引擎都是最合适的,InnoDB也是MySQL的默认存储引擎。
简述MySQL InnoDB引擎和MyISAM引擎的差异?
- InnoDB支持事物,而MyISAM不支持事物。
- InnoDB支持行级锁,而MyISAM支持表级锁。
- InnoDB支持MVCC, 而MyISAM不支持。
- InnoDB支持外键,而MyISAM不支持。
- InnoDB不支持全文索引,而MyISAM支持。
简述MySQL主从复制过程?
- 1、Slave上面的IO线程连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
- 2、Master接收到来自Slave的IO线程的请求后,通过负责复制的IO线程根据请求信息读取指定日志指定位置之后的日志信息,返回给Slave端的IO线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在Master端binary log文件的名称以及在Binary log中的位置;
- 3、Slave的IO线程收到信息后,将接收到的日志内容依次写入到Slave端的RelayLog文件(mysql-relay-lin.xxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中,以便在下一次读取的时候能够明确知道从什么位置开始读取日志;
- 4、Slave的SQL线程检测到Relay Log中新增加了内容后,会马上解析该Log文件中的内容成为在Master端真实执行时候的那些可执行的查询或操作语句,并在自身执行那些查询或操作语句,这样,实际上就是在master端和Slave端执行了同样的查询或操作语句,所以两端的数据是完全一样的。
简述MySQL常见的读写分离方案?
MySQL+Amoeba读写分离方案:Amoeba(变形虫)项目,这个工具致力于MySQL的分布式数据库前端代理层,它主要在应用层访问MySQL的时候充当SQL路由功能。具有负载均衡、高可用性、SQL 过滤、读写分离、可路由相关的到目标数据库、可并发请求多台数据库合并结果。通过Amoeba你能够完成多数据源的高可用、负载均衡、数据切片、读写分离的功能。
MySQL+MMM读写分离方案:MMM即Multi-Master Replication Manager for MySQL,mysql多主复制管理器是关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入)。MMM也能对从服务器进行读负载均衡,通过MMM方案能实现服务器的故障转移,从而实现mysql的高可用。MMM不仅能提供浮动IP的功能,如果当前的主服务器挂掉后,会将你后端的从服务器自动转向新的主服务器进行同步复制,不用手工更改同步配置。
简述MySQL常见的高可用方案?
MySQL主从复制
:Mysql内建的复制功能是构建大型,高性能应用程序的基础。将Mysql的数据分布在多个节点(slaves)之上,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。MySQL双主
:参考MySQL主从复制。MySQL双主多从
:参考MySQL主从复制。MySQL复制+Keepalived高可用
:MySQL自身的复制,对外基于Keepalived技术,暴露一个VIP,从而实现高可用。Heartbeat + MySQL 实现MySQL的高可用
:通过Heartbeat的心跳检测和资源接管、集群中服务的监测、失效切换等功能,结合MySQL来实现高可用性。
简述MySQL常见的优化措施?
MySQL可通过如下方式优化:
- 1、开启查询缓存,优化查询。
- 2、使用explain判断select查询,从而分析查询语句或是表结构的性能瓶颈,然后有针对性的进行优化。
- 3、为搜索字段建索引
- 4、对于有限定范围取值的字段,推荐使用 ENUM 而不是 VARCHAR。
- 5、垂直分表。
- 6、选择正确的存储引擎。
简述MySQL常见备份方式和工具?
MySQL自带
mysqldump:mysqldump支持基于innodb的热备份,使用mysqldump完全备份+二进制日志可以实现基于时间点的恢复,通常适合备份数据比较小的场景 。
系统层面
tar备份:可以使用tar之类的系统命令对整个数据库目录进行打包备份。
lvm快照备份:可基于文件系统的LVM制作快照,进行对整个数据库目录所在的逻辑卷备份。
第三方备份工具
可使用其他第三方工具进行备份,如xtrabackup工具,该工具支持innodb的物理热备份,支持完全备份、增量备份,而且速度非常快,支持innodb存储引起的数据在不同数据库之间迁移,支持复制模式下的从机备份恢复备份恢复。
监控
简述常见的监控软件?
常见的监控软件有:
Cacti
:是一套基于PHP、MySQL、SNMP及RRDTool开发的网络流量监测图形分析工具。Zabbix
:Zabbix是一个企业级的高度集成开源监控软件,提供分布式监控解决方案。可以用来监控设备、服务等可用性和性能。Open-falcon
:open-falcon是一款用golang和python写的监控系统,由小米启动这个项目。Prometheus
:Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发,是Google BorgMon监控系统的开源版本。
简述Prometheus及其主要特性?
Prometheus是一个已加入CNCF的开源监控报警系统和时序列数据库项目,通过不同的组件完成数据的采集,数据的存储和告警。
Prometheus主要特性:
- 多维数据模型
- 时间序列数据通过 metric 名和键值对来区分。
- 所有的 metrics 都可以设置任意的多维标签。
- 数据模型更随意,不需要刻意设置为以点分隔的字符串。
- 可以对数据模型进行聚合,切割和切片操作。
- 支持双精度浮点类型,标签可以设为全 unicode。
- 灵活的查询语句(PromQL),可以利用多维数据完成复杂的查询
- Prometheus server 是一个单独的二进制文件,不依赖(任何分布式)存储,支持 local 和 remote 不同模型
- 采用 http 协议,使用 pull 模式,拉取数据,或者通过中间网关推送方式采集数据
- 监控目标,可以采用服务发现或静态配置的方式
- 支持多种统计数据模型,图形化友好
- 高效:一个 Prometheus server 可以处理数百万的 metrics
- 适用于以机器为中心的监控以及高度动态面向服务架构的监控
简述Prometheus主要组件及其功能?
Prometheus 的主要模块包含:prometheus server, exporters, push gateway, PromQL, Alertmanager, WebUI 等。
- 1、
prometheus server
:定期从静态配置的 targets 或者服务发现(主要是DNS、consul、k8s、mesos等)的 targets 拉取数据,用于收集和存储时间序列数据。 - 2、
exporters
:负责向prometheus server做数据汇报,暴露一个http服务的接口给Prometheus server定时抓取。而不同的数据汇报由不同的exporters实现,比如监控主机有node-exporters,mysql有MySQL server exporter。 - 3、
push gateway
:主要使用场景为,当Prometheus 采用 pull 模式,可能由于不在一个子网或者防火墙原因,导致 Prometheus 无法直接拉取各个 target 数据。此时需要push gateway接入,以便于在监控业务数据的时候,将不同数据汇总, 由 Prometheus 统一收集。实现机制类似于zabbix-proxy功能。 - 4、
Alertmanager
:从 Prometheus server 端接收到 alerts 后,会进行去除重复数据,分组,并路由到对收的接受方式,发出报警,即主要实现prometheus的告警功能。AlertManager的整体工作流程如下图所示: - 5、
webui
:Prometheus内置一个简单的Web控制台,可以查询指标,查看配置信息或者Service Discovery等,实践中通常结合Grafana,Prometheus仅作为Grafana的数据源。
简述Prometheus的机制?
Prometheus简单机制如下:
- Prometheus以其Server为核心,用于收集和存储时间序列数据。Prometheus Server 从监控目标中拉取数据,或通过push gateway间接的把监控目标的监控数据存储到本地HDD/SSD中。
- 用户接口界面通过各种UI使用PromQL查询语言从Server获取数据。
- 一旦Server检测到异常,会推送告警到AlertManager,由告警管理负责去通知相关方。
简述Prometheus中什么是时序数据?
Prometheus 存储的是时序数据,,时序数据是指按照相同时序(相同的名字和标签),以时间维度存储连续的数据的集合。时序(time series) 是由名字(Metric),以及一组 key/value 标签定义的,具有相同的名字以及标签属于相同时序。
简述Prometheus时序数据有哪些类型?
Prometheus 时序数据分为 Counter, Gauge, Histogram, Summary 四种类型。
Counter
:计数器表示收集的数据是按照某个趋势(增加/减少)一直变化的,通常用它记录服务请求总量,错误总数等。Gauge
:计量器表示搜集的数据是一个瞬时的,与时间没有关系,可以任意变高变低,往往可以用来记录内存使用率、磁盘使用率等。Histogram
:直方图 Histogram 主要用于对一段时间范围内的数据进行采样,(通常是请求持续时间或响应大小),并能够对其指定区间以及总数进行统计,通常我们用它计算分位数的直方图。Summary
:汇总Summary 和 直方图Histogram 类似,主要用于表示一段时间内数据采样结果,(通常是请求持续时间或响应大小),它直接存储了 quantile 数据,而不是根据统计区间计算出来的。
简述Zabbix及其优势?
Zabbix是一个企业级的高度集成开源监控软件,提供分布式监控解决方案。可以用来监控设备、服务等可用性和性能。其主要优势有:
- 自由开放源代码产品,可以对其进行任意修改和二次开发,采用GPL协议;
- 安装和配置简单;
- 搭建环境简单,基于开源软件构建平台;
- 完全支持Linux、Unix、Windows、AIX、BSD等平台,采用C语言编码,系统占用小,数据采集性能和速度非常快;
- 数据采集持久存储到数据库,便于对监控数据的二次分析;
- 非常丰富的扩展能力,轻松实现自定义监控项和实现数据采集。
简述Zabbix体系架构?
Zabbix体系相对清晰,其主要组件有:
Zabbix Server
:负责接收agent发送的报告信息的核心组件,所有配置、统计数据及操作数据均由其组织进行。Database Storage
:专用于存储所有配置信息,以及有zabbix收集的数据。Web interface
(frontend):zabbix的GUI接口,通常与server运行在同一台机器上。Proxy
:可选组件,常用于分布式监控环境中,代理Server收集部分被监控数据并统一发往Server端。Agent
:部署在被监控主机上,负责收集本地数据并发往Server端或者Proxy端。
简述Zabbix所支持的监控方式?
目前由zabbix提供包括但不限于以下事项类型的支持:
Zabbix agent checks
:这些客户端来进行数据采集,又分为Zabbix agent(被动模式:客户端等着服务器端来要数据),Zabbix agent (active)(主动模式:客户端主动发送数据到服务器端)SNMP agent checks
:SNMP方式,如果要监控打印机网络设备等支持SNMP设备的话,但是又不能安装agent的设备。SNMP traps
:IPMI checks
:IPMI即智能平台管理接口,现在是业界通过的标准。用户可以利用IPMI监视服务器的物理特性,如温度、电压、电扇工作状态、电源供应以及机箱入侵等。
简述Zabbix分布式及其适应场景?
zabbix proxy 可以代替 zabbix server 收集性能和可用性数据,然后把数据汇报给 zabbix server,并且在一定程度上分担了zabbix server 的压力。
此外,当所有agents和proxy报告给一个Zabbix server并且所有数据都集中收集时,使用proxy是实现集中式和分布式监控的最简单方法。
zabbix proxy 使用场景:
- 监控远程区域设备
- 监控本地网络不稳定区域
- 当 zabbix 监控上千设备时,使用它来减轻 server 的压力
- 简化分布式监控的维护
网络管理
简述什么是CDN?
CDN即内容分发网络,是在现有网络中增加一层新的网络架构,从而实现将源站内容发布和传送到最靠近用户的边缘地区,使用户可以就近访问想要的内容,提高用户访问的响应速度。
---本文结束感谢您的阅读。微信扫描二维码,关注我的公众号---
本文链接: https://www.yp14.cn/2020/08/11/IT运维面试问题总结-数据库-监控-网络管理/
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!