务器和至少一个从票池服务器，η个中间层的哨兵应用服务器，η为奇数且大于3，至少2个上层的监视器构成主从机制和哨兵机制；所述的票池中间件包括多个票池集群；
通过多个Redis实例之间的主从机制和哨兵功能，搭建票池集群，可以大大的提高稳定性和可用性。票池中间件可以包括多个集群；集群的架构图如图2所示。哨兵之间，以及哨兵应用服务器与底层主从票池服务器示之间通过socket通信，本实施例中，票池集群由7个服务器组成，在底层是一个Redis主票池服务器和一个Redis从票池服务器，中间层是3个哨兵应用服务器，上层是2个监视器。主从机制一方面提高了数据安全性，(因为Redis把数据放在内存中，一旦进程崩溃，可能会导致数据丢失，从票池服务器作为主票池服务器的备份，一定程度避免了这一点)，另一方面可以做读写分离，提高吞吐量。除此之外，配合中间层哨兵应用服务器，主从票池服务器之间可以做热切换。哨兵应用服务器两两之间通过socket通彳目来知晓对方状态，同时和主票池服务器也进彳T socket通彳目来知晓其运彳丁状态，以及它的从票池服务器的运行状态。在主票池服务器崩溃的或者失去连接的情况下，从票池服务器会通过投票机制来推举从票池服务器成为新的主票池服务器，当只有一个从票池服务器时，此从票池服务器成为新的主票池服务器，而不必重新启动系统。上层的监视器通过Redis的订阅一发布机制，能够监视每个进程，包括主票池服务器、从票池服务器和哨兵应用服务器的运行状态。同时使用2个从票池服务器进一步提高了可用性，使其在一个崩溃的状态下，仍然能正常运行。
[0018]如图3，具体包括如下步骤；
步骤1:在票池集群中采取相应的数据结构表示各类票务数据；将各项票务操作活动的读写属性，在票池中间层的哨兵应用服务器的配置文件中进行配置；以便明确地指明，票池操作活动和主票池服务器、从票池服务器之间的关系，各项操作所使用的至少一个从票池服务器、η个中间层的哨兵应用服务器，η为奇数且大于3，至少2个上层的监视器，运行时在票池集群中动态确定。
[0019]步骤2:在从票池服务器的配置文件中配置主票池服务器的IP地址和端口号，以至少一个的从票池服务器对一个主票池服务器的方式进行配置；
主从复制是实现哨兵集群的基础。对于本票池中间件，需要在从票池服务器的配置文件配置主票池服务器的IP地址和端口号，以至少一个的从票池服务器对一个主票池服务器的方式进行配置。
[0020]步骤3:在底层的多至少一个从票池服务器对一个主票池服务器配置基础上，使用η个中间层的哨兵对主从票池服务器的监视与管理，η为奇数且大于3 ;本实施例中，在至少一个从票池服务器对一个主票池服务器配置基础上，使用3个哨兵应用服务器来做主从机制的监视与管理。哨兵应用服务器对内能够判断各个主从票池服务器的状态，在主票池服务器宕机或者断网时，能够做主从热切换。宕机或断网的Redis启动后，能够再次加入票池集群作为从票池服务器使用。设置3个哨兵应用服务器的原因，一是在于保证可用性，一个会导致单点故障(哨兵也有可能宕机)，3个同时宕机的可能性基本不存在；二是在于3个有利于投票机制。哨兵在判断Redis进程崩溃或断网，以及启动故障恢复(Failover)的过程中都会通过投票机制完成，奇数有利于投票的尽快完成。在哨兵应用服务器配置文件中分别设置哨兵应用服务器的地址和端口，同时还需要设置一些基本参数:比如主票池服务器的地址；主票池服务器、从票池服务器以及其它哨兵应用服务器的宕机判断条件；故障恢复的启动时间等等。
[0021]步骤4:设置至少2个上层的监视器检测每个服务器(票池集群中的每个服务器)的状态；并向外发布信息；单个票池集群搭建完成，所述的票池中间件包括多个票池集群，每个票池集群有唯一的ID标识，票池中间件构建完成。
同时为了检测每个进程(包括主票池服务器、从票池服务器、哨兵应用服务器)的状态，设置两个监视器。监视器需要配置每个服务进程(即主票池服务器、从票池服务器、哨兵应用服务器)的IP和端口号。监视器还作为WCF Service向外发布服务，通过该服务可以知道票池集群中每个服务器的状态。
[0022]一种利用所述的票池中间件的购票方法，如下所述:
票池中间件接收售票客户端的票务请求，票池集群之间由VPN互联，票务请求由票池中间件代理服务器进行代理路由，其中，票池中间件代理服务器作为票池集群之间的代理服务器，然后定位到票池集群上；票池中间件再完成购票请求，返回购票或查询列表；
每个票池集群由站务公司ID标识，票池集群之间由VPN互联，各个售票客户端的请求由代理服务进行路由，来定位到合适的票池集群上。这种结构也可以很好的应用于比如全省乃至全国范围的联网票务活动、大型连锁电影院线的票池系统中。
[0023]售票客户端(包括窗口售票程序、手机APP、网站售票等各种票务应用)，通常设置有分布式缓存，用于存放相对静态的班次数据集，其目的是对于班次日期之类的查询，不涉及到剩余票据的查询，都在本地或者就近发生(手机APP和网站售票的分布式缓存设置在应用服务器、或者Web服务器中)。
[0024]具体步骤如下:
步骤1:售票客户端首先根据日期、出发和到达站点等信息，就近查询分布式缓存，获取到具体的日期班次信息。然后，由售票客户端向票池中间件，发起查询余票的请求，其输入数据是出发站点的ID、以及一组日期班次集。
[0025]票池中间件将根据请求中的票池集群ID，对于请求进行路由，将请求重定位到水平分割之后、存储了指定始发站所有票据信息的票池集群，同时将一组日期班次集传入，作为进一步查询余票信息的输入数据。
[0026]票池集群将根据输入的日期班次集，逐一地在票池集群中查找指定班次对应的班次车票集、对应班次的售票锁票集、对应班次的管理锁票集，所有这些集合的内容加在一起，可以从逻辑上，完整地描述指定日期班次的所有票据信息。这些集合在完成差、并运算之后，可以返回指定日期班次的所有剩余、待售的票据，并将每个日期班次的完整的票据列表组织为一个集合，回传给售票客户端，售票客户端可能根据需要，仅显示可售票数、或者显不出完整的待售列表。
[0027]步骤2:售票客户端从票池集群中获取到日期班次、及其对应的待售票据信息后，在本地可以进行指定座位号、或者是随机选座的方式，继续进行购票。指定座位号表示，顾客明确地指定了所购车票的座位号；而随机选座，则表示顾客仅指定购票张数，具体的座位号由系统自动生成。对于指定座位号的购票方式，售票客户端需要将日期班次集、以及每个日期班次集关联的一个座位号的列表(包括每张车票的座号、购买信息、全半价等)传递给票池集群；而对于随机选座方式，售票客户端可以指定购买信息，然后将日期班次集、以及每个日期班次集关联的待购张数(仅包括购买信息、全半价等)信息传递给票池集群。
[0028]步骤3:票池集群根据售票客户端传入的信息，通过票池集群进行售票锁票操作。对于指定座位号的购票方式，票池集群在接收到票池集群返回的日期班次集、以及每个日期班次集关联的一个座位号的列表后，会对票池集群中的实时票据进行逐张的售卖活动。
[0029]对于随机选座方式，票池集群将根据连续优先的原则，从低号段开始，为售票客户端请求生成一个座位号列表，同时按照前述的方法，对车票进行加锁处理，并将成功锁定的票据，返回给售票客户端。在票池集群中，以会话Sess1n (⑶ID)的形式记录了每个售票客户端的所有锁票请求，作为下一步售票活动的依据。
步骤4:售票客户端根据请求，继续进行票据的售卖活动、或者放弃票据的购买。对购买或放弃，则需要指定具体日期班次、以及座位号，进行单张或多张票据的放弃或购买操作。直至完成所有操作，并确认进行购买活动。
[0030]步骤5:票池集群将根据售票客户端的请求，遍历其请求的所有票据，逐张进行票据售卖操作。对于每一张票据，首先会将待售车票从相应的日期班次集中移除、从相应的日期班次售票锁票集中移除，最后删除掉当前售卖车票的锁对象，完成单张车票的售卖活动。
[0031]步骤6