40、Airbnb系统设计与新闻推送系统设计解析

perl8

于 2025-11-05 09:36:45 发布

阅读量20

点赞数

CC 4.0 BY-SA版权

分类专栏：系统设计的艺术与权衡文章标签： Airbnb系统设计新闻推送系统预订服务

本文链接：https://blog.youkuaiyun.com/perl8/article/details/154759130

系统设计的艺术与权衡专栏收录该内容

48 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

Airbnb系统设计与新闻推送系统设计解析

一、Airbnb系统设计

（一）预订服务

简化预订流程
- 客人提交搜索查询，包含城市、入住日期和退房日期，获取可用房源列表，列表中每个房源可能包含缩略图和简要信息。
- 客人可按价格和其他房源细节过滤结果。
- 客人点击房源查看更多细节，包括高分辨率照片和视频（如有），也可返回结果列表。
- 客人决定预订的房源，提交预订请求并收到确认或错误信息。
- 若收到确认信息，客人需进行支付。
- 客人可能改变主意并提交取消预订请求。
通知机制
- 预订成功完成或取消后通知客人和房东。
- 若客人填写了预订请求细节但未完成，数小时或数天后提醒其完成。
- 根据客人的过往预订、浏览房源、其他在线活动、人口统计等因素推荐房源。
- 关于支付的通知，可选择在房东接受前托管支付或在接受后请求支付。
可扩展性要求
可按城市对房源进行功能分区，假设一个城市最多有100万房源，每天最多有1000万次搜索、过滤和房源细节请求。即使这些请求集中在一天中的一小时，每秒查询量也不到3000次，单个或少量主机即可处理。
预订服务架构
- 所有查询由后端服务处理，后端服务根据情况查询共享的Elasticsearch或SQL服务。
- 搜索和过滤请求由Elasticsearch服务处理，该服务还可处理分页，支持模糊搜索。
- 对房源细节的CRUD请求使用ORM格式化为SQL查询并发送到SQL服务，照片和视频从CDN下载。
- 预订请求转发到可用性服务。
- SQL服务使用主从架构，写入操作包括预订请求、审批服务的更新和取消预订请求。
- SQL服务的Booking表包含id、listing_id、guest_id、check_in、check_out、timestamp等列。
分布式事务
房源可用性或细节变化时，需更新Elasticsearch索引。添加或更新房源需要同时向SQL服务和Elasticsearch服务发送写请求，可作为分布式事务处理以防止写入失败时出现不一致。预订请求也应作为分布式事务处理。
搜索结果排序
Elasticsearch结果可按客人评分降序排序，也可由机器学习实验服务排序。
简化预订流程序列图

sequenceDiagram
    participant Client
    participant Elasticsearch
    participant Booking
    participant Payment
    participant Availability

    Client->>Elasticsearch: Search/filter listings.
    Client->>Booking: Make booking.
    Client->>Payment: Get listing details.
    Booking->>Availability: Booking request
    Availability->>Booking: Listings.
    Booking->>Client: Listing details.
    Booking->>Availability: Check availability.
    alt Listing available
        Availability-->>Booking: True
        Booking->>Payment: If booking confirmed, make payment.
        Payment-->>Booking: Payment confirmed.
    else Listing unavailable
        Availability-->>Booking: False
        Booking-->>Client: Booking failed.
    end
    alt Payment failed
        Payment-->>Booking: [Payment failed.]
        Booking->>Availability: Cancel booking.
        Booking-->>Client: Booking canceled.
    end

（二）可用性服务

避免的情况
- 避免双重预订。
- 确保客人的预订对房东可见。
- 防止房东标记不可用的日期被客人预订。
- 减少因这些不良体验导致的客户支持部门负担。
服务端点
- 根据位置ID、房源类型ID、入住日期和退房日期获取可用房源。
- 在特定时间段内锁定房源。
- 对特定时间段的预订进行CRUD操作。
可用性服务架构
由后端服务和共享SQL服务组成，SQL服务采用主从架构。
SQL服务可用性表
包含listing_id、date、booking_id、available、timestamp等列，无主键。
房源锁定机制
在客户端显示六分钟计时器，客户端计时器时长略长于后端。可使用SQL行锁定防止重叠预订，后端服务在主主机上使用SQL事务，先查询房源是否可用，再进行相应标记。
一致性权衡
主从SQL架构可能导致搜索结果包含不可用房源，若客人尝试预订不可用房源，预订服务可返回409响应。应添加指标监控此类情况。
存储需求
若每列占用64位，一行占用40字节，100万房源180天的数据占用7.2GB，可手动删除旧数据释放空间。

（三）日志记录、监控和警报

异常检测
对异常的预订、房源或取消率进行异常检测，监控房源被手动或编程标记为违规的异常高比率。
用户故事监控
定义端到端用户故事，监控完成与未完成用户故事/流程的比率，对未完成情况异常高发发出警报。
不良用户故事监控
定义并监控不良用户故事的比率，如客人与房东沟通后未提出或取消预订请求。

