设计一个高性能的酒店房间预订系统

Posted 2023-02-23

【中文标题】设计一个高性能的酒店房间预订系统

【英文标题】：Designing a high performing hotel room booking system

【发布时间】：2018-08-29 23:37:24

【问题描述】：

我正面临设计一个酒店网站的预订系统的情况，该网站可以处理成千上万的酒店房间及其可用性。类似于 Expedia 网站。

此可用性需要存储在本地，我需要查询这些酒店房间的可用性。

到目前为止，我已经达到了以下结构：

room_type 的划分，将是其特征的组合，例如是否有景观，或房间中的最大人数，例如：with view/3 people 将是一个单独的类型，而其他类型将是：有视野/4人，无视野2人，有视野/4人等\ 每个房间都将分配给一个 room_type 用于在前端进行演示。例如：我不会显示单个房间记录（例如：房间 201），但我会显示我有该类型的可用房间。 所以我会有一个房间“table”和一个 room_type“table”，每个房间都有一个类型。 然后是从今天到未来 6 个月的房间（行）和日期（列）矩阵。

矩阵如下所示：

其中 1 表示该日期有空房，0 表示已预订。因此，如果要检测某个日期范围内的 room_type 是否可用，我必须：

此类型的每个房间； 扫描所需日期之间的所有列； 如果有房间在该行中没有找到 0，则表示该房间可用，因此表示该房间类型在该日期范围内可以显示为可用。

在上表中，假设日期范围为 2017 年 10 月 10 日至 2017 年 10 月 14 日（美国格式），唯一可用的房间是酒店 C 的 101 号房间。

然后我可以为客户预订该房间，因此客户在入住期间无需更换房间。

我的问题是：

是否有任何存储器可以在内存中容纳像这样的大矩阵？ （mysql、Redis、PostgreSQL、Cassandra、MongoDB 等） 如果我应该使用 RDBMS，应该使用哪种？我应该使用传统的 RDBMS 吗？或者这种“类矩阵结构”是否更适合另一种新型 NoSQL 数据库。 这些巨大的高访问量网站是如何构建其数据的“矩阵式结构”吗？ （例如：Expedia、Booking.com、Trivago 等）或者是否有更好的方法可以更快地查询日期范围？

我担心现在没有选择正确的结构，并在以后网站需求量大且房间数量更多时偶然发现性能问题。

谢谢。

【参考方案1】：

首先，感谢您的提问。这是我所知道的复杂问题之一，考虑到除了基本酒店可用性之外的各种用例。一些例子：你如何进行地理搜索，如何支持同一房间在同一天多次入住，如何保持数据与世界观高度一致（最新价格和可用性） ，您如何根据价格对酒店进行排名，如何添加更多属性，如自定义优惠（无烟、24 小时入住、包括厨房等），如何处理不同的取消政策等。

我相信你明白了。

我遇到的最好的设计是使用无列存储或无模式存储（如 cassandra、mongo）以及 RDBMS。

NoSQL 存储提供了不断添加更多属性以及跨多个维度（如城市、附近搜索等）进行搜索的灵活性。

RDBMS 可以存储很少变化的数据，例如不同的房间类型、酒店描述等。

例如，对于上面的简单用例，我会将所有不同的房间类型、酒店到房间的映射存储在 RDBMS 中。但是酒店的价格和空房情况将转到 NoSQL 商店。我会将房价和空房情况存储在 NoSQL 存储中，其中包含入住/退房日期、人数、房间数等搜索属性作为该表的键。我会定期运行一个 cron 作业来填充所有可用房间的所有不同搜索排列（通过在另一个预订表上的交叉查找）并更新 NoSQL 存储。这种方式读取路径更快（这与许多社交媒体网站设计其架构的写入方式的扇出非常相似。优化读取路径并在写入路径上传播更新，充分意识到读取数据可以有点陈旧）。在我们的例子中，价格和可用性在 cron 作业运行之间的时间段内可能是陈旧的，但这可以通过在预订时间之前通过一致的商店（例如预订表）再次检查来轻松抵消。如果存在差异，您可以重新启动工作流程。

注意：以上是高度主观的意见，并基于价格和可用性不经常变化的假设。您可以结合使用诸如 kafka 之类的流系统来加快更新速度

【讨论】：

您为什么会假设酒店可用性不经常变化？在预订系统中，这不是最频繁变化的事情吗？除非几乎没有人使用该系统并进行预订。对于您为什么选择将预订信息存储在不符合 ACID 的数据库中也很困惑。