集群、分布式、SOA、微服务的概念及区别
集群:不同服务器部署同一套应用服务对外提供访问,实现服务的负载均衡或者互备(热备,主从等),指同一种组件的多个实例,形成的逻辑上的整体。单个节点可以提供完整服务。集群是物理形态
分布式:服务的不同模块部署在不同的服务器上,单个节点不能提供完整服务,需要多节点协调提供服务(也可以是相同组件部署在不同节点、但节点间通过交换信息协作提供服务),分布式强调的是工作方式
SOA:面向服务的架构,一种设计方法,其中包含多个服务, 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。
中心化实现:ESB(企业服务总线),各服务通过ESB进行交互,解决异构系统之间的连通性,通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。很重,有一定的逻辑,可以解决一些公用逻辑的问题。
去中心化实现:微服务
微服务:在 SOA 上做的升华,微服务架构强调的一个重点是业务需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成
服务单一职责
轻量级通信:去掉ESB总线,采用restapi通信
简述Base理论
cap理论的一种妥协,由于cap只能二取其一,base理论降低了发生分区容错时对可用性和一致性的要求
1、基本可用:允许可用性降低(可能响应延长、可能服务降级),
2、软状态:指允许系统中的数据存在中间状态,并认为该中间状态不会影响系统整体可用性。
2、最终一致性:节点数据同步可以存在时延),但在一定的期限后必须达成数据的一致,状态变为最终状态
选举算法Quorum 机制、WARO
waro:一种简单的副本控制协议,写操作时、只有当所有的副本都更新成功之后,这次写操作才算成功,否则视为失败。优先保证读、任何节点读到的数据都是最新数据,牺牲了更新服务的可用性、只要有一个副本宕机了,写服务就不会成功。但只要有一个节点存活、仍能提供读服务
Quorum 机制:10个副本,一次成功更新了三个,那么至少需要读取八个副本的数据,可以保证读到了最新的数据。无法保证强一致性,也就是无法实现任何时刻任何用户或节点都可以读到最近一次成功提交的副本数据。需要配合一个获取最新成功提交的版本号的 metadata 服务,这样可以确定最新已经成功提交的版本号,然后从已经读到的数据中就可以确认最新写入的数据
分布式系统的设计目标
可扩展性:通过对服务、存储的扩展,来提高系统的处理能力,通过对多台服务器协同工作,来完成单台服务器无法处理的任务,尤其是高并发或者大数据量的任务。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫:1253431195(里面有大量的面试题及答案)里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多
高可用:单点不影响整体,单点故障指系统中某个组件一旦失效,会让整个系统无法工作
无状态:无状态的服务才能满足部分机器宕机不影响全部,可以随时进行扩展的需求。
可管理:便于运维,出问题能不能及时发现定位
高可靠:同样的请求返回同样的数据;更新能够持久化;数据不会丢失
简述redis数据结构
String:字符串
List:列表
Hash:哈希表
Set:无序集合
Sorted Set:有序集合
bitmap:布隆过滤器
GeoHash:坐标,借助Sorted Set实现,通过zset的score进行排序就可以得到坐标附近的其它元素,通过将score还原成坐标值就可以得到元素的原始坐标
HyperLogLog:统计不重复数据,用于大数据基数统计
Streams:内存版的kafka
数据库实现分布式锁的问题及解决方案
利用唯一约束键存储key,insert成功则代表获取锁成功,失败则获取失败,操作完成需要删除锁
问题:
非阻塞,锁获取失败后没有排队机制,需要自己编码实现阻塞,可以使用自旋,直到获取锁
不可重入,如果加锁的方法需要递归,则第二次插入会失败,可以使用记录线程标识解决重入问题
死锁,删除锁失败、则其他线程没办法获取锁,可以设置超时时间、使用定时任务检查
数据库单点故障,数据库高可用
Kafka、ActiveMQ、RabbitMQ、RocketMQ 对比
ActiveMQ:JMS规范,支持事务、支持XA协议,没有生产大规模支撑场景、官方维护越来越少
RabbitMQ:erlang语言开发、性能好、高并发,支持多种语言,社区、文档方面有优势,erlang语言
不利于java程序员二次开发,依赖开源社区的维护和升级,需要学习AMQP协议、学习成本相对较高
以上吞吐量单机都在万级
kafka:高性能,高可用,生产环境有大规模使用场景,单机容量有限(超过64个分区响应明显变长)、社区更新慢吞吐量单机百万
rocketmq:java实现,方便二次开发、设计参考了kafka,高可用、高可靠,社区活跃度一般、支持语言较少吞吐量单机十万
rabbitmq的持久化机制
1、交换机持久化:exchange_declare创建交互机时通过参数指定
2、队列持久化:queue_declare创建队列时通过参数指定
3、消息持久化:new AMQPMessage创建消息时通过参数指定
append的方式写文件,会根据大小自动生成新的文件,rabbitmq启动时会创建两个进程,一个负责持久化消息的存储,另一个负责非持久化消息的存储(内存不够时)
消息存储时会在ets表中记录消息在文件中的映射以及相关信息(包括id、偏移量,有效数据,左边文件,右边文件),消息读取时根据该信息到文件中读取、同时更新信息
消息删除时只从ets删除,变为垃圾数据,当垃圾数据超出比例(默认50%),并且文件数达到3个,触发垃圾回收,锁定左右两个文件,整理左边文件有效数据、将右边文件有效数据写入左边,更新文件信息,删除右边,完成合并。当一个文件的有用数据等于0时,删除该文件。
写入文件前先写buffer缓冲区,如果buffer已满,则写入文件(此时只是操作系统的页存)
每隔25ms刷一次磁盘,不管buffer满没满,都将buffer和页存中的数据落盘
每次消息写入后,如果没有后续写入请求,则直接刷盘
image.png
网友评论