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

tes*_*ter 5 architecture database-design scalability nosql database-performance

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

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

到目前为止,我已经达到了以下结构:

  • room_type 的一个划分,这将是它的特征的组合,例如它是否有视野,或者房间里的人数最多,例如:with view/3 people 将是一个类型,其他类型将是:with view /4人,无景2人,有景/4人等\
  • 每个房间都将分配给一个 room_type 用于前端的演示目的。例如:我不会显示个人房间记录(例如:201 号房间),但我会显示我有该类型的可用房间。
  • 所以我会有一个房间“桌子”和一个房间类型“桌子”,每个房间都有一个类型。
  • 然后是从今天到未来 6 个月的房间(行)和日期(列)的矩阵。

矩阵如下所示: 可用性矩阵

其中 1 表示该日期有可用房间,0 表示已预订。因此,为了检测某个日期范围内的 room_type 是否可用,我必须:

  1. 每间此类客房;
  2. 扫描所需日期之间的所有列;
  3. 如果有一个房间在该行中没有找到 0,则表示它可用,因此这意味着此 room_type 可以显示为在该日期范围内可用。

在上表中,假设日期范围是 10/10/2017 到 10/14/2017(美国格式),唯一可用的房间是酒店 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 的数据库中。 (2认同)