假如我来架构12306网站(一) - 概论

wangfans

->系统巨量的交易数据转储、交易日志的转储问题， 这个问题的解决需要结合前面在设计时的 数据库垂直（按时间维度）扩展以及日志按照天的维度来进行维护的方式进行有计划地转储到不同时间段的历史库中，并且通过数据的清洗、整理将部分重要数据转入到OLAP/OLTP系统中，为后续系统基于实时交易数据的联机分析改进业务提供帮助；

wangfans

9. 优化阶段
  ->业务流程优化：这块最主要的问题是将购票这个核心业务按照计算机易于执行计算的模型来进行不断地优化，同时体验，譬如异步事务提交优化、排队技术等皆可以使用在用户的模型上，同时可以向用户提供预订业务等来降低某个时段的网站流量压力，使得流量的整体峰值、谷值差距缩小很多；

wangfans

->架构设计优化：在数据库的分区（垂直、水平分区）方面不断地进行优化，同时对于单数据库，就事务处理能力方面进行优化存储方面的操作，譬如使用固态硬盘替代传统的SCSI盘等，并行虚拟写技术等大幅提升磁盘I/O操作能力、或者采用内存数据库技术来管理好读写分离（读自内存、写到内存与磁盘同时），这样可以在数据库层面上获得性能的大幅提升；如果能够配合系统压力测试模型来获取其性能衰减曲线图针对性地优化，其效果将更加明显；

wangfans

在中间层服务器上，如何将不同的车次分布在大小几百个数据库上，并且使用反向搜索引擎技术来连接前端的访问请求到后端的数据库服务器之间的映射与集成（这点可以参考MapReduce并行算法）；
在应用层服务器上，如何将静态内容与动态内容予以剥离，并且无需保存的内容（只读）内容全放在内存中，如何平衡CDN加速与后端Web server的服务架构也是不断提升单个农场集群服务能力的关键与核心；

wangfans

->性能优化： 这些优化是非常之多的，譬如针对Web server的socket连接池优化、日志优化，针对中间集成服务器的并行任务分解与结果集成优化，基于后端数据库服务器的数据计算模型、访问方式、冗余与数据同步、传递优化、数据分区优化等；
  ->其他调优：其他方面的调优譬如基于监控的优化、基于大并发量的快速响应与扩展优化等等；

wangfans

写到此，感觉上似乎已经设计完毕了，不过突然回头一望，还真发现内容非常之多，可能有实战经验的朋友肯定会提到此系统属于“过度设计”了，不过笔者在此要说的是，确实这个最后的提醒是非常有必要的

wangfans

任何系统的设计特别是如此复杂的系统的设计只能是需要通过时间来循序渐进，先原型后实际系统并且遵循几轮研发调优（含架构设计调优），最后逐渐演变到一个真实成熟的系统，任何超前的设计最终都被证明是无用功而遭废弃；

wangfans

很多的网友对于12306的网站的技术议论纷纭，并且提出了众多的创造性想法，笔者在提出自己的想法后还有几点补充想法供大家参考：
1. 其实此网站的需求不是一个纯粹的技术问题，试想一下，真的按照国庆、春节的高峰访问需求来设计、部署整个系统的时候，在平时的时候大部分机器都是浪费的，如何平衡峰值与谷值时矛盾是个技术问题，可背后掩盖着的是全中国13亿多人口在短短的10-15天内完成众多的人口迁徙，如此巨大的工程放在任何一个国家都是难于解决的问题

wangfans

如何从需求层面来化解这个短期内的巨量人口流动问题才是此问题的命根； 正所谓 “ 解决火车票购买过程容易，而解决人人能买到火车票难！！！”
2. 此问题的求解永远是个迭代过程，需要看到的是很难有人能够在短期内设计并且实现这么一个巨量系统，这个工程问题的求解是拆解为不同的子模块来分步实现，并且逐步迭代优化求解的过程；

wangfans

3. 此问题的解决必须是个系统工程，牵涉到资金、技术、人才、时间 这4个基本要素，很多的同行过于看重人才与技术，而忽略了资金等前提性因素，试想如果只有3000万预算让你来设计实现这个巨型交易系统，你能解决么？ 不说别的，光性能模拟测试就需要调动数以万计的前端机器来在全国范围内不同的典型区域发起海量请求，这些是个小资金能够解决得了的问题么？