高并发、高可用、分布式相关面试题汇总

  1. ⾼并发原则
    ⽆状态
    ⽆状态应⽤,便于⽔平扩展
    有状态配置可通过配置中⼼实现⽆状态
    实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、
    Xdiamond等
    拆分
    系统维度:按照系统功能、业务拆分,如购物⻋,结算,订单等
    功能维度:对系统功能在做细粒度拆分
    读写维度:根据读写⽐例特征拆分;读多,可考虑多级缓存;写多,可考
    虑分库分表
    AOP维度: 根据访问特征,按照AOP进⾏拆分,⽐如商品⻚可分为
    CDN、⻚⾯渲染系统,CDN就是⼀个AOP系统
    模块维度:对整体代码结构划分Web、Service、DAO
    服务化
    服务化演进: 进程内服务-单机远程服务-集群⼿动注册服务-⾃动注册和发
    现服务-服务的分组、隔离、路由-服务治理
    考虑服务分组、隔离、限流、⿊⽩名单、超时、重试机制、路由、故障补
    偿等
    实践:利⽤Nginx、HaProxy、LVS等实现负载均衡,ZooKeeper、Consul
    等实现⾃动注册和发现服
    消息队列
    ⽬的: 服务解耦(⼀对多消费)、异步处理、流量削峰缓冲等
    ⼤流量缓冲: 牺牲强⼀致性,保证最终⼀致性(案例:库存扣减,现在
    Redis中做扣减,记录扣减⽇志,通过后台进程将扣减⽇志应⽤到DB)
    数据校对: 解决异步消息机制下消息丢失问题
    数据异构
    数据异构: 通过消息队列机制接收数据变更,原⼦化存储
    数据闭环: 屏蔽多从数据来源,将数据异构存储,形成闭环
    缓存银弹
    ⽤户层:
    DNS缓存
    浏览器DNS缓存
    操作系统DNS缓存
    本地DNS服务商缓存
    DNS服务器缓存
    客户端缓存
    浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)* App
    客户缓存(js/css/image…)
    代理层:
    CDN缓存(⼀般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-
    ⼆级节点-中⼼节点-源站)
    接⼊层:
    Nginx为例:
    Proxy_cache: 代理缓存,可以存储到/dev/shm或者SSD
    FastCGI Cache
    Nginx+Lua+Redis: 业务数据缓存
    PHP为例:
    Opcache: 缓存PHP的Opcodes
    应⽤层:
    ⻚⾯静态化
    业务数据缓存(Redis/Memcached/本地⽂件等)
    消息队列
    数据层:
    NoSQL: Redis、Memcache、SSDB等
    MySQL: Innodb/MyISAM等Query Cache、Key Cache、Innodb
    Buffer Size等
    系统层:
    CPU : L1/L2/L3 Cache/NUMA
    内存
    磁盘:磁盘本身缓存、dirty_ratio/dirty_background_ratio、阵列卡本
    身缓存
    并发化
  2. ⾼可⽤原则
    降级
    降级开关集中化管理:将开关配置信息推送到各个应⽤
    可降级的多级读服务:如服务调⽤降级为只读本地缓存
    开关前置化:如Nginx+lua(OpenResty)配置降级策略,引流流量;可基于
    此做灰度策略
    业务降级:⾼并发下,保证核⼼功能,次要功能可由同步改为异步策略或
    屏蔽功能
    限流
    ⽬的: 防⽌恶意请求攻击或超出系统峰值
    实践:
    恶意请求流量只访问到Cache
    穿透后端应⽤的流量使⽤Nginx的limit处理
    恶意IP使⽤Nginx Deny策略或者iptables拒绝
    切流量
    ⽬的:屏蔽故障机器
    实践:
    DNS: 更改域名解析⼊⼝,如DNSPOD可以添加备⽤IP,正常IP故障
    时,会⾃主切换到备⽤地址;⽣效实践较慢
    HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度
    LVS/HaProxy/Nginx: 摘除故障节点
    可回滚
    发布版本失败时可随时快速回退到上⼀个稳定版本
  3. 业务设计原则
    防重设计
    幂等设计
    流程定义
    状态与状态机
    后台系统操作可反馈
    后台系统审批化
    ⽂档注释
    备份
  4. 总结
    先⾏规划和设计时有必要的,要对现有问题有⽅案,对未来有预案;⽋下的
    技术债,迟早都是要还的。
  5. 分布式与集群的区别:
    分布式是指将不同的业务分布在不同的地⽅。 ⽽集群指的是将⼏台服务器集中在
    ⼀起,实现同⼀业务
  6. 分布式事务:
  7. ⼆阶段提交:
    a. 概念:参与者将操作成败通知协调者,再由协调者根据所有参与者的
    反馈情报决定各参与者是否要提交操作还是中⽌操作。
    b. 作⽤:主要保证了分布式事务的原⼦性;第⼀阶段为准备阶段,第⼆
    阶段为提交阶段;
    c. 缺点:不仅要锁住参与者的所有资源,⽽且要锁住协调者资源,开销
    ⼤。⼀句话总结就是:2PC效率很低,对⾼并发很不友好。
  8. 三阶段提交:
    a. 概念:三阶段提交协议在协调者和参与者中都引⼊超时机制,并且把
    两阶段提交协议的第⼀个阶段拆分成了两步:询问,然后再锁资源,最
    后真正提交。这样三阶段提交就有CanCommit、PreCommit、
    DoCommit三个阶段。
    b. 缺点:如果进⼊PreCommit后,Coordinator发出的是abort请求,假
    设只有⼀个Cohort收到并进⾏了abort操作,
    ⽽其他对于系统状态未知的Cohort会根据3PC选择继续Commit,此时系统状态
    发⽣不⼀致性。
  9. 柔性事务:
    a. 概念:所谓柔性事务是相对强制锁表的刚性事务⽽⾔。流程⼊下:
    服务器A的事务如果执⾏顺利,那么事务A就先⾏提交,如果事务B也执
    ⾏顺利,则事务B也提交,整个事务就算完成。但是如果事务B执⾏失
    败,事务B本身回滚,这时事务A已经被提交,所以需要执⾏⼀个补偿操
    作,将已经提交的事务A执⾏的操作作反操作,恢复到未执⾏前事务A的
    状态。
    b. 缺点:业务侵⼊性太强,还要补偿操作,缺乏普遍性,没法⼤规模推
    ⼴。
  10. 消息最终⼀致性解决⽅案之RabbitMQ实现:
    a. 实现:发送⽅确认+消息持久化+消费者确认。
  11. 什么时候⽤到分布式开发:
    a. 优点:
    i. 模块解耦:把模块拆分,使⽤接⼝通信,降低模块之间的耦合度.
    ii. 项⽬拆分,不同团队负责不同的⼦项⽬:把项⽬拆分成若⼲个⼦
    项⽬,不同的团队负责不同的⼦项⽬.
    iii. 提⾼项⽬扩展性:增加功能时只需要再增加⼀个⼦项⽬,调⽤其
    他系统的接⼝就可以。
    iv. 分布式部署:可以灵活的进⾏分布式部署.
    v. 提⾼代码的复⽤性:⽐如service层,如果不采⽤分布式rest服务
    ⽅式架构就会在⼿机wap商城,微信商城,pc,android,ios每个端都
    要写⼀个service层逻辑,开发量⼤,难以维护⼀起升级,这时候就可以
    采⽤分布式rest服务⽅式,公⽤⼀个service层。
    a. 缺点:
    i. 系统之间的交互要使⽤远程通信,接⼝开发增⼤⼯作量;
    ii. ⽹络请求有延时;
    iii. 事务处理⽐较麻烦,需要使⽤分布式事务。
  12. cdn(异地多活)
    1、异地多活:异地多活指分布在异地的多个站点同时对外提供服务的业务场
    景。异地多活是⾼可⽤架构设计的⼀种,与传统的灾备设计的最主要区别在
    于“多活”,即所有站点都是同时在对外提供服务的。
    2、两地容灾切换⽅案:
    容灾是异地多活中最核⼼的⼀环, 以两个城市异地多活部署架构图为例:

