超级军网忘情前不久写了篇火车订票系统的博文，现在程序员要出来 ...
来源：百度文库 编辑：超级军网 时间：2024/04/29 12:55:20
程序员不满订票难 自建12306开源项目组
2012-09-30 08:09:18 15194 人阅读 编辑：萧萧 [复制链接] [我要爆料]
国庆前，12306 再次站到风口浪尖上，因为系统崩溃而买不到火车票的人们纷纷在网上吐槽。当程序员也订不到火车票，后果就不止吐槽那么简单。
据ifanr报道，27 日下午 3:02，网友@caoz 发表了一条微博(见下图)，很快该微博就被转发了上万次：
随后，各种专业吐槽和评论，让人们从专业角度了解到 12306 在技术层面上还有很多需要改进的地方。然而，程序员的脚步不止于此。同一天晚上 10 ：34，网友@大学001 发了这么一条微博：
为了程序猿可以顺利在 12306 预订到火车票，我建议成立 12306NG 开源项目组。有兴趣参加的请转起来！我负责筹资并以一个程序猿老兵名义奉献不止…
28 日凌晨 1:38，12306NG.org 注册成功，并接受报名。@大学001 表示：“这将是项目组自己的网站，完全公益！我们将通过此网站发布项目所有成果，包括源代码、技术方案、各类文档等。此网站也是我们项目组讨论、协作、分享的地方。”下午 5:07，12306NG 开源项目组官方微博发了第一条微博，表示项目组开始筹备。
今天，@12306NG开源项目组 发表微博，公布项目进度。现在，项目已吸纳 10 多名程序员，涵盖数据库、大并发、高性能、分布式架构等多领域。而项目范围日益清晰，技术框架渐现眉目。
@大学001 在新浪微博上的认证身份为京东商城副总裁李大学，但他声明：此事与京东无关，纯属个人行为。
现在，12306NG 开源项目组论坛上《【需求分析】12306NG 的需求总汇》一帖已有44 楼，用户活跃地讨论交流对于 12306 的设想。
李大学认为，在中国，社区力量能够挑战商业组织，中国经济已经从资源争夺转向技术驱动，属于程序员的时代来了。他希望程序员们能做到：不抱怨，去改变，从我做起。
NG 是 Next Generation 的意思。《建设一个靠谱的火车票网上订购系统》一文写道：“如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点，而且是贴着中国标签的前沿科技的亮点。”现实也许是，最后铁道部并没采纳项目组的方案，但我们可以看到，正是由于网络的开放性，才能聚集民间智慧，推动社会进步。至少，参与其中的程序员能将受益于彼此的想法，而铁道部技术人员也能从中借鉴。最终受益的是老百姓。
“中国程序猿们站起来，火车上的民工们才能坐下去！”
——@大学001
我想，很快，这一条将位于“找程序员当男朋友的十大好处”这一类排行榜榜首。
======================================================
虽然本人没学过数据库
不过也知道LIKE语句是一条很没有查询效率的语句
看看这帮程序员能搞出什么好东西吧程序员不满订票难 自建12306开源项目组
2012-09-30 08:09:18 15194 人阅读 编辑：萧萧 [复制链接] [我要爆料]
国庆前，12306 再次站到风口浪尖上，因为系统崩溃而买不到火车票的人们纷纷在网上吐槽。当程序员也订不到火车票，后果就不止吐槽那么简单。
据ifanr报道，27 日下午 3:02，网友@caoz 发表了一条微博(见下图)，很快该微博就被转发了上万次：
随后，各种专业吐槽和评论，让人们从专业角度了解到 12306 在技术层面上还有很多需要改进的地方。然而，程序员的脚步不止于此。同一天晚上 10 ：34，网友@大学001 发了这么一条微博：
为了程序猿可以顺利在 12306 预订到火车票，我建议成立 12306NG 开源项目组。有兴趣参加的请转起来！我负责筹资并以一个程序猿老兵名义奉献不止…
28 日凌晨 1:38，12306NG.org 注册成功，并接受报名。@大学001 表示：“这将是项目组自己的网站，完全公益！我们将通过此网站发布项目所有成果，包括源代码、技术方案、各类文档等。此网站也是我们项目组讨论、协作、分享的地方。”下午 5:07，12306NG 开源项目组官方微博发了第一条微博，表示项目组开始筹备。
今天，@12306NG开源项目组 发表微博，公布项目进度。现在，项目已吸纳 10 多名程序员，涵盖数据库、大并发、高性能、分布式架构等多领域。而项目范围日益清晰，技术框架渐现眉目。
@大学001 在新浪微博上的认证身份为京东商城副总裁李大学，但他声明：此事与京东无关，纯属个人行为。
现在，12306NG 开源项目组论坛上《【需求分析】12306NG 的需求总汇》一帖已有44 楼，用户活跃地讨论交流对于 12306 的设想。
李大学认为，在中国，社区力量能够挑战商业组织，中国经济已经从资源争夺转向技术驱动，属于程序员的时代来了。他希望程序员们能做到：不抱怨，去改变，从我做起。
NG 是 Next Generation 的意思。《建设一个靠谱的火车票网上订购系统》一文写道：“如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点，而且是贴着中国标签的前沿科技的亮点。”现实也许是，最后铁道部并没采纳项目组的方案，但我们可以看到，正是由于网络的开放性，才能聚集民间智慧，推动社会进步。至少，参与其中的程序员能将受益于彼此的想法，而铁道部技术人员也能从中借鉴。最终受益的是老百姓。
“中国程序猿们站起来，火车上的民工们才能坐下去！”
——@大学001
我想，很快，这一条将位于“找程序员当男朋友的十大好处”这一类排行榜榜首。
======================================================
虽然本人没学过数据库
不过也知道LIKE语句是一条很没有查询效率的语句
看看这帮程序员能搞出什么好东西吧
2012-09-30 08:09:18 15194 人阅读 编辑：萧萧 [复制链接] [我要爆料]
国庆前，12306 再次站到风口浪尖上，因为系统崩溃而买不到火车票的人们纷纷在网上吐槽。当程序员也订不到火车票，后果就不止吐槽那么简单。
据ifanr报道，27 日下午 3:02，网友@caoz 发表了一条微博(见下图)，很快该微博就被转发了上万次：
随后，各种专业吐槽和评论，让人们从专业角度了解到 12306 在技术层面上还有很多需要改进的地方。然而，程序员的脚步不止于此。同一天晚上 10 ：34，网友@大学001 发了这么一条微博：
为了程序猿可以顺利在 12306 预订到火车票，我建议成立 12306NG 开源项目组。有兴趣参加的请转起来！我负责筹资并以一个程序猿老兵名义奉献不止…
28 日凌晨 1:38，12306NG.org 注册成功，并接受报名。@大学001 表示：“这将是项目组自己的网站，完全公益！我们将通过此网站发布项目所有成果，包括源代码、技术方案、各类文档等。此网站也是我们项目组讨论、协作、分享的地方。”下午 5:07，12306NG 开源项目组官方微博发了第一条微博，表示项目组开始筹备。
今天，@12306NG开源项目组 发表微博，公布项目进度。现在，项目已吸纳 10 多名程序员，涵盖数据库、大并发、高性能、分布式架构等多领域。而项目范围日益清晰，技术框架渐现眉目。
@大学001 在新浪微博上的认证身份为京东商城副总裁李大学，但他声明：此事与京东无关，纯属个人行为。
现在，12306NG 开源项目组论坛上《【需求分析】12306NG 的需求总汇》一帖已有44 楼，用户活跃地讨论交流对于 12306 的设想。
李大学认为，在中国，社区力量能够挑战商业组织，中国经济已经从资源争夺转向技术驱动，属于程序员的时代来了。他希望程序员们能做到：不抱怨，去改变，从我做起。
NG 是 Next Generation 的意思。《建设一个靠谱的火车票网上订购系统》一文写道：“如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点，而且是贴着中国标签的前沿科技的亮点。”现实也许是，最后铁道部并没采纳项目组的方案，但我们可以看到，正是由于网络的开放性，才能聚集民间智慧，推动社会进步。至少，参与其中的程序员能将受益于彼此的想法，而铁道部技术人员也能从中借鉴。最终受益的是老百姓。
“中国程序猿们站起来，火车上的民工们才能坐下去！”
——@大学001
我想，很快，这一条将位于“找程序员当男朋友的十大好处”这一类排行榜榜首。
======================================================
虽然本人没学过数据库
不过也知道LIKE语句是一条很没有查询效率的语句
看看这帮程序员能搞出什么好东西吧程序员不满订票难 自建12306开源项目组
2012-09-30 08:09:18 15194 人阅读 编辑：萧萧 [复制链接] [我要爆料]
国庆前，12306 再次站到风口浪尖上，因为系统崩溃而买不到火车票的人们纷纷在网上吐槽。当程序员也订不到火车票，后果就不止吐槽那么简单。
据ifanr报道，27 日下午 3:02，网友@caoz 发表了一条微博(见下图)，很快该微博就被转发了上万次：
随后，各种专业吐槽和评论，让人们从专业角度了解到 12306 在技术层面上还有很多需要改进的地方。然而，程序员的脚步不止于此。同一天晚上 10 ：34，网友@大学001 发了这么一条微博：
为了程序猿可以顺利在 12306 预订到火车票，我建议成立 12306NG 开源项目组。有兴趣参加的请转起来！我负责筹资并以一个程序猿老兵名义奉献不止…
28 日凌晨 1:38，12306NG.org 注册成功，并接受报名。@大学001 表示：“这将是项目组自己的网站，完全公益！我们将通过此网站发布项目所有成果，包括源代码、技术方案、各类文档等。此网站也是我们项目组讨论、协作、分享的地方。”下午 5:07，12306NG 开源项目组官方微博发了第一条微博，表示项目组开始筹备。
今天，@12306NG开源项目组 发表微博，公布项目进度。现在，项目已吸纳 10 多名程序员，涵盖数据库、大并发、高性能、分布式架构等多领域。而项目范围日益清晰，技术框架渐现眉目。
@大学001 在新浪微博上的认证身份为京东商城副总裁李大学，但他声明：此事与京东无关，纯属个人行为。
现在，12306NG 开源项目组论坛上《【需求分析】12306NG 的需求总汇》一帖已有44 楼，用户活跃地讨论交流对于 12306 的设想。
李大学认为，在中国，社区力量能够挑战商业组织，中国经济已经从资源争夺转向技术驱动，属于程序员的时代来了。他希望程序员们能做到：不抱怨，去改变，从我做起。
NG 是 Next Generation 的意思。《建设一个靠谱的火车票网上订购系统》一文写道：“如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点，而且是贴着中国标签的前沿科技的亮点。”现实也许是，最后铁道部并没采纳项目组的方案，但我们可以看到，正是由于网络的开放性，才能聚集民间智慧，推动社会进步。至少，参与其中的程序员能将受益于彼此的想法，而铁道部技术人员也能从中借鉴。最终受益的是老百姓。
“中国程序猿们站起来，火车上的民工们才能坐下去！”
——@大学001
我想，很快，这一条将位于“找程序员当男朋友的十大好处”这一类排行榜榜首。
======================================================
虽然本人没学过数据库
不过也知道LIKE语句是一条很没有查询效率的语句
看看这帮程序员能搞出什么好东西吧
如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点
这句话很有意思！是不是可以这么理解！12306有很多问题！但如果能相对系统的解决12306的问题,还是需要很高的技术含量的！甚至高于很多购物网站！
这句话很有意思！是不是可以这么理解！12306有很多问题！但如果能相对系统的解决12306的问题,还是需要很高的技术含量的！甚至高于很多购物网站！
2012年3月，他面试了来求职的铁科研12306产品开发团队的一位成员，该成员长期负责12306的架构设计。他向李先生详细介绍了12306的架构设计思路和过程，李先生认为这位架构师基本没有互联网产品设计经验。
据李先生介绍，12306架构设计中连基本的分布式和高性能都没考虑过，诸如读写分离、高并发下的分布式处理也没考虑过，系统也没有考虑设置不同数据库分布到不同的服务器上，甚至都没有考虑为读写做相应的缓存，整个流程中也没有考虑过队列，所以卡住后排队等基本情况都没想过。
而这些都是互联网架构师需要具备的最基本的思维，这位12306的架构师完全没有这样的思维。
其实12306这个系统的业务项比较复杂，跟机票系统一样，出票等业务规则复杂，由于规则负杂，会有特殊的颗粒、特殊的流，比如分段出票，退票、新增票等，所以必须要有相应的架构设计与之相对应。比如从技术角度看，订票是一个写操作，查询是读的操作，不能因为查询很多影响订票操作，需要通过使用读写分离就可以实现。
=====================================
据李先生介绍，12306架构设计中连基本的分布式和高性能都没考虑过，诸如读写分离、高并发下的分布式处理也没考虑过，系统也没有考虑设置不同数据库分布到不同的服务器上，甚至都没有考虑为读写做相应的缓存，整个流程中也没有考虑过队列，所以卡住后排队等基本情况都没想过。
而这些都是互联网架构师需要具备的最基本的思维，这位12306的架构师完全没有这样的思维。
其实12306这个系统的业务项比较复杂，跟机票系统一样，出票等业务规则复杂，由于规则负杂，会有特殊的颗粒、特殊的流，比如分段出票，退票、新增票等，所以必须要有相应的架构设计与之相对应。比如从技术角度看，订票是一个写操作，查询是读的操作，不能因为查询很多影响订票操作，需要通过使用读写分离就可以实现。
=====================================
还是能者上吧，我设计的网站还真是满版的like,<% %>之类，连STRUTS都没用。
忘情写那玩意只是为了炫耀自己能参加所谓内部会议而已，它懂啥网站开发啊。
分布式，集群，读写分离，内存数据库，消息中间件，缓存机制这些都要用得上才能适应这个订票系统的要求。
另外解决订票请求集中爆发的问题，应该还得从算法和系统架构上做更多的考虑，我觉得可以用票池预分配的手段，根据历史数据和前若干天车票的请求情况，对票池结构、计算资源进行合理组织和预先分配，这样不仅在主机、数据库以及读与写的层面达到分布的目的，对数据本身也根据业务特征进行了动态的分布，请求响应时，通过一定的算法直接在其票池范围内的交易服务器上以负载均衡的方式进行处理，票池内车票的数量低于某个阈值时，再由主控服务器进行后续批次的分配。交易服务器上仅对分配的车票是否订成功这件事进行处理，达到及时给用户反馈信息的目的，后续出票、打印、验票的事情，可以交给售后服务的服务器进行。
总之，开源我认为是潮流，现在很多开源项目比商业的好多了，这是一个公共服务系统，技术方案完全可以以开源的方式来运作，肯定比1、2个公司的那么些人搞出来的要靠谱，当然这个开源项目必须要有足够多的人关注和参与才行。
另外解决订票请求集中爆发的问题，应该还得从算法和系统架构上做更多的考虑，我觉得可以用票池预分配的手段，根据历史数据和前若干天车票的请求情况，对票池结构、计算资源进行合理组织和预先分配，这样不仅在主机、数据库以及读与写的层面达到分布的目的，对数据本身也根据业务特征进行了动态的分布，请求响应时，通过一定的算法直接在其票池范围内的交易服务器上以负载均衡的方式进行处理，票池内车票的数量低于某个阈值时，再由主控服务器进行后续批次的分配。交易服务器上仅对分配的车票是否订成功这件事进行处理，达到及时给用户反馈信息的目的，后续出票、打印、验票的事情，可以交给售后服务的服务器进行。
总之，开源我认为是潮流，现在很多开源项目比商业的好多了，这是一个公共服务系统，技术方案完全可以以开源的方式来运作，肯定比1、2个公司的那么些人搞出来的要靠谱，当然这个开源项目必须要有足够多的人关注和参与才行。
12306这么高的并发量用上几千万条索引不见得效率就高到哪去，SQL写LIKE其实没什么大不了，无非就是要做全表操作，效率低下，应尽量避免使用，但不是完全不可以用，我们要结合TDB那万年后台来考虑，SSH,iBatis这些框架有时候不能完全解决问题。如果TDB的数据库许久没有升级过的话，据我所知早期的informix,db2对于F5负载均衡的支持并不好。
一般这种老国有企业的用的系统都有稀奇八糟的幺蛾子，曾经观摩过邮储银行的case，没错，就是那个邮电局改的银行。告诉大家个秘密，邮储银行的账务核心系统有100多个，没错，100多个，一般银行核心也就几套生产，几套灾备就行了，而邮储银行还必须把这100多套用着不同架构、不同数据库、不同中间件、不同语言甚至不同通信协议的核心系统捏到一起，当时看得我目瞪口呆，没想到都21世纪咧，竟然还有用RSP协议的嘞
。so,12306这个标我觉得3亿真心少了....
一般这种老国有企业的用的系统都有稀奇八糟的幺蛾子，曾经观摩过邮储银行的case，没错，就是那个邮电局改的银行。告诉大家个秘密，邮储银行的账务核心系统有100多个，没错，100多个，一般银行核心也就几套生产，几套灾备就行了，而邮储银行还必须把这100多套用着不同架构、不同数据库、不同中间件、不同语言甚至不同通信协议的核心系统捏到一起，当时看得我目瞪口呆，没想到都21世纪咧，竟然还有用RSP协议的嘞
。so,12306这个标我觉得3亿真心少了....这东西用云存储来解决
就像微博上的段子那样，很可能是哪个学校编程系的期末考试
作为会员制网站，首页居然都没有“注册”和“登陆”按钮，实在是奇葩……
废土行者 发表于 2012-10-2 23:19 
这东西用云存储来解决
你这就是纯粹不懂瞎扯了
这东西用云存储来解决
你这就是纯粹不懂瞎扯了
longxia 发表于 2012-10-2 23:25
你这就是纯粹不懂瞎扯了
你懂个锤子。
你这就是纯粹不懂瞎扯了
你懂个锤子。
ac58310 发表于 2012-10-2 23:16
12306这么高的并发量用上几千万条索引不见得效率就高到哪去，SQL写LIKE其实没什么大不了，无非就是要做全表 ...
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下来每台也就是2万个，这个对于好一点的PC Server服务器都能满足了，如果我们能够根据请求特征hash到特定范围的服务器，在这个范围内负载均衡，进行车票资源的预分配和购票的交易处理，就能够满足这样的高并发请求。如果没有这么多服务器，联合各门户网站和电商的计算资源，也肯定可以满足了。
12306这么高的并发量用上几千万条索引不见得效率就高到哪去，SQL写LIKE其实没什么大不了，无非就是要做全表 ...
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下来每台也就是2万个，这个对于好一点的PC Server服务器都能满足了，如果我们能够根据请求特征hash到特定范围的服务器，在这个范围内负载均衡，进行车票资源的预分配和购票的交易处理，就能够满足这样的高并发请求。如果没有这么多服务器，联合各门户网站和电商的计算资源，也肯定可以满足了。
废土行者 发表于 2012-10-2 23:37
你懂个锤子。
屁话 来点实际意见啊 云储存 云储存 别就会一个名词
你懂个锤子。
屁话 来点实际意见啊 云储存 云储存 别就会一个名词
longxia 发表于 2012-10-2 23:40
屁话 来点实际意见啊 云储存 云储存 别就会一个名词
你不是说我啥都不懂，你懂得很嘛，咋个喊我拿意见喃，你发表意见三。
屁话 来点实际意见啊 云储存 云储存 别就会一个名词
你不是说我啥都不懂，你懂得很嘛，咋个喊我拿意见喃，你发表意见三。
一目半 发表于 2012-10-2 23:37
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下 ...
必须有索引服务器。
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下 ...
必须有索引服务器。
废土行者 发表于 2012-10-2 23:45
你不是说我啥都不懂，你懂得很嘛，咋个喊我拿意见喃，你发表意见三。
诡辩 我说了云储存在这里是扯淡 实现不了 这也要我证明？
你说狗可以飞 我说不能 当然是你找条会飞的狗来证明啊
你不是说我啥都不懂，你懂得很嘛，咋个喊我拿意见喃，你发表意见三。
诡辩 我说了云储存在这里是扯淡 实现不了 这也要我证明？
你说狗可以飞 我说不能 当然是你找条会飞的狗来证明啊
一目半 发表于 2012-10-2 23:37
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下 ...
甭管几个数据库，原理都是一样的，每个数据库你都得准备至少上百万个索引，而且每个数据库还要考虑冷热备切换，是物理分割还是逻辑分割?并且数据库肯定不止账务数据一种，肯定还包含至少几十个子项目，比如说CIF，参数系统，监控系统，数据仓库可能还得供数，这些建立的时间都不一样，当时考虑的情况也不一样，哪个地方出差错会造成整体效率的瓶颈。况且购票请求不是仅仅一个onClick就完事了，其中要包含一系列业务逻辑。业务逻辑的运行肯定不能参考单例模式，那就用工厂模式吧，那这问题又来了一个包含线程管理，业务组装定制这个都够做成一个新的SOB化的平台了，考虑到兼容性可能还得再封一层，真要是完善那可是个大工程。我个人不看好几个程序员在网上一拍脑门就能把这问题解决了，阿里巴巴也不是一天建成的啊。。。
所以TDB脑子进水，你把这业务直接外包给淘宝，京东坐着分提成不就好了，还折腾啥。
一目半 发表于 2012-10-2 23:37
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下 ...
甭管几个数据库，原理都是一样的，每个数据库你都得准备至少上百万个索引，而且每个数据库还要考虑冷热备切换，是物理分割还是逻辑分割?并且数据库肯定不止账务数据一种，肯定还包含至少几十个子项目，比如说CIF，参数系统，监控系统，数据仓库可能还得供数，这些建立的时间都不一样，当时考虑的情况也不一样，哪个地方出差错会造成整体效率的瓶颈。况且购票请求不是仅仅一个onClick就完事了，其中要包含一系列业务逻辑。业务逻辑的运行肯定不能参考单例模式，那就用工厂模式吧，那这问题又来了一个包含线程管理，业务组装定制这个都够做成一个新的SOB化的平台了，考虑到兼容性可能还得再封一层，真要是完善那可是个大工程。我个人不看好几个程序员在网上一拍脑门就能把这问题解决了，阿里巴巴也不是一天建成的啊。。。
所以TDB脑子进水，你把这业务直接外包给淘宝，京东坐着分提成不就好了，还折腾啥。
一目半 发表于 2012-10-2 23:37
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下 ...
数据库并行咋解决？ 最后一张票 A服务器上有人要买 B上也有人要买 不在一个库上 到底是卖谁？
肯定不会是一个数据库来解决，而是N多个数据库。假设有1000台交易服务器，那么2千万级别的购票请求平均下 ...
数据库并行咋解决？ 最后一张票 A服务器上有人要买 B上也有人要买 不在一个库上 到底是卖谁？
longxia 发表于 2012-10-2 23:51
诡辩 我说了云储存在这里是扯淡 实现不了 这也要我证明？
你说狗可以飞 我说不能 当然是你找条会飞的狗来 ...
算了，呵呵，懒得和你扯，没意思。
诡辩 我说了云储存在这里是扯淡 实现不了 这也要我证明？
你说狗可以飞 我说不能 当然是你找条会飞的狗来 ...
算了，呵呵，懒得和你扯，没意思。
废土行者 发表于 2012-10-2 23:53
算了，呵呵，懒得和你扯，没意思。
明明是你不懂在瞎扯
算了，呵呵，懒得和你扯，没意思。
明明是你不懂在瞎扯
废土行者 发表于 2012-10-2 23:47
必须有索引服务器。
索引的目的是快速找到数据的物理位置，倒还不是火车票系统的关键问题。我觉得关键问题首先在于如何解决数据的合理分布、以及请求的合理分布，就是把数据如何打碎的问题，然后是分布数据的一致性，就是如何把打碎的拼合起来的问题，当然如果设计得好，可能用最少的拼合就能知道数据的全貌。
必须有索引服务器。
索引的目的是快速找到数据的物理位置，倒还不是火车票系统的关键问题。我觉得关键问题首先在于如何解决数据的合理分布、以及请求的合理分布，就是把数据如何打碎的问题，然后是分布数据的一致性，就是如何把打碎的拼合起来的问题，当然如果设计得好，可能用最少的拼合就能知道数据的全貌。
longxia 发表于 2012-10-2 23:52
数据库并行咋解决？ 最后一张票 A服务器上有人要买 B上也有人要买 不在一个库上 到底是卖谁？
数据库并行其实还不是重点，你说的业务逻辑的判断也不应该在某台服务器上来做。应该是有一个平台来做这个事情，那么无论多少数据库，多少台服务器对这个平台来讲完全透明，他并不用关心A到底走的哪台服务器做的结算，他只知道A和B有先后顺序就够了。
数据库并行咋解决？ 最后一张票 A服务器上有人要买 B上也有人要买 不在一个库上 到底是卖谁？
数据库并行其实还不是重点，你说的业务逻辑的判断也不应该在某台服务器上来做。应该是有一个平台来做这个事情，那么无论多少数据库，多少台服务器对这个平台来讲完全透明，他并不用关心A到底走的哪台服务器做的结算，他只知道A和B有先后顺序就够了。
longxia 发表于 2012-10-2 23:58
明明是你不懂在瞎扯
我不懂，你懂完了。话说回来，我懂不懂关你屁事，哈哈，你继续纠结我懂不懂好了。
明明是你不懂在瞎扯
我不懂，你懂完了。话说回来，我懂不懂关你屁事，哈哈，你继续纠结我懂不懂好了。
ac58310 发表于 2012-10-2 23:59
数据库并行其实还不是重点，你说的业务逻辑的判断也不应该在某台服务器上来做。应该是有一个平台来做这个 ...
他说数据库我就说数据库喽 其实本质就是这东西没法分散 什么云储存 就tm扯淡 对个人可以 对企业还云储存 除非是google那样 自己弄N个数据中心 全是自己的 如果这算云储存的话 那还有点用
这几年还有人扯云办公没？ 谁敢放心自己的机密资料运行在别人服务器上
数据库并行其实还不是重点，你说的业务逻辑的判断也不应该在某台服务器上来做。应该是有一个平台来做这个 ...
他说数据库我就说数据库喽 其实本质就是这东西没法分散 什么云储存 就tm扯淡 对个人可以 对企业还云储存 除非是google那样 自己弄N个数据中心 全是自己的 如果这算云储存的话 那还有点用
这几年还有人扯云办公没？ 谁敢放心自己的机密资料运行在别人服务器上
废土行者 发表于 2012-10-3 00:03
我不懂，你懂完了。话说回来，我懂不懂关你屁事，哈哈，你继续纠结我懂不懂好了。
我纠结个毛 写作业呢 谁有时间理你 抽空看下超大罢了
对不起 强迫症 看见有人引用我习惯性回复 看过就丢 你丫谁啊 让我纠结
我不懂，你懂完了。话说回来，我懂不懂关你屁事，哈哈，你继续纠结我懂不懂好了。
我纠结个毛 写作业呢 谁有时间理你 抽空看下超大罢了
对不起 强迫症 看见有人引用我习惯性回复 看过就丢 你丫谁啊 让我纠结
longxia 发表于 2012-10-3 00:03
他说数据库我就说数据库喽 其实本质就是这东西没法分散 什么云储存 就tm扯淡 对个人可以 对企业还云储存 ...
怎么说云办公这个东西呢，OA我认为就是一种局部云。云这个概念的提出其实完全是一场阴谋，大型的网络服务提供商想通过企业在云端的服务来得到某种重要的行为模式，然后利用这种抽取出的行为模式数据赚钱。不过我觉得小微企业尝试下网络ERP，软件呼叫中心这种东东还是能降低成本的。
他说数据库我就说数据库喽 其实本质就是这东西没法分散 什么云储存 就tm扯淡 对个人可以 对企业还云储存 ...
怎么说云办公这个东西呢，OA我认为就是一种局部云。云这个概念的提出其实完全是一场阴谋，大型的网络服务提供商想通过企业在云端的服务来得到某种重要的行为模式，然后利用这种抽取出的行为模式数据赚钱。不过我觉得小微企业尝试下网络ERP，软件呼叫中心这种东东还是能降低成本的。
一目半 发表于 2012-10-2 23:58
索引的目的是快速找到数据的物理位置，倒还不是火车票系统的关键问题。我觉得关键问题首先在于如何解决数 ...
ceph可以解决，几年前我们就在用了，现在还比较可靠。
索引的目的是快速找到数据的物理位置，倒还不是火车票系统的关键问题。我觉得关键问题首先在于如何解决数 ...
ceph可以解决，几年前我们就在用了，现在还比较可靠。
longxia 发表于 2012-10-3 00:04
我纠结个毛 写作业呢 谁有时间理你 抽空看下超大罢了
对不起 强迫症 看见有人引用我习惯性回复 看过就丢 ...
豁，结果还没毕业唆。年轻人要谦虚点，你才摸计算机几年哦。
我纠结个毛 写作业呢 谁有时间理你 抽空看下超大罢了
对不起 强迫症 看见有人引用我习惯性回复 看过就丢 ...
豁，结果还没毕业唆。年轻人要谦虚点，你才摸计算机几年哦。
废土行者 发表于 2012-10-3 00:13
豁，结果还没毕业唆。年轻人要谦虚点，你才摸计算机几年哦。
摸了几年管你屁事 讲不出点门道 也好意思这里充大
豁，结果还没毕业唆。年轻人要谦虚点，你才摸计算机几年哦。
摸了几年管你屁事 讲不出点门道 也好意思这里充大
ac58310 发表于 2012-10-3 00:08
怎么说云办公这个东西呢，OA我认为就是一种局部云。云这个概念的提出其实完全是一场阴谋，大型的网络服务 ...
本来就是阴谋 计算这种东西 全部丢到服务器上 要天顶星科技才能支持。。。
怎么说云办公这个东西呢，OA我认为就是一种局部云。云这个概念的提出其实完全是一场阴谋，大型的网络服务 ...
本来就是阴谋 计算这种东西 全部丢到服务器上 要天顶星科技才能支持。。。
longxia 发表于 2012-10-3 00:18
摸了几年管你屁事 讲不出点门道 也好意思这里充大
算了，不和你吵，没意义。我只是说，既然讨论技术，你就该发表技术上的观点，不应该把矛头指向对方本人，你这种态度做学问就根本不正确。
摸了几年管你屁事 讲不出点门道 也好意思这里充大
算了，不和你吵，没意义。我只是说，既然讨论技术，你就该发表技术上的观点，不应该把矛头指向对方本人，你这种态度做学问就根本不正确。
废土行者 发表于 2012-10-3 00:20
算了，不和你吵，没意义。我只是说，既然讨论技术，你就该发表技术上的观点，不应该把矛头指向对方本人， ...
问题你啥干货没拿出来 还讨论啥
算了，不和你吵，没意义。我只是说，既然讨论技术，你就该发表技术上的观点，不应该把矛头指向对方本人， ...
问题你啥干货没拿出来 还讨论啥
ac58310 发表于 2012-10-2 23:52
甭管几个数据库，原理都是一样的，每个数据库你都得准备至少上百万个索引，而且每个数据库还要考虑冷热 ...
建索引不是解决架构上的问题。显然这个系统现在面临的是一个架构问题，没有一个好的架构，有再好的索引也没用。
我认为交易是否成功，并不在于所有所有相关的动作都要一次完成，完全应该根据其时效性来合理安排业务动作的先后顺序以及轻重缓急，比如结账之类的动作完全可以在给出用户提示订票成功后再进行。如果结算时余额不足，可以在客户领票、验票或者通过短信查询/推送结算结果时给出提示。这样，只要余票量可以满足用户的订票需求，就可以给客户及时的反馈。如果非要当场结算，那么通过建立系统自己的预充值系统也能加快这个结算速度，而不用每次到外部系统比如银行系统之类的去交易。
甭管几个数据库，原理都是一样的，每个数据库你都得准备至少上百万个索引，而且每个数据库还要考虑冷热 ...
建索引不是解决架构上的问题。显然这个系统现在面临的是一个架构问题，没有一个好的架构，有再好的索引也没用。
我认为交易是否成功，并不在于所有所有相关的动作都要一次完成，完全应该根据其时效性来合理安排业务动作的先后顺序以及轻重缓急，比如结账之类的动作完全可以在给出用户提示订票成功后再进行。如果结算时余额不足，可以在客户领票、验票或者通过短信查询/推送结算结果时给出提示。这样，只要余票量可以满足用户的订票需求，就可以给客户及时的反馈。如果非要当场结算，那么通过建立系统自己的预充值系统也能加快这个结算速度，而不用每次到外部系统比如银行系统之类的去交易。
longxia 发表于 2012-10-3 00:23
问题你啥干货没拿出来 还讨论啥
这讨论技术就是抛砖引玉，你有不同见解也可以说出来，不能说你见解和别人不同，你就可以开始开炮是不是
问题你啥干货没拿出来 还讨论啥
这讨论技术就是抛砖引玉，你有不同见解也可以说出来，不能说你见解和别人不同，你就可以开始开炮是不是
ac58310 发表于 2012-10-2 23:59
数据库并行其实还不是重点，你说的业务逻辑的判断也不应该在某台服务器上来做。应该是有一个平台来做这个 ...
数据有分布，当然就有数据一致性问题了。比如A车次的票，可能在S1~S50这50台机器上都有，如果在S1上卖出去了，S2~S50应该要知道这件事啊，否则它们上面可能就会再卖，假设当时S1卖出去的是最后一张了呢？
数据库并行其实还不是重点，你说的业务逻辑的判断也不应该在某台服务器上来做。应该是有一个平台来做这个 ...
数据有分布，当然就有数据一致性问题了。比如A车次的票，可能在S1~S50这50台机器上都有，如果在S1上卖出去了，S2~S50应该要知道这件事啊，否则它们上面可能就会再卖，假设当时S1卖出去的是最后一张了呢？
真心的一点也看不懂
废土行者 发表于 2012-10-3 00:24
这讨论技术就是抛砖引玉，你有不同见解也可以说出来，不能说你见解和别人不同，你就可以开始开炮是不是
我说云储存在这是扯淡 道理来说 不是你应该摆云储存在这应用的例子或者理论 然后我不同意的话再摆我的理论
结果你来一锤子 那不就锤子下去了 我又没提解决方案 讨论的是云储存 你不上观点不上理论 除掉锤子还有啥好讨论的
这讨论技术就是抛砖引玉，你有不同见解也可以说出来，不能说你见解和别人不同，你就可以开始开炮是不是
我说云储存在这是扯淡 道理来说 不是你应该摆云储存在这应用的例子或者理论 然后我不同意的话再摆我的理论
结果你来一锤子 那不就锤子下去了 我又没提解决方案 讨论的是云储存 你不上观点不上理论 除掉锤子还有啥好讨论的
做嵌入式的路过,我也不懂,看个热闹
废土行者 发表于 2012-10-3 00:08
ceph可以解决，几年前我们就在用了，现在还比较可靠。
分布式文件系统的基本粒度还是文件，可能对订票系统来说粒度显得大了。分布式文件系统用来记录处理日志并依此进行后续的大批量结算什么的还比较合适。
ceph可以解决，几年前我们就在用了，现在还比较可靠。
分布式文件系统的基本粒度还是文件，可能对订票系统来说粒度显得大了。分布式文件系统用来记录处理日志并依此进行后续的大批量结算什么的还比较合适。