ToB企服应用市场:ToB评测及商务社交产业平台
标题:
【后端口试题】【中心件】【NoSQL】MongoDB的配置服务器、复制机制、写入语
[打印本页]
作者:
九天猎人
时间:
2024-7-23 19:15
标题:
【后端口试题】【中心件】【NoSQL】MongoDB的配置服务器、复制机制、写入语
MongoDB的配置服务器
引入了分片机制之后,MongoDB启用了
配置服务器
(config server) 来存储元数据,这些元数据包罗
分片信息、权限控制信息
,用来控制分布式锁。其中分片信息还会被负责实行查询mongos使用。
MongoDB的配置服务器有一个很大的优点,就是
主节点崩溃了,它也可以继续提供读服务
。
大多数中心件的主从布局都是在主节点崩溃之后完全不可用,直到推举出了一个新的主节点。
但是不管怎么说,配置服务器在MongoDB里是一个非常关键的组件,如果一旦配置服务器有问题,哪怕只是稍微地性能抖动一下,对整个MongoDB集群的影响都很大。
MongoDB的复制机制(主从机制)
MongoDB的副本也是MongoDB实例,它们和主实例持有一样的数据。在MongoDB里,用Primary来代表主实例,用Secondary来代表副本实例。主从实例合并在一起,也叫做一个复制集(Replica Set)
类似于数据库的读写分离机制,可以在MongoDB上举行读写分离。读从Secondary0实例读,写入Primary实例,同时Secondary0和Secondary1从Primary实例里同步数据
在MongoDB里,主从之间的数据同步是通过所谓的oplog来实现的,类似MySQL的binlog。但是oplog会有一些缺点:
在一些特定的操纵里,oplog大概会超乎想象地大。这主要是由于oplog是幂等的,所以
任何操纵都比要转化为幂等操纵
。简朴来说,任何对MongoDB里数据的操纵,
末了都会被转化成一个set操纵
。所以可以预计的是,就是只更新了数据的一小部门,但是生成的oplpg照旧set整个数据。
oplog是
有期限
的,即MongoDB
限制了oplog的大小
。当oplog占据了太多的磁盘之后,就会被删除。就算某个从节点来不及同步,oplog也是会被删除的。这个时候,这个从节点
只能重新发起一次全量的数据同步
。
写入语义
和Kafka的写入语义非常像,可以通过参数来控制写入数据毕竟写到哪里,写入语义对
性能、可用性和数据可靠性
有明显的影响。
在MongoDB里,写入语义也叫Write Concern,它由w、j和wtimeout三个参数控制。
w参数
它的取值如下:
majority:要求写操纵已经同步给大部门节点,默认取值,可用性强,但是写入性能差
数字N:如果N=1,要求必须写入主节点;如果N大于1,那么就必须写入主节点,而且写入N-1个从节点;如果N=0,那么就不消等任何节点写入。性能很好,但是固然客户端收到了乐成的相应,数据也有大概丢失。
自定义写入节点策略:可以给一些节点打上标签,然后要求写入的时候肯定要写入带有这些标签的节点,实践中用的较少
j参数
控制数据有没有被写到磁盘上,对于j来说它的取值就是true或false
wtimeout参数
写入的超时时间,只会在w>1的时候见效。
在超时之后MongoDB就直接返回一个错误,但是这种环境下,MongoDB大概照旧写入数据乐成了
口试预备
负责的业务或公司有没有使用MongoDB,主要用来做什么
为什么要用MongoDB,用MySQL可以吗
用MongoDB的时候,文档支持分片吗?如果支持的话,按什么来分片的?
业务有多少数据量,并发有多高?
MongoDB怎么摆设的,主从节点有多少?有没有多数据中央的摆设方案?
MongoDB的写入语义,即w和j这两个参数的取值
口试话题引导
Kafka的acks机制,可以引申到MongoDB的写入语义上
其他中心件的对等布局,或主从布局,可以引导到MongoDB的分片和主从机制上
Kafka的元数据,可以联合MongoDB的元数据一起回答
MongoDB数据不丢失的问题,可以联合写入语义来回答,参考Kafka分析的思绪。
在整个MongoDB的口试过程中,注意和不同的中心件举行对比,凸显在这方面的积聚
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)
Powered by Discuz! X3.4