文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

经典系统架构设计案例分析:票务系统深度解析

2024-11-30 12:35

关注

然而,票务系统也存在一些挑战,如如何保护用户隐私,如何防止票务欺诈,以及如何提供更好的用户体验等。因此,票务系统的开发和运营需要考虑到这些问题,并持续改进和升级。

项目简介:大麦网是中国的领先在线票务平台,提供多样化的活动票务,如音乐会、戏剧和体育赛事等。主要功能包括活动搜索、在线购票、电子票务、实时座位选择、退换票服务以及支付接口。其智能推荐系统可以根据用户兴趣推送相关活动,为用户提供方便、快捷的一站式购票体验。

类似的产品有:猫眼娱乐、永乐票务、bookmyshow.com、ticketmaster.com

难度级别:困难

1、什么是在线电影票预订系统

电影票预订系统为其客户提供在线购买影院座位的能力。电子票务系统允许客户浏览当前正在上映的电影,并在任何地方任何时候预订座位。

2、系统的需求和目标

我们的票务预订服务应满足以下需求:

功能需求

  1. 我们的票务预订服务应能列出其联盟影院所在的不同城市。
  2. 用户选择城市后,服务应显示该特定城市已经上映的电影。
  3. 用户选择电影后,服务应显示正在放映该电影的影院及其可用的放映时间。
  4. 用户应能选择在特定影院的一场放映并预订他们的票。
  5. 服务应能向用户展示影院大厅的座位布局。用户应能根据他们的喜好选择多个座位。
  6. 用户应能从已预订的座位中区分出可用的座位。
  7. 用户应能在付款以完成预订之前,将座位保留五分钟。
  8. 如果有可能座位会变得可用,例如,当其他用户的保留到期时,用户应能等待。
  9. 等待的客户应以公平的、先到先得的方式服务。

非功能性需求

3、一些设计考虑

4、容量估计

流量估计:我们假设我们的服务每月有30亿次页面浏览,每月售出1000万张电影票。

存储估计:假设我们有500个城市,平均每个城市有10家影院。如果每个影院有2000个座位,平均每天有两场放映。

我们假设每个座位预订需要50字节(ID、NumberOfSeats、ShowID、MovieID、SeatNumbers、SeatStatus、Timestamp 等)存储在数据库中。我们还需要存储关于电影和影院的信息;我们假设它会需要50字节。所以,要存储所有城市的所有影院的所有放映的所有数据一天:

500个城市 * 10家影院 * 2000个座位 * 2场放映 * (50+50) 字节 = 2GB / 天

要存储五年的这些数据,我们大约需要3.6TB。

5、系统API

我们可以有SOAP或REST API来公开我们服务的功能。以下可能是搜索电影放映和预订座位的API的定义。

SearchMovies(api_dev_key, keyword, city, lat_long, radius, start_datetime, end_datetime, postal_code, includeSpellcheck, results_per_page, sorting_order)

参数

返回:(JSON) 以下是电影及其放映的示例列表:

{
    "MovieID": 1,
    "ShowID": 1,
    "Title": "Cars 2",
    "Description": "About cars",
    "Duration": 120,
    "Genre": "Animation",
    "Language": "English",
    "ReleaseDate": "8th Oct. 2014",
    "Country": USA,
    "StartTime": "14:00",
    "EndTime": "16:00",
    "Seats": 
    [
    {  
        "Type": "Regular"
        "Price": 14.99
        "Status: "Almost Full"
    },
    {  
        "Type": "Premium"
        "Price": 24.99
        "Status: "Available"
    }
    ]
},
{
    "MovieID": 1,
    "ShowID": 2,
    "Title": "Cars 2",
    "Description": "About cars",
    "Duration": 120,
    "Genre": "Animation",
    "Language": "English",
    "ReleaseDate": "8th Oct. 2014",
    "Country": USA,
    "StartTime": "16:30",
    "EndTime": "18:30",
    "Seats": 
    [
        {  
        "Type": "Regular"
        "Price": 14.99
        "Status: "Full"
    },
        {  
        "Type": "Premium"
        "Price": 24.99
        "Status: "Almost Full"
    }
    ]
}
ReserveSeats(api_dev_key, session_id, movie_id, show_id, seats_to_reserve[])

