12306的已知信息、数据及问题
　　需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
　　需求分析（二）—— 涉众、用户体验
　　核心业务需求及逻辑架构分析
　　需求分析（三）—— 票仓
　　票仓设计（一）—— 预生成车票方案的优缺点
　　票仓设计（二）—— 区间二进制方案的优缺点
　　票仓设计（三）—— 平衡方案的优缺点
　　票务并发冲突处理原则设计（基于平衡方案）
　　缓存逻辑架构设计
　　数据库逻辑设计
　　灾难备份与恢复
　　快要太监了 :-(
　　由于各种个人原因， 铁道部的这个博文系列中止了很久。近终于连自己都不好意思了。所以还是继续完成它吧，估计1-2周一篇的节奏。
　　感觉不先划分一下大的系统架构总会让大家感觉有点头晕， 不过没能力对整个12306进行设计，这个货太大了。只是借这个机会谈谈自己对系统结构分析的一些感想
　　朴素的面向对象分析
　　面向对象是一个万金油，但是据说真正懂的人不多是吧？
　　我对面向对象的感觉是: 他本质上是对现实世界的抽象，其表面现象是不断细分对象的粒度，提升对象的抽象度。终形成一种用有限数量的独立的对象“积木”构造整个需求不断变化的系统的目标。
　　而系统级别的分析也大致如此，我们可以借鉴类分析中的很多概念，不断划小系统规模，剥离职责，抽出依赖性。
　　一般系统结构
　　这里只是一个简单模型，用以表达我对多数项目的结构分析。

　　配置数据服务：系统运行所需要的动态配置信息
　　资产数据服务：所有实际或虚拟的“物”的管理（CRUD），甚至可以包括人。
　　业务数据服务：该企业实际经营的业务产生的数据。超市的收银记录，企业的销售记录，铁道部的售票记录
　　报表数据服务：各类统计报表需要的
　　其中业务系统和业务数据服务应该是核心的部分。
　　一般而言，那些配置和资产管理的部分不会造成严重的性能问题。只要在实现CRUD的时候多考虑考虑相关的业务需求，努力做到任何资产的属性变动时，确保相关的业务完整性好（出租公司管理系统里，一辆出租车还在运营，后台系统不应该可以轻松地把它标记成报废车辆，连软删除都是不合理的做法）。
　　12306之所以能招人民围观，我觉得主要还是花的钱和大家的感受之间有落差。而我阴暗的以为这个问题的核心部分在票务处理的部分。
　　所以我后续的几篇博文都会围绕票务处理里面的内容展开。
　　另外，我要大家了解的是，我是要设计一个合理的区间票售票系统核心。而不是实现铁道部的需求。本质上我认为铁道部不会说清楚他自己的需求，而太极公司的需求分析有可以进一步深挖的可能。
　　12306核心需求及模块分析
　　整体架构没法子设计，太大了。有兴趣的可以参考
　　中国铁路客票发售和预订系统5_0版的研究与实现
　　国铁路客票发售和预订系统5.0版本(TRSv5.0)售票与经由维护操作说明
　　目前我专注的是用于订票的部分。我感觉这个是重要的部分。
　　12306大的问题，是如何在订票的时候高效率得并且适当优化得找到需要数量的车票。并且要能彻底保证一张票不会被两个请求同时处理成功。
　　只要这个问题无法彻底解决，任何分布式处理，终都会卡在这个问题上。
　　我会涉及到的模块