在两个城市(城市1位于华南1地域、城市2位于华东1地域)均部署⼀
套完整的业务系统。
下单业务按照“user_id”% 100 进⾏分⽚,在正常情况下:
[00~49]分⽚所有的读写都在城市1的数据库实例主库。
[50~99]分⽚所有的读写都在城市2的数据库实例主库。
“城市1的数据库实例主库”和 “城市2的数据库实例主库”建⽴DTS双向复
制。
当出现异常时,需要进⾏容灾切换。可能出现的场景有以下4种:
将第2种、第3种异常情况,全部采⽤第2种⽅案进⾏处理,那么不管是所有
的APP Server异常、所有的数据库异常、整个城市异常,就直接按照城市级
容灾⽅案处理,直接将APP Server、数据库切换到到另⼀个城市。
3、多城异地多活:
多城市异地多活模式指的是3个或者3个以上城市间部署异地多活。该模式
下存在中⼼节点和单元节点:
中⼼节点:指单元节点的增量数据都需要实时的同步到中⼼节点,同时
中⼼节点将所有分⽚的增量数据同步到其他单元节点。
单元节点:即对应分⽚读写的节点,该节点需要将该分⽚的增量同步到
中⼼节点,并且接收来⾃于中⼼节点的其他分⽚的增量数据。
下图是3城市异地多活架构图,其中华东1就是中⼼节点,华南1和华北1是
单元节点。
9. 分布式环境下宕机的处理⽅案?
1、dubbo:服务器宕机,zk临时被删除;
2、springcloud:每30s发送⼼跳检测重新进⾏租约,如果客户端不能多次
更新租约,它将在90s内从服务器注册中⼼移除。
3、apm监控:
10.

你可能感兴趣的:(高并发、高可用、分布式相关面试题汇总)