参数

返回:(JSON)

返回预订的状态,其中包括以下之一:

6、数据库设计

以下是我们即将存储的数据的一些观察:

  1. 每个城市可以有多个影院。
  2. 每个影院将有多个影厅。
  3. 每部电影将有多场放映,每场放映将有多次预订。
  4. 一个用户可以有多次预订。

7、顶层设计

在顶层面上,我们的web服务器将管理用户的会话,应用服务器将处理所有的票务管理,将数据存储在数据库中,以及与缓存服务器一起处理预订。

8、组件设计

首先,我们试着建立服务,假设它是由一个单一的服务器提供的。

票务预订流程:以下将是典型的票务预订流程:

  1. 用户搜索一部电影。
  2. 用户选择一部电影。
  3. 向用户显示该电影的可用场次。
  4. 用户选择一场放映。
  5. 用户选择要预订的座位数量。
  6. 如果需要的座位数可用,用户将看到一个剧院的地图以选择座位。如果不是,用户将进入下面的“步骤8”。
  7. 一旦用户选择了座位,系统将尝试预订这些选定的座位。
  8. 如果无法预订座位,我们有以下选项:
  1. 如果成功预订了座位,用户有五分钟的时间支付预订。付款后,预订标记为完成。如果用户不能在五分钟内支付,他们所有的预订座位都将被释放,以供其他用户使用。

服务器如何跟踪所有尚未预订的活动预订?服务器又如何跟踪所有等待的客户? 我们需要两个守护服务,一个用来跟踪所有活动的预订并从系统中移除任何过期的预订;我们称之为ActiveReservationService。另一个服务将跟踪所有等待的用户请求,一旦需要的座位数变得可用,它将通知(等待时间最长的)用户选择座位;我们称之为WaitingUserService。

A. ActiveReservationsService(活动预订服务)

我们可以在内存中保留一个与Linked HashMap或TreeMap相似的数据结构来存储一场“演出”的所有预订,除了在数据库中保留所有数据。我们需要一种Linked HashMap类型的数据结构,它允许我们在预订完成时跳转到任何预订以移除它。此外,由于我们将有与每个预订关联的到期时间,HashMap的头部将始终指向最旧的预订记录,以便在达到超时时过期预订。

为了存储每场演出的每个预订,我们可以有一个HashTable,其中'key'是'ShowID','value'是包含'BookingID'和创建'Timestamp'的Linked HashMap。

在数据库中,我们将在'Booking'表中存储预订,到期时间将在Timestamp列中。'Status'字段将有一个值为'Reserved (1)'的值,一旦预订完成,系统将更新'Status'为'Booked (2)'并从相关演出的Linked HashMap中删除预订记录。当预订过期时,我们可以从Booking表中移除它,或者将其标记为'Expired (3)',除此之外还要从内存中移除。

ActiveReservationsService也将与外部金融服务一起处理用户支付。每当预订完成或预订过期时,WaitingUsersService都会收到一个信号,以便可以为任何等待的客户提供服务。

B. WaitingUsersService(等待用户服务)

就像ActiveReservationsService一样,我们可以将一个演出的所有等待用户存储在Linked HashMap或TreeMap的内存中。我们需要一个类似于Linked HashMap的数据结构,以便我们可以在用户取消请求时跳转到任何用户以从HashMap中移除他们。此外,由于我们是以先到先得的方式服务,Linked HashMap的头部总是指向等待时间最长的用户,因此每当座位变得可用时,我们都可以以公平的方式为用户提供服务。

我们将有一个HashTable用来存储每个Show的所有等待用户。'key'将是'ShowID','value'将是包含'UserIDs'和他们的等待开始时间的Linked HashMap。

