CN104809510B - 一种提供票务支持的票池中间件的构建、购票及锁票方法 - Google Patents
一种提供票务支持的票池中间件的构建、购票及锁票方法 Download PDFInfo
- Publication number
- CN104809510B CN104809510B CN201510262322.8A CN201510262322A CN104809510B CN 104809510 B CN104809510 B CN 104809510B CN 201510262322 A CN201510262322 A CN 201510262322A CN 104809510 B CN104809510 B CN 104809510B
- Authority
- CN
- China
- Prior art keywords
- ticket
- pond
- ticketing
- shift
- date
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明提供了一种提供票务支持的票池中间件构建、购票及锁票方法,通过搭建票池集群;构建一个最底层主服务器和多个从服务器,n个中间层的哨兵,至少2个最上层的监视器构成主从机制(Master‑Slave)和哨兵机制(Sentinel);本发明通过搭建一种高并发、高可用的健壮的票池中间件,在支持各类票务操作的同时,能够以中间件的形式,适用于各种票务活动场景。
Description
技术领域
本发明涉及中间件领域,特别涉及一种提供票务支持的票池中间件的构建、购票及锁票方法。
背景技术
很多商业活动中都存在一种业务——凭票入座,比如车票、电影票、热门演唱会的门票等等。它们有两个共同的特点:一是稀缺性,票是有限的,越是热门的票争抢越激烈;二是准确性,票与座要一一对应,一张票只能卖给一个人。这类售票系统在逻辑上往往可以抽象出一个“池”,卖方可以向这个池加票、减票,而买方可以从这个池中取票。这个池也就是,票池。
传统的售票系统往往采用关系型数据库(例如SQL Server、MySQL)来实现票池,但是面对同一票池、甚至是对同一张票的大量并发操作,往往在高吞吐量和高可靠性之间难以两全,极有可能会出现一张票被卖给多个人、实时性低、响应速度非常慢、不支持灵活的票务操作的情况。因此非常有必要设计一种支持高并发、高可用的健壮的票池中间件,在支持各类票务操作的同时,能够以中间件的形式,适用于各种票务活动场景。
发明内容
针对现有技术存在的缺陷和不足之处,本发明提供了一种提供票务支持的票池中间件的构建、购票及锁票方法,同时适用于大范围(比如全省联网、全国联网)的票务需求。
为了解决上述技术问题,提出了一种提供票务支持的票池中间件构建方法,如下所述:
搭建单个票池集群;通过构建底层的一个主票池服务器和至少一个从票池服务器,n个中间层的哨兵应用服务器,n为奇数且大于3,至少2个上层的监视器构成主从机制和哨兵机制;所述的票池中间件包括多个票池集群;具体包括如下步骤;
步骤1:在票池集群中采取相应的数据结构表示各类票务数据;将各项票务操作活动的读写属性,在票池中间层的哨兵应用服务器的配置文件中进行配置;
步骤2:在从票池服务器的配置文件中配置主票池服务器的IP地址和端口号,以至少一个底层的从票池服务器对一个主票池服务器的方式进行配置;
步骤3:在至少一个底层的从票池服务器对一个主票池服务器配置基础上,使用n个中间层的哨兵应用服务器对主从票池服务器的监视与管理,n为奇数且大于3;
步骤4:设置至少2个上层的监视器检测每个服务器的状态;并向外发布信息;单个票池集群搭建完成,所述的票池中间件包括多个票池集群,每个票池集群有唯一的ID标识,票池中间件构建完成。
优选的,所述的票池集群基于Redis内存数据库作为构建票池的存储基础。
优选的,所述的步骤1中的票池服务器数据结构特征如下:
1.车票信息使用“日期、班次号:座位号”的键值形式进行标识;
2.日期班次有3个集合,使用的键值分别是:“日期:班次号”、“日期:班次号:SaleLocked”、“日期:班次号:CommandLocked”;
其中,“日期:班次号”表示某个日期班次的余票集,“日期:班次号:SaleLocked”表示某个日期班次的售票锁票集,“日期:班次号:CommandLocked”表示某个日期班次的管理锁票集。
一种利用权利要求3所述票池中间件的购票方法,票池中间件接收售票客户端的票务请求,票池集群之间由VPN互联,票务请求由票池中间件代理服务器进行代理路由,然后定位到票池集群上;票池中间件再完成购票请求,返回购票或查询列表;
具体包括下述步骤:
步骤1: 售票客户端首先根据日期、出发和到达站点信息,就近查询分布式缓存,获取到具体的日期班次信息;然后,向票池中间件,发起查询余票的请求,输入数据是出发站点的ID、以及一组日期班次集;
票池中间件根据请求中的票池集群ID,对于请求进行路由,将请求重定位到票池集群中水平分割之后、存储了指定始发站所有票据信息的票池集群,同时将一组日期班次集传入,作为进一步查询余票信息的输入数据;
票池集群将根据输入的日期班次集,逐一地在内存数据库中查找指定班次对应的班次余票集、对应班次的售票锁票集、对应班次的管理锁票集,将所有集合的内容汇总描述指定日期班次集;
步骤2:售票客户端根据票池集群中获取到日期班次集,在本地进行指定座位号、或者随机选座方式,进行购票;对于指定座位号的购票方式,将日期班次集、以及每个日期班次集关联的一个座位号的列表传递给票池集群;对于随机选座方式,指定购票信息,然后将日期班次集、以及每个日期班次集关联的待购张数信息传递给票池集群;
步骤3:票池集群根据售票客户端传入的购票信息,对待购票据进行售票锁票操作;对于指定座位号的购票方式,在接收到日期班次集、以及每个日期班次集关联的一个座位号的列表后,对票池集群中的实时票据进行逐张售卖活动;
对于随机选座方式,票池集群将根据连续优先原则,从低号段开始,为售票客户端请求生成一个座位号列表,对车票进行加锁处理,并将成功锁定的票据,返回给售票客户端;在票池集群中,以会话Session的形式记录每个售票客户端的所有锁票请求,作为下一步售票的依据;
步骤4:售票客户端根据请求继续进行票据的购买或者放弃票据的购买;
步骤5:票池集群将根据售票客户端的请求,逐张进行票据售卖;对于每一张票据,首先将待售车票从相应的日期班次集中移除、从相应的日期班次售票锁票集中移除,完成单张车票的售卖;
步骤6:如果进行售卖活动时锁定成功的票超过了售票锁的时限,自动回到票池中变成待售状态;否则,票池集群将会在售票客户端提交购票请求后,返回给售票客户端完整的、成功购票的列表;
步骤7:锁定成功之后,票池中间件将成功购得的票加入到对应日期班次集的售票锁票集;
步骤8:结束。
一种利用权利要求3所述的票池中间件的锁票方法,具体包括下述步骤:
步骤1:管理客户端根据起始站点、日期、班次号、所属票池集群ID查询班次计划;选择要管理的班次计划,所述的班次计划包括日期和班次号标识,查询所有票的状态,包括被售票锁定、被管理锁定、可用、异常;对被售票锁定、被管理锁定和异常状态的票,不进行下一步操作;
步骤2:对于选择指定座位号的管理员请求,指定数目,生成请求的座位号列表,请求票池中间件进行锁定;票池中间件遍历输入座位号列表,逐张进行锁定操作,如锁票不成功,则返回锁定成功的座位号列表,得到管理锁票集;
步骤4:对于随机锁票,票池中间件先查询该班次计划的余票集,遍历余票集,逐张锁定,直至达到指定数目或者余票集遍历结束,同样返回锁定成功的座位号列表;票池中间件以随机的方式选择出指定数据的余票,得到管理锁票集;
步骤5:票池中间件对管理锁票集中的所有票,进行锁定操作;在锁定时,指定锁定时间,并且记录临时锁票的用户姓名;
步骤6:结束。
优选的,所述的管理客户端的权限包括锁定和解锁票,以管理员锁的形式预留或者放弃预留票。
本发明的有益效果是:一种提供票务支持的票池中间件构建方法购票及锁票方法,通过搭建一种高并发、高可用的健壮的票池中间件,在支持各类票务操作的同时,能够以中间件的形式,适用于各种票务活动场景。
附图说明
图1-1 本发明中锁票过程第一步骤的示意图;
图1-2本发明中锁票过程第二步骤的示意图;
图1-3 本发明中锁票过程第三步骤的示意图;
图2 本发明中票池集群设计图;
图3 本发明的票池中间件构建的流程图。
具体实施方式
一种提供票务支持的票池中间件构建方法,包括:
搭建票池集群;通过构建底层的一个主票池服务器和至少一个从票池服务器,n个中间层的哨兵应用服务器,n为奇数且大于3,至少2个上层的监视器构成主从机制和哨兵机制;所述的票池中间件包括多个票池集群;
通过多个Redis实例之间的主从机制和哨兵功能,搭建票池集群,可以大大的提高稳定性和可用性。票池中间件可以包括多个集群;集群的架构图如图2所示。哨兵之间,以及哨兵应用服务器与底层主从票池服务器示之间通过socket通信,本实施例中,票池集群由7个服务器组成,在底层是一个Redis主票池服务器和一个Redis从票池服务器,中间层是3个哨兵应用服务器,上层是2个监视器。主从机制一方面提高了数据安全性,(因为Redis把数据放在内存中,一旦进程崩溃,可能会导致数据丢失,从票池服务器作为主票池服务器的备份,一定程度避免了这一点),另一方面可以做读写分离,提高吞吐量。除此之外,配合中间层哨兵应用服务器,主从票池服务器之间可以做热切换。哨兵应用服务器两两之间通过socket通信来知晓对方状态,同时和主票池服务器也进行socket通信来知晓其运行状态,以及它的从票池服务器的运行状态。在主票池服务器崩溃的或者失去连接的情况下,从票池服务器会通过投票机制来推举从票池服务器成为新的主票池服务器,当只有一个从票池服务器时,此从票池服务器成为新的主票池服务器,而不必重新启动系统。上层的监视器通过Redis的订阅-发布机制,能够监视每个进程,包括主票池服务器、从票池服务器和哨兵应用服务器的运行状态。同时使用2个从票池服务器进一步提高了可用性,使其在一个崩溃的状态下,仍然能正常运行。
如图3,具体包括如下步骤;
步骤1:在票池集群中采取相应的数据结构表示各类票务数据;将各项票务操作活动的读写属性,在票池中间层的哨兵应用服务器的配置文件中进行配置;以便明确地指明,票池操作活动和主票池服务器、从票池服务器之间的关系,各项操作所使用的至少一个从票池服务器、n个中间层的哨兵应用服务器,n为奇数且大于3,至少2个上层的监视器,运行时在票池集群中动态确定。
步骤2:在从票池服务器的配置文件中配置主票池服务器的IP地址和端口号,以至少一个的从票池服务器对一个主票池服务器的方式进行配置;
主从复制是实现哨兵集群的基础。对于本票池中间件,需要在从票池服务器的配置文件配置主票池服务器的IP地址和端口号,以至少一个的从票池服务器对一个主票池服务器的方式进行配置。
步骤3:在底层的多至少一个从票池服务器对一个主票池服务器配置基础上,使用n个中间层的哨兵对主从票池服务器的监视与管理,n为奇数且大于3;本实施例中,在至少一个从票池服务器对一个主票池服务器配置基础上,使用3个哨兵应用服务器来做主从机制的监视与管理。哨兵应用服务器对内能够判断各个主从票池服务器的状态,在主票池服务器宕机或者断网时,能够做主从热切换。宕机或断网的Redis启动后,能够再次加入票池集群作为从票池服务器使用。设置3个哨兵应用服务器的原因,一是在于保证可用性,一个会导致单点故障(哨兵也有可能宕机),3个同时宕机的可能性基本不存在;二是在于3个有利于投票机制。哨兵在判断Redis进程崩溃或断网,以及启动故障恢复(Failover)的过程中都会通过投票机制完成,奇数有利于投票的尽快完成。在哨兵应用服务器配置文件中分别设置哨兵应用服务器的地址和端口,同时还需要设置一些基本参数:比如主票池服务器的地址;主票池服务器、从票池服务器以及其它哨兵应用服务器的宕机判断条件;故障恢复的启动时间等等。
步骤4:设置至少2个上层的监视器检测每个服务器(票池集群中的每个服务器)的状态;并向外发布信息;单个票池集群搭建完成,所述的票池中间件包括多个票池集群,每个票池集群有唯一的ID标识,票池中间件构建完成。
同时为了检测每个进程(包括主票池服务器、从票池服务器、哨兵应用服务器)的状态,设置两个监视器。监视器需要配置每个服务进程(即主票池服务器、从票池服务器、哨兵应用服务器)的IP和端口号。监视器还作为WCF Service向外发布服务,通过该服务可以知道票池集群中每个服务器的状态。
一种利用所述的票池中间件的购票方法,如下所述:
票池中间件接收售票客户端的票务请求,票池集群之间由VPN互联,票务请求由票池中间件代理服务器进行代理路由,其中,票池中间件代理服务器作为票池集群之间的代理服务器,然后定位到票池集群上;票池中间件再完成购票请求,返回购票或查询列表;
每个票池集群由站务公司ID标识,票池集群之间由VPN互联,各个售票客户端的请求由代理服务进行路由,来定位到合适的票池集群上。这种结构也可以很好的应用于比如全省乃至全国范围的联网票务活动、大型连锁电影院线的票池系统中。
售票客户端(包括窗口售票程序、手机APP、网站售票等各种票务应用),通常设置有分布式缓存,用于存放相对静态的班次数据集,其目的是对于班次日期之类的查询,不涉及到剩余票据的查询,都在本地或者就近发生(手机APP和网站售票的分布式缓存设置在应用服务器、或者Web服务器中)。
具体步骤如下:
步骤1:售票客户端首先根据日期、出发和到达站点等信息,就近查询分布式缓存,获取到具体的日期班次信息。然后,由售票客户端向票池中间件,发起查询余票的请求,其输入数据是出发站点的ID、以及一组日期班次集。
票池中间件将根据请求中的票池集群ID,对于请求进行路由,将请求重定位到水平分割之后、存储了指定始发站所有票据信息的票池集群,同时将一组日期班次集传入,作为进一步查询余票信息的输入数据。
票池集群将根据输入的日期班次集,逐一地在票池集群中查找指定班次对应的班次车票集、对应班次的售票锁票集、对应班次的管理锁票集,所有这些集合的内容加在一起,可以从逻辑上,完整地描述指定日期班次的所有票据信息。这些集合在完成差、并运算之后,可以返回指定日期班次的所有剩余、待售的票据,并将每个日期班次的完整的票据列表组织为一个集合,回传给售票客户端,售票客户端可能根据需要,仅显示可售票数、或者显示出完整的待售列表。
步骤2:售票客户端从票池集群中获取到日期班次、及其对应的待售票据信息后,在本地可以进行指定座位号、或者是随机选座的方式,继续进行购票。指定座位号表示,顾客明确地指定了所购车票的座位号;而随机选座,则表示顾客仅指定购票张数,具体的座位号由系统自动生成。对于指定座位号的购票方式,售票客户端需要将日期班次集、以及每个日期班次集关联的一个座位号的列表(包括每张车票的座号、购买信息、全半价等)传递给票池集群;而对于随机选座方式,售票客户端可以指定购买信息,然后将日期班次集、以及每个日期班次集关联的待购张数(仅包括购买信息、全半价等)信息传递给票池集群。
步骤3:票池集群根据售票客户端传入的信息,通过票池集群进行售票锁票操作。对于指定座位号的购票方式,票池集群在接收到票池集群返回的日期班次集、以及每个日期班次集关联的一个座位号的列表后,会对票池集群中的实时票据进行逐张的售卖活动。
对于随机选座方式,票池集群将根据连续优先的原则,从低号段开始,为售票客户端请求生成一个座位号列表,同时按照前述的方法,对车票进行加锁处理,并将成功锁定的票据,返回给售票客户端。在票池集群中,以会话Session(GUID)的形式记录了每个售票客户端的所有锁票请求,作为下一步售票活动的依据。
步骤4:售票客户端根据请求,继续进行票据的售卖活动、或者放弃票据的购买。对购买或放弃,则需要指定具体日期班次、以及座位号,进行单张或多张票据的放弃或购买操作。直至完成所有操作,并确认进行购买活动。
步骤5: 票池集群将根据售票客户端的请求,遍历其请求的所有票据,逐张进行票据售卖操作。对于每一张票据,首先会将待售车票从相应的日期班次集中移除、从相应的日期班次售票锁票集中移除,最后删除掉当前售卖车票的锁对象,完成单张车票的售卖活动。
步骤6:如果进行售卖活动时锁定成功的票超过了售票锁的时限,自动回到票池中变成待售状态;否则,票池集群将会在售票客户端提交购票请求后,返回给售票客户端完整的、成功购票的列表;
由于每个售票客户端在进行售卖活动时,售票锁是有时限的,默认设置为3分钟,大量售票客户端在进行并发购票的活动中,可能锁定成功的票超过了售票锁的时限,自动回到票池中变成待售状态,而后被另外的售票客户端完成了售票活动。为了解决这种并发竞争的问题,票池集群将会在客户端提交购票请求后,返回给售票客户端完整的、成功购票的列表,以便为售票客户端提供完整的返回信息。
步骤7:锁定成功之后,票池中间件将成功购得的票加入到对应日期班次集的售票锁票集;
首先,会尝试对指定票据进行售票加锁操作,如果成功,则表示该票据目前仍处于可售卖状态;否则,则表示从上次售票客户端查询到现在,指定票据的状态发生了变化,要么该票据已经销售,要么已被其他并发的售票客户端锁定,无法继续进行销售。锁定成功之后,票池中间件会将其加入到对应日期班次集的售票锁集合,以避免其他售票客户端对当前待售票据进行查询和检索,从而相互产生干扰。
步骤8:结束。
一种利用所述的票池中间件的锁票方法,具体包括下述步骤:
管理客户端可以在售票过程中,对票池中间件进行实时监视,包括锁定和解锁票。管理客户端为售票客户端的一种,但是可以出于业务上的考虑,以管理员锁的形式,预留或者放弃预留一些票。
步骤1:管理客户端根据起始站点、日期、班次号、所属票池集群ID查询班次计划;选择要管理的班次计划,所述的班次计划包括日期和班次号标识,查询所有票的状态,包括被售票锁定、被管理锁定、可用、异常;对被售票锁定、被管理锁定和异常状态的票,不进行下一步操作;
步骤2:对于选择指定座位号的管理员请求,指定数目,生成请求的座位号列表,请求票池中间件进行锁定;票池中间件遍历输入座位号列表,逐张进行锁定操作,如锁票不成功,则返回锁定成功的座位号列表,得到管理锁票集;
步骤4:对于随机锁票,票池中间件先查询该班次计划的余票集,遍历余票集,逐张锁定,直至达到指定数目或者余票集遍历结束,同样返回锁定成功的座位号列表;票池中间件以随机的方式选择出指定数据的余票,得到管理锁票集;
步骤5:票池中间件对管理锁票集中的所有票,进行锁定操作;在锁定时,指定锁定时间,并且记录临时锁票的用户姓名;
步骤6:结束。
本发明采用了Redis内存数据库作为构建票池中间件的存储基础,将所有票放在内存中。由于所有数据都存储在内存中,Redis的读写操作都非常快,读写时间几乎稳定在毫秒级,与数据的规模无关,非常适合高并发的场景;同时,通过主-从机制进行主从复制,一方面提高数据的安全性,一方面实现了读写分离,可以通过中间件集群的水平扩展,实现票务活动的查询与票务购销操作的高度分离,进一步大幅度提升了执行效率;在一主多从或一主一从的主-从方式的基础上,本方法还设计并使用哨兵建立票池集群,使得主从之间能够实现自动的无缝切换,增强票池中间件系统的稳定性和可用性。
与现有技术相比,本发明中票池中间件系统的主要内容包括:
1.表示票据实体(比如车票)和从属实体(比如班次)的各类数据结构,以及与各种具体票务活动相对应的利用票池中间件的购票方法和锁票方法。
与关系型数据库按照实体属性和实体之间的关联关系的设计不一样,本方法在Redis内部使用了键、集合、哈希表、排序集等数据结构来实现和表示各类数据,并在键值的设计上,采取了特殊编码方式,以适应各种不同的查询需求。具体内容,以车票为例,描述如下:
a)车票信息使用“日期:班次号:座位号”的键形式进行标识。
b)日期班次有3个集合,它们使用的键值分别是:“日期:班次号”、“日期:班次号:SaleLocked”、“日期:班次号:CommandLocked”;
它们分别对应3个集合。第一个集合表示这个日期班次的余票集,第二个集合表示这个日期班次的售票锁票集,第三个集合表示这个日期班次的管理锁票集。
c)在a)、b)数据结构设计的基础上,各类票池中间件操作方法的设计与实现,包括车票查询(站站查询、车次查询、地区查询)、单/多张车票的售票、指定座次或随机选座的单/多张车票的售票、多班次联合售票、退票、改签车票、电话订票、推票入池等一系列方法。下面以车票查询为例简要说明:
比如,查询2015年1月16日班次号为ABC的可用余票,逻辑上可以表示为
SDIFF 2015-01-16:ABC
2015-01-16:ABC:CommandLocked
2015-01-16:ABC:SaleLocked
SDIFF是Redis的命令,是求第1个集合和第2、3两个集合的差集,是在余票中除去所有已被锁定的票,包括售票锁票和管理锁票。
2.各种票据锁对象的数据结构,以及与锁票活动相对应的票池中间件的操作方法。
在本票池中间件的内存数据库中,使用“Lock:日期:班次号:座位号”的逻辑形式,表示一张票对应的锁。锁操作的过程及原理见说明书附图1-1,图1-2,图1-3。
在大量并发场景下,必须保证对于一张票只有一个售票客户端能够拿到锁,以进行对该张票的后续操作。以车票票池为例,锁票流程如下。
如图1-1,步骤一:图中共有四个售票客户端A、B、C、D同时向票池中间件发起请求,其中A请求锁定3号票,B和C都请求锁定2号票,D请求锁定8号票。对应的操作指令分别是A执行指令SETNX(Lock:SD:003,1) B、C 执行指令SETNX(Lock:SD:002,1) D 执行指令SETNX(Lock:SD:008,1)
如图1-2,步骤二: SETNX指令,它可以设置一个键值对,当这个键不存在时,设置成功且返回1;否则设置失败且返回0。由于每条指令都是原子的,且是单线程按顺序执行的,所以保证了对于同一张票只有一个售票客户端能拿到锁。如附图1所示,售票客户端A、C、D拿到了锁,而B与C竞争锁失败。之后,A、C两个售票客户端把已锁票加入售票锁票集,而D把已锁票加入管理锁票集,这是因为D是由管理客户端发起的请求。把票加入管理锁票集的原因是方便查看票的状态,避免使用遍历的方式观察票的状态。在这两步操作之后,锁票工作就完成了,可以进行售票之类的操作了。
如图1-3,步骤三:对于在售票锁定之后,并成功完成了销售活动的车票,将从票池中的各个集合中对其进行移除,包括余票集、售票锁票集等,以正确反映出实时票务活动的进行情况。售票在锁票的基础之上完成。在图1中,2、3号已经被售票锁票集锁定。之后的操作分为三步:第一步即是从余票集合中删除2、3号票;第二步即是从售票锁票集删除2、3号票;第三步即是删除2、3号票对应的锁对象,即键Lock:SD:002和键Lock:SD:003。
3.票务活动各类性能计数器,用于提供实时票务活动的统计信息,例如最大速度(MaxSpeed)和时刻、平均销售速度、余票总数(LeftCount)、班次总数等数据,可以依情况设置。
4.主-从及读写分离机制
本票池中间件,支持一主(Read-Write)多从(Read only)的主-从结构,所有票务数据的操作,在主服务器节点执行完成,并在集群中由主到从进行复制(Replication),确保了各节点上数据的实时一致性;在实现前述的各项票池操作时,本中间件对所有操作进行了读写操作的划分和标注,票池中间件系统会自动将这些操作根据其性质标注,重定向到某个主或从节点,从而实现更好的高并发。
5.基于哨兵机制实现主从切换
本票池中间件,使用哨兵机制,实时对集群中的所有主-从数据节点的活动状态进行监控,当发现主票池服务器工作状态或网络连接异常时,多个哨兵应用服务器采用投票机制,确定新的主票池服务器(提升某个从票池服务器),并在集群中无缝地完成新的主-从结构的建立,并在新的拓扑结构上重新启用读写分离机制。
6.基于监视器的代理(Agent)机制
本票池中间件,设计并实现了监视器机制,用于完成票务活动中需要第三方(非售方、非买方)参与的自动化操作,以满足特殊的票务活动需求。比如:以某种频率定期地、自动地更新性能计数器;或者在完成电话订票进行车票预售后(尚未付款)能够在提前预定的解锁时刻(如发车前2小时)自动将票据解锁入池;或者网络售票时,在付款超时的情况下,将票据解锁入池,以便重新进行销售。考虑到这些情况下所需要进行的非人工操作,本系统专门设计并实现了基于监视器的代理机制。
7.分布式缓存机制
分布式缓存机制也是本票池中间件的主要内容之一,所有售票客户端,包括窗口售票程序、提供网售功能的Web服务器、用于支持移动APP的应用服务器,在首次连接本票池中间件时,将完成自动的注册处理,以自动生成的GUID的形式唯一标识客户端程序,以便以双工的方式,将非实时的、票务查询所需的数据更新推送至售票客户端,形成基于网络的分布式缓存架构。分布式缓存机制在通信机制的设计上采用了WCF通信方式,完善地支持HTTP,TCP,Named Pipe,MSMQ,Peer-To-Peer TCP 等协议。
以上所述为本通信发明的最佳实施例,并非对本通信发明作任何形式上的限制,凡是依据本通信发明的技术实质对以上实例所作的任何简单修改、等同变化与修饰,均仍落入本通信发明的保护范围内。
Claims (4)
1.一种提供票务支持的票池中间件的构建、购票及锁票方法,其特征在于:
搭建单个票池集群;通过构建底层的一个主票池服务器和至少一个从票池服务器,n个中间层的哨兵应用服务器,n为奇数且大于3,至少2个上层的监视器构成主从机制和哨兵机制;所述的票池中间件包括多个票池集群;具体包括如下步骤;
步骤1:在票池集群中采取相应的数据结构表示各类票务数据;将各项票务操作活动的读写属性,在票池中间层的哨兵应用服务器的配置文件中进行配置;
步骤2:在从票池服务器的配置文件中配置主票池服务器的IP地址和端口号,以至少一个底层的从票池服务器对一个主票池服务器的方式进行配置;
步骤3:在至少一个底层的从票池服务器对一个主票池服务器配置基础上,使用n个中间层的哨兵应用服务器对主从票池服务器的监视与管理,n为奇数且大于3;
步骤4:设置至少2个上层的监视器检测每个服务器的状态;并向外发布信息;单个票池集群搭建完成,所述的票池中间件包括多个票池集群,每个票池集群有唯一的ID标识,票池中间件构建完成;
所述的步骤1中的票池服务器数据结构特征如下:
1.车票信息使用“日期、班次号:座位号”的键值形式进行标识;
2.日期班次有3个集合,使用的键值分别是:“日期:班次号”、“日期:班次号:SaleLocked”、“日期:班次号:CommandLocked”;
其中,“日期:班次号”表示某个日期班次的余票集,“日期:班次号:SaleLocked”表示某个日期班次的售票锁票集,“日期:班次号:CommandLocked”表示某个日期班次的管理锁票集;
所述的票池中间件接收售票客户端的票务请求,票池集群之间由VPN互联,票务请求由票池中间件代理服务器进行代理路由,然后定位到票池集群上;票池中间件再完成购票请求,返回购票或查询列表;
具体包括下述步骤:
步骤1:售票客户端首先根据日期、出发和到达站点信息,就近查询分布式缓存,获取到具体的日期班次信息;然后,向票池中间件,发起查询余票的请求,输入数据是出发站点的ID、以及一组日期班次集;
票池中间件根据请求中的票池集群ID,对于请求进行路由,将请求重定位到票池集群中水平分割之后、存储了指定始发站所有票据信息的票池集群,同时将一组日期班次集传入,作为进一步查询余票信息的输入数据;
票池集群将根据输入的日期班次集,逐一地在内存数据库中查找指定班次对应的班次余票集、对应班次的售票锁票集、对应班次的管理锁票集,将所有集合的内容汇总描述指定日期班次集;
步骤2:售票客户端根据票池集群中获取到日期班次集,在本地进行指定座位号、或者随机选座方式,进行购票;对于指定座位号的购票方式,将日期班次集、以及每个日期班次集关联的一个座位号的列表传递给票池集群;对于随机选座方式,指定购票信息,然后将日期班次集、以及每个日期班次集关联的待购张数信息传递给票池集群;
步骤3:票池集群根据售票客户端传入的购票信息,对待购票据进行售票锁票操作;对于指定座位号的购票方式,在接收到日期班次集、以及每个日期班次集关联的一个座位号的列表后,对票池集群中的实时票据进行逐张售卖活动;
对于随机选座方式,票池集群将根据连续优先原则,从低号段开始,为售票客户端请求生成一个座位号列表,对车票进行加锁处理,并将成功锁定的票据,返回给售票客户端;在票池集群中,以会话Session的形式记录每个售票客户端的所有锁票请求,作为下一步售票的依据;
步骤4:售票客户端根据请求继续进行票据的购买或者放弃票据的购买;
步骤5:票池集群将根据售票客户端的请求,逐张进行票据售卖;对于每一张票据,首先将待售车票从相应的日期班次集中移除、从相应的日期班次售票锁票集中移除,完成单张车票的售卖;
步骤6:如果进行售卖活动时锁定成功的票超过了售票锁的时限,自动回到票池中变成待售状态;否则,票池集群将会在售票客户端提交购票请求后,返回给售票客户端完整的、成功购票的列表;
步骤7:锁定成功之后,票池中间件将成功购得的票加入到对应日期班次集的售票锁票集;
步骤8:结束。
2.根据权利要求1所述的一种提供票务支持的票池中间件的构建、购票及锁票方法,其特征在于:所述的票池集群基于Redis内存数据库作为构建票池的存储基础。
3.根据权利要求1所述的一种提供票务支持的票池中间件的构建、购票及锁票方法,所述的锁票方法,其特征在于,具体包括下述步骤:
步骤1:管理客户端根据起始站点、日期、班次号、所属票池集群ID查询班次计划;选择要管理的班次计划,所述的班次计划包括日期和班次号标识,查询所有票的状态,包括被售票锁定、被管理锁定、可用、异常;对被售票锁定、被管理锁定和异常状态的票,不进行下一步操作;
步骤2:对于选择指定座位号的管理员请求,指定数目,生成请求的座位号列表,请求票池中间件进行锁定;票池中间件遍历输入座位号列表,逐张进行锁定操作,如锁票不成功,则返回锁定成功的座位号列表,得到管理锁票集;
步骤4:对于随机锁票,票池中间件先查询该班次计划的余票集,遍历余票集,逐张锁定,直至达到指定数目或者余票集遍历结束,同样返回锁定成功的座位号列表;票池中间件以随机的方式选择出指定数据的余票,得到管理锁票集;
步骤5:票池中间件对管理锁票集中的所有票,进行锁定操作;在锁定时,指定锁定时间,并且记录临时锁票的用户姓名;
步骤6:结束。
4.根据权利要求3所述的一种提供票务支持的票池中间件的构建、购票及锁票方法,其特征在于:所述的管理客户端的权限包括锁定和解锁票,以管理员锁的形式预留或者放弃预留票。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510262322.8A CN104809510B (zh) | 2015-05-21 | 2015-05-21 | 一种提供票务支持的票池中间件的构建、购票及锁票方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510262322.8A CN104809510B (zh) | 2015-05-21 | 2015-05-21 | 一种提供票务支持的票池中间件的构建、购票及锁票方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104809510A CN104809510A (zh) | 2015-07-29 |
CN104809510B true CN104809510B (zh) | 2018-07-27 |
Family
ID=53694320
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510262322.8A Expired - Fee Related CN104809510B (zh) | 2015-05-21 | 2015-05-21 | 一种提供票务支持的票池中间件的构建、购票及锁票方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104809510B (zh) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105491065A (zh) * | 2015-12-31 | 2016-04-13 | 深圳前海微众银行股份有限公司 | 消息中间件的资源访问方法、服务器及资源访问系统 |
CN107133677B (zh) * | 2016-02-29 | 2020-11-13 | 创新先进技术有限公司 | 检测购票过程中是否发生锁座异常的方法和装置 |
CN107203890B (zh) * | 2016-03-17 | 2021-02-23 | 创新先进技术有限公司 | 凭证数据发放方法、装置及系统 |
CN105933407B (zh) * | 2016-04-20 | 2019-12-06 | 中国银联股份有限公司 | 一种实现Redis集群高可用的方法及系统 |
CN106126673A (zh) * | 2016-06-29 | 2016-11-16 | 上海浦东发展银行股份有限公司信用卡中心 | 一种基于Redis和HBase的分锁方法 |
CN108062325A (zh) * | 2016-11-08 | 2018-05-22 | 北京京东尚科信息技术有限公司 | 比较方法和比较系统 |
CN106709039A (zh) * | 2016-12-29 | 2017-05-24 | 武汉达梦数据库有限公司 | 一种高并发操作环境中多用户高并发查询方法 |
CN106846123A (zh) * | 2017-02-20 | 2017-06-13 | 江苏蓝深远望科技股份有限公司 | 物品购买方法及装置 |
CN106920149B (zh) * | 2017-02-28 | 2020-10-30 | 武汉大学 | 一种支持多方联网票务的方法 |
CN108965355B (zh) * | 2017-05-18 | 2021-05-25 | 北京京东尚科信息技术有限公司 | 用于数据传输的方法、装置及计算机可读存储介质 |
CN108932556A (zh) * | 2017-05-27 | 2018-12-04 | 北京微影时代科技有限公司 | 一种锁定座位的方法及装置 |
CN107343034B (zh) * | 2017-06-26 | 2019-12-27 | 杭州铭师堂教育科技发展有限公司 | 基于QConf的Redis高可用系统及方法 |
CN113672645A (zh) * | 2021-07-26 | 2021-11-19 | 中国铁道科学研究院集团有限公司电子计算技术研究所 | 余票计算方法及系统 |
CN114331576A (zh) * | 2021-12-30 | 2022-04-12 | 福建博思软件股份有限公司 | 基于高并发场景下的电子票号快速取票方法及存储介质 |
CN114785713B (zh) * | 2022-03-31 | 2024-02-23 | 度小满科技(北京)有限公司 | 一种用于实现Redis集群高可用的方法和代理中间件 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103390246A (zh) * | 2013-07-30 | 2013-11-13 | 武汉大学 | 一种用于应对高并发的在线售票方法 |
CN103714487A (zh) * | 2013-12-19 | 2014-04-09 | 广东粤铁科技有限公司 | 轨道交通的票务系统及其购票验票方法 |
CN103838855A (zh) * | 2014-03-17 | 2014-06-04 | 广东创能科技有限公司 | 余票更新的方法 |
CN104182799A (zh) * | 2014-09-16 | 2014-12-03 | 成都北纬航信网络科技有限责任公司 | 基于移动互联网的机票预订及航信信息查询的方法和系统 |
US8918506B1 (en) * | 2002-10-10 | 2014-12-23 | NetCracker Technology Solutions Inc. | Architecture for a system and method for work and revenue management |
-
2015
- 2015-05-21 CN CN201510262322.8A patent/CN104809510B/zh not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8918506B1 (en) * | 2002-10-10 | 2014-12-23 | NetCracker Technology Solutions Inc. | Architecture for a system and method for work and revenue management |
CN103390246A (zh) * | 2013-07-30 | 2013-11-13 | 武汉大学 | 一种用于应对高并发的在线售票方法 |
CN103714487A (zh) * | 2013-12-19 | 2014-04-09 | 广东粤铁科技有限公司 | 轨道交通的票务系统及其购票验票方法 |
CN103838855A (zh) * | 2014-03-17 | 2014-06-04 | 广东创能科技有限公司 | 余票更新的方法 |
CN104182799A (zh) * | 2014-09-16 | 2014-12-03 | 成都北纬航信网络科技有限责任公司 | 基于移动互联网的机票预订及航信信息查询的方法和系统 |
Also Published As
Publication number | Publication date |
---|---|
CN104809510A (zh) | 2015-07-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104809510B (zh) | 一种提供票务支持的票池中间件的构建、购票及锁票方法 | |
US11899684B2 (en) | System and method for maintaining a master replica for reads and writes in a data store | |
CN104040526B (zh) | 对虚拟机池中的资源的分派 | |
CN104081353B (zh) | 可缩放环境中的动态负载平衡 | |
JP6165729B2 (ja) | クライアント/サーバシステムの分散した複製コンテンツの強一貫性を維持するための方法およびシステム | |
US9965364B2 (en) | Fault tolerant listener registration in the presence of node crashes in a data grid | |
CN106453665B (zh) | 基于分布式缓存系统的数据缓存方法、服务器和系统 | |
KR101429555B1 (ko) | 고 가용성 데이터를 제공하기 위한 시스템 및 방법 | |
CN107787490A (zh) | 分布式数据库网格中的直接连接功能 | |
CN101853186A (zh) | 分布式事务恢复系统和方法 | |
CN103226483B (zh) | 基于soa、云存储实现的双机热备份系统及其方法 | |
RU2606058C2 (ru) | Усовершенствованная система управления запасами и способ для ее осуществления | |
CN101771723A (zh) | 数据同步方法 | |
CN108319618B (zh) | 一种分布式存储系统的数据分布控制方法、系统及装置 | |
CN106933548A (zh) | 全局信息获取、处理及更新、方法、装置和系统 | |
CN105812423B (zh) | 一种云系统配置方法、服务器及装置 | |
CN107038192A (zh) | 数据库容灾方法和装置 | |
CN100449539C (zh) | 无共享数据库系统中的单相提交 | |
CN101930431A (zh) | 数据库备份信息清理系统及方法 | |
CN110830582A (zh) | 一种基于服务器集群选主方法和装置 | |
CN103095759B (zh) | 恢复资源环境的方法及设备 | |
CN101789963A (zh) | 数据同步系统 | |
CN105471986B (zh) | 一种数据中心建设规模评估方法及装置 | |
JP4571090B2 (ja) | スケジューラプログラム、サーバシステム、スケジューラ装置 | |
CN110083653A (zh) | 一种订单数据的操作方法、装置、计算机设备和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
EXSB | Decision made by sipo to initiate substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20180727 Termination date: 20200521 |
|
CF01 | Termination of patent right due to non-payment of annual fee |