在需求高并发的情形下，系统如何控制并发需求的资源分配？

数据必须实时一致性，才能保证不会超售。电子客票的移动支付业务要求很高，更像银行，因为一旦支付成功， 不能马上生效，如果保证客运站能够实时看到数据提供客票。 公路客票实际就是
联机交易：客户并发量大，交易响应实时性要求高。交易需要满足原子性、一致性、隔离性和持久性，要求具备ACID的特性，否则在事务处理的过程中无法保证数据的完整一致性。

- A(Atomicity,原子性)：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

- C(Consistency,一致性)：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。

- I(Isolation,隔离性)：两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。

- D(Durability,持久性)：在事务完成以后，该事务所对数据库所作的更改会持久的保存在数据库之中，并不会被回滚交易处理涉及产品面广，相应的数据库实体较多并结构复杂

例如，淘宝的订单处理是比银行的凭证更简单的业务类型,而支付交易基本也只是完成银行内部转账的交易

基于银行这种多样化的数据信息，无非分为两种数据基本处理策略-数据实时强一致性（ACID）和基本可用最终一致（BASE）。以帐务处理为例，解释他们的区别：

如果接受BASE计算模式，以下场景会发生：

•你到银行存了1000元，当天查询银行存款发现账户上没有这1000元，但是银

行承诺第二天系统会自动补上，你能接受吗？还会在这家银行继续存款吗？

•如果双十一在淘宝上您用1000元买了一些打了三折优惠的正品（平日最低八

折），你当天发现购物清单和账户上的余额对不上，多扣了1000元，但是淘宝承第二天系统会自动补上，你能接受吗？你明知道同样扣错款的事情会发生，明年的双十一你还会在淘宝上抢购商品吗？

BASE的数据处理策略不适用于电子客票支付清算业务，我们的企业可能投资再大的资源从应用层面解决事务的完整性和数据完整性吗？

银行交易事务

ACID：整个事务中的所有操作，要么全部完成，要么全部不完成，事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，数据库的完整性没有被破坏。两个事务的执行是互不干扰的。在事务完成以后，该事务所对数据库所作的更改会持久的保存在数据库之中

分布式计算中由于部分部件失效(尤其是网络)会产生业务操作是否生效，对于非幂等操作如果没有完善的应用处理将会产生1000亿转帐多次重复造成千亿元错帐。

联网售票和移动支付时的业务逻辑就是要保证数据的一致性，就是在保证有剩余票数的情况下，才可以完成下单和支付。

为了控制并发需求的资源分配，可以有多种处理方式。

1、采用负载均衡设备，对高并发访问进行同时处理，针对不同的访问进程设置优先级，优先级高的可以正常下单完成支付，对于优先级低的进程返回下单失败。

2、随机选择有效的下单请求，达到可售票数量后即可终止请求。

3、采用排队机制，按照访问时间顺序，每次只处理一定数量的连接请求，处理完毕后不再接受新的连接请求。

以上无论采用哪种方式，都需要保证订单数量不能超过余票数量，已经成交的订单需要保留一定的“锁定时间”完成支付，超过支付时间再将余票资源释放出来。

再高的并发请求，再多的购票渠道，最后无非都要落到数据库里。只有完成支付流程（付完钱），数据库得到结果，才会出票。会出现查询有票，在支付过程中显示无票，完不成交易的，但绝不会出现超售的情况