当前位置：首页 > news >正文

【后端开发面试题】每日 3 题（四）

news 来源：原创 2025/6/12 17:57:08

✍个人博客：Pandaconda-CSDN博客
📣专栏地址：https://blog.csdn.net/newin2020/category_12903849.html
📚专栏简介：在这个专栏中，我将会分享后端开发面试中常见的面试题给大家~
❤️如果有收获的话，欢迎点赞👍收藏📁，您的支持就是我创作的最大动力💪

1. 简述消息队列在后端开发中的作用及常见使用场景

作用

异步处理：将一些非核心业务逻辑从主业务流程中分离出来，通过消息队列异步处理。这样可以提高主业务流程的响应速度，减少用户等待时间。例如，在用户注册时，注册成功的消息可以发送到消息队列，后续的邮件通知、积分赠送等操作可以由其他服务从队列中取出消息异步执行。
流量削峰：在高并发场景下，消息队列可以作为缓冲，将大量的请求先存储在队列中，然后后端服务按照自身的处理能力从队列中消费消息，避免系统因瞬间高流量而崩溃。比如电商系统的秒杀活动，大量用户的请求可以先进入消息队列，系统按照一定的速率处理这些请求。
系统解耦：各个服务之间通过消息队列进行通信，一个服务的变更不会直接影响到其他服务。不同的服务可以独立开发、部署和维护，提高了系统的可扩展性和可维护性。例如，订单服务和库存服务之间通过消息队列传递订单创建和库存扣减的消息，订单服务无需关心库存服务的具体实现。
数据同步：可以用于不同系统之间的数据同步。例如，将数据库中的数据变更信息发送到消息队列，其他系统从队列中获取这些信息并更新自己的数据。

常见使用场景

日志收集：将各个服务产生的日志信息发送到消息队列，然后由专门的日志处理服务从队列中消费消息，进行日志的存储和分析。
异步通知：如短信通知、邮件通知等，将通知信息发送到消息队列，由通知服务异步处理。
任务调度：将任务信息发送到消息队列，任务处理服务从队列中获取任务并执行。例如，定时任务可以通过消息队列进行调度。

2. 在 Python 的 Flask 框架中，如何处理跨域请求？

跨域请求（CORS，Cross - Origin Resource Sharing）是指浏览器从一个域名的网页去请求另一个域名的资源时，由于浏览器的同源策略会受到限制。在 Flask 中可以通过以下几种方式处理跨域请求：

使用 flask_cors 扩展

flask_cors 是一个专门用于处理 Flask 跨域请求的扩展，使用起来非常方便。

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
# 允许所有域名跨域访问
CORS(app)

@app.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run()

如果需要更细粒度的控制，可以指定允许的域名、请求方法等：

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
# 只允许特定域名跨域访问
CORS(app, resources={r"/api/*": {"origins": "http://example.com"}})

@app.route('/api/data')
def get_data():
    return {'message': 'This is some data'}

if __name__ == '__main__':
    app.run()

手动设置响应头

在 Flask 视图函数中手动设置响应头 Access - Control - Allow - Origin 等信息。

from flask import Flask, jsonify, make_response

app = Flask(__name__)

@app.route('/')
def hello_world():
    response = make_response(jsonify({'message': 'Hello, World!'}))
    # 允许所有域名跨域访问
    response.headers['Access-Control-Allow-Origin'] = '*'
    return response

if __name__ == '__main__':
    app.run()

3. 解释分布式系统中的 CAP 定理

CAP 定理是分布式系统设计中的一个重要理论，由计算机科学家 Eric Brewer 提出，该定理指出在一个分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个特性最多只能同时满足两个。

一致性（Consistency）

在分布式系统中，一致性要求所有节点在同一时间看到的数据是一致的。也就是说，当一个写操作完成后，后续的读操作都应该返回最新写入的数据。例如，在一个分布式数据库中，当一个客户端更新了某个数据后，其他客户端在读取该数据时应该立即看到更新后的值。

可用性（Availability）

可用性表示系统中的每个请求都能在合理的时间内得到响应，不会出现请求失败或长时间无响应的情况。无论系统出现什么故障，用户都能正常使用系统。例如，在一个电商系统中，用户在任何时候进行商品查询、下单等操作，系统都应该能够及时响应。

分区容错性（Partition tolerance）

分区容错性是指在分布式系统中，由于网络故障等原因导致系统的节点之间出现网络分区（即部分节点之间无法通信）时，系统仍然能够继续运行。例如，一个分布式系统由多个数据中心组成，当某个数据中心与其他数据中心之间的网络连接中断时，系统仍然能够正常提供服务。

由于分布式系统通常部署在多个节点上，网络故障是不可避免的，因此分区容错性是必须要保证的。在这种情况下，就需要在一致性和可用性之间进行权衡：

CP 系统：保证一致性和分区容错性，牺牲可用性。当系统出现网络分区时，为了保证数据的一致性，系统可能会暂停服务，直到分区问题解决。例如，一些分布式数据库（如 MongoDB 在某些配置下）在出现网络分区时，会牺牲部分可用性来保证数据的一致性。
AP 系统：保证可用性和分区容错性，牺牲一致性。当系统出现网络分区时，系统会继续提供服务，但可能会返回旧的数据。例如，一些分布式缓存系统（如 Redis Cluster）更注重可用性，在出现网络分区时会允许部分数据的不一致。