预订逻辑和架构、数据库同步:酒店、网球场预订系统

发布于 2024-09-01 19:27:16 字数 395 浏览 6 评论 0原文

想象一下,您想要设计一个网球预订系统。 您有 5 个网球俱乐部作为合作伙伴,没有在线 api 允许您检查他们这边是否预订了球场:您也必须构建此部分。

每次在他们这边完成预订时,您都希望我们的系统知道这一点。可能使用网球伙伴向我们的服务器发送 POST 请求。

每次在我们的网站上完成预订时,我们都希望将预订推送到他们的系统。困难在于他们的系统需要在线并且可以从外部访问。 IP可能会改变,我们必须使用DNS更新程序。

如果他们的系统不可用,我们仍然接受预订并退回到发送给俱乐部的带有“我确认预订/拒绝预订”链接的异步电子邮件。

我发现整个过程相当复杂,并且想知道在线酒店预订系统和酒店的工作方式。他们的数据都公开并在线吗?

好处是数据会变大并且非常适合一些无 SQL ;) 比如 couch db

Imagine that you want to design a tennis booking system.
You have 5 tennis clubs as partners with no online api allowing you to check on their side if a court is booked or not: You have to build this part as well.

Every time a booking is done on their side you want it to be known by our system. Probably using a POST request form tennis partner to our server.

Every time a booking is done on our website, we want to push the booking to their system. The difficulty is that their system need to be online and accessible from outside. Ip may change, we have to use a dns updater.

In case their system is not available we still accept the booking and fallback to an async email with 'i confirm booking/reject booking' link sent to the club.

I find the whole process quite complex and was wondering about the way online hotel booking system and hotel were working. Do they all have their data open and online ?

The good thing is that the data will grow large and fits nicely to some no SQL ;) like couch db

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

穿越时光隧道 2024-09-08 19:27:16

这里有几个问题,让我尝试解决每个问题......

由于这似乎是一个具有联合服务器的互联网应用程序,因此使用隐含的 HTTP 协议很有意义。这可以通过表单 POST、GET,甚至是一些自定义数据结构的 REST 式提交来完成。最后,确切的使用方法需要取决于所传达信息的大小和复杂性。许多架构都采用这些方法,并且通常将它们与加密、签名和/或编码的有效负载结合起来以确保安全。这些方法需要考虑的一个缺点是,它们要求您清楚地传达所有请求/响应消息格式、字段范围和变化,因为这些机制并不是真正的自我描述。另一方面,这些模式使用非常常见的协议,易于理解、易于实现,并且通常是在线的。

相比之下,结构非常复杂的架构通常选择使用基于 WSDL 的 Web 服务。同样由通用标准驱动,这些往往是自描述的,本质上是可版本化的,尽管它们可能需要更多的时间和精力来实现。由许多 WS-* 标准驱动的 Web 服务有很多优点,可能值得根据您的情况进一步研究。

至于预订过程......许多类似的架构将采用如下的编排模型:

  • 查找开放的预订空间
  • 对预订空间进行预订。这会在请求者填写所有必需的预订信息时对空间设置过期锁定。这可以缓解可能导致同一空间多次预订的竞争条件
  • 一旦收到并验证了所有必需的预订信息,预订就会被确认并永久锁定以防止其他请求者使用

至于 SQL 风格的数据库注释,我真的不能考虑到所提供的信息量。话虽如此,我的直觉告诉我 SQL 风格的数据库对于这个问题集是完全合理的。我的数据库有很多 PB,并且有非常高的 SLA。您暗示需要高可用性,并且基于 SQL 的数据库在该领域拥有数十年经过验证的支持。

希望这有帮助。

There are several questions here, let me try and address each one...

Since this appears to be an internet application with federated servers, using the implied HTTP Protocol makes a lot of sense. This could be done via Form POSTs, GET, or even REST-ful submission of some custom data structure. In the end, the exact approach to use will need to come down to the size and complexity of the information being communicated. Many architectures employ these approaches and often combine them with encrypted, signed, and/or encoded payloads for security. One short-fall to consider with these approaches is that they will require you to clearly communicate all request / response message formats, field ranges, and variations since these mechanisms are not really self-describing. On the other hand, these patterns use very common protocols, are easily understood, easy to implemented, and are typically lean on-the-wire.

In constrast, architectures with very complex structures often chose to use WSDL-based web services. Also driven by common standards, these tend to be self-describing, inherently versionable, although they can take more time and energy to implement. There are a lot of advantanges to web services which are driven by many WS-* standards which may be worth investigating further in your case.

As for the reservation process... many similar architectures will employ an orchestration model such as the following:

  • Find open booking spaces
  • Make a reservation for a booking space. This places an expiring lock on a space while the requestor fills in all required booking information. This mitigates against race conditions that could lead to multiple bookings for the same space
  • Once all required booking information is received and validated the booking is confirmed and permamently locked from use by other requestors

As for the SQL-style DB comment, I can't really say given the amount of information supplied. With that said, my instincts tell me a SQL-style DB is completely reasonable for this problem set. I have databases with many pedabytes and have very high SLA's. You implied a need for high availability and SQL-based databases have a few decades of proven support behind them in this area.

Hope this helps.

两相知 2024-09-08 19:27:16

我想您会发现大多数在线酒店预订系统并不是真正在线的。我的经验是,那些提供在线预订系统的公司(而不是酒店本身)也坚持要求酒店本身也使用同一系统在线预订房间。

只要连接不是问题,一切都可以正常工作 - 在小型汽车旅馆中通常会出现问题。当然,较大的酒店使用与航空公司相同的系统,并且为此目的有专用的通信链路。当然,预订是在一台带有适当备份链接的中央计算机上维护的。

各个网球俱乐部很容易使用自己的数据库/网站以及 MyCourts 提供然而,一旦您想链接多个俱乐部设施,那么除了拥有一个用户和俱乐部都必须使用中央服务器来预订设施。

I think you will find most on-line hotel reservation systems aren't really on-line. My experience is that those companies (not the hotels themselves) offering on-line booking systems also insist that the hotel itself also books their rooms on-line using the same system.

Everything works fine as long as connectivity is not an issue - and in small motels scenario it normally will. Of course the bigger hotels use the same system the airlines do and they have dedicated communications links for the purpose. The reservations are of course maintained on one central computer with appropriate backup links etc etc etc.

It is very easy for individual tennis clubs to offer their own real-time online booking systems using their own database/website with programs like MyCourts offers however once you want to link more than one clubs facilities then you really don't have much option other than to have a centralized server that both the user and the club both have to use to reserve facilities.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文