三、数据分区
数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，把数据分区。数据分区有很多种做法，一般来说有下面这几种：
1)把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。
2)把数据按字段分，也就是坚着分表。比如把一些不经常改的数据放在一个表里，经常改的数据放在另一个表里。把一张表变成 1 对 1 的关系，这样，你可以减少表的字段个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的页表里，这对于读写性能都有问题。
3)平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。所以，也有采用平均分配的方式，通过主键 ID 的范围来分表。
4)同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的服务器上，比如有 10000 个库存，可以分到 10 台服务器上，一台上有 1000 个库存。然后负载均衡。
这三种分区都有好有坏。最常用的还是第一种。数据一量分区，你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，会对 12306 这个系统有非常有意义的质的性能的提高。
四、后端系统负载均衡
前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程序。因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。
任务分配服务器有一些难点：
负载情况比较复杂。什么叫忙?是 CPU 高?还是磁盘I/O高?还是内存使用高?还是并发高?你可能需要全部都要考虑。这些信息要发送给那个任务分配器上，由任务分配器挑选一台负载最轻的服务器来处理。
任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以以批量的方式把任务分配给计算服务器。
任务分配服务器死了怎么办?这里需要一些如 Live-Standby 或是 failover 等高可用性的技术。我们还需要注意那些持久化了的任务的队列如果转移到别的服务器上的问题。
我看到有很多系统都用静态的方式来分配，有的用 hash，有的就简单地轮流分析。这些都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知道。
还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法可能是比较好的负载均衡。
五、异步、 throttle 和批量处理
异步、throttle(节流阀) 和批量处理都需要对并发请求数做队列处理的。
异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处理程序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a)被调用方的结果返回，会涉及进程线程间通信的问题。b)如果程序需要回滚，回滚会有点复杂。c)异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d)很多异步系统都用消息机制，消息的丢失和乱序也会是比较复杂的问题。
throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理的流量给搞垮了，这其实是个保护机制。使用 throttle 技术一般来说是对于一些自己无法控制的系统，比如，和你网站对接的银行系统。
批量处理的技术，是把一堆基本相同的请求批量处理。比如，大家同时购买同一个商品，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操作。这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的 MTU(最大传输单元)，以态网是 1500 字节，光纤可以达到 4000 多个字节，如果你的一个网络包没有放满这个 MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率才会高。因此，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一种批量处理的方式。批量处理的敌人是流量低，所以，批量处理的系统一般都会设置上两个阀值，一个是作业量，另一个是 timeout，只要有一个条件满足，就会开始提交处理。
所以，只要是异步，一般都会有 throttle 机制，一般都会有队列来排队，有队列，就会有持久化，而系统一般都会使用批量的方式来处理。
云风同学设计的“排队系统” 就是这个技术。这和电子商务的订单系统很相似，就是说，我的系统收到了你的购票下单请求，但是我还没有真正处理，我的系统会跟据我自己的处理能力来 throttle 住这些大量的请求，并一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可以真正购票了。
在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深入思考的地方：
1)队列的 DoS 攻击。首先，我们思考一下，这个队是个单纯地排队的吗?这样做还不够好，因为这样我们不能杜绝黄牛，而且单纯的 ticket_id 很容易发生 DoS 攻击，比如，我发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正常不能访问，让用户只能通过他们来买。
2)对列的一致性?对这个队列的操作是不是需要锁?只要有锁，性能一定上不去。试想，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数据库实现得性能好，所以，可能比现在还差
3)队列的等待时间。购票时间半小时够不够?多不多?要是那时用户正好不能上网呢?如果时间短了，用户也会抱怨，如果时间长了，后面在排队的那些人也会抱怨。这个方法可能在实际操作上会有很多问题。另外，半个小时太长了，这完全不现实，我们用 15 分钟来举例：有 1 千万用户，每一个时刻只能放进去 1 万个，这 1 万个用户需要 15 分钟完成所有操作，那么，这 1 千万用户全部处理完，需要 1000*15m = 250 小时，10天半，火车早开了。(我并乱说，根据铁道部专家的说明：这几天，平均一天下单 100 万，所以，处理 1000 万的用户需要十天。这个计算可能有点简单了，我只是想说，在这样低负载的系统下用排队可能都不能解决问题)
4)队列的分分式。这个排队系统只有一个队列好吗?还不足够好。因为，如果你放进去的可以购票的人如果在买同一个车次的同样的类型的票(比如某动车卧铺)，还是等于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。因此，最好的方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队列也就可以是多个，只要是多个队列，就可以水平扩展了。
我觉得完全可以向网上购物学习。在排队(下单)的时候，收集好用户的信息和想要买的票，并允许用户设置购票的优先级，比如，A车次卧铺买不到就买 B 车次的卧铺，如果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地异步处理订单。成功不成功都发短信或邮件通知用户。这样，系统不仅可以省去那半个小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理(减少数据库的操作次数)。这种方法最妙的事是可以知道这些排队用户的需求，不但可以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，让铁道部做车次统筹安排和调整(最后，排队系统(下单系统)还是要保存在数据库里的或做持久化，不能只放在内存中，不然机器一 down，就等着被骂吧)。
小结
写了那么多，我小结一下：
0)无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加 3 倍的服务器”才不会被人讥笑。
1)上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。
2)集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。
3)春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的人在某个早晨的 8 点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的变态决定了无论他们怎么办干一定会被骂。
4)为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，也就是铁路才干得出来这样的事了。