客户端可以使用Long Polling来保持自己的预订状态更新。每当座位变得可用时,服务器可以使用这个请求来通知用户。

预订过期

在服务器上,ActiveReservationsService跟踪活动预订的过期时间(基于预订时间)。由于客户端将显示一个计时器(用于过期时间),这可能与服务器稍微不同步,我们可以在服务器上添加五秒钟的缓冲区以防止破碎的体验,从而确保客户端在服务器超时后永不超时,防止成功购买。

9、并发性

如何处理并发性,以便没有两个用户能够预订同一座位。我们可以在SQL数据库中使用事务来避免任何冲突。例如,如果我们使用的是SQL服务器,我们可以利用事务隔离级别来锁定行,然后再更新它们。下面是样本代码:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

BEGIN TRANSACTION;

    -- Suppose we intend to reserve three seats (IDs: 54, 55, 56) for ShowID=99 
    Select * From Show_Seat where ShowID=99 && ShowSeatID in (54, 55, 56) && Status=0 -- free 

    -- if the number of rows returned by the above statement is three, we can update to 
    -- return success otherwise return failure to the user.
    update Show_Seat ...
    update Booking ...

COMMIT TRANSACTION;

'Serializable' 是最高的隔离级别,可以保证免受脏读、不可重复读和幻读的影响。这里要注意一点;在一个事务中,如果我们读取了行,我们会在这些行上加写锁,以防止它们被任何其他人更新。

一旦上述数据库事务成功,我们就可以开始在ActiveReservationService中跟踪预订情况。

10、容错性

当ActiveReservationsService或WaitingUsersService崩溃时会发生什么? 每当ActiveReservationsService崩溃时,我们可以从‘Booking’表中读取所有的活动预订。请记住,直到预订完成,我们都将“Status”列保持为“Reserved (1)”。另一个选择是拥有主-次配置,这样,当主服务崩溃时,次服务可以接管。我们没有将等待的用户存储在数据库中,所以,当WaitingUsersService崩溃时,除非我们有主次设置,否则我们没有任何方式恢复那些数据。

同样,我们会为数据库设置主次配置,以使其具有容错性。

11、数据分区

数据库分区:如果我们按‘MovieID’进行分区,那么一部电影的所有场次都会在同一个服务器上。对于热门电影来说,这可能会给那台服务器带来大量负载。更好的方法是根据ShowID进行分区;这样,负载就可以分散到不同的服务器上。

ActiveReservationService和WaitingUserService分区:我们的Web服务器将管理所有活动用户的会话,并处理与用户的所有通信。我们可以使用一致性哈希算法来根据‘ShowID’为ActiveReservationService和WaitingUserService分配应用服务器。这样,特定场次的所有预订和等待用户将由某一组服务器处理。假设为了负载平衡,我们的"一致性哈希"为任何场次分配了三个服务器,那么每当一个预订过期时,持有该预订的服务器将执行以下操作:

  1. 更新数据库以移除预订(或标记为过期)并更新‘Show_Seats’表中座位的状态。
  2. 从Linked HashMap中移除预订。
  3. 通知用户他们的预订已过期。
  4. 向所有持有该场次等待用户的WaitingUserService服务器广播消息,以找出等待时间最长的用户。一致性哈希方案将告诉我们哪些服务器持有这些用户。
  5. 如果所需的座位已经变为可用,就向持有最长等待用户的WaitingUserService服务器发送消息以处理他们的请求。

每当一个预订成功时,将发生以下事情:

  1. 持有该预订的服务器向所有持有该场次等待用户的服务器发送消息,以便这些服务器可以使所有需要的座位数多于可用座位数的等待用户过期。
  2. 收到上述消息后,所有持有等待用户的服务器将查询数据库,以查找现在有多少个空闲座位。此处的数据库缓存将大大有助于只运行一次这个查询。
  3. 使所有希望预订的座位数多于可用座位数的等待用户过期。为此,WaitingUserService必须遍历所有等待用户的Linked HashMap。
来源:今日头条内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