@yangwenbo
2023-07-20T10:47:32.000000Z
字数 2734
阅读 160
面试笔记(技术)
- 首先服务端启动RPC服务,默认监听端口号:111
- 其次服务端启动NFS服务,并向RPC注册端口信息
- 客户端启动RPC服务,然后向服务端的RPC服务发送请求,索要NFS服务的端口号
- 服务端的RPC把NFS的端口号告诉客户端的RPC ,同时进行标记
- 客户端通过获得的端口号与NFS服务端进行连接
准备工作:
- Master(主库):
- 开启binlog日志log-bin=mysql-bin
- 创建主从复制账号及密码
- 在主库的MySQL配置文件/etc/my.cnf中的[mysqld]模块中设置
Server-id = 1- Slave(从库):
- 关闭binlog日志,开启中继日志relay-log = relay-bin
- 告诉从库:主库IP地址和端口号、主从复制账号及密码、当前binlog日志名及在当前binlog日志中所处的位置
- 在从库的MySQL配置文件/etc/my.cnf中的[mysqld]模块中设置
Server-id = n (注:n不为1)- 开启从库start slave
原理:
- 在Slave服务器上执行start slave命令开启主从复制开关,开始进行主从复制
- 此时,Slave服务器的I/O线程会通过在Master上已经授权的复制用户权限请求连接Master服务器,并请求从指定binlog日志文件的指定位置(日志文件名和位置就是在配置主从复制服务时执行change master命令指定的)之后开始发送binlog日志内容。
- Master服务器接收到来自Slave服务器的I/O线程的请求后,其上负责复制的I/O线程会根据Slave服务器的I/O线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息,然后返回给Slave端的I/O线程。返回的信息中除了binlog日志内容外,还有在Master服务器端记录的新的binlog文件名称,以及在新的binlog中的下一个指定更新位置。
- 当Slave服务器的I/O线程获取到Master服务器上I/O线程发送的日志内容,日志文件及位置点后,会将binlog日志内容依次写到Slave端自身的Relay Log(即中继日志)文件(MySQL-relay-bin.xxxx)的最末端,并将新的binlog文件名和位置记录到master-info文件中,以便下一次读取Master端新binlog日志时能够告诉Master服务器从新binlog日志的指定文件及位置开始请求新的binlog日志内容。
- Slave服务器端的SQL线程会实时检测本地Relay Log中I/O线程新增加的日志内容,然后及时地把Relay Log文件中的内容解析成SQL语句,并在自身Slave服务器上按解析SQL语句的位置顺序执行应用这些SQL语句,并在relay-log.info中记录当前应用中继日志的文件名及位置点。
MHA由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以独立部署在一台独立的机器上管理多个Master-Slave集群,也可以部署在一台Slave上。把主库master的binlog日志复制,当Master出现故障时,系统会找出relay-log日志最全的从库slave,然后将其relay-log同步到其它从库,提升此从库slave为新的主库,并让所有其余的从库重新指向新的主库,同时把复制出来的binlog日志放到新的主库中。
- 浏览器输入域名
- DNS进行域名解析,解析出IP地址
- 浏览器发起一个http协议请求
- web响应用户发的请求,发了一个响应包
- 用户浏览器解析http协议的响应包,出现了网站的具体内容
- 用户通过浏览器输入域名请求Nginx Web服务,如果请求是静态资源,则由Nginx解析返回给用户;
- 如果是动态请求(.php结尾),那么Nginx就会把它通过FastCGI接口发送给PHP引擎服务(FastCGI进程php-fpm)进行解析;
- 如果这个动态请求要读取数据库数据,那么PHP就会继续向后请求MySQL数据库,以读取需要的数据,并最终通过Nginx服务把获取的数据返回给用户。
- 用户请求找到网关的公网IP,网关把请求数据包作DNAT地址转换成VIP;
- 网关通过ARP协议获取到LVS负载均衡器的MAC地址,把请求数据包转发到LVS负载均衡器上;
- 负载均衡服务器LVS根据调度算法选出一台RS服务器,通过ARP协议获取RS服务器的MAC地址,并将数据包发送给RS服务器。
- 需要在RS服务器的lo网卡上绑定VIP,同时抑制RS服务器对VIP做出ARP响应。
- RS服务器将用户的请求数据包处理后,把处理结果直接发给网关;
- 由网关返还数据包给用户
- Keepalived高可用服务之间的故障切换转移,是通过VRRP协议来实现的。
- 在Keepalived服务正常工作时,主Master节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备Backup节点自己还活着,当主Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主Master节点的心跳了,于是调用自身的接管程序,接管主Master节点的IP资源及服务。而当主Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的IP资源及服务,恢复到原来的备用角色。
- 备节点可以有多个,通过优先级竞选,但一般Keepalived系统运维工作中都是一对。
squid 作为反向代理服务器,通常工作在一个服务器集群的前端,在用户端看来,squid 服务器就是他说要访问的服务器,而实际意义上 squid 只是接受用户的请求,同时将用过户请求转发给内网真正的WEB服务器,如果 squid 本身有用户要访问的内容,则 squid 直接将数据返回给用户,起到了缓存数据的作用,减少了后端服务的压力
- Logstash 主要是用来日志的搜集、分析、过滤日志的工具,支持大量的数据获取方式,client端安装在需要收集日志的主机上,server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
- Kibana 也是一个开源和免费的工具,Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助汇总、分析和搜索重要数据日志。
- Elasticsearch是个开源分布式搜索引擎,提供搜集、分析、存储数据三大功能。