架构师面试

正在做的项目,

微服务,

对业务的分析,业务怎么使用中间件,

spring cloud,boot关系怎么看,

注册中心

eureka, zookeeper
eureka是基于ap的。zookeeper是基于cp的。
eureka保证ap
eureka优先保证可用性。在Eureka平台中,如果某台服务器宕机,Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切换 到新的Eureka节点;当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中;而对于它来说,所有要做的无非是同步一些新的服务 注册信息而已。所以,再也不用担心有“掉队”的服务器恢复以后,会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障,并实现“0”宕机维护需求。当网络分割故障发生时,每个Eureka节点,会持续的对外提供服务(注:ZooKeeper不会):接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来,就可以实现在同一个子网中(same side of partition),新发布的服务仍然可以被发现与访问。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
当网络稳定时,当前实例新的注册信息会被同步到其它节点中
Eureka还有客户端缓存功能(注:Eureka分为客户端程序与服务器端程序两个部分,客户端程序负责向外提供注册与发现服务接口)。 所以即便Eureka集群中所有节点都失效,或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下,所有正常的Eureka节点都不对请求产生相应,也没有更好的服务器解决方案来解 决这种问题时;得益于Eureka的客户端缓存技术,消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息。
zookeeper保证cp
作为一个分布式协同服务,ZooKeeper非常好,但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算是 返回了包含不实的信息的结果也比什么都不返回要好;再者,对于Service发现服务而言,宁可返回某服务5分钟之前在哪几个服务器上可用的信息,也不能 因为暂时的网络故障而找不到可用的服务器,而不返回任何结果。所以说,用ZooKeeper来做Service发现服务是肯定错误的。
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

spring cloud服务组件,

Spring Cloud Eureka 注册中心
Spring Cloud Ribbon 客户端负载均衡器
Spring Cloud Feign 是一个声明web服务客户端,集成 Ribbon 和 Eureka 提供的负载均衡的HTTP客户端
Spring Cloud Hystrix 断路器
Spring Cloud Config 分布式配置中心组件 一是Config Server,二是Config Client
Spring Cloud Zuul 服务网关
Spring Cloud Bus 消息总线。

分布式的信息分享,共享信息,底层的分析,

1.信息分级
2.公用数据库/备份
3.Mq
4.信息寻址

组件
Outbox vs CDC

  • 事务性发件箱(Transactional Outbox)
  • 变更数据捕获(Change Data Capture, CDC)
    第一个是阿里开源的Canal,
    第二个是Redhat开源的Debezium,
    第三个是Zendesk开源的Maxwell,
    第四个是Airbnb开源的SpinalTap

项目管理发布部署这块,阿里一些p8s的发布工具,

jekins + docker

dubbo

Dubbo :是一个RPC框架,SOA框架
Dubbo缺省协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用
作为RPC:支持各种传输协议,如dubbo,hession,json,fastjson,底层采用mina,netty长连接进行传输!典型的provider和cusomer模式!
作为SOA:具有服务治理功能,提供服务的注册和发现!用zookeeper实现注册中心!启动时候服务端会把所有接口注册到注册中心,并且订阅configurators,服务消费端订阅provide,configurators,routers,订阅变更时,zk会推送providers,configuators,routers,启动时注册长连接,进行通讯!proveider和provider启动后,后台启动定时器,发送统计数据到monitor(监控中心)!提供各种容错机制和负载均衡策略!!

熔断,

image.png

Redis

Redis缓存穿透以及解决方法
1.当用户查询的key在redis中不存在,对应的id在数据库也不存在,此时被非法用户进行攻击,大量的请求会直接打在db上,造成宕机,从而影响整个系统,这种现象称之为缓存穿透。

2.解决方案一:把空的数据也缓存起来,比如空字符串,空对象,空数组或list
3.解决方案二:布隆过滤器

redis挂机之后的数据恢复,分区的一些东西,

RDB 周期性存储 远程存储
aof 日志型存储

redis存储数据类型,

1.String类型

String是最简单的类型,一个key对应一个value

String类型的数据最大512MB。
String类型的值可以被视作integer,从而可以让“INCR”命令族操作(incrby、decr、decrby),这种情况下,该integer的值限制在64位有符号数。
在list、set和zset中包含的独立的元素类型都是Redis String类型。

int:当存储的字符串全是数字时,此时使用int方式来存储;
embstr:当存储的字符串长度小于44个字符时,此时使用embstr方式来存储;
raw:当存储的字符串长度大于44个字符时,此时使用raw方式来存储;

2.List类型

链表类型,主要功能是push、pop、获取一个范围的所有值等。其中的key可以理解为链表的名字。

在Redis中,list就是Redis String的列表,按照插入顺序排序。比如使用LPUSH命令在list头插入一个元素,使用RPUSH命令在list的尾插入一个元素。当这两个命令之一作用于一个空的key时,一个新的list就创建出来了。
一个List的最大长度是2^32-1个元素 (4294967295, 每个列表超过40亿个元素)。

3.Set类型

集合,和数学中的集合概念相似。操作中的key理解为集合的名字。

在Redis中,set就是Redis String的无序集合,不允许有重复元素。

Set的最大元素数是2^32-1。

Redis中对set的操作还有交集、并集、差集等。

4.ZSet类型

Zset是set的一个升级版本,在set的基础上增加了一个顺序属性,这一属性在添加修改元素时可以指定,每次指定后zset会自动安装指定值重新调整顺序。可以理解为一张表,一列存value,一列存顺序。操作中的key理解为zset的名字。

Zset的最大元素数是2^32-1。

对于已经有序的zset,仍然可以使用SORT命令,通过指定ASC|DESC参数对其进行排序。

5.hash类型

hash是最接近关系数据库结构的数据类型,可以将数据库一条记录或程序中一个对象转换成hashmap存放在redis中。

String:缓存、限流、计数器、分布式锁、分布式Session
Hash:存储用户信息、用户主页访问量、组合查询
List:微博关注人时间轴列表、简单队列
Set:赞、踩、标签、好友关系
Zset:排行榜(geo的底层实现)

redis雪崩怎么解决,

缓存雪崩:缓存中的数据大批量失效,然后这个使用又要大量的请求进来,但是由于redis中的key全部失效了所有会全部请求到db上,造成宕机
1.设置对应热点key永不过期
2.过期时间错开,过期时间使用随机生成,并且热点数据的过期时间设置的长一点,非热点数据可以设置短一点
3.多缓存结合,例如:请求进入,可以现请求redis,当redis中不存在的时候再去请求memcache,如果都没有再去请求db

缓存数据恢复

1,主动推送
2,查询缓存
3,本地文件pipline

数据库

数据库的优化,

Java基础

haspmap,

高并发造成的,

1.服务器
服务器可以做负载均衡集群,分摊系统的工作,减少单一服务器的资源负担

2.数据库
2.1 通过表设计防止并发导致数据错乱
2.2 表设计成分库分表,分库减少单一数据库的负担,分表防止因数据量增多而降低数据库的性能
2.3 数据库读写分离
2.4 将数据存到redis缓存

3.程序设计
3.1 同步机制
3.2 事物+锁,防止并发数据错乱
3.3 数据缓存,加快响应速度

java有几种基础设计类型,

单例模式
AOP就靠代理模式,
IOC工厂模式➕反射
模板方法(Template Method) jdbcTemplate

你可能感兴趣的:(架构师面试)