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

随着信息技术和互联网的发展，票务系统也在不断升级，比如实现了移动支付、电子票据、实时数据分析等先进功能。此外，许多票务系统还引入了人工智能和大数据技术，用于精准营销、个性化推荐和风险管理。,然而，票务系统也存在一些挑战，如如何保护用户隐私，如何防止票务欺诈，以及如何提供更好的用户体验等。因此，票务系统的开发和运营需要考虑到这些问题，并持续改进和升级。,,项目简介：大麦网是中国的领先在线票务平台，提供多样化的活动票务，如音乐会、戏剧和体育赛事等。主要功能包括活动搜索、在线购票、电子票务、实时座位选择、退换票服务以及支付接口。其智能推荐系统可以根据用户兴趣推送相关活动，为用户提供方便、快捷的一站式购票体验。,类似的产品有：猫眼娱乐、永乐票务、bookmyshow.com、ticketmaster.com,难度级别：困难,电影票预订系统为其客户提供在线购买影院座位的能力。电子票务系统允许客户浏览当前正在上映的电影，并在任何地方任何时候预订座位。,我们的票务预订服务应满足以下需求：,功能需求：,非功能性需求：,流量估计：我们假设我们的服务每月有30亿次页面浏览，每月售出1000万张电影票。,存储估计：假设我们有500个城市，平均每个城市有10家影院。如果每个影院有2000个座位，平均每天有两场放映。,我们假设每个座位预订需要50字节（ID、NumberOfSeats、ShowID、MovieID、SeatNumbers、SeatStatus、Timestamp 等）存储在数据库中。我们还需要存储关于电影和影院的信息；我们假设它会需要50字节。所以，要存储所有城市的所有影院的所有放映的所有数据一天：,500个城市 * 10家影院 * 2000个座位 * 2场放映 * (50+50) 字节 = 2GB / 天,要存储五年的这些数据，我们大约需要3.6TB。,我们可以有SOAP或REST API来公开我们服务的功能。以下可能是搜索电影放映和预订座位的API的定义。,参数：,返回：（JSON） 以下是电影及其放映的示例列表：,参数：,返回：（JSON）,返回预订的状态，其中包括以下之一：,以下是我们即将存储的数据的一些观察：,,在顶层面上，我们的web服务器将管理用户的会话，应用服务器将处理所有的票务管理，将数据存储在数据库中，以及与缓存服务器一起处理预订。,,首先，我们试着建立服务，假设它是由一个单一的服务器提供的。,票务预订流程：以下将是典型的票务预订流程：,,服务器如何跟踪所有尚未预订的活动预订？服务器又如何跟踪所有等待的客户？ 我们需要两个守护服务，一个用来跟踪所有活动的预订并从系统中移除任何过期的预订；我们称之为ActiveReservationService。另一个服务将跟踪所有等待的用户请求，一旦需要的座位数变得可用，它将通知（等待时间最长的）用户选择座位；我们称之为WaitingUserService。,我们可以在内存中保留一个与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都会收到一个信号，以便可以为任何等待的客户提供服务。,,就像ActiveReservationsService一样，我们可以将一个演出的所有等待用户存储在Linked HashMap或TreeMap的内存中。我们需要一个类似于Linked HashMap的数据结构，以便我们可以在用户取消请求时跳转到任何用户以从HashMap中移除他们。此外，由于我们是以先到先得的方式服务，Linked HashMap的头部总是指向等待时间最长的用户，因此每当座位变得可用时，我们都可以以公平的方式为用户提供服务。,我们将有一个HashTable用来存储每个Show的所有等待用户。’key’将是’ShowID’，’value’将是包含’UserIDs’和他们的等待开始时间的Linked HashMap。,客户端可以使用Long Polling来保持自己的预订状态更新。每当座位变得可用时，服务器可以使用这个请求来通知用户。,预订过期,在服务器上，ActiveReservationsService跟踪活动预订的过期时间（基于预订时间）。由于客户端将显示一个计时器（用于过期时间），这可能与服务器稍微不同步，我们可以在服务器上添加五秒钟的缓冲区以防止破碎的体验，从而确保客户端在服务器超时后永不超时，防止成功购买。,如何处理并发性，以便没有两个用户能够预订同一座位。我们可以在SQL数据库中使用事务来避免任何冲突。例如，如果我们使用的是SQL服务器，我们可以利用事务隔离级别来锁定行，然后再更新它们。下面是样本代码：,’Serializable’ 是最高的隔离级别，可以保证免受脏读、不可重复读和幻读的影响。这里要注意一点；在一个事务中，如果我们读取了行，我们会在这些行上加写锁，以防止它们被任何其他人更新。,一旦上述数据库事务成功，我们就可以开始在ActiveReservationService中跟踪预订情况。,当ActiveReservationsService或WaitingUsersService崩溃时会发生什么？ 每当ActiveReservationsService崩溃时，我们可以从‘Booking’表中读取所有的活动预订。请记住，直到预订完成，我们都将“Status”列保持为“Reserved (1)”。另一个选择是拥有主-次配置，这样，当主服务崩溃时，次服务可以接管。我们没有将等待的用户存储在数据库中，所以，当WaitingUsersService崩溃时，除非我们有主次设置，否则我们没有任何方式恢复那些数据。,同样，我们会为数据库设置主次配置，以使其具有容错性。,数据库分区：如果我们按‘MovieID’进行分区，那么一部电影的所有场次都会在同一个服务器上。对于热门电影来说，这可能会给那台服务器带来大量负载。更好的方法是根据ShowID进行分区；这样，负载就可以分散到不同的服务器上。,ActiveReservationService和WaitingUserService分区：我们的Web服务器将管理所有活动用户的会话，并处理与用户的所有通信。我们可以使用一致性哈希算法来根据‘ShowID’为ActiveReservationService和WaitingUserService分配应用服务器。这样，特定场次的所有预订和等待用户将由某一组服务器处理。假设为了负载平衡，我们的”一致性哈希”为任何场次分配了三个服务器，那么每当一个预订过期时，持有该预订的服务器将执行以下操作：,每当一个预订成功时，将发生以下事情：