A. 谁能帮我做一个电子商务网站策划书，就是很普通的B2C,C2C，不需要太复杂
1、建设网站前的市场分析
（1）目前行业的市场分析（目前市场的情况调查分析、市场有什么样的特定和变化、目前是否能够并适合在因特网上开展业务。）
（2）市场的主要竞争者分析 （竞争对手上网情况及其网站规划、功能作用等）
（3）公司自身条件分析 （包括公司概况、市场优势，可以利用网站提升哪些竞争力，建设网站的能力――费用、技术、人力等。）
2、建设网站目的
（1）为什么要建立网站。
（企业的需要还是市场开拓的延伸）
（2）网站功能
（根据公司的需要，确定网站的功能。）
（3）网站的目标
（确定网站应达到的目标和作用）
3、网站技术解决方案
根据网站的功能确定网站技术解决方案
（1）服务器 ―― 自建、租用虚拟主机或主机托管
（2）操作系统 ―― UNIX，Linux还是Window 2000 Server / NT。 分析投入成本、功能开发、稳定性和安全性等。
（3）网站安全措施，防黑、防病毒方案
（4）相关程序开发 ―― 网页程序ASP、JSP、CGI、数据库程序等
4、网站内容规划
（公司简介、产品介绍、服务内容、价格信息、联系方式、网上订单、会员注册、详细的商品服务信息、信息搜索查询、订单确认、付款、个人信息保密措施、相关帮助等）
5、网页设计
（1）网页美术设计要求 ―― 色彩、图片应用、版面规划等
（2）制定网页更新和改版计划
6、网站维护
（1）服务器及相关软硬件的维护 ―― 对可能出现的问题进行评估，制定响应时间
（2）数据库维护 － 数据管理、备份、灾难恢复等
（3）内容维护 ―― 内容的更新、调整等
7、网站测试
在网站发布前要进行周密的测试，以保证正常浏览和使用
（1）服务器 － 稳定性、安全性等
（2）程序、数据库测试
（3）网页兼容性测试 ―― 浏览器、分辨率等
（4）其他测试
8、网站的发布与推广
（1）发布的公关、广告活动
（2）搜索引擎登记
（3）其他推广活动
9、网站建设日程表
各项规划任务的开始完成时间、负责人等
10、费用明细
各项事宜所需费用清单。
B. 网上订机票流程
网上订票流程其实很简单： 登陆网上订票系统（推荐用支付宝付款的网站，等你到达目的地后再确认付款，安全放心），然后用它们的机票信息查询系统，一般可选择出发城市，目的地城市，乘机时间等，然后查询。
在查询出来的结果后面选择你要预订的航班。预订完了，可以直接用支付宝支付。也可以通过银行转账，当然，用支付宝最好了！
C. 如何撰写旅游网站建设策划书
一、网站定位
网站属性：旅游行业门户网站
实现目标：专业大型、中型旅游网站。网站具有旅游信息咨询交流版块、旅游B2C商务预订版块、旅游B2B电子商务交易版块或偏重其一,成为南昌及周边最好的旅游网站之一。
二、建站原则
1、以目的地为核心
旅游资讯网站以目的地为核心的原则进行信息组织。信息内容的组织、网站的设计、信息的表现形式等都以旅游目的地为核心。
2、以游客为中心
网站遵循以游客为中心的原则建设，信息的提供根据游客的需求制定。把游客放在服务对象的第一位，所有信息内容都以游客的需求为第一需要。要做到条理清晰、能够让游客快速查找到需要的信息。
3、旅游描述的专业化
在组织旅游信息内容时，涉及到旅游专业词汇时，要使用行业内的标准词语，使旅游信息更加规范化，专业化，从而提高信息查询的便捷性。
4、检索的便捷化
网站的信息之间、功能之间必须体现关联性。要做到信息要素之间的关联。信息内容的检索要便捷，让游客迅速找到自己需要的信息。
5、增强游客互动性
根据游客的需求，提供人性化专业化的在线咨询、留言板、在线投诉等线上服务，并做到及时解决、及时反馈。
网站栏目及功能
新闻发布管理、网站内容管理、酒店预订管理、线路预订管理、门票预订、机票预订、团购管理、商品销售、广告发布管理、友情链接、会员管理、旅游论坛等多套系统，以及完善的强大的后台管理操作。
6、酒店价格管理系统
管理员可在后台添加、删除、修改客房价格、客房简介、配套设施与服务、房价、图片等客房信息。后台做操作后，前台页面会自动做相应的改动。 酒店会员注册成功后自己也可以动态发布房型信息、房态等信息。
7、旅游线路管理系统
管理员可在后台添加、删除、修改线路信息、价格、服务、图片等旅游线路信息。后台做操作后，前台页面会自动做相应的改动。 旅行社会员注册成功后自己也可以动态发布线路信息。提供可靠的在线旅游信息服务和在线预订、客户登录 、信息查询 、线路预订 、更改预订 、取消预订 、旅行社管理和维护。?
8、门票预订管理系统
管理员可在后台添加、删除、修改旅游景点门票信息、价格、图片等旅游景点信息。后台做操作后，前台页面会自动做相应的改动。景区会员注册成功后自己也可以动态发布景区新闻、图片、门票信息。提供可靠的在线旅游景点信息服务和在线门票预订管理和维护。
D. 旅游网站策划方案书怎么写
旅游网站策划书范例
第一章 现状与发展条件分析
一、 白云区概况
白云区是广州市10个城区之一，因其境内有白云山风景名胜区而得名。位于广州市城区的北部，东邻增城区市，西界南海市，南连荔湾、越秀、天河、黄埔等4个城区，北接花都区和从化市。全区面积1042.7平方公里，2000年末全区常住人口84万，流动人口约90万，行政区辖12个镇，15条行政街。
白云区地处北回归线以南，阳光充足，雨量充沛，气候温和，属亚热带海洋性气候，年平均气温为21.8度，年均降雨量为1655毫米，境内兼具有多种地貌，东部和东北是丘陵地区,有广州市（原八区）最高峰帽峰山（海拔534.7米）和著名的白云山风景名胜区，山丘坡度平缓，林木茂盛，果树如海，大小水库山塘遍布，湖光山色。风景宜人。中部为广花平原，西部是珠江水系，河网交织，珠江西航道，巴江河及流溪河流经境内，既得灌溉之便，更得航运之利，其中流溪河更是广州市民主要的饮水源。
改革开放以来，白云区凭借锐意进取的开拓精神、优越的区位和丰富的资源条件，经济发展和社会各项事业均取得了令人瞩目的成就。2000年，全区GDP127.53亿元人民币，比1995年翻了一番。产业结构进一步优化，农业经营从单家独户的分散经营，向龙头带动的集约经营转变，产业化、集约化程度不断提高。工业整体素质进一步提升，新一代企业群体逐步成长，成为新的经济增长点和带动经济结构调整优化的主要力量。第三产业发展迅速，各类商贸专业市场不断发展壮大，旅游业、房地产、金融保险、信息中介等行业兴旺发达，第三产业已成为国民经济的骨干。目前，全区三大产业比例为16：38：46。
二、 旅游发展评价
(一)现状评估
改革开放以来，伴随全国和广州市旅游业的蓬勃发展，白云区立足优越的区位、便利的交通、宽广的地域空间和组合良好的旅游资源等优势，积极开拓旅游业务，建设酒店宾馆，开发景区景点，拓展旅游市场，走上了旅游发展之路．经过20多年的发展，尤其是"九五"时期的大发展，白云区旅游业从无到有，从小到大，初步形成旅游产业体系，进入初步发展到加速发展的转变时期。
1、旅游接待设施日益完善，旅游产业体系初步形成。
经过20多年的奋斗，白云区旅游业已经初步形成产业体系。标志是旅游接待设施日益完善，旅游产业规模逐步扩大，旅游要素逐步发育。到2000年底，全区共有住宿设施195家，客房11000间，床位22000张，纳入旅游统计范围的酒店80座，其中星级酒店15家。旅游餐饮方面，随着经济及广州市旅游业的快速发展，区内餐饮资源得到利用，现有各类酒家、餐馆网点2000家，较具规模和档次的60家，其中定点餐馆4家，近年形成的新广从公路饮食长廊最具特色，该区域聚集了20多家上规模上档次的特色餐馆，成为"食在广州"的旅游强势产品的组成部分。旅游购物方面，随着广清路综合批发市场、黄石路汽车汽配市场、梓元岗皮具市场、机场路化妆品市场等商业街和专业批发市场的建成，日渐形成独具特色的旅游消费市场。以南湖国家旅游度假区、东方乐园和广州新体育馆、白云山风景区为代表的众多游乐场所，可满足市民和游客的娱乐要求．目前，全区"行、游、住、吃、购、娱"旅游六要素基本配套，产业体系初步形成。
2、各类旅游资源得到初步利用和开发，旅游产品开发正在从观光产品为主向观光与休闲度假、生态相结合过渡。
改革开放以来，尤其是九十年代以来，白云区逐步开发了以白云山风景名胜区、南湖国家旅游度假区、东方乐园、萝岗香雪公园等为代表的一批具有一定知名度的旅游景点和游乐场所，初步形成了具有一定特色的观光、游乐和休闲度假的旅游产品系列。农业生态旅游项目也得到-定发展，并成为适应现代旅游发展的特色旅游产品，亲亲农庄，广州绿田野生态教育中心、明兴农业基地、广州水果世界等，经过包装和推介，已成为新的旅游热点。具有白云区特色的山野蔬菜和田园风味等也逐渐发展成为吸引广州市民及四方游客的旅游吸引物．尤其是近年，随着云台花园、雕塑公园、广州新体育馆，白云山西侧景观带等标志性工程的建成，广州白云山西线休闲带已形成；
3、旅游业务有了一定发展
相较于广州中心城区各区，白云区由于在花都、番禺撤市改区以前，区位相对偏北，不在广州旅游发展的核心区域内，在城市旅游尤其是商务、会议旅游等方面不占优势，但凭借广州"山水城市"的代表和生态、水乡的独特优势做文章，积极拓展观光、度假、休闲和市民周末客源，使旅游业务得到长足的发展，每年吸引了几百万的游客到白云区旅游，成为广州旅游尤其是一日游的重要接待区域。
(二)存在的问题
1、旅游业定位尚不明晰，发展方向没有明确
改革开放以来，白云区实施的是巩固农业基础地位、坚持商业是经济发展的主要动力和外向带动的发展战略，相对而言，旅游业基本处于自我发展状态，地位偏低。应该说，近年来白云区政府对旅游业的发展是重视的，在《广州市白云区国民经济和社会发展第十个五年十划纲要》(草案)中，作为重要章节作了阐述，但对旅游业在整个经济社会发展中和第三产业中的地位和作用尚未作出明确的定位。这同当前的形势是不相称的，目前，全国很多省市，都将旅游业作为新的经济增长点或国民经济的支柱产业，广州市的其他区、市(县级市)也将旅游业摆在极其重要的位置加以发展。定位不明确，势必影响到产业发展政策，行业管理职能和营造旅游大环境相关措施的落实到位。
2、行业管理力量薄弱，管理工作滞后
缺乏行业管理人员和专业管理人才，这一问题是同前一问题紧密相联的。由于旅游业的地位没有在白云区经济社会发展中得到恰如其分的确认，其管理机构的设置、行政管理人员的配备自然难以得到有效的保证。目前，承担全区的旅游市场管理、旅游资源开发、旅游线路组织、旅游业务的开展等工作的仅有3人的编制，显得力不从心。旅游局是在商业局基础上增设的一个部门，缺乏对旅游全行业的管理权威，尤其是对旅游市场和旅游项目建设的宏观调控缺乏力度，容易导致因缺乏规划，失去监控而引发的布局失衡和资源开发的无序状态等问题，造成资源、资金的浪费，妨碍旅游业的良性发展，给整个经济发展带来不利影响。
3、丰富的旅游资源尚未得到高效率的利用和开发，没有形成有足够影响力的拳头产品，资源优势没有转化成直接的经济优势。
白云区的旅游资源在广州市10大城区中是较为丰富的区域之一，既有深具岭南特色的自然景观资源，又有多姿多彩的人文景观资源，还有时尚流行的现代旅游资源，如休闲度假、水乡风情、农业生态等，但由于对旅游资源的认识不足和定位不准，至今没有形成在广州旅游市场占据较重要位置的拳头产品。目前，白云区的旅游资源开发现状是，白云山成为广州"山水城市"山的象征，是广州重点旅游区域，但对整个白云区旅游市场的带动作用不明显；南湖国家旅游度假区的建设进展较为缓慢，没有对白云区度假休闲产品开发起到期望中的示范效应；而丰富的水乡风情、农业观光和生态等旅游资源的利用和开发尚处于初始期，没有形成鲜明的个性。
因字数限制,详细请看参考资料
E. 不就是一个订票网站吗 12306 的核心模型设计思路究竟复杂在哪里
本文的重点不是在如何解决高并发的问题，而是希望从业务角度去分析，12306 的理想模型应该是怎么样的。网上目前谈 12306 的文章貌似都是千篇一律的只谈技术，不谈业务分析和如何建模的。所以我想写一下自己的设计和大家交流学习。
1、需求概述
12306 这个系统，核心要解决的问题是网上售票。涉及到 2 个角色使用该系统：用户、铁道部。用户的核心诉求是查询余票、购票；铁道部的核心诉求是售票。购票和售票其实是一个场景，对用户来说是购票，对铁道部来说是售票。因此，我们要设计一个在线的网站系统，解决用户的查询余票、购票，以及铁道部的售票这 3 个核心诉求。看起来，这 3 个场景都是围绕火车票展开的。
查询余票：用户输入出发地、目的地、出发日三个条件，查询可能存在的车次，用户可以看到每个车次经过的站点名称，以及每种座位的余票数量。
购票：购票分为订票和付款两个阶段，本文重点分析订票的模型设计和实现思路。
其实还有很多其他的需求，比如给不同的车次设定销售座位数配额，以及不同的区段设置不同的限额。但相比前面两个需求来说，我觉得这个需求相对次要一些。
2、需求分析
确实，12306 也是一个电商系统，而且看起来商品就是票了。因为如果把一张票看成是一个商品，那购票就类似于购买商品，然后每张票都有库存，商品也有库存的概念。但是如果我们仔细想想，会发现 12306 要复杂很多，因为我们无法预先确定好所有的票，如果非要确定，那只能通过穷举法了。
我们以北京西到深圳北的 G71 车次高铁为例(这里只考虑南下的方向，不考虑深圳北到北京西的，那是另外一个车次，叫 G72)，它有 17 个站(北京西是 01号站，深圳北是 17号站)，3 种座位(商务、一等、二等)。表面看起来，这不就是 3 个商品吗？G71 商务座、G71 一等座、G71 二等座。大部分轻易喷 12306 的技术人员(包括某些中等规模公司的专家、CTO)就是在这里栽第一个跟头的。实际上，G71 有 136*3=408 种商品(408 个 SKU)，怎么算来的？如下：
如果卖北京西始发的，有 16 种卖法(因为后面有 16 个站)，北京西到：保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品，同理，石家庄上车的，有 15 种下车的可能，以此类推，单以上下车的站来计算，有 136 种票：16+15+14....+2+1=136。每种票都有 3 种座位，一共是 408 个商品。
为了方便后面的讨论，我们先明确一下票是什么？
一张票的核心信息包括：出发时间、出发地、目的地、车次、座位号。持有票的人就拥有了一个凭证，该凭证表示持有它的人可以坐某个车次的某个座位号，从某地到某地。所以，一张票，对用户来说是一个凭证，对铁道部来说是一个承诺；那对系统来说是什么呢？不知道。这就是我们要分析业务，领域建模的原因，我们再继续思考吧。
明白了票的核心信息后，我们再看看 G71 这个车次的高铁，可以卖多少张票？
讨论前先说明一下，一辆火车的物理座位数(站票也可以看成是一种座位，因为站票也有数量配额)不等于可用的最大配合。所有的物理座位不可能都通过 12306 网站来销售，而是只会销售一部分，比如 40%。其余的还是会通过线下的方式销售。不仅如此，可能有些站点上车的人会比较多，有些比较少，所以我们还会给不同的区间配置不同的限额。
比如 D31 北京南至上海共有 765 张，北京南有 260 张，杨柳青有 80 张，泰安有 76 张。如果杨柳青的 80 张票售完就会显示无票，就算其他站有票也会显示无票的。每个车次肯定会有各种座位的配额和限额的配置的，这种配置我目前无法预料，但我已经把这些规则都封装近车次聚合根里了，所有的配置策略都是基于座位类型、站点、区间配置的。关于票的配置抽象出来，我觉得主要有 3 种：
某个区段最多允许出多少张；
某个区段最少允许出多少张；
某个站点上车的最多多少张。
当用户订票时，把用户指定的区段和这 3 种配置条件进行比较，3 个条件都满足，则可以出票。不满足，则认为无票了。下面举个例子：
ABCDEFG，这是所有站点。座位总配额是 100，假设 B 站点上车，E 站下车的人比较少，那我们就可以设定 BE 这个区段最多只能出 10 张票。所以，只要是用户的订票是在这个区段内的，就最多出 10 张。再比如，一列车次，总共 100 个座位配额，希望全程票最少满足 80 张，那我们只要给 AG 这个区段设定最少 80 张。那任何订票请求，如果是子区间的，就不能超过 100-80，即 20 张。这两种条件必须同时满足，才允许出票。
但是，不管如何做配额和限额，我们总是针对某个车次进行配置，这些配置只是车次内部售票时的一些额外的判断条件(业务规则)，不影响车次模型的核心地位和对外暴露的功能。所以，为了本文讨论的清楚起见，我后续的讨论都不涉及配额和限额的问题，而是认为任何区段都可以享受火车最大的物理座位数。
并且，为了讨论问题方便，我们减少一些站点来讨论。假设某个车次有 A,B,C,D 四个站点。那 001 这个人购买了 A,B 这个区间，系统会分配给 001 一个座位 x；但是因为 001 坐到 B 站点后会下车，所以相当于 x 这个座位又空出来了，也就是说，从 B 站点开始，系统又可以认为 x 这个座位是可用的。所以，我们得出结论：同一个座位，其实可以同时出售 AB,BC 这两张票。通过这个简单的分析，我们知道，一列火车虽然只有有限的座位数，比如 1000 个座位。但可以卖出的票远远不止 1000 个。
还是以 A,B,C,D 四个站点为例，假如火车总共有 1000 个座位，那 AB 可以卖 1000 张，BC 也可以卖 1000 张，同样，CD 也可以卖 1000 张。也就是说，理论上最多可以卖出 3000 张票。但是如果换一种卖法，所有人都是买 ABCD 的票，也就是说所有的票都是经过所有站点的，那就是最多只能卖出 1000 张票了。而实际的场景，一定是介于 1000 到 3000 之间。然后实际的 G71 这个车次，有 17 个站，那到底可以卖出多少个票，大家应该可以算了吧。理论上这 17 个站中的任意两个站点之间所形成的线段，都可以出售为一张票。我数学不好，算不太清楚，麻烦有数学好的人帮我算算，呵呵。
通过上面的分析，我们知道一张票的本质是某个车次的某一段区间(一条线段)，这个区间包含了若干个站点。然后我们还发现，只要区间不重叠，那座位就不会发生竞争，可以被回收利用，也就是说，可以同时预先出售。
另外，经过更深入的分析，我们还发现区间有 4 种关系：
不重叠；
部分重叠；
完全重叠；
覆盖。
不重叠的情况我们已经讨论过了，而覆盖也是重叠的一种。所以我们发现如果重叠，比如有两个区间发生重叠，那重叠部分的区间(可能夸一个或多个站点)是在争抢座位的。因为假设一列火车有 100 个座位，那每个原子区间(两个相邻站点的连线)，最多允许重叠 99 次。
所以，经过上面的分析，我们知道了一个车次能够出售一张车票的核心业务规则是什么？就是：这张车票所包含的每个原子区间的重叠次数加 1 都不能超过车次的总座位数，实际上重叠次数 +1 也可以理解为线段的厚度。
3、模型设计
上面我分析了一下票的本质是什么。那接下来我们再来看看怎么设计模型，来快速实现购票的需求，重点是怎么设计商品聚合以及减库存的逻辑。
传统电商的思路
如果按照普通电商的思路，把票(站点区间)设计为商品(聚合根)，然后为票设计库存数量。我个人觉得是很糟糕的。因为一方面这种聚合根非常多(上面的 G71 就有 408 个)；另一方面，即便枚举出来了，一次购票也一定会影响非常多其他聚合根的库存数量(只要被部分或全部重叠的区间都受影响)。这样的一次订单处理的复杂度是难以评估的。而且这么多聚合根的更新要在一个事务里，这不是为难数据库吗？而且，这种设计必然带来大量的事务的并发冲突，很可能导致数据库死锁。
总之，我认为这种是典型的由于领域模型的设计错误，导致并发冲突高、数据持久化落地困难。或者如果要解决并发问题，只能排队单线程处理，但是仍然解决不了要在一个事务里修改大量聚合根的尴尬局面。
听说 12306 是采用了 Pivotal Gemfire 这种高大上的内存数据库，我对这个不太了解。我不可想象要是不使用内存数据库，他们要怎么实现车次内的票之间的数据强一致性(就是保证所有出售的票都是符合上面讨论的业务规则的)？所以，这种设计，我个人认为是思维定势了，把火车票看成是普通电商的商品来看待。所以，我们有时做设计又要依赖于经验，又要不能被以往经验所束缚，真的不容易，关键还是要根据具体的业务场景多多深入分析，尽量分析抽象出问题的本质出来，这样才能对症下药。那是否有其他的设计思路呢？
我的思路
1、聚合设计
通过上面的分析我们知道，其实任何一次购票都是针对某个车次的，我认为车次是负责处理订票的聚合根。我们看看一个车次包含了哪些信息？一个车次包括了：
车次名称，如 G71；
座位数，实际座位数会分类型，比如商务座 20 个，一等座 200 个；二等座 500 个；我们这里为了简化问题，可以暂时忽略类型，我认为这个类型不影响核心的模型的设计决策。需要格外注意的是：这里的座位数不要理解为真实的物理座位数，很有可能比真实的座位数要少。因为我们不可能把一个车次的所有座位都在网上通过 12306 来出售，而是只出售一部分，具体出售多少，要由工作人员人工指定。
经过的站点信息(包括站点的 ID、站点名称等)，注意：车次还会记录这些站点之间的顺序关系；
出发时间；看过 GRASP 九大模式中的信息专家模式的同学应该知道，将职责分配给拥有执行该职责所需信息的类。
我们这个场景，车次具有一次出票的所有信息，所以我们应该把出票的职责交给车次。另外学过 DDD 的同学应该知道，聚合设计有一个原则，就是：聚合内强一致性，聚合之间最终一致性。经过上面的分析，我们知道要产生一张票，其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部，所以车次聚合内部自然可以维护所有的原子区间，以及每个原子区间的可用票数(相当于是库存数)。当一个原子区间的可用票数为 0 的时候，意味着火车针对这个区间的票已经卖完了。所以，我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。对于车次聚合根来说，这很简单，因为只是几次简单的内存操作而已，耗时可以忽略。一列火车假如有 ABCD 四个站点，那原子区间就是 3 个。对于 G71，则是 16 个。
2、怎么判断是否能出票？
基于上面的聚合设计，出票时扣减库存的逻辑是：
根据订单信息，拿到出发地和目的地，然后获取这段区间里的所有的原子区间。然后尝试将每个原子区间的可用票数减 1，如果所有的原子区间都够减，则购票成功；否则购票失败，提示用户该票已经卖完了。是不是很简单呢？知道了出票的逻辑，那退票的逻辑也就很简单了，就是把这个票的所有原子区间的可用票数加 1 就 OK 了。如果我们从线段的厚度的角度去考虑，那出票时，每个原子区间的厚度就是 +1，退票时就是减一。就是相反的操作，但本质是一样的。
所以，通过这样的思路，我们将一次订票的处理控制在了一个聚合根里，用聚合根内的强一致性的特性保证了订票处理的强一致性，同时也保证了性能，免去了并发冲突的可能性。传统电商那种把票单做类似商品的核心聚合根的设计，我当时第一眼看到就觉得不妥。因为这违背了 DDD 强调的强一致性应该由聚合根来保证、聚合根之间的最终一致性通过 Saga 来保证的原则。
还有一个很重要的概念我想说一下我的看法，就是座位和区间的关系。因为有些朋友和我讲，考虑座位号的问题，虽然都能减 1，座位号也必须是同一个。我觉得座位是全局共享的，和区段无关(也许我的理解完全有误，请大家指正)。座位是一个物理概念，一个用户成功购买了一张票后，座位就会少一个，一张票唯一对应一个座位，但是一个座位有可能会对应多张票；而区间是一个逻辑上的概念，区间的作用有两个：1)表示票的出发地和目的地；2)记录票的可用数额。如果区间能连通(即该区间内的每个原子区间的可用数额都大于 0)，则表示允许拥有一个座位。所以，我觉得座位和票(区间)是两个维度的概念。
3、如何为票分配座位？
我觉得车次聚合根内部应该维护所有该车次已经售出的票，已经出售的票的的本质是区间和座位的对应关系。系统处理订票时，用户提交过来的是一段区间。所以，系统应该做两个事情：
先根据区间去判断是否有可用的座位；
如果有可用座位，则再通过算法去选择一个可用的座位；
当得到一个可用座位后，就可以生成一张票了，然后保存这个票到车次聚合根内部即可。下面举个例子：
假设现在的情况是座位有 3 个，站点有 4 个：
座位：1,2,3
站点：abcd
票的卖法 1：
票 1：ab,1
票 2：bc,2
票 3：cd,3
票 4：ac,3
票 5：bd,1
这种选座位的方式应该比较高效，因为总是优先从座位池里去拿座位，只有在万不得已的时候才会去回收可重复利用的票。
上面的 4，5 两个票，就是考虑回收利用的结果。
票的卖法 2：
票 1：ab,1
票 2：bc,1
票 3：cd,1
票 4：ac,2
票 5：bd,3
这种选座位的方式应该相对低效，因为总是优先会去扫描是否有可回收的座位，而扫描相对直接从座位池里去拿票总是成本相对要高的。
上面的 2，3 两个票，就是考虑回收利用的结果。
但是，优先从座位池里拿票的算法有缺陷，就是会出现虽然第一步判断认为有可用的座位，但是这个座位可能不是全程都是同一个座位。举例：
假设现在的情况是座位有 3 个，站点有 4 个：
座位：1,2,3
站点：abcd
票的卖法 3：
票 1：ab,1
票 2：bc,2
票 3：cd,3
现在如果有人要买 ad 的票，那可用的座位有 2，或者 3。但是无论是 2 还是 3，都要这个乘客中途换车位。比如卖给他座位 2，那他 ab 是坐的座位 2，但是 bc 的时候要坐座位 1 的。否则拿票 2 的那个人上车时，发现座位 2 已经有人了。而通过优先回收利用的算法，是没这个问题的。
所以，从上面的分析我们也知道选座位的算法该怎么写了，就是采用优先回收利用座位的算法。我认为不管我们这里怎么设计算法，都不影响大局，因为这一切都只发生在车次聚合根内部，这就是预先设计好聚合根，明确出票职责在哪个对象上的好处。
4、模型分析总结
我认为票不是核心聚合根，票只是一次出票的结果，一个凭证而已。
12306 真正的核心聚合根应该是车次，车次具有出票的职责，一次出票具体做的事情有：
判断是否可出票；
选择可用的座位；
更新一次出票时所有原子区间的可用票数，用于判断下次是否能出票；
维护所有已售出的票，用于为选择可用座位提供依据。
通过这样的模型设计，我们可以确保一次出票处理只会在一个车次聚合根内进行。这样的好处是：
不需要依赖数据库事务就能实现数据修改的强一致性，因为所有修改只在一个聚合根内发生；
在保证数据强一致性的同时还能提供很高的并发处理能力，具体设计见下面的架构设计。
4、架构设计
我觉得 12306 这样的业务场景，非常适合使用 CQRS 架构；因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以，非常适合做架构层面的读写分离，即采用 CQRS 架构。而且应该使用数据存储也分离的 CQRS。这样 CQ 两端才可以完全不需要顾及对方的问题，各自优化自己的问题即可。我们可以在 C 端使用 DDD 领域模型的思路，用良好设计的领域模型实现复杂的业务规则和业务逻辑。而 Q 端则使用分布式缓存方案，实现可伸缩的查询能力。
1、订票的实现思路
同时借助像 ENode 这样的框架，我们可以实现 in-memory + Event Sourcing 的架构。Event Sourcing 技术，可以让领域模型的所有状态修改的持久化统一起来，本来要用 ORM 的方式保存聚合根最新状态的，现在只需要简单的通用的方式保存一个事件即可(一次订票只涉及一个车次聚合根的修改，修改只产生一个事件，只需要持久化一个事件(一个 JSON 串)即可，保证了高性能，无须依赖事务，而且通过 ENode 可以解决并发问题)。
我们只要保存了聚合根每次变化的事件(事件的结构怎么设计，本文不做多的介绍了，大家可以思考下)，就相当于保存了聚合根的最新状态。而正是由于 Event Sourcing 技术的引入，让我们的模型可以一直存活在内存中，即可以使用 in-memory 技术。不要小看 in-memory 技术，in-memory 技术在某些方面对提高命令的处理性能非常有帮助。
比如就以我们车次聚合根处理出票的逻辑，假设某个车次有大量的命令发送到分布式消息队列，然后有一台机器订阅了这个队列的消息，然后这台机器处理这个车次的订票命令时，由于这个车次聚合根一直在内存，所以就省去了每次要去数据库取出聚合根的步骤，相当于少了一次数据库 IO。
这样的好处是，因为一个车次能够真正出售的票是有限的，因为座位就那么几个，比如就 1000 个座位，估计一般正常情况也就出个 2000 个左右的票吧(具体能出多少张票要取决于区间的相交程度，上面分析过)。也就是说，这个聚合根只会产生 2000 个事件，也就是说只会有 2000 个订票命令的处理是会产生事件，并持久化事件；而其余的大量命令，因为车次在内存计算后发现没有余票了，就不会做任何修改，也不会产生领域事件，这样就可以直接处理下一个订票命令了。这样就可以大大提高处理订票命令的性能。
另外一个问题我觉得还需要提一下，因为用户订票成功后，还需要付款。但用户有可能不去付款或者没有在规定的时间内完成付款。那这种情况下，系统会自动释放该用户之前订购的票。所以基于这样的需求，我们在业务上需要支持业务级别的 2pc。即先预扣库存，也就是先占住这张票一定时间(比如 15 分钟)，然后付款成功后再真实给你这张票，系统做真正的库存修改。
通过这样的预扣处理，可以保证不会出现超卖的情况。这个思路其实和传统电商比如淘宝这样的系统类似，我就不多展开了，我之前写的 Conference 案例也是这样的思路，大家有兴趣的可以去看一下我之前录制的视频。
2、查询余票的实现思路
我觉得余票的查询的实现相对简单。虽然对于 12306 来说，查询的请求占了 80%，提交订单的请求只占 20%。但查询由于对数据没有修改，所以我们完全可以使用分布式缓存来实现。我们只需要精心设计好缓存的 key 即可；缓存 key 的多少要看成本，如果所有可能的查询都设计对应的 key，那时间复杂度为 1，查询性能自然高；但代价也大，因为 key 多了。如果想 key 少一点，那查询的复杂度自然要上去一点。所以缓存设计无非就是空间换时间的思路。然后，缓存的更新无非就是：自动失效、定时更新、主动通知 3 种。通过 CQRS 架构，由于 CQ 两端是事件驱动的，当 C 端有任何状态变化，都会产生对应的事件去通知 Q 端，所以我们几乎可以做到 Q 端的准实时更新。
同时由于 CQ 两端的完全解耦，Q 端我们可以设计多种存储，如数据库和缓存(Redis 等)；数据库用于线下维护关系型数据，缓存用户实时查询。数据库和缓存的更新速度相互不受影响，因为是并行的。对同一个事件，可以 10 台机器负责更新缓存，100 台机器负责更新数据库。即便数据库的更新很慢，也不会影响缓存的更新进度。这就是 CQRS 架构的好处，CQ 的架构完全不同，且我们随时可以重建一种新的 Q 端存储。不知道大家体会到了没有？
关于缓存 key 的设计，我觉得主要从查询余票时传递的信息来考虑。12306 的关键查询是：出发地、目的地、出发日期三个信息。我觉得有两种 key 的设计思路：
直接设计了该查询条件的 key，然后快速拿到车次信息，直接返回；这种方式就是要求我们系统已经枚举了所有车次的所有可能出现的票(区间)的缓存 key，相信你一定知道这样的 key 是非常多的。
不是枚举所有区间，而是把每个车次的每个原子区间(相邻的两个站点所连成的直线)的可用票数作为 key。这样，key 就非常少了，因为车次假如有 10000 个，然后每个车次平均 15 个区间，那也就 15W 个 key 而已。当我们要查询时，只需要把用户输入的出发地和目的地之间的所有原子区间的可用票数都查出来，然后比较出最小可用票数的那个原子区间。则这个原子区间的可用票数就是用户输入的区间的可用票数了。当然，到这里我提到考虑出发日期。我认为出发日期是用来决定具体是哪个车次聚合根的。同一个车次，不同的日期，对应的聚合根实例是不同的，即便是同一天，也可能有多个车次聚合根，因为有些车次一天有几班的，比如上午 9 点发车的一班，下午 3 点发车的一般。所以，我们也只要把日期也作为缓存 key 的一部分即可。
总结
本文完全是凭自己对 12306 这个网站的核心业务的简单思考而得到的一些设计结果。如果真正的 DDD 领域建模，更多的是要和业务一线的工作人员、领域专家进行深入沟通，才能更深入的了解该领域内的业务知识，从而才能设计出更靠谱的领域模型和架构设计。
非常惭愧，我没有上 12306 买过火车票，家离的比较近，就算要买也是家人给我买:)所以，本文所分享的内容难免是纸上谈兵。但我觉得 12306 这个系统的业务确实比传统的电商系统要复杂，且并发又这么高。所以，我觉得这个系统真的很值得大家重视模型的设计，而不只是只关注技术层面的实现。
F. 不就是一个订票网站吗，12306的核心模型设计思路究竟复杂在哪儿
12306这个系统，核心要解决的问题是网上售票。涉及到2个角色使用该系统：用户、铁道部。用户的核心诉求是查询余票、购票；铁道部的核心诉求是 售票。购票和售票其实是一个场景，对用户来说是购票，对铁道部来说是售票。因此，我们要设计一个在线的网站系统，解决用户的查询余票、购票，以及铁道部的 售票这3个核心诉求。看起来，这3个场景都是围绕火车票展开的。
查询余票：用户输入出发地、目的地、出发日三个条件，查询可能存在的车次，用户可以看到每个车次经过的站点名称，以及每种座位的余票数量。
购票：购票分为订票和付款两个阶段，本文重点分析订票的模型设计和实现思路。
其实还有很多其他的需求，比如给不同的车次设定销售座位数配额，以及不同的区段设置不同的限额。但相比前面两个需求来说，我觉得这个需求相对次要一些。
需求分析
确实，12306也是一个电商系统，而且看起来商品就是票了。因为如果把一张票看成是一个商品，那购票就类似于购买商品，然后每张票都有库存，商品 也有库存的概念。但是如果我们仔细想想，会发现12306要复杂很多，因为我们无法预先确定好所有的票，如果非要确定，那只能通过穷举法了。
我们以北京西到深圳北的G71车次高铁为例（这里只考虑南下的方向，不考虑深圳北到北京西的，那是另外一个车次，叫G72），它有17个站（北京西 是01号站，深圳北是17号站），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、G71一等座、G71二等座。大部分轻 易喷12306的技术人员（包括某些中等规模公司的专家、CTO）就是在这里栽第一个跟头的。实际上，G71有136*3=408种商品（408个 SKU），怎么算来的？如下：
如果卖北京西始发的，有16种卖法（因为后面有16个站），北京西到：保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商 品，同理，石家庄上车的，有15种下车的可能，以此类推，单以上下车的站来计算，有136种票：16+15+14….+2+1=136。每种票都有3种座 位，一共是408个商品。
为了方便后面的讨论，我们先明确一下票是什么？
一张票的核心信息包括：出发时间、出发地、目的地、车次、座位号。持有票的人就拥有了一个凭证，该凭证表示持有它的人可以坐某个车次的某个座位号， 从某地到某地。所以，一张票，对用户来说是一个凭证，对铁道部来说是一个承诺；那对系统来说是什么呢？不知道。这就是我们要分析业务，领域建模的原因，我 们再继续思考吧。
明白了票的核心信息后，我们再看看G71这个车次的高铁，可以卖多少张票？
讨论前先说明一下，一辆火车的物理座位数（站票也可以看成是一种座位，因为站票也有数量配额）不等于可用的最大配合。所有的物理座位不可能都通过 12306网站来销售，而是只会销售一部分，比如40%。其余的还是会通过线下的方式销售。不仅如此，可能有些站点上车的人会比较多，有些比较少，所以我 们还会给不同的区间配置不同的限额。比如D31 北京南至上海共有765张，北京南有260张，杨柳青有80张，泰安有76张。如果杨柳青的80张票售完就会显示无票，就算其他站有票也会显示无票的。每 个车次肯定会有各种座位的配额和限额的配置的，这种配置我目前无法预料，但我已经把这些规则都封装近车次聚合根里了，所有的配置策略都是基于座位类型、站 点、区间配置的。关于票的配置抽象出来，我觉得主要有3种：1）某个区段最多允许出多少张；2）某个区段最少允许出多少张；3）某个站点上车的最多多少 张；当用户订票时，把用户指定的区段和这3种配置条件进行比较，3个条件都满足，则可以出票。不满足，则认为无票了。下面举个例子：
ABCDEFG，这是所有站点。座位总配额是100，假设B站点上车，E站下车的人比较少，那我们就可以设定BE这个区段最多只能出10张票。所 以，只要是用户的订票是在这个区段内的，就最多出10张。再比如，一列车次，总共100个座位配额，希望全程票最少满足80张，那我们只要给AG这个区段 设定最少80张。那任何订票请求，如果是子区间的，就不能超过100-80，即20张。这两种条件必须同时满足，才允许出票。
但是，不管如何做配额和限额，我们总是针对某个车次进行配置，这些配置只是车次内部售票时的一些额外的判断条件（业务规则），不影响车次模型的核心 地位和对外暴露的功能。所以，为了本文讨论的清楚起见，我后续的讨论都不涉及配额和限额的问题，而是认为任何区段都可以享受火车最大的物理座位数。
并且，为了讨论问题方便，我们减少一些站点来讨论。假设某个车次有A,B,C,D四个站点。那001这个人购买了A,B这个区间，系统会分配给 001一个座位x；但是因为001坐到B站点后会下车，所以相当于x这个座位又空出来了，也就是说，从B站点开始，系统又可以认为x这个座位是可用的。所 以，我们得出结论：同一个座位，其实可以同时出售AB,BC这两张票。通过这个简单的分析，我们知道，一列火车虽然只有有限的座位数，比如1000个座 位。但可以卖出的票远远不止1000个。还是以A,B,C,D四个站点为例，假如火车总共有1000个座位，那AB可以卖1000张，BC也可以卖 1000张，同样，CD也可以卖1000张。也就是说，理论上最多可以卖出3000张票。但是如果换一种卖法，所有人都是买ABCD的票，也就是说所有的 票都是经过所有站点的，那就是最多只能卖出1000张票了。而实际的场景，一定是介于1000到3000之间。然后实际的G71这个车次，有17个站，那 到底可以卖出多少个票，大家应该可以算了吧。理论上这17个站中的任意两个站点之间所形成的线段，都可以出售为一张票。我数学不好，算不太清楚，麻烦有数 学好的人帮我算算，呵呵。
通过上面的分析，我们知道一张票的本质是某个车次的某一段区间（一条线段），这个区间包含了若干个站点。然后我们还发现，只要区间不重叠，那座位就不会发生竞争，可以被回收利用，也就是说，可以同时预先出售。
另外，经过更深入的分析，我们还发现区间有4种关系：1）不重叠；2）部分重叠；3）完全重叠；4）覆盖；不重叠的情况我们已经讨论过了，而覆盖也 是重叠的一种。所以我们发现如果重叠，比如有两个区间发生重叠，那重叠部分的区间（可能夸一个或多个站点）是在争抢座位的。因为假设一列火车有100个座 位，那每个原子区间（两个相邻站点的连线），最多允许重叠99次。
所以，经过上面的分析，我们知道了一个车次能够出售一张车票的核心业务规则是什么？就是：这张车票所包含的每个原子区间的重叠次数加1都不能超过车次的总座位数，实际上重叠次数+1也可以理解为线段的厚度。
模型设计
上面我分析了一下票的本质是什么。那接下来我们再来看看怎么设计模型，来快速实现购票的需求，重点是怎么设计商品聚合以及减库存的逻辑。
传统电商的思路
如果按照普通电商的思路，把票（站点区间）设计为商品（聚合根），然后为票设计库存数量。我个人觉得是很糟糕的。因为一方面这种聚合根非常多（上面 的G71就有408个）；另一方面，即便枚举出来了，一次购票也一定会影响非常多其他聚合根的库存数量（只要被部分或全部重叠的区间都受影响）。这样的一 次订单处理的复杂度是难以评估的。而且这么多聚合根的更新要在一个事务里，这不是为难数据库吗？而且，这种设计必然带来大量的事务的并发冲突，很可能导致 数据库死锁。总之，我认为这种是典型的由于领域模型的设计错误，导致并发冲突高、数据持久化落地困难。或者如果要解决并发问题，只能排队单线程处理，但是 仍然解决不了要在一个事务里修改大量聚合根的尴尬局面。听说12306是采用了Pivotal Gemfire这种高大上的内存数据库，我对这个不太了解。我不可想象要是不使用内存数据库，他们要怎么实现车次内的票之间的数据强一致性（就是保证所有 出售的票都是符合上面讨论的业务规则的）？所以，这种设计，我个人认为是思维定势了，把火车票看成是普通电商的商品来看待。所以，我们有时做设计又要依赖 于经验，又要不能被以往经验所束缚，真的不容易，关键还是要根据具体的业务场景多多深入分析，尽量分析抽象出问题的本质出来，这样才能对症下药。那是否有 其他的设计思路呢？
我的思路
聚合设计
通过上面的分析我们知道，其实任何一次购票都是针对某个车次的，我认为车次是负责处理订票的聚合根。我们看看一 个车次包含了哪些信息？一个车次包括了：1）车次名称，如G71；2）座位数，实际座位数会分类型，比如商务座20个，一等座200个；二等座500个； 我们这里为了简化问题，可以暂时忽略类型，我认为这个类型不影响核心的模型的设计决策。需要格外注意的是：这里的座位数不要理解为真实的物理座位数，很有 可能比真实的座位数要少。因为我们不可能把一个车次的所有座位都在网上通过12306来出售，而是只出售一部分，具体出售多少，要由工作人员人工指定。 3）经过的站点信息（包括站点的ID、站点名称等），注意：车次还会记录这些站点之间的顺序关系；4）出发时间；看过GRASP九大模式中的信息专家模式的同学应该知道，将职责分配给拥有执行该职责所需信息的类。我们这个场景，车次具有一次出票的所有信息，所以我们应该把出票的职责交给车次。另外学过DDD的同学应该知道，聚合设计有一个原则，就是：聚合内强一致性，聚合之间最终一致性。经 过上面的分析，我们知道要产生一张票，其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部，所以车次聚合内部 自然可以维护所有的原子区间，以及每个原子区间的可用票数（相当于是库存数）。当一个原子区间的可用票数为0的时候，意味着火车针对这个区间的票已经卖完 了。所以，我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。对于车次聚合根来说，这很简单，因为只是几次简单的内存 操作而已，耗时可以忽略。一列火车假如有ABCD四个站点，那原子区间就是3个。对于G71，则是16个。
怎么判断是否能出票
基于上面的聚合设计，出票时扣减库存的逻辑是：
根据订单信息，拿到出发地和目的地，然后获取这段区间里的所有的原子区间。然后尝试将每个原子区间的可用票数减1，如果所有的原子区间都够减，则购 票成功；否则购票失败，提示用户该票已经卖完了。是不是很简单呢？知道了出票的逻辑，那退票的逻辑也就很简单了，就是把这个票的所有原子区间的可用票数加 1就OK了。如果我们从线段的厚度的角度去考虑，那出票时，每个原子区间的厚度就是+1，退票时就是减一。就是相反的操作，但本质是一样的。
所以，通过这样的思路，我们将一次订票的处理控制在了一个聚合根里，用聚合根内的强一致性的特性保证了订票处理的强一致性，同时也保证了性能，免去 了并发冲突的可能性。传统电商那种把票单做类似商品的核心聚合根的设计，我当时第一眼看到就觉得不妥。因为这违背了DDD强调的强一致性应该由聚合根来保 证、聚合根之间的最终一致性通过Saga来保证的原则。
还有一个很重要的概念我想说一下我的看法，就是座位和区间的关系。因为有些朋友和我讲，考虑座位号的问题，虽然都能减1，座位号也必须是同一个。我 觉得座位是全局共享的，和区段无关（也许我的理解完全有误，请大家指正）。座位是一个物理概念，一个用户成功购买了一张票后，座位就会少一个，一张票唯一 对应一个座位，但是一个座位有可能会对应多张票；而区间是一个逻辑上的概念，区间的作用有两个：1）表示票的出发地和目的地；2）记录票的可用数额。如果 区间能连通（即该区间内的每个原子区间的可用数额都大于0），则表示允许拥有一个座位。所以，我觉得座位和票（区间）是两个维度的概念。
如何为票分配座位
我觉得车次聚合根内部应该维护所有该车次已经售出的票，已经出售的票的的本质是区间和座位的对应关系。系统处理订票时，用户提交过来的是一段区间。所以，系统应该做两个事情：
先根据区间去判断是否有可用的座位；
如果有可用座位，则再通过算法去选择一个可用的座位；
当得到一个可用座位后，就可以生成一张票了，然后保存这个票到车次聚合根内部即可。下面举个例子：
假设现在的情况是座位有3个，站点有4个
座位：1,2,3
站点：abcd
票的卖法1：
票1：ab,1
票2：bc,2
票3：cd,3
票4：ac,3
票5：bd,1
这种选座位的方式应该比较高效，因为总是优先从座位池里去拿座位，只有在万不得已的时候才会去回收可重复利用的票。
上面的4，5两个票，就是考虑回收利用的结果。
票的卖法2：
票1：ab,1
票2：bc,1
票3：cd,1
票4：ac,2
票5：bd,3
这种选座位的方式应该相对低效，因为总是优先会去扫描是否有可回收的座位，而扫描相对直接从座位池里去拿票总是成本相对要高的。
上面的2，3两个票，就是考虑回收利用的结果。
但是，优先从座位池里拿票的算法有缺陷，就是会出现虽然第一步判断认为有可用的座位，但是这个座位可能不是全程都是同一个座位。举例：
假设现在的情况是座位有3个，站点有4个
座位：1,2,3
站点：abcd
票的卖法3：
票1：ab,1
票2：bc,2
票3：cd,3
现在如果有人要买ad的票，那可用的座位有2，或者3。但是无论是2还是3，都要这个乘客中途换车位。比如卖给他座位2，那他ab是坐的座位2，但是bc的时候要坐座位1的。否则拿票2的那个人上车时，发现座位2已经有人了。而通过优先回收利用的算法，是没这个问题的。
所以，从上面的分析我们也知道选座位的算法该怎么写了，就是采用优先回收利用座位的算法。我认为不管我们这里怎么设计算法，都不影响大局，因为这一切都只发生在车次聚合根内部，这就是预先设计好聚合根，明确出票职责在哪个对象上的好处。
模型分析总结
我认为票不是核心聚合根，票只是一次出票的结果，一个凭证而已。
12306真正的核心聚合根应该是车次，车次具有出票的职责，一次出票具体做的事情有：
判断是否可出票；
选择可用的座位；
更新一次出票时所有原子区间的可用票数，用于判断下次是否能出票；
维护所有已售出的票，用于为选择可用座位提供依据；
通过这样的模型设计，我们可以确保一次出票处理只会在一个车次聚合根内进行。这样的好处是：
不需要依赖数据库事务就能实现数据修改的强一致性，因为所有修改只在一个聚合根内发生；
在保证数据强一致性的同时还能提供很高的并发处理能力，具体设计见下面的架构设计；
架构设计（非本文重点，没兴趣的朋友可以略过）
我觉得12306这样的业务场景，非常适合使用CQRS架构；因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以，非常适合做架构层面的读写分离，即采用CQRS架构。而且应该使用数据存储也分离的CQRS。这样CQ两端才可以完全不需要顾及对方的问题，各自优化自己的问题即可。我们可以在C端使用DDD领域模型的思路，用良好设计的领域模型实现复杂的业务规则和业务逻辑。而Q端则使用分布式缓存方案，实现可伸缩的查询能力。
订票的实现思路
同时借助像ENode这样的框架，我们可以实现in-memory + Event Sourcing的架构。Event Sourcing技术，可以让领域模型的所有状态修改的持久化统一起来，本来要用ORM的方式保存聚合根最新状态的，现在只需要简单的通用的方式保存一个 事件即可（一次订票只涉及一个车次聚合根的修改，修改只产生一个事件，只需要持久化一个事件（一个JSON串）即可，保证了高性能，无须依赖事务，而且通 过ENode可以解决并发问题）。我们只要保存了聚合根每次变化的事件（事件的结构怎么设计，本文不做多的介绍了，大家可以思考下），就相当于保存了聚合 根的最新状态。而正是由于Event Sourcing技术的引入，让我们的模型可以一直存活在内存中，即可以使用in-memory技术。不要小看in-memory技术，in- memory技术在某些方面对提高命令的处理性能非常有帮助。比如就以我们车次聚合根处理出票的逻辑，假设某个车次有大量的命令发送到分布式消息队列，然 后有一台机器订阅了这个队列的消息，然后这台机器处理这个车次的订票命令时，由于这个车次聚合根一直在内存，所以就省去了每次要去数据库取出聚合根的步 骤，相当于少了一次数据库IO。这样的好处是，因为一个车次能够真正出售的票是有限的，因为座位就那么几个，比如就1000个座位，估计一般正常情况也就 出个2000个左右的票吧（具体能出多少张票要取决于区间的相交程度，上面分析过）。也就是说，这个聚合根只会产生2000个事件，也就是说只会有 2000个订票命令的处理是会产生事件，并持久化事件；而其余的大量命令，因为车次在内存计算后发现没有余票了，就不会做任何修改，也不会产生领域事件， 这样就可以直接处理下一个订票命令了。这样就可以大大提高处理订票命令的性能。
另外一个问题我觉得还需要提一下，因为用户订票成功后，还需要付款。但用户有可能不去付款或者没有在规定的时间内完成付款。那这种情况下，系统会自 动释放该用户之前订购的票。所以基于这样的需求，我们在业务上需要支持业务级别的2pc。即先预扣库存，也就是先占住这张票一定时间（比如15分钟），然 后付款成功后再真实给你这张票，系统做真正的库存修改。通过这样的预扣处理，可以保证不会出现超卖的情况。这个思路其实和传统电商比如淘宝这样的系统类 似，我就不多展开了，我之前写的Conference案例也是这样的思路，大家有兴趣的可以去看一下我之前录制的视频。
查询余票的实现思路
我觉得余票的查询的实现相对简单。虽然对于12306来说，查询的请求占了80%，提交订单的请求只占20%。但查询由于对数据没有修改，所以我们 完全可以使用分布式缓存来实现。我们只需要精心设计好缓存的key即可；缓存key的多少要看成本，如果所有可能的查询都设计对应的key，那时间复杂度 为1，查询性能自然高；但代价也大，因为key多了。如果想key少一点，那查询的复杂度自然要上去一点。所以缓存设计无非就是空间换时间的思路。然后， 缓存的更新无非就是：自动失效、定时更新、主动通知3种。通过CQRS架构，由于CQ两端是事件驱动的，当C端有任何状态变化，都会产生对应的事件去通知 Q端，所以我们几乎可以做到Q端的准实时更新。
同时由于CQ两端的完全解耦，Q端我们可以设计多种存储，如数据库和缓存（Redis等）；数据库用于线下维护关系型数据，缓存用户实时查询。数据 库和缓存的更新速度相互不受影响，因为是并行的。对同一个事件，可以10台机器负责更新缓存，100台机器负责更新数据库。即便数据库的更新很慢，也不会 影响缓存的更新进度。这就是CQRS架构的好处，CQ的架构完全不同，且我们随时可以重建一种新的Q端存储。不知道大家体会到了没有？
关于缓存key的设计，我觉得主要从查询余票时传递的信息来考虑。12306的关键查询是：出发地、目的地、出发日期三个信息。我觉得有两种key 的设计思路：1）直接设计了该查询条件的key，然后快速拿到车次信息，直接返回；这种方式就是要求我们系统已经枚举了所有车次的所有可能出现的票（区 间）的缓存key，相信你一定知道这样的key是非常多的。2）不是枚举所有区间，而是把每个车次的每个原子区间（相邻的两个站点所连成的直线）的可用票 数作为key。这样，key就非常少了，因为车次假如有10000个，然后每个车次平均15个区间，那也就15W个key而已。当我们要查询时，只需要把 用户输入的出发地和目的地之间的所有原子区间的可用票数都查出来，然后比较出最小可用票数的那个原子区间。则这个原子区间的可用票数就是用户输入的区间的 可用票数了。当然，到这里我提到考虑出发日期。我认为出发日期是用来决定具体是哪个车次聚合根的。同一个车次，不同的日期，对应的聚合根实例是不同的，即 便是同一天，也可能有多个车次聚合根，因为有些车次一天有几班的，比如上午9点发车的一班，下午3点发车的一般。所以，我们也只要把日期也作为缓存key 的一部分即可。
G. 旅游网站的策划怎么写
一、客户需求分析：
互联网正在慢慢地改变生活，这已经不仅仅是概念的演绎，在生活工作的各个方面，都留下了互联网的印记。旅游业也不例外，据统计，网上旅游业销售额已经占到全球电子商务销售额的20%以上。随着假日旅游、自助旅游、各种主题旅游的兴起，旅游网站也焕发着春天般的气息，一个好的网站对旅游资源的宣传和游客出行计划都有着积极的意义，让游客们有备而来、尽兴而归。通过网站开展相关旅游资源的电子商务整合和旅游资源的管理都将会是旅游业不可回避的现实。
二、网站功能和内容：
1、网站功能：
前台实现功能
(1)新用户注册
(2)密码修改功能
(3)分类信息搜索
后台实现功能
(1)用户注册信息管理
(2)分类信息管理
1)、旅游企业的旅游产品能够通过互联网得到广泛的、全面的宣传，让尽可能多的旅游企业、旅游者了解和熟知旅游企业的产品以及产品特色，旅游企业服务。
2)、能够通过互联网找到新的合作伙伴，拓宽市场销售渠道。
3)、能够通过网站和客户之间达成直接交流，收集客户意见。
4)、能够为企业的旅游产品提供直接销售的空间，旅游企业通过互联网宣传企业产品的过程中能够直接接收到网上的游客订单。
5)、能够帮助旅游企业在具体业务过程中提供便利、快捷、实惠的信息;互联网能够充分体现网络优势，帮助企业实现散客网上成团，即使散客不成团企业需要独立操作时。
2、栏目架构
三、系统功能：
本公司开发人员拥有丰富的大型网站开发经验，在网站建设方面拥有丰厚的底蕴和积累，在旅游综合信息建设、旅游电子商务预订、旅游B2B电子商务平台建设方面均有自己独特完整的解决方案。该系统主要包括：新闻发布系统、旅游线路发布及预订系统、游客出游意向询价系统、在线散客拼团系统、电子杂志订阅分发系统、电子邮件营销系统、在线市场调查系统、统计系统、动态栏目更新、专业旅游论坛系统、后台管理及权限分配等。系统采用Browse/Server模式，既用户端采用浏览器方式。
下面简单介绍各子系统功能：
1、新闻发布系统
多栏目：可根据需要建立数个新闻栏目。
自动列出相关新闻：程序将自动将相关连的新闻显示出来，方便浏览者。
关键词功能：发布新闻时，可为每篇文章设定关键词，使搜索更加准确，相关新闻相关性更好。
搜索功能：可以进行标题和时间搜索，让用户查找信息更加方便快捷。
自动更新功能：在发布/修改新闻后可以更新首页或栏目首页以反映最新新闻变化。
后台管理：可以新发布、修改、删除新闻。
2、旅游线路发布及预订系统
后台管理功能：
方便地管理旅游线路：轻松发布、修改、删除旅游线路，有标准发布和自定义发布两种形式，自定义发布可以将你已经有的线路Word文档直接上传到网站上发布，界面设计精巧新颖。
方便地管理订单：可方便的查看、修改、删除、回复用户订单
方便地管理用户资料：可对旅游者进行会员制管理，保存会员的资料以便日后联系
方便地推荐旅游线路：可以设置、取消旅游线路是否为推荐旅游线路，推荐的旅游线路优先显示良好的完备查询功能：可以查询按地区、线路、价格、姓名等查询旅游线路资料或用户资料。
前台预订功能：
浏览功能：旅游者可选择旅游线路进行浏览，了解旅游线路的详细情况，如天数、价格、景点、餐标、住宿、已包含的费用和未包含的费用等。
预订功能：如果满意的话即可预定该旅游线路，填写订单。如果用户对所有的线路都不满意的话，可以自己填写出游意向，旅行社可根据用户的要求提供个性化的服务。
会员注册功能：本系统可作为会员系统使用，接受用户注册，本系统的用户数据库和线路预订系统、网上订票系统的数据库为统一的一个库，更加方便网站对用户的管理。
3、游客出游意向询价系统
游客可将自己的出游意向发布到网站上，由旅行社为其定制服务。后台可对其进行删除操作。
4、在线散客拼团系统
包括：发布/维护拼团信息、线上报名拼团、后台管理程序。
发布拼团请求：旅行社会员发布自己的拼团线路和团队计划请其他同行前来参加拼团。
修改/删除拼团请求：旅行社会员可以发布自己的拼团线路进行修改和删除操作。
修改拼团计划：旅行社在该团队的动态出团/成团发生变化后，即时上网更新团队状况。
拼团需求(团队询价)：如果用户在拼团计划中没有查询到符合自己要求的线路而自己手头客源。可以发布自己的拼团需求进行团队询价。
5、电子杂志订阅分发系统
电子杂志的创建、修改、发布、删除、查询、订阅、退订。
反垃圾邮件功能：订阅电子杂志的用户只需通过简单的设置就能保证其它用户以及电子杂志的发布者不能看到你的电子邮箱地址，即不会收到某些用户通过本系统发给您的垃圾邮件。
用户间互相传递消息功能：用户可通过本系统向其他用户和系统管理员发送短消息和电子邮件。
6、电子邮件营销系统
电子邮件营销的优点有：
便捷根本不用制作印刷品，也不用雇佣人力投递。
成本低廉制作成本和发送成本都比传统邮件低得多。
反馈率高电子邮件本身具有定向性，其使用的便捷性也会导致更高的反馈率。
7、在线市场调查系统
本系统支持单用户版的网上投票，投票结果用条形图或饼图显示。
可随时修改已申请投票内容的主题与选项。
系统有防止一人投多票的功能。
投票引擎申请模块支持多达八个选项的申请。
申请用户可以自由选择生成立体的饼图或者条形图来显示投票结果。
引擎后台管理提供友好界面，管理员不需涉及任何编程，就可对数据库内容进行修改。
管理员可以增加或删除现有投票主题的各个选项。管理员可以直接删除投票主题或增加新增投票主题的选项。
8、统计系统
我公司开发统计系统的优点有：
可以统计客户的详细来源。
可以锁定客户的来源区域及来访次数。
统计真实IP，可以自定义统计时间。可以锁定目标客户的来源搜索引挚及所用关键词。
提供数据的统计分析功能。
9、动态栏目更新
可以按不同的时期在页面显示不同的内容栏目页，实现后台动态栏目更新。可以增设及修修栏目并为该栏目添加资讯信息。支持图文并茂显示。
10、后台管理及权限分配
系统支持多人维护，可根据分工的不同分配不同的权限。
支持数据安全备份。
统一数据库，轻松维护网站。
11、专业旅游论坛系统
本系统支持多人发言，可限制权限等。
四、系统特点：
·先进性
该系统在设计上采用三层结构、WebService技术，使之在选用平台、采用技术上具有先进性、前瞻性、扩充性，从而保证建成的网站系统具有良好的稳定性、可扩展性和安全性。
·实用性
考虑到要尽量满足业务功能需求的前提下，又要适应各业务角色的工作特点，该系统做到简单、实用、人性化，实现了统一身份和资源管理、统一认证、统一内容管理、个性化界面和内容定制。
·可靠性
由于该系统用户群比较复杂，所以建设的信息服务网站系统我们考虑了在建设平台上保证系统的可靠性和安全性。系统设计中，应有适量冗余及其他保护措施，平台和应用软件具有良好的容错性、容灾性等。
·开放性
在系统构架、采用技术、选用平台方面都有较好的开放性。特别是在选择产品上，我们采用符合开放性要求，遵循国际标准化组织的技术标准，我们的产品既有自己的独特优势，又能与其他多家优秀的产品进行组合，共同构成一个开放的、易扩充的、稳定的、统一软件的系统。
·可维护性
系统设计应标准化、规范化，按照分层设计，软件构件化实现。采用软件构件化的开发方式：一是系统结构分层，业务与实现分离，逻辑与数据分离;二是以统一的服务接口规范为核心，使用开放标准;三是构件语意描述形式化;四是提炼封装构件规范化。
·可伸缩性
考虑到政务系统的网上业务建设是一个循序渐进、不断扩充的过程，系统采用积木式结构，整体构架可以与原有系统进行无缝连接，为今后系统扩展和集成留有扩充余量。
·可移植性
选择开放的应用平台，建设一套与平台无关，以统一的服务接口规范和与各种数据库相连的应用组件。
五、运行环境：
服务器：Windows2003Server
数据库：SQLServer2000
六、技术实现：
编程语言：服务器端。Net，客户端Javascript
页面实现：DIV+CSS
应用技术：AJAX、RSS、XML等
七、网站功能和内容
1、网站功能：
前台实现功能
(1)新用户注册
(2)密码修改功能
(3)分类信息搜索
后台实现功能
(1)用户注册信息管理
(2)分类信息管理
2、网站的内容规划：
首页导航条：美容、瘦身、养生、最新信息、留言板、关于我们、联系我们、会员登录等。
美容：提供各种健康美白、护肤、保养信息等。
瘦身：提供各种健康纤体、瘦身、保健信息等。
养生：提供四季生活养生信息。
最新信息：提供及时的新品信息。
留言板：为了更好的与网民交流，为了让客户在网络上有一个可交流的地方，我们打造一个网上交流的BBS论坛系统，使客户与客户，我们与客户之间可以针对某一问题进行交流，从而增加网站的人气。
关于我们：提供在网站购物相关的帮助信息。
联系我们：利用E-mail客户可以直接和我们联系。
会员注册、登陆系统：用户可进行在线注册，免费成为会员。注册成会员后可以在网站的登录位置进行登录。
3、网站的目标和作用
网站要达到让客户了解我们网站的各种信息的目的，以及通过网络宣传我们的网站，进一步实现盈利的目的。并且对网站进行推广，促使客户数目的增加。
4、网站技术解决方案
(1)操作系统
系统采用WinxpServer+IIS+SQLServer+APS作为平台，开发成本低、功能强大，完全满足客户需求，将客户的理想转化为现实。
(2)租用虚拟主机、个性化开发
(3)网站安全措施，防黑、防病毒方案
在设置口令的时候尽可能复杂，单纯的英文或者数字很容易被暴力破解。某些系统服务功能有内建账号，应及时修改操作系统内部账号口令的缺省设置，防止别人利用默认的密码侵入系统。
我们还要时刻关注微软官方站点发布的补丁程序。通常在微软公司发现了某些有可能影响系统安全的漏洞之后，都会在它的官方网站中发布系统补丁，这时应该在第一时间中下载安装最新的补丁，及时堵住系统漏洞。
使用Windows2000/XP过程中还需要经常查看系统日志文件，因为这个文件会完整记录一段时间之内所有的网络活动情况，通过查看系统日志能够得知是否有人对系统尝试攻击以及攻击的结果，便于我们进行针对性的弥补。
最行之有效的网络安全防护手段就是安装一款防火墙软件。目前这种防火墙软件很多，比如天网防火墙、NortonInternetFirewall、ZoneAlarm等，它们不仅可以防Ping、防止恶意连接，而且在遇到恶意攻击的时候还会有独特的警告信息来引起注意，并且把所有的入侵信息记录下来。
(4)相关程序开发
我们使用网页程序ASP、JSP等网页技术来完善网站建设，并使用photoshop来修饰图片。
5、网页风格设计
网站的页面设计：我们的网页主要采用的是以粉红色为主色调，淡紫色为辅助颜色，在此种颜色的基础之上还要添加一些绿色为基调。总之主要的就是体现女性的青春活力，吸引更多的浏览者进入观赏，并积极地进行讨论。而且能让他们在我们的网站上找到他们所要了解的知识，既要迅速又要快捷。
网站页面制作先进技术应用：我们将采用先进的JAVE技术、VBScript等等来对所要进行的网站进行编程以及系统的设计。
内容风格：网站的内容时尚新颖，简洁明朗，方便快速浏览，具有当今美容潮流的风格。我们所涉及的美容、瘦身、养生等知识能够以最新的内容吸引留言者的观赏，掌握最新的动态以及现今对于美容瘦身以及养生各种最新的讨论和评价，使整体上感觉很真实，而不是一味的吹捧等。除此之外，我们还会在我们的网站上投放一些现当今比较流行的音乐，让浏览者一边听着优美的音乐一边观赏我们的网页，有种赏心悦目的感觉，给他们留下深刻的印象，以增加我们的访问量。当然在以上的基础之上，我们要把动态和静态网页做好。
6、网站维护
(1)数据库维护
我们将对数据库进行管理、备份、灾难恢复。
(2)内容维护
我们会对网站的内容进行及时地更新和调整，并对新产品进行及时的发布
7、网站测试
在网站发布前我们会进行周密的测试，以保证正常浏览和使用。
(1)服务器-稳定性、安全性等
(2)程序、数据库测试
(3)网页兼容性测试――浏览器、分辨率等
(4)其他测试
8、网站的发布与推广
(1)发布广告
(2)搜索引擎登记
1)注册3721网络实名，并可参考竞价排名。
2)加入网络、Google等国内大型网站搜索引擎
(3)友情 链接
网站的友情链接系统可以与国内外的广大化妆品网站联系起来，让我们了解别人，也让别人了解我们，交换友情链接不但可以提高网站的访问量，而且可以带来无限的商机。链接的方式很多，我们采取文字与LOGO交换。文字简便，LOGO图片直接。
(4)其他推广活动
1)在国内电子公告栏BBS发布信息
2)通过E-mail，向广大网民发布网站信息
9、网站建设日程表
各项规划任务的开始完成时间、负责人等。