12306的已知信息、数据及问题
需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
需求分析（二）—— 涉众、用户体验
核心业务需求及逻辑架构分析
需求分析（三）—— 票仓
票仓设计（一）—— 预生成车票方案的优缺点
票仓设计（二）—— 区间二进制方案的优缺点
票仓设计（三）—— 平衡方案的优缺点
票务并发冲突处理原则设计（基于平衡方案）
缓存逻辑架构设计
数据库逻辑设计
灾难备份与恢复
快要太监了 :-(
由于各种个人原因, 铁道部的这个博文系列中止了很久。最近终于连自己都不好意思了。所以还是继续完成它吧，估计1-2周一篇的节奏。
感觉不先划分一下大的系统架构总会让大家感觉有点头晕, 不过没能力对整个12306进行设计，这个货太大了。只是借这个机会谈谈自己对系统结构分析的一些感想
朴素的面向对象分析
面向对象是一个万金油，但是据说真正懂的人不多是吧？
我对面向对象的感觉就是: 他本质上是对现实世界的抽象，其表面现象是不断细分对象的粒度，提升对象的抽象度。最终形成一种用有限数量的独立的对象“积木”构造整个需求不断变化的系统的目标。
而系统级别的分析也大致如此，我们可以借鉴类分析中的很多概念，不断划小系统规模，剥离职责，抽出依赖性。
一般系统结构
这里只是一个简单模型，用以表达我对多数项目的结构分析。
配置数据服务：系统运行所需要的动态配置信息
资产数据服务：所有实际或虚拟的“物”的管理（CRUD），甚至可以包括人。
业务数据服务：该企业实际经营的业务产生的数据。超市的收银记录，企业的销售记录，铁道部的售票记录
报表数据服务：各类统计报表需要的
其中业务系统和业务数据服务应该是最核心的部分。
一般而言，那些配置和资产管理的部分不会造成严重的性能问题。只要在实现CRUD的时候多考虑考虑相关的业务需求，努力做到任何资产的属性变动时，确保相关的业务完整性就好（出租公司管理系统里，一辆出租车今天还在运营，后台系统绝对不应该可以轻松地把它标记成报废车辆，连软删除都是不合理的做法）。
12306之所以能招全国人民围观，我觉得主要还是花的钱和大家的感受之间有落差。而我阴暗的以为这个问题的核心部分就在票务处理的部分。
所以我后续的几篇博文都会围绕票务处理里面的内容展开。
另外，我要大家了解的是，我是要设计一个合理的区间票售票系统核心。而不是实现铁道部的需求。本质上我认为铁道部不会说清楚他自己的需求，而太极公司的需求分析有可以进一步深挖的可能。
12306核心需求及模块分析
整体架构没法子设计，太大了。有兴趣的可以参考
中国铁路客票发售和预订系统5_0版的研究与实现
国铁路客票发售和预订系统5.0版本(TRSv5.0)售票与经由维护操作说明
目前我专注的是用于订票的部分。我感觉这个是最重要的部分。
12306最大的问题，就是如何在订票的时候高效率得并且适当优化得找到需要数量的车票。并且要能彻底保证一张票不会被两个请求同时处理成功。
只要这个问题无法彻底解决，任何分布式处理，最终都会卡在这个问题上。
我会涉及到的模块
