建设公司宣传网站,软件开发流程八个步骤及介绍,网站建设qianhaiyou,商城网站模板框架文章目录何为在线售票系统#xff1f;系统目标和要求1、功能要求2、非功能性需求3、设计注意事项4、容量估算5、系统API1.SearchMovies2.ReserveSeats6、数据库设计7、高级设计8、细节模块设计9、流程服务器如何跟踪所有尚未预订的active预订#xff1f;服务器如何跟踪所有等… 文章目录何为在线售票系统系统目标和要求1、功能要求2、非功能性需求3、设计注意事项4、容量估算5、系统API1.SearchMovies2.ReserveSeats6、数据库设计7、高级设计8、细节模块设计9、流程服务器如何跟踪所有尚未预订的active预订服务器如何跟踪所有等待的客户ActiveReservationServiceWaitingUsersService10、并发性11、容错性12、数据分区 何为在线售票系统
电影票预订系统为其客户提供了在线购买影院座位的能力。Eticketing系统允许客户浏览当前正在播放的电影并预订座位随时随地。
系统目标和要求
1、功能要求
功能要求
1、我们的售票服务应该能够列出其附属影院所在的不同城市。2、一旦用户选择城市服务应显示在该特定城市发布的电影。3、一旦用户选择了一部电影服务应显示运行该电影的电影院及其可用放映时间。4、用户应该能够在特定电影院选择一场演出并预订门票。5、服务应能向用户展示影院大厅的座位安排。用户应该能够根据自己的喜好选择多个座位。6、用户应能区分可用座位和预定座位。7、用户应能在付款完成预订之前将座位保留五分钟。8、如果座位有可能可用例如当其他用户持有的座位过期时用户应该能够等待。9、等待的客户应以公平、先到先服务的方式进行服务。
2、非功能性需求
1、系统需要高度并发。
在任何特定时间点同一座位都会有多个预订请求。服务应该优雅而公平地处理这一问题。
2、这项服务的核心是订票即金融交易。
这意味着系统应该是安全的并且数据库符合ACID。
3、设计注意事项
1。为简单起见假设我们的服务不需要任何用户身份验证。
2、系统不处理部分客票订单。要么用户得到了他们想要的所有门票要么什么也得不到。
3、公平是制度的强制性要求。
4、为了防止系统滥用我们可以限制用户一次预订10个以上的座位。
5、我们可以假设在人们期待已久的热门电影上映时流量会急剧上升座位很快就会挤满。该系统应具有可扩展性和高可用性以跟上流量激增的步伐。
4、容量估算
1、流量估计
假设我们的服务每月有30亿次页面浏览量销量为10%一个月一百万张票。
2、存储量估计
假设我们有500个城市平均每个城市有10家电影院。如果每家电影院有2000个座位平均每天有两场演出。
假设每个座位预订需要50字节ID、NumberOfSeats、ShowID、MovieID、SeatNumber、SeatStatus、Timestamp等存储在数据库中。我们还需要存储关于电影和电影院的信息假设需要50字节。所以要存储所有关于所有城市的所有电影院一天的放映
500 cities * 10 cinemas * 2000 seats * 2 shows * (5050) bytes 2GB / day
要存储五年的数据我们需要大约3.6TB。
5、系统API
我们可以使用SOAP或RESTAPI来公开服务的功能。以下可能是用于搜索电影节目和预订座位的API的定义。
1.SearchMovies api参数讲解
api_dev_key (string): 注册账户的API开发人员密钥。这将用于根据分配的配额限制用户。keyword (string): 要搜索的关键字city (string): 筛选电影的城市lat_long (string): 用来过滤的经纬度信息radius (number): 要搜索事件的区域半径 start_datetime (string): 用来筛选的电影的开始日期end_datetime (string): 用来筛选的电影的结束日期postal_code (string): 用来筛选的邮政编码includeSpellcheck (Enum: “yes” or “no”): 拼写检查建议results_per_page (number): 每页返回的结果数。 Maximum is 30. sorting_order (string): 对搜索结果进行排序.
Some allowable values : ‘name,asc’, ‘name,desc’, ‘date,asc’, ‘date,desc’, ‘distance,asc’, ‘name,date,asc’,
‘name,date,desc’, ‘date,name,asc’, ‘date,name,desc’. 下面是电影及其节目的示例列表后台的Returns: (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: RegularPrice: 14.99Status: Almost Full},{Type: PremiumPrice: 24.99Status: 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: RegularPrice: 14.99Status: Full},{ Type: PremiumPrice: 24.99Status: Almost Full}]},]2.ReserveSeats api参数讲解
api_dev_key (string): same as above session_id (string): 用于跟踪此预订的用户会话ID。一旦保留时间到期将使用此删除用户在服务器上的保留
身份证件movie_id (string): 要预定的电影show_id (string): 要预定的场次eats_to_reserve (number): 包含要保留的座位ID的数组
下面是api返回值Returns: (JSON)
Returns the status of the reservation, which would be one of the following:
1) “Reservation Successful”
2) “Reservation Failed - Show Full,”
3) “Reservation Failed - Retry, as other users are holding reserved seats”. 6、数据库设计
我们要存储的数据
1、每个城市可以有多家电影院。
2、每家电影院将有多个大厅。
3、每部电影将有多场演出每场演出将有多个预订。
4、一个用户可以进行多次预订。
下面是UML表单图设计 7、高级设计
在上层我们的web服务器将管理用户会话应用服务器将处理所有票证管理将数据存储在数据库中并与缓存服务器一起处理预订。 8、细节模块设计
首先让我们尝试构建我们的服务假设它是从单个服务器提供的。
以下是典型的售票流程
1.用户搜索电影。
2.用户选择一部电影。
3.向用户显示电影的可用放映。
4.用户选择一个场次。
5.用户选择要预订的座位数目
6.如果有所需数量的座位则会向用户显示要选择的剧院地图座位。如果没有用户将进入下面的“步骤8”。
7.一旦用户选择了座位系统将尝试预订这些选定的座位。
8.如果无法预订座位我们有以下选择
本场次已满座向用户显示错误消息用户想要预订的座位不再可用但还有其他座位可用因此用户将返回影院地图以选择不同的座位。没有可用的座位可预订但是进入选定状态的座位有些还没有支付也就是预订池中有一些其他用户持有的座位尚未预订。用户将进入等待页面在那里他们可以等待直到所需的座位从预订池中释放出来。这种等待可能会导致以下选项 如果所需的座位数量可用用户将被带到剧院地图页面在那里他们可以选择座位。等待期间如果所有座位都已预订成功或者预订池中的座位数少于用户预定的座位数则会向用户显示错误消息。用户取消等待并返回到电影搜索页面。在用户会话过期并返回到电影搜索页面后用户最多可以等待一个小时。
9.如果成功预订座位用户有五分钟的时间支付预订费用。付款后预订被标记为完成。如果用户无法在五分钟内付款则其所有预留座位将被释放以供其他用户使用。 整个流程如下 9、流程 服务器如何跟踪所有尚未预订的active预订服务器如何跟踪所有等待的客户
我们需要两个守护程序服务一个用于跟踪所有active预订并从系统中删除任何过期的预定我们称之为ActiveReservationService。
另一项服务将跟踪所有等待的用户请求一旦所需的座位数可用它将通知等待时间最长的用户选择座位我们叫它WaitingUserService吧。
ActiveReservationService
除了将所有数据保存在数据库中之外我们还可以将本场次的所有预定保留在内存中保存在类似于链接HashMap或TreeMap的数据结构中。
我们需要一个链接的HashMap类型的数据结构允许我们跳转到任何预订以便在预订完成后将其删除。
此外由于我们将有与每个保留相关联的过期时间哈希映射的头部将始终指向最旧的保留记录以便在达到超时时可以过期保留。
为了存储每个场次的每个预订我们可以有一个哈希表其中“key”是“ShowID”而“value”是包含“BookingID”和创建“Timestamp”的链接哈希表。
在数据库中我们将预订存储在“Booking”表中过期时间将在时间戳列中。
“Status”状态字段的值为“Reserved1”一旦预订完成系统会将“Status”状态更新为“Booked2”并从相关节目的链接哈希表中删除预订记录。当预订过期时除了从内存中删除外我们还可以将其从预订表中删除或将其标记为“过期3”。
ActiveReservationsService还将与外部金融服务一起处理用户付款。无论何时预订完成或预订过期WaitingUsersService都会收到信号以便为任何等待的客户提供服务。 WaitingUsersService
就像ActiveReservationsService一样我们可以将一个场次的所有等待用户保存在链接哈希映射或树映射的内存中。我们需要一个类似于链接HashMap的数据结构这样当用户取消请求时我们就可以跳转到任何用户将其从HashMap中删除。此外由于我们以先到先得的方式提供服务链接HashMap的头部将始终指向等待时间最长的用户因此每当有座位可用时我们都可以以公平的方式为用户提供服务。
我们将有一个哈希表来存储每个节目的所有等待用户。“key”将是“ShowID”“value”将是一个包含“userid”及其等待开始时间的链接HashMap。客户端可以使用长轮询来更新自己的预订状态。每当座位可用时服务器都可以使用此请求通知用户。
在服务器上ActiveReservationsService跟踪活动预订的到期时间基于预订时间。由于客户端将显示一个计时器用于过期时间该计时器可能与服务器有点不同步因此我们可以在服务器上添加一个5秒的缓冲区以防止出现中断的体验这样客户端就不会在服务器之后超时从而阻止成功购买。
10、并发性
如何处理并发性以便没有两个用户能够预订同一个座位。我们可以在SQL数据库中使用事务来避免任何冲突。例如如果我们使用的是SQL server我们可以利用事务隔离级别锁定行然后再更新它们。以下是示例代码
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;-- Suppose we intend to reserve three seats (IDs: 54, 55, 56) for ShowID99
Select * From Show_Seat where ShowID99 and ShowSeatID in (54, 55, 56) and
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中开始跟踪保留。
11、容错性
当ActiveReservationsService或WaitingUserService崩溃时会发生什么情况
每当ActiveReservationsService崩溃时我们都可以从“Booking”表中读取重新所有active预定。请记住在预订之前我们将“状态”列保留为“预定1”。
另一种选择是进行主从配置以便在主服务器崩溃时从服务器可以接管。
我们没有将等待的用户存储在数据库中因此当WaitingUsersService崩溃时我们没有任何方法来恢复该数据除非我们有主从设置。类似地我们将对数据库进行主从设置使其具有容错性。
12、数据分区
数据库分区如果我们按“MovieID”进行分区那么一部电影的所有放映都将在一台服务器上进行。对于非常热门的电影这可能会在该服务器上造成大量负载。更好的方法是基于ShowID进行分区这样负载就可以分布在不同的服务器上。
ActiveReservationService和WaitingUserService分区
我们的web服务器将管理所有active用户的会话并处理与用户的所有通信。我们可以使用一致性哈希根据“ShowID”为ActiveReservationService和WaitingUserService分配应用程序服务器。
这样特定场次的所有预订和等待用户都将由一组特定的服务器处理。
让我们假设为了负载平衡我们的一致哈希为任何场次分配三台服务器因此每当预订过期时持有该预订的服务器将执行以下操作
1、更新数据库以删除预订或将其标记为过期并更新“Show seats”表中的座位状态。
2、从链接的HashMap中删除保留。
3、通知用户其预约已过期。
4、向所有等待该节目的等待用户的WaitingUserService服务器广播一条消息以找出等待时间最长的用户。一致性哈希将告诉哪些服务器容纳这些用户。如果所需座位可用则向等待时间最长的用户所在的WaitingUserService服务器发送消息以处理其请求。
无论何时预订成功都会发生以下情况
1。持有该预订的服务器将向持有该节目等待用户的所有服务器发送一条消息以便这些服务器可以终止需要比可用座位更多座位的所有等待用户。
2、在收到上述消息后所有等待用户的服务器都会查询数据库以确定现在有多少免费座位。在这里数据库缓存将非常有助于只运行一次此查询。
3、让所有想预订比可用座位更多座位的等待用户过期。为此WaitingUserService必须遍历所有等待用户的链接HashMap。