二、新闻推送系统设计

（一）系统设计要求

设计一个新闻推送系统，为用户提供按大致逆时间顺序排序的新闻条目列表，新闻条目属于用户选择的主题。每个新闻条目可分为1 - 3个主题，用户可随时选择最多三个感兴趣的主题。

（二）系统特点

在社交媒体应用中，用户的新闻推送通常由朋友/联系人的帖子填充，而此新闻推送系统中，用户获取的是其他人撰写的帖子。

Airbnb系统设计与新闻推送系统设计解析

一、Airbnb系统设计（续）

（四）其他可能的讨论话题

搜索服务设计
- 用户可能对不完全符合搜索标准的房源感兴趣，如入住或退房日期稍有不同，或附近城市的房源。可考虑在提交搜索查询到Elasticsearch之前修改查询，或设计能将此类结果视为相关的Elasticsearch索引。
为不同用户设计功能
- 客人：可设计系统让客人报告不适当的房源；设计监控客人行为的系统，以推荐可能的惩罚措施，如限制使用服务或停用账户。
- 房东：可设计适合房东的其他功能，如提供房源管理工具等。
- 运维人员（Ops） ：可设计便于运维人员管理系统的功能，如系统监控和故障排查工具。
未讨论的功能需求
之前定义为超出面试范围的功能需求，需考虑其架构细节，判断是在现有服务中满足需求还是应作为单独的服务。
搜索功能扩展
可让客人通过关键词搜索房源，需要对房源进行索引，可使用Elasticsearch或设计自己的搜索服务。
产品范围扩展
- 如提供适合商务旅行者的房源。
- 允许类似酒店的双重预订，若房间不可用则升级客人入住更贵的房间，因为较贵房间通常空置率较高。
数据分析与展示
- 可参考相关的分析系统，为用户展示一些统计信息，如房源的受欢迎程度。
个性化推荐
设计推荐系统，如为新房源推荐客人，鼓励新房东。
前端与用户体验
前端工程师或UX设计师面试可能会讨论UX流程。
欺诈防护
设计系统进行欺诈防护和缓解。

（五）处理法规

法规服务设计
设计并实现专门的法规服务，提供用于传达法规的标准API，其他所有服务都应与该API交互，以便灵活应对法规变化，或至少在遇到意外法规时更易于重新设计。
法规对业务的影响
法规可能直接影响Airbnb的核心业务，例如：
- 房源每年最多可托管的天数限制。
- 只有特定年份之前或之后建造的房产才能列出。
- 某些日期（如公共假期）不能进行预订。
- 特定城市的预订有最短或最长时长限制。
- 某些城市或地址不允许列出房源。
- 房源需要配备安全设备，如一氧化碳探测器、火灾探测器和消防逃生通道。
- 其他宜居性和安全法规。

二、新闻推送系统设计（续）

（三）系统设计思路

数据存储
- 可使用数据库存储新闻条目和用户信息。新闻条目表可包含新闻ID、标题、内容、发布时间、所属主题等字段；用户表可包含用户ID、选择的主题等字段。
- 为提高查询效率，可对新闻条目表的发布时间和主题字段建立索引。
新闻筛选与排序
- 根据用户选择的主题，从数据库中筛选出属于这些主题的新闻条目。
- 按照大致逆时间顺序对筛选出的新闻条目进行排序，确保最新的新闻排在前面。
个性化推荐
- 可根据用户的历史浏览记录、点赞、评论等行为，为用户提供更个性化的新闻推荐。例如，若用户经常浏览科技类新闻，可适当增加科技类新闻在推送列表中的比例。
性能优化
- 考虑使用缓存技术，如Redis，缓存热门新闻条目，减少数据库查询次数，提高系统响应速度。
- 对系统进行分布式部署，使用负载均衡器将请求均匀分配到多个服务器上，提高系统的并发处理能力。

（四）系统架构示例

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A[用户]:::process --> B[前端界面]:::process
    B --> C[应用服务器]:::process
    C --> D[数据库]:::process
    C --> E[缓存服务器（Redis）]:::process
    D --> C
    E --> C
    C --> F[新闻筛选与排序模块]:::process
    F --> C
    C --> B
    B --> A

该架构图展示了新闻推送系统的基本流程：用户通过前端界面向应用服务器发送请求，应用服务器根据请求从数据库或缓存服务器获取新闻条目，经过新闻筛选与排序模块处理后，将新闻列表返回给前端界面，最终展示给用户。

总结

Airbnb系统是一个复杂的多用户系统，涉及众多服务和业务逻辑。在设计时，需要考虑可扩展性、数据一致性、法规合规性等多个方面。通过合理的架构设计、分布式事务处理和监控机制，可以确保系统的稳定运行。而新闻推送系统则需要关注数据存储、筛选排序、个性化推荐和性能优化等关键问题，以提供满足用户需求的新闻列表。在实际应用中，还需根据具体业务场景和用户需求，不断完善和优化系统。