高级工程师讲解的系统设计——会议室预订系统设计会议

这次模拟面试的对象是 Meta 的一位高级工程师，这位工程师提到了系统设计问题的关键点。

系统设计 — 设计会议室预订系统

这里有几个要点：

1. 可用性和调度 房间预订情况

房间的实时可用性需要在所有用户和系统之间准确地显示。

实时动态：

• 实现一个发布-订阅模型，其中房间可用性变化（例如新预订、取消或修改）会被作为事件发布。
• 维护一个内存中的分布式事件队列，将这些事件推送给所有订阅的客户端。这确保了更新可以立即推送，减少轮询开销。
• 使用共识协议（如Paxos或Raft）在分布式系统中同步这些变更，以确保多个服务器处理房间状态时的一致性。

集中式可用性状态:

• 将数据的可用性信息存储在高性能的内存数据库中。为每个房间维护一个按时间段索引的当前预订记录。
• 使用原子操作来更新该状态，确保同时尝试预订同一房间的操作能够安全地进行。

日历整合:

• 设计一个日历管理的抽象层次，将每个用户的个人日程和会议室预定合并。
• 使用冲突解决机制（如下详细说明）来处理动态合并日程时出现的重叠项。

冲突解决

高效的冲突检测与解决对于确保预订操作期间数据的完整性和一致性至关重要。

自动冲突检测：

• 实现一个基于范围的查询系统来检查是否有重叠。当用户尝试预订时，查询该房间在所选时间范围内的预订情况。
• 确保查询操作具有事务一致性，使用行级锁定来防止重叠时间检查中的竞态条件。
• 使用基于多数写入机制来确认预订在提交前不会与其他分布式节点上的预订冲突。

解决机制:

• 建议如下：

• 查询同一房间相邻时间段的可用性。

• 识别配置相似且位置相近的房间。

• 维护一个评分机制，考虑距离、用户偏好和历史预订模式，对备选方案进行排序。

时区管理

时区是一个复杂的问题，特别是对于全球使用的系统来说。

时区保存:

• 将所有预订时间存储为通用格式，例如 UTC，在后端。
• 每个请求中包含用户的时区元数据，以便后端能够正确理解和存储时间信息。

转换机制:

• 在显示层，根据时区偏移和夏令时规则算出用户的时间。
• 维护一个预先计算好的时区偏移表，从而优化运行时的转换效率。

2. 用户管理和访问控制 （可选）

请注意：如果您对用户访问控制不熟悉，此主题可选。

用户角色定义

基于角色的权限定义了不同用户的访问权限和功能。

角色管理:

• 创建一个数据库架构，其中将角色存储为独立实体，每个角色都关联一组权限。
• 构建一个访问控制矩阵，该矩阵将角色映射到资源（如房间、日程）和操作（如读取、写入、删除）。

注：保留了“读取、写入、删除”的翻译方式，以便更贴近原文表述。

动态角色分配功能:

• 根据用户的具体情况动态分配角色。例如，当用户担任某个房间或资源的管理员时，可临时赋予其更高权限。

认证和权限

用户验证确保安全接入，而授权则限制访问权限的使用。

身份验证机制:

• 使用哈希后的凭证并将带有盐值的哈希值存储在数据库中。在登录时，通过哈希输入并与存储的值进行比较来验证凭证。
• 使用带有过期时间的签名令牌来管理用户的会话，以减少过期会话带来的安全风险。

授权逻辑:

• 在每个端点评估用户权限时，通过将令牌与访问控制矩阵进行对比。
• 实现分级权限评估，其中权限可以逐级传递（例如，组织管理员可以拥有房间管理员的所有权限）。

访客权限

外部用户经常需要临时和有限的访问。

限时访问令牌（Token）:

• 为访客生成唯一的、不可重复使用的访问令牌，并嵌入元数据，例如过期时间和允许的操作。
• 在服务器端记录已发放的令牌，以进行验证，确保系统可以在必要时撤销或过期这些令牌。

限定权限：

• 定义一组最小的操作（例如，只查看），其中包括访客可以执行的操作。将其范围包含在令牌载荷里，以确保整个系统的合规性。

3. 可扩展性和性能 加载管理

系统在高流量下需要保持稳定性能。

请求分发如下:

• 使用哈希分区方案将请求分散到多个服务器上。例如，根据房间ID进行分区，以确保相关请求在同一服务器上处理。
• 在系统入口处维护路由表，以将传入的请求导向适当分区。

动态资源调度:

• 使用响应时间、请求频率和资源利用率等指标监控系统负载。一旦预定义的阈值被超过，根据需要动态增加资源，例如增加服务器或线程的数量。

数据库优化技巧

高效的数据存取能保证在操作时最小的延迟时间。

索引策略如下:

• 对于预订数据，建议在房间ID和时间范围字段上使用复合索引，以支持高效的范围查询。
• 定期检查查询模式的频率和复杂性，然后优化索引。

数据划分:

可以按日期或地区划分预订表，限制每个分区的数据量。这样可以加快查找速度并减少竞争。

横向扩展

通过横向扩展系统，它可以处理更多的需求。

无状态的服务：

• 设计服务要无状态，将所有会话或用户特定数据存储在分布式存储中或包含在请求里。这样任何服务实例都可以处理任何请求。

数据复制:

• 为读取密集型工作负载实现异步复制。例如，可以异步跨节点复制房间可用性信息，以确保信息的一致性。

4. 通知和提醒事项 通知方式（Notification Channels）

有效通知需要实时和定时发送的渠道。

实时交付功能:

• 使用消息队列系统来处理通知事件。生产者（例如预订服务）将消息入队，通知处理者消费这些消息并发送通知。
• 维护用户的特定投递偏好表，确保消息通过用户首选的渠道（例如电子邮件、短信）发送。

故障转移机制：

• 实现重试逻辑，对于未送达的通知，我们定期从队列中尝试重新发送这些消息。

提醒安排

提醒功能通过提醒用户及时采取行动来提高用户的参与度。

批量处理（例如：批量导入数据）:

• 使用后台任务调度器定期检查即将进行的预订，并批量发送提醒信息，从而减轻系统的实时负担。
• 将提醒设置（如时间安排和发送方式）与预订详情一并存储，以便轻松查找。

动态时间管理:

• 根据预订详情计算最合适的提醒时间。比如，对于涉及多个时区的会议，可以发送调整为每位参与者当地时间的提醒。

会议室预订系统设计指南