红软基地 推荐
2012-01-18
三类请求的业务处理过程，被分为两个阶段，
1. 运行于缓存中的任务队列。设置队列的目的，是防止处理过程耗时太长，导致大量用户请求拥塞于门户服务器，导致系统瘫痪。
2. 业务处理处理器，对于每一类业务，分别有一群业务服务器。不同业务的处理流程，各不相同。
图二。12306.cn 网站查询和订票业务流程设想图。
Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/12306-1.png
图二描述了查询和订票，两个业务的处理流程。登记业务流程从略。
查询的业务流程，参见图二上半部，分五步。这里有两个问题需要注意，
1. 用户发出请求后，经过短暂的等待时间，能够迅速看到结果。平均等待时间不能超过 1 秒。
2. 影响整个查询速度的关键，是“查询服务器”的设计。
查询任务可以进一步细化，大致分成三种。
1. 查询车次和时间表，这是静态内容，很少与数据库交互，数据量也不大，可以缓存在内存中。
车次和时间表的数据结构，不妨采用 Key-Value 的方式，开发简单，使用效率高。Key-Value 的具体实现有很多产品，[5] 建议使用 Redis。
这些是技术细节，不妨通过对比实验，针对火车票订票系统的实际流量，以及峰值波动，确定哪一个产品最合适。
2. 查询某一班次的剩余车票，这需要调用数据库中不断更新的数据。
[5] 建议把剩余车票只分为两种，“有”或“无”，这样减少调用访问数据库的次数，降低数据库的压力。但是这样做，不一定能够满足用户的需求，说不定会招致网友的批评讥讽。
[4] 建议在订票队列中，增加测算订票队列长度的功能，根据订票队列长度以及队列中每个请求的购票数量，可以计算出每个车次的剩余座位。如果 12306.cn 网站只有一个后台系统，这个办法行之有效。
但是假如 12306.cn 网站采用分布式结构，每个铁路分局设有子系统，分别管理各个铁路分局辖区内的各个车次。在分布式系统下，这个办法面临任务转发的麻烦。不仅开发工作量大，而且会延长查询流程处理时间，导致用户长久等待。
3. 已经下单的用户，查询是否已经成功地订上票。
每个用户通常只关心自己订的票。如果把每个用户订购的车票的所有内容，都缓存在内存里，不仅非常耗用内存空间，内存空间使用效率低下，更严重的问题是，访问数据库过于频繁，数据量大，增大数据库的压力。
解决上述分布式同步，以及数据库压力的两个问题，不妨从订票的流程设计和数据结构设计入手。
假如有个北京用户在网上订购了一套联票，途经北京铁路局和郑州铁路局辖区的两个车次。用户从北京上网，由北京铁路局的子系统，处理他的请求。北京铁路局的订票服务器把他的请求一分为二，北京铁路局的车次的订票，在北京子系统完成，郑州铁路局的车次在郑州子系统完成。
每个子系统处理四种 Key-Value 数据组。
1. 用户ID：多个 (订单ID)s。
2. 订单ID：多个 (订票结果ID)s。
3. 订票结果ID: 一个 (用户ID，车次ID)。
4. 车次ID：一个(日期)，多个 (座位，用户ID)。
北京订票服务器完成订票后，把上述四个数据组，写入北京子系统的数据库，同时缓存进北京的查询服务器，参见图二下半部第6步和第7步。
郑州订票服务器完成订票后，把上述四个数据组，写入郑州子系统的数据库，同时缓存进北京的查询服务器，而不是郑州的服务器。
让订票服务器把订票数据，同时写入数据库和查询服务器的缓存，目的是让数据库永久保留订票记录，而让大多数查询，只访问缓存，降低数据库的压力。
北京用户的订票数据，只缓存在北京的查询服务器，不跨域缓存，从而降低缓存空间的占用，和同步的麻烦。这样做，有个前提假设，查询用户与订票用户，基本上是同一个人，而且从同一个城市上网。
但是这里有个缺陷，某用户在北京上网订了票。过了几天，他在北京上网，输入用户ID和密码后，就会看到他订购的所有车票。可是又过了几天，他去了郑州，从郑州上网，同样输入用户ID和密码，却看不到他订购的所有车票。
解决这个缺陷的办法并不麻烦，在用户查询订票信息时，需要注明订票地点，系统根据订票地点，把查询请求转发到相应区域的子系统。
另外，每次订票的时候，网站会给他的手机发送短信，提供订票信息，参见图二下半部第8步和第9步。
来源：admin5