T**********t
发帖数: 449 | 1 基本假设：
（1）班次信息用点到点方式，5000个火车站，单个信息不到100字节，
5000X5000 = 25 M X 100 = 2500 M = 2.5G，这可以全部装入内存，不用考虑硬盘表现
了。
（2）主要流量来自于对当天出来的票源的抢购。每天新增票源按照每两个连续站就算
一票，来存储
6000 班次 X 30站 /每班次= 18000区间 X 14车厢 X 5种位置 = 1.260M
（3）每小时查询峰值：5000万次
（4）每小时交易峰值：200万次， 每秒交易量： 555次
下面是基本架构：核心数据库、剩余票源发布服务器、中心城市订票端服务器
其中
1、核心数据库：完成真正的交易，更新现有座位数目。每秒预计交易量： 555次。
Capability of 1 typical Oracle Database: 30,000 TPS for credit card
transaction
Capability of 1 IBM Power Database: 50,000 TPS for credit card transaction
结论：数据库不是bottleneck，10万美元左右搞定，目前Oracle Database 11 一个
license 不到5万美元。
数据库只管交易，不管查询，这是一个重要的设计要点。
2、剩余票源发布服务器：
数据库每1秒向中心信息发布服务器更新一次最新数据：数据量大小为10M左右， 1G网
卡下的速度非常快。 中心信息发布服务器采用multicast向全国30个中心城市订票端服
务器通过专用网更新数据。
该剩余票源发布服务器的成本约在5000美元。
3、中心城市订票端服务器
中心城市服务器使用普通8核的处理器Apache服务器，每秒可以处理约5万个inquiry,
预计最高峰期全国每小时有5千万次查询，每秒查询量平均不超过15000次左右。 每个
中心城市的服务器每秒平均查询量不到500次，距离其5万的能力大大有余。
每台服务器价格约5000美元，30台总价格也就是15万美元。
4、专线费用
其实也就是30条专线。100M专线足够了。价格每条每月15万元人民币左右。15X30 =
450万元/月。春运前后也就一个月的时间需要。
5、软件开发费用：
剩下就是软件开发费用：1000万应该足够了吧。
结论：以上各种费用，火车春运订票系统开发运营满打满算2000万人民币搞定。同时，
各个节点的运营能力都大大超出理论峰值20到100倍。 |
l******t
发帖数: 55733 | 2 连基本的备份服务器都没啊。web和app服务器怎么也要分开吧。DB得多少冗余？专线也
要备份吧。交易数据放在哪呢？
开发维护至少要10套全功能测试系统，dev，int，user，load，training等等。
幸好这系统不是你设计的。不然铁道部要被轰上天 |
b********6
发帖数: 35437 | |
T**********t
发帖数: 449 | 4 不要去牵扯这些枝节问题，说了是框架。
你们公司开会讨论architecture会去说这些routine的事情吗？
懂得自然明白要填上。我相信预算够了。
30个服务器了你还要备份？有这个必要吗？你的问题真的太routine了，问问大学生就
知道
【在 l******t 的大作中提到】
: 连基本的备份服务器都没啊。web和app服务器怎么也要分开吧。DB得多少冗余？专线也
: 要备份吧。交易数据放在哪呢？
: 开发维护至少要10套全功能测试系统，dev，int，user，load，training等等。
: 幸好这系统不是你设计的。不然铁道部要被轰上天
|
T**********t
发帖数: 449 | 5 你这个问题有解吗？
这里解决的就是，你来订票，如果有就给你，没有你就赶紧找替代班次，整个过程非常
快，非常smooth，而且是立即commit, 10秒钟内给您答案。
当天票源放开以后，你当然是越早越好。
如果2个人硬要买同一张票，这个上帝也解决不了喽。
【在 b********6 的大作中提到】
: 你怎么解决火车票供小于求的问题？
|
d******r
发帖数: 16947 | 6 现在买火车票可以选座次的么？
【在 T**********t 的大作中提到】
: 你这个问题有解吗？
: 这里解决的就是，你来订票，如果有就给你，没有你就赶紧找替代班次，整个过程非常
: 快，非常smooth，而且是立即commit, 10秒钟内给您答案。
: 当天票源放开以后，你当然是越早越好。
: 如果2个人硬要买同一张票，这个上帝也解决不了喽。
|
l******t
发帖数: 55733 | 7
懒得和你辩。就你这逻辑我还可以论证来100万个算盘也应付了
【在 T**********t 的大作中提到】
: 不要去牵扯这些枝节问题，说了是框架。
: 你们公司开会讨论architecture会去说这些routine的事情吗？
: 懂得自然明白要填上。我相信预算够了。
: 30个服务器了你还要备份？有这个必要吗？你的问题真的太routine了，问问大学生就
: 知道
|
b********6
发帖数: 35437 | 8 现在的问题就在这里
我买不到票肯定是因为你的系统有问题，有人声称买到了黄牛票，所以你的票全部给黄
牛了，今天不给老子弄到票你们铁道部解散算鸟
12306已经做的很好了，卡的时段越来越少
【在 T**********t 的大作中提到】
: 你这个问题有解吗？
: 这里解决的就是，你来订票，如果有就给你，没有你就赶紧找替代班次，整个过程非常
: 快，非常smooth，而且是立即commit, 10秒钟内给您答案。
: 当天票源放开以后，你当然是越早越好。
: 如果2个人硬要买同一张票，这个上帝也解决不了喽。
|
y******i
发帖数: 558 | 9 这个SPIKY 的需求要做实时的AVAILABILITY 是很难的，什么样的数据库都很难同时保
证实时性，一致性和availability.
损失实时性可能会好一点：系统每天开放几个小时的订票窗口，订票人可以选定提供几
个车次的OPTION。订票窗口关闭后，后台随机摇奖，尽量满足订票人的需求。 |
n******1
发帖数: 3756 | 10 内存crash了怎么办？
【在 T**********t 的大作中提到】
: 基本假设：
: （1）班次信息用点到点方式，5000个火车站，单个信息不到100字节，
: 5000X5000 = 25 M X 100 = 2500 M = 2.5G，这可以全部装入内存，不用考虑硬盘表现
: 了。
: （2）主要流量来自于对当天出来的票源的抢购。每天新增票源按照每两个连续站就算
: 一票，来存储
: 6000 班次 X 30站 /每班次= 18000区间 X 14车厢 X 5种位置 = 1.260M
: （3）每小时查询峰值：5000万次
: （4）每小时交易峰值：200万次， 每秒交易量： 555次
: 下面是基本架构：核心数据库、剩余票源发布服务器、中心城市订票端服务器
|
|
|
y******i
发帖数: 558 | 11 用云计算平台可以降低成本，否则搞那么多的硬件就为满足一年一次的春运需要实在不
划算。 |
z******4
发帖数: 4716 | 12 你算是白写了，菌斑智力水平很低的，愤怒情绪却很高
我的想法也是把查询和交易分开，不过貌似铁道部不会脑残到想不到吧，我猜可能是内
部关系找的公司，技术实力不够，才导致性能这么差吧 |
l******t
发帖数: 55733 | 13
实时查询不？
【在 z******4 的大作中提到】
: 你算是白写了，菌斑智力水平很低的，愤怒情绪却很高
: 我的想法也是把查询和交易分开，不过貌似铁道部不会脑残到想不到吧，我猜可能是内
: 部关系找的公司，技术实力不够，才导致性能这么差吧
|
O****X
发帖数: 24292 | 14 图样图新破啊
真以为道部做不了啊
拿出来外包就是帮道部挨骂的 |
h******k
发帖数: 13418 | 15 这30条专线，30个中心城市是怎么来的？为什么不是按照铁路局的分片规划？ |
h******k
发帖数: 13418 | 16 你和他水平一样搞?
【在 z******4 的大作中提到】
: 你算是白写了，菌斑智力水平很低的，愤怒情绪却很高
: 我的想法也是把查询和交易分开，不过貌似铁道部不会脑残到想不到吧，我猜可能是内
: 部关系找的公司，技术实力不够，才导致性能这么差吧
|
h******k
发帖数: 13418 | 17 此贴专业个屁，G点在于带预算，又一个来黑铁道部的。 |
T**********t
发帖数: 449 | 18 你写个高水平的吧，LOL
【在 h******k 的大作中提到】
: 你和他水平一样搞?
|
h******k
发帖数: 13418 | 19 不了解也不胡扯，你自称专业，先解释解释那30个专线和30个中心城市服务器是怎么来
的？
【在 T**********t 的大作中提到】
: 你写个高水平的吧，LOL
|
T**********t
发帖数: 449 | 20 辩不过的时候都是这么说吧，哈哈
开玩笑了，不人身攻击哈，这个不是论证不论证的问题。
比如你和朋友讨论开车出去玩，要不要吃饭，要不要加油？但是你们不会考虑这些事情
，没人这样吧，哎，“咱们去大瀑布吧”，回答，“好啊，路上吃麦当劳还是肯德基啊
?”
4、500百页的标书我不是没写过，光是买多少网线，网线厂家的各种历史，就写了10页
纸。
所谓routine，就是大家都会去做，也做的大同小异，没必要考虑那么仔细。
我就是这个意思。
除非你觉得有技术难点，拿出来讨论讨论，我向您学习。
【在 l******t 的大作中提到】
:
: 实时查询不？
|
|
|
h******k
发帖数: 13418 | 21 说的不错
【在 y******i 的大作中提到】
: 用云计算平台可以降低成本，否则搞那么多的硬件就为满足一年一次的春运需要实在不
: 划算。
|
T**********t
发帖数: 449 | 22 这是基于分散流量的考虑，也是基于中国地盘大的事实。你说20个行不行？当然行。我
这里是Engineering Design, 不是Mathematical Proof. 这就跟人民大会堂一样，再
高个5米不行吗？
我也没有说这是最优解法，其实这个问题如果找到最优解，成本比最优解本身可能还要
高，完全没有那个必要。
依据当然有，不过是比较loose,具体看我的假设。假设你不同意，你提一个，我相信数
量级上也不会有什么差别。
很多Engineering的事情，跟过马路一样，你为啥一定这样过，不那样过？没有唯一的
选择，你的选择集合可能很大，而且你的optimum core的curve也可能非常地平滑，以
至于你很难判断最优点，或者最优点并不能materialize.
这有点类似方法论的讨论了，呵呵，不要毁三观就好。
【在 h******k 的大作中提到】
: 不了解也不胡扯，你自称专业，先解释解释那30个专线和30个中心城市服务器是怎么来
: 的？
|
T**********t
发帖数: 449 | 23 那不是技术问题了，这样的问题都是常委们考虑的。我们码工就拿这当个面试题做着玩。
【在 b********6 的大作中提到】
: 现在的问题就在这里
: 我买不到票肯定是因为你的系统有问题，有人声称买到了黄牛票，所以你的票全部给黄
: 牛了，今天不给老子弄到票你们铁道部解散算鸟
: 12306已经做的很好了，卡的时段越来越少
|
h******k
发帖数: 13418 | 24 你往那分散？分散到30个城市去，还是不同的数据中心？每个服务器给一个100M的专线？
【在 T**********t 的大作中提到】
: 这是基于分散流量的考虑，也是基于中国地盘大的事实。你说20个行不行？当然行。我
: 这里是Engineering Design, 不是Mathematical Proof. 这就跟人民大会堂一样，再
: 高个5米不行吗？
: 我也没有说这是最优解法，其实这个问题如果找到最优解，成本比最优解本身可能还要
: 高，完全没有那个必要。
: 依据当然有，不过是比较loose,具体看我的假设。假设你不同意，你提一个，我相信数
: 量级上也不会有什么差别。
: 很多Engineering的事情，跟过马路一样，你为啥一定这样过，不那样过？没有唯一的
: 选择，你的选择集合可能很大，而且你的optimum core的curve也可能非常地平滑，以
: 至于你很难判断最优点，或者最优点并不能materialize.
|
T**********t
发帖数: 449 | 25 就是订票系统的前端啊，网页呗。
就近分配啊，无锡的分到南京，宁波的分到杭州。
数据中心找一个地方放就行了，大把地方可以放，呵呵。
线？
【在 h******k 的大作中提到】
: 你往那分散？分散到30个城市去，还是不同的数据中心？每个服务器给一个100M的专线？
|
T**********t
发帖数: 449 | 26 哈哈，握爪握爪，
【在 z******4 的大作中提到】
: 你算是白写了，菌斑智力水平很低的，愤怒情绪却很高
: 我的想法也是把查询和交易分开，不过貌似铁道部不会脑残到想不到吧，我猜可能是内
: 部关系找的公司，技术实力不够，才导致性能这么差吧
|
h******k
发帖数: 13418 | 27 一个地方放你还要30条专线？
谁来分配，谁判定那个请求是无锡来的，那个是宁波来的？
【在 T**********t 的大作中提到】
: 就是订票系统的前端啊，网页呗。
: 就近分配啊，无锡的分到南京，宁波的分到杭州。
: 数据中心找一个地方放就行了，大把地方可以放，呵呵。
:
: 线？
|
T**********t
发帖数: 449 | 28 30个城市，每个城市一个网页服务器，每个网页服务器接一根专线，
30城市 X 1 专线/城市 = 30 专线， OK？
通过IP啊，IP查所在城市不是小菜，您电脑大菜鸟吧？呵呵
【在 h******k 的大作中提到】
: 一个地方放你还要30条专线？
: 谁来分配，谁判定那个请求是无锡来的，那个是宁波来的？
|
d*********8
发帖数: 2192 | 29 信用卡交易和购票没有任何可比性
依次为论据得出数据库不是瓶颈实在荒谬
打回去重写
★ 发自iPhone App: ChineseWeb 7.8
【在 T**********t 的大作中提到】
: 基本假设：
: （1）班次信息用点到点方式，5000个火车站，单个信息不到100字节，
: 5000X5000 = 25 M X 100 = 2500 M = 2.5G，这可以全部装入内存，不用考虑硬盘表现
: 了。
: （2）主要流量来自于对当天出来的票源的抢购。每天新增票源按照每两个连续站就算
: 一票，来存储
: 6000 班次 X 30站 /每班次= 18000区间 X 14车厢 X 5种位置 = 1.260M
: （3）每小时查询峰值：5000万次
: （4）每小时交易峰值：200万次， 每秒交易量： 555次
: 下面是基本架构：核心数据库、剩余票源发布服务器、中心城市订票端服务器
|
z******4
发帖数: 4716 | 30 你就没必要和他争，他是喜欢打脸的，什么都觉得被打脸了，忍不住跳出哀嚎
你看看他的回答，不懂就罢了，还捞说别人不懂，你和一2B青年有啥好讨论的，这样的
，在工作中遇到的多了，我通常就是大力赞同，然后扔一边自生自灭了，过不了多久就
狲了
【在 T**********t 的大作中提到】
: 辩不过的时候都是这么说吧，哈哈
: 开玩笑了，不人身攻击哈，这个不是论证不论证的问题。
: 比如你和朋友讨论开车出去玩，要不要吃饭，要不要加油？但是你们不会考虑这些事情
: ，没人这样吧，哎，“咱们去大瀑布吧”，回答，“好啊，路上吃麦当劳还是肯德基啊
: ?”
: 4、500百页的标书我不是没写过，光是买多少网线，网线厂家的各种历史，就写了10页
: 纸。
: 所谓routine，就是大家都会去做，也做的大同小异，没必要考虑那么仔细。
: 我就是这个意思。
: 除非你觉得有技术难点，拿出来讨论讨论，我向您学习。
|
|
|
T**********t
发帖数: 449 | 31 购票有lock和unlock的问题，不过没你说的那么严重。况且我还可以pre-sort,办法多
了，这些小算法讲那么细干啥
【在 d*********8 的大作中提到】
: 信用卡交易和购票没有任何可比性
: 依次为论据得出数据库不是瓶颈实在荒谬
: 打回去重写
:
: ★ 发自iPhone App: ChineseWeb 7.8
|
s*****e
发帖数: 16824 | 32 你这专业个屁，连备份服务器都没有。给你看个专业的，
http://www.360doc.com/content/11/0607/15/110467_122245229.shtml
这个虽然是网游服务器，但基本思路跟你这个是一样的，数据和查询分开。人家一组服
务器
包括4台网关服务器3台游戏服务器，1台数据库1台备份一共9台服务器。这么一组也只
能支持4000多人同时在线。这一组光硬件就得10-20万人民币。如果你要支持200万人同
时在线，就需要500组。那光硬件费用就是5000万到1亿了。
尽管火车购票系统在有些方面比网游负荷要小，但是在其他方便又比网游负荷大。比如
说网游你可以分组，每个组的数据是独立的，修改了不会影响其他组。但是火车必须所
有数据一致，所以数据服务器比网游负荷大多了，而且必须保证互锁，在任何一台数据
服务器上的改动必须即时反映到所有服务器上去。
【在 T**********t 的大作中提到】
: 基本假设：
: （1）班次信息用点到点方式，5000个火车站，单个信息不到100字节，
: 5000X5000 = 25 M X 100 = 2500 M = 2.5G，这可以全部装入内存，不用考虑硬盘表现
: 了。
: （2）主要流量来自于对当天出来的票源的抢购。每天新增票源按照每两个连续站就算
: 一票，来存储
: 6000 班次 X 30站 /每班次= 18000区间 X 14车厢 X 5种位置 = 1.260M
: （3）每小时查询峰值：5000万次
: （4）每小时交易峰值：200万次， 每秒交易量： 555次
: 下面是基本架构：核心数据库、剩余票源发布服务器、中心城市订票端服务器
|
r******1
发帖数: 367 | 33 每秒预计交易量： 555次。
【在 T**********t 的大作中提到】
: 基本假设：
: （1）班次信息用点到点方式，5000个火车站，单个信息不到100字节，
: 5000X5000 = 25 M X 100 = 2500 M = 2.5G，这可以全部装入内存，不用考虑硬盘表现
: 了。
: （2）主要流量来自于对当天出来的票源的抢购。每天新增票源按照每两个连续站就算
: 一票，来存储
: 6000 班次 X 30站 /每班次= 18000区间 X 14车厢 X 5种位置 = 1.260M
: （3）每小时查询峰值：5000万次
: （4）每小时交易峰值：200万次， 每秒交易量： 555次
: 下面是基本架构：核心数据库、剩余票源发布服务器、中心城市订票端服务器
|
T**********t
发帖数: 449 | 34 啊，这样啊，菌斑还是有明白人啊
【在 z******4 的大作中提到】
: 你就没必要和他争，他是喜欢打脸的，什么都觉得被打脸了，忍不住跳出哀嚎
: 你看看他的回答，不懂就罢了，还捞说别人不懂，你和一2B青年有啥好讨论的，这样的
: ，在工作中遇到的多了，我通常就是大力赞同，然后扔一边自生自灭了，过不了多久就
: 狲了
|
d*********8
发帖数: 2192 | 35 难度就在这个锁上面
你能解决好了 的确可以去做淘宝的cto
★ 发自iPhone App: ChineseWeb 7.8
【在 T**********t 的大作中提到】
: 购票有lock和unlock的问题，不过没你说的那么严重。况且我还可以pre-sort,办法多
: 了，这些小算法讲那么细干啥
|
T**********t
发帖数: 449 | 36 你这个话不好听啊，火气这么大，何必呢
网游服务器是要保持concurrent connection的，完全不是一码事。你查查web server
benchmark, 各自有各自的performance。
【在 s*****e 的大作中提到】
: 你这专业个屁，连备份服务器都没有。给你看个专业的，
: http://www.360doc.com/content/11/0607/15/110467_122245229.shtml
: 这个虽然是网游服务器，但基本思路跟你这个是一样的，数据和查询分开。人家一组服
: 务器
: 包括4台网关服务器3台游戏服务器，1台数据库1台备份一共9台服务器。这么一组也只
: 能支持4000多人同时在线。这一组光硬件就得10-20万人民币。如果你要支持200万人同
: 时在线，就需要500组。那光硬件费用就是5000万到1亿了。
: 尽管火车购票系统在有些方面比网游负荷要小，但是在其他方便又比网游负荷大。比如
: 说网游你可以分组，每个组的数据是独立的，修改了不会影响其他组。但是火车必须所
: 有数据一致，所以数据服务器比网游负荷大多了，而且必须保证互锁，在任何一台数据
|
s*****r
发帖数: 43070 | 37 算错了吧，每秒是55555次交易，而且每个交易都是分布式，涉及多个系统，不是一个
数据库操作就能完成。
做过商务网站就应该知道，估计LZ当成课程设计了。 |
s*****e
发帖数: 16824 | 38 你以为一个交易系统就是个web server?
server
【在 T**********t 的大作中提到】
: 你这个话不好听啊，火气这么大，何必呢
: 网游服务器是要保持concurrent connection的，完全不是一码事。你查查web server
: benchmark, 各自有各自的performance。
|
z******4
发帖数: 4716 | 39 哥哥，求求你了，做架构的，真的备份服务器是最后考虑的，无底线show智力不太好
火车票系统的核心，是lock，上千个人交易锁同一个记录，你要让别人交易，同时保证
数据一致性
网游，一个id根本没有锁的问题啊
【在 s*****e 的大作中提到】
: 你这专业个屁，连备份服务器都没有。给你看个专业的，
: http://www.360doc.com/content/11/0607/15/110467_122245229.shtml
: 这个虽然是网游服务器，但基本思路跟你这个是一样的，数据和查询分开。人家一组服
: 务器
: 包括4台网关服务器3台游戏服务器，1台数据库1台备份一共9台服务器。这么一组也只
: 能支持4000多人同时在线。这一组光硬件就得10-20万人民币。如果你要支持200万人同
: 时在线，就需要500组。那光硬件费用就是5000万到1亿了。
: 尽管火车购票系统在有些方面比网游负荷要小，但是在其他方便又比网游负荷大。比如
: 说网游你可以分组，每个组的数据是独立的，修改了不会影响其他组。但是火车必须所
: 有数据一致，所以数据服务器比网游负荷大多了，而且必须保证互锁，在任何一台数据
|
T**********t
发帖数: 449 | 40 不是不可以去做， LOL
我有不少code在critical area都是没有lock 保护的，依然thread safe, go figure
【在 d*********8 的大作中提到】
: 难度就在这个锁上面
: 你能解决好了 的确可以去做淘宝的cto
:
: ★ 发自iPhone App: ChineseWeb 7.8
|
|
|
s*****e
发帖数: 16824 | 41 所以火车购票比网游系统还要难啊，你要考虑一个镜像服务器组的互锁和即时更新。
【在 z******4 的大作中提到】
: 哥哥，求求你了，做架构的，真的备份服务器是最后考虑的，无底线show智力不太好
: 火车票系统的核心，是lock，上千个人交易锁同一个记录，你要让别人交易，同时保证
: 数据一致性
: 网游，一个id根本没有锁的问题啊
|
T**********t
发帖数: 449 | 42 55555 X 3600 = ?
自己算
我的假设每小时2百万次交易量，这个你别给我改了
我教我儿子做算术，一定要double check,我锻炼他的方法，就是一次10道题，错一罚
三，再错罚四，最后他做题果然不马大哈了。
【在 s*****r 的大作中提到】
: 算错了吧，每秒是55555次交易，而且每个交易都是分布式，涉及多个系统，不是一个
: 数据库操作就能完成。
: 做过商务网站就应该知道，估计LZ当成课程设计了。
|
s*****e
发帖数: 16824 | 43 这是瞎搞，如果不是严格保证了互锁和先后的话，小规模可能永远碰不上问题，一旦规
模大了问题就指数上升。
【在 T**********t 的大作中提到】
: 不是不可以去做， LOL
: 我有不少code在critical area都是没有lock 保护的，依然thread safe, go figure
|
l******t
发帖数: 55733 | 44
最后个NMB啊。你要么说你就搞个论证prototype要么讨论production。别装逼。
【在 T**********t 的大作中提到】
: 辩不过的时候都是这么说吧，哈哈
: 开玩笑了，不人身攻击哈，这个不是论证不论证的问题。
: 比如你和朋友讨论开车出去玩，要不要吃饭，要不要加油？但是你们不会考虑这些事情
: ，没人这样吧，哎，“咱们去大瀑布吧”，回答，“好啊，路上吃麦当劳还是肯德基啊
: ?”
: 4、500百页的标书我不是没写过，光是买多少网线，网线厂家的各种历史，就写了10页
: 纸。
: 所谓routine，就是大家都会去做，也做的大同小异，没必要考虑那么仔细。
: 我就是这个意思。
: 除非你觉得有技术难点，拿出来讨论讨论，我向您学习。
|
T**********t
发帖数: 449 | 45 就是说个思路，和大致框架，你们老给我弄的那么复杂
【在 l******t 的大作中提到】
:
: 最后个NMB啊。你要么说你就搞个论证prototype要么讨论production。别装逼。
|
n******1
发帖数: 3756 | 46 IO和锁是数据库其中两个主要问题
既然你用内存做数据库，你还没回答crash了怎么办
另外你说2.5G的数据量和2.5内存是两回事，当然现在搞到10G，20G的内存甚至100G的
内存以上都不是问题，但是随着时间的推进，内存里面是什么情况你完全没有把握
【在 T**********t 的大作中提到】
: 55555 X 3600 = ?
: 自己算
: 我的假设每小时2百万次交易量，这个你别给我改了
: 我教我儿子做算术，一定要double check,我锻炼他的方法，就是一次10道题，错一罚
: 三，再错罚四，最后他做题果然不马大哈了。
|
y******i
发帖数: 558 | 47 大家还在吵，我还真觉得我的方案可行，而且便宜。
除了亚马逊的BLACK FRIDAY， 估计就抢火车票这个比较SPIKY 了。如果类似的PROJECT
很多，可以考虑专门就做这个了。 |
n******1
发帖数: 3756 | 48 框架谁都可以说的天花乱坠，无数的实践证明，这些系统最后都像12306这样
【在 T**********t 的大作中提到】
: 就是说个思路，和大致框架，你们老给我弄的那么复杂
|
g*******g
发帖数: 9753 | 49 我靠，连个与银行实时结算的步骤都没有，也敢号称专业？
顺便告诉你，中国人网上买火车票用的是网银，不是信用卡，别弄错了啊 |
T**********t
发帖数: 449 | 50 当然严格，我自己算法自带thread safe check不行吗? 非要用系统那个慢的要死的
mutex?
有的时候，你自己code多3到4个clock, 你就可以不用mutex了，这个要了解自己的程序
，不是mutex那样到处都能用的。
如果同时几个thread把数据改了，我如果自己能发现，再改回来行不行？同学你要换个
思路，码工也不是光是砌砖。
【在 s*****e 的大作中提到】
: 这是瞎搞，如果不是严格保证了互锁和先后的话，小规模可能永远碰不上问题，一旦规
: 模大了问题就指数上升。
|
|
|
T**********t
发帖数: 449 | 51 这你就兴奋了，我不能预授权完了再进我的数据库交易啊? 我那30个服务器吃干饭的？
我感觉我这给你们上课来了。
【在 g*******g 的大作中提到】
: 我靠，连个与银行实时结算的步骤都没有，也敢号称专业？
: 顺便告诉你，中国人网上买火车票用的是网银，不是信用卡，别弄错了啊
|
n******1
发帖数: 3756 | 52 其实这个已经是在框架外的问题，比如网银接口半天没反应怎么办呢，诸如之类都是工
程上的问题
【在 g*******g 的大作中提到】
: 我靠，连个与银行实时结算的步骤都没有，也敢号称专业？
: 顺便告诉你，中国人网上买火车票用的是网银，不是信用卡，别弄错了啊
|
s*****e
发帖数: 16824 | 53 所以你这就是瞎搞嘛，根本就不能允许几个thread同时改数据，一旦允许后果就不可测
了，不是你说改回来就行的。一个大型系统不可能只有你的程序访问这些数据，你自己
搞的东西顶多保证自己的程序没问题，但是如果其他程序在你改回之前访问了这些数据
那就是大灾难。而且很多系统，你根本没有权力改回，就像火车购票，你说不好意思，
购票金额错了，我要改回来，你想改，人银行让吗？
【在 T**********t 的大作中提到】
: 当然严格，我自己算法自带thread safe check不行吗? 非要用系统那个慢的要死的
: mutex?
: 有的时候，你自己code多3到4个clock, 你就可以不用mutex了，这个要了解自己的程序
: ，不是mutex那样到处都能用的。
: 如果同时几个thread把数据改了，我如果自己能发现，再改回来行不行？同学你要换个
: 思路，码工也不是光是砌砖。
|
s*****r
发帖数: 43070 | 54 倒了，architecture还就是干这些的
【在 T**********t 的大作中提到】
: 不要去牵扯这些枝节问题，说了是框架。
: 你们公司开会讨论architecture会去说这些routine的事情吗？
: 懂得自然明白要填上。我相信预算够了。
: 30个服务器了你还要备份？有这个必要吗？你的问题真的太routine了，问问大学生就
: 知道
|
y******i
发帖数: 558 | 55 我觉得实时系统难度很大的。各种各样的LATENCY。做到了成本也很高。上面的同学提
得很对，就算你的系统能实时，银联说不定都给你拖垮。
CAP， PICK TWO。 不是早就证明了么。
牺牲掉A， 用FACEBOOK 的技术，NOSQL 存储车票预订。再用HADOOP 延迟优化匹配预订
，6小时窗口接受预订，6小时窗口处理接受预订，并售票，再扣款。 |
s*****r
发帖数: 43070 | 56 选座系统在开发中，在成都招的标。
【在 d******r 的大作中提到】
: 现在买火车票可以选座次的么？
|
T**********t
发帖数: 449 | 57 你根本不知道我在说什么。
我告诉你，我的code是100% bullet proof,（关于thread safe部分哈，其他小bug大家
都会有）， 不然公司那帮QA也不是吃素的，
咱们总不至于在这里掰code吧，哈哈
【在 s*****e 的大作中提到】
: 所以你这就是瞎搞嘛，根本就不能允许几个thread同时改数据，一旦允许后果就不可测
: 了，不是你说改回来就行的。一个大型系统不可能只有你的程序访问这些数据，你自己
: 搞的东西顶多保证自己的程序没问题，但是如果其他程序在你改回之前访问了这些数据
: 那就是大灾难。而且很多系统，你根本没有权力改回，就像火车购票，你说不好意思，
: 购票金额错了，我要改回来，你想改，人银行让吗？
|
s*****e
发帖数: 16824 | 58 你这个也不行，如果要这么搞，必须屏蔽掉实时查询功能，否则别人上网查票发现有座
，然后订票了，结果6小时后告诉他没票，人绝对怀疑你把票卖给黄牛了。
【在 y******i 的大作中提到】
: 我觉得实时系统难度很大的。各种各样的LATENCY。做到了成本也很高。上面的同学提
: 得很对，就算你的系统能实时，银联说不定都给你拖垮。
: CAP， PICK TWO。 不是早就证明了么。
: 牺牲掉A， 用FACEBOOK 的技术，NOSQL 存储车票预订。再用HADOOP 延迟优化匹配预订
: ，6小时窗口接受预订，6小时窗口处理接受预订，并售票，再扣款。
|
s*****r
发帖数: 43070 | 59 交易系统哪那么容易实时，信用卡还行，其他都是延时交易，所以有交了钱买不到票的
可能。
【在 y******i 的大作中提到】
: 我觉得实时系统难度很大的。各种各样的LATENCY。做到了成本也很高。上面的同学提
: 得很对，就算你的系统能实时，银联说不定都给你拖垮。
: CAP， PICK TWO。 不是早就证明了么。
: 牺牲掉A， 用FACEBOOK 的技术，NOSQL 存储车票预订。再用HADOOP 延迟优化匹配预订
: ，6小时窗口接受预订，6小时窗口处理接受预订，并售票，再扣款。
|
T**********t
发帖数: 449 | 60 这个当你课后作业吧，自己看看有没有答案吧
【在 n******1 的大作中提到】
: IO和锁是数据库其中两个主要问题
: 既然你用内存做数据库，你还没回答crash了怎么办
: 另外你说2.5G的数据量和2.5内存是两回事，当然现在搞到10G，20G的内存甚至100G的
: 内存以上都不是问题，但是随着时间的推进，内存里面是什么情况你完全没有把握
|
|
|
g*******g
发帖数: 9753 | 61 哈哈，你牛逼，把你的作品拿出来给大伙瞅瞅吧
别干说不练啊
【在 T**********t 的大作中提到】
: 这你就兴奋了，我不能预授权完了再进我的数据库交易啊? 我那30个服务器吃干饭的？
: 我感觉我这给你们上课来了。
|
y******i
发帖数: 558 | 62 就是不要提供实时查询。抽奖形式。
【在 s*****e 的大作中提到】
: 你这个也不行，如果要这么搞，必须屏蔽掉实时查询功能，否则别人上网查票发现有座
: ，然后订票了，结果6小时后告诉他没票，人绝对怀疑你把票卖给黄牛了。
|
s*****e
发帖数: 16824 | 63 我不说了么，你的code没问题那没用，关键是你不能允许多个thread同时修改数据，否
则你的code不出问题，不代表别人的code不出问题。
【在 T**********t 的大作中提到】
: 你根本不知道我在说什么。
: 我告诉你，我的code是100% bullet proof,（关于thread safe部分哈，其他小bug大家
: 都会有）， 不然公司那帮QA也不是吃素的，
: 咱们总不至于在这里掰code吧，哈哈
|
T**********t
发帖数: 449 | 64 那是你们公司，我们公司不是，谢谢
【在 s*****r 的大作中提到】
: 倒了，architecture还就是干这些的
|
y******i
发帖数: 558 | 65 大家都一窝蜂抢票的时候，查询有啥意义啊。没有半点意义。
【在 y******i 的大作中提到】
: 就是不要提供实时查询。抽奖形式。
|
T**********t
发帖数: 449 | 66 我就是做底层library的，我的code没问题，上面的就也没问题。
【在 s*****e 的大作中提到】
: 我不说了么，你的code没问题那没用，关键是你不能允许多个thread同时修改数据，否
: 则你的code不出问题，不代表别人的code不出问题。
|
y******i
发帖数: 558 | 67 我老以前用电话订票的时候就还有查询选项，当时就觉得非常搞笑。春运的票还有时间
给你查询？ |
s*****e
发帖数: 16824 | 68 那更瞎搞，底层不允许这么玩，你现在没问题，万一你走了，换人再搞出一些底层
library呢？
【在 T**********t 的大作中提到】
: 我就是做底层library的，我的code没问题，上面的就也没问题。
|
n******1
发帖数: 3756 | 69 其实如果最粗鲁的办法就是分区分域，比如以终点省或者出发省份作为一个分开的标志
，因为这些数据本身不需要合并或者同步，集中式设计一开始就进入陷阱
不过说到底是商业模式问题，投资那么多只是为应付一段时间的高峰，这个特征在原有
设计思路下都是无解，最好的办法还是分给其他电商去做，铁路系统只需要应付平时需
求就行，这样的系统就谁都可以设计出来 |
n******1
发帖数: 3756 | 70 你这个推论确实有点搞笑
【在 T**********t 的大作中提到】
: 我就是做底层library的，我的code没问题，上面的就也没问题。
|
|
|
y******i
发帖数: 558 | 71 不如讨论一下这种系统卖给铁道部以外还能卖给谁吧？ |
x****o
发帖数: 29677 | 72
还查询和交易分开，你还嫌数据库死的不够快么
【在 z******4 的大作中提到】
: 你算是白写了，菌斑智力水平很低的，愤怒情绪却很高
: 我的想法也是把查询和交易分开，不过貌似铁道部不会脑残到想不到吧，我猜可能是内
: 部关系找的公司，技术实力不够，才导致性能这么差吧
|
y******i
发帖数: 558 | 73 用户输入一个列表外加身份证。凭身份领票
1. 期望车次。 2. 座位要求。 3. 起始站。 4.如果起始站不符合要求，愿意在【】公
里内调剂 5. 如果座位不符合您的条件，是否接受调剂？ |
n******1
发帖数: 3756 | 74 其实遇到这种情况的系统不少
这就是为什么云计算会出现原因，amazon就是想卖这种临时的计算和内存，但是目前看
到大规模可以应用在第三方系统上的我没了解过
我意思是云计算系统很多，但成功的都是自建自用为主，因为通常做大了就做大了
【在 y******i 的大作中提到】
: 不如讨论一下这种系统卖给铁道部以外还能卖给谁吧？
|
T**********t
发帖数: 449 | 75 LOL, 看你这心操的，我都笑出声了。
我告诉你，这是logically proven, OK？谁拿自己饭碗开玩笑？
My work is the most mission critical part of a billion dollar business.
Performance is my lifeline, got it?
有个组件上面管理层说用google的open source library，我老的solution beat them
by 80% in performance, 管理层没话说。
【在 s*****e 的大作中提到】
: 那更瞎搞，底层不允许这么玩，你现在没问题，万一你走了，换人再搞出一些底层
: library呢？
|
u****u
发帖数: 229 | 76 whoever is stupid enough to be lured by a few bucks to take on the shit and
blame...
【在 y******i 的大作中提到】
: 不如讨论一下这种系统卖给铁道部以外还能卖给谁吧？
|
y******i
发帖数: 558 | 77 春运售票真的是非常问题，需要和平常的订票系统分开的。 |
y******i
发帖数: 558 | 78 So it's gotta be someone living in the states.
雇佣兵就是干这个的呀。哈哈
and
【在 u****u 的大作中提到】
: whoever is stupid enough to be lured by a few bucks to take on the shit and
: blame...
|
T**********t
发帖数: 449 | 79 BTW, 我们连linux kernel的scheduler都改了，我们玩的就是底层，我看你还是嫩点。
【在 s*****e 的大作中提到】
: 那更瞎搞，底层不允许这么玩，你现在没问题，万一你走了，换人再搞出一些底层
: library呢？
|
y******i
发帖数: 558 | 80 不是吧 reddit. salesforce.
已经挺成功的了啊。这个站点的SPIKY TRAFFIC 也很大了
【在 n******1 的大作中提到】
: 其实遇到这种情况的系统不少
: 这就是为什么云计算会出现原因，amazon就是想卖这种临时的计算和内存，但是目前看
: 到大规模可以应用在第三方系统上的我没了解过
: 我意思是云计算系统很多，但成功的都是自建自用为主，因为通常做大了就做大了
|
|
|
s*****e
发帖数: 16824 | 81 所谓logically proven的，那就是严格保证了先后或者互锁的，跟你前面说的完全背道
而驰。假如不是，我真是替你们管理层感到悲哀。
them
【在 T**********t 的大作中提到】
: LOL, 看你这心操的，我都笑出声了。
: 我告诉你，这是logically proven, OK？谁拿自己饭碗开玩笑？
: My work is the most mission critical part of a billion dollar business.
: Performance is my lifeline, got it?
: 有个组件上面管理层说用google的open source library，我老的solution beat them
: by 80% in performance, 管理层没话说。
|
g*******g
发帖数: 9753 | 82 分给其他的电商没意义，而且只会增加结算的复杂度。
因为，每一张火车票都不是独立的商品，而是与其它的票相关的。而总票数并不是一个
特别大的数，分给电商与增加服务器没区别。
比如某一趟车中间要停20站，乘客可能买任意两站之间的票，这样就把这一趟车分成了
好几段，这些票是不可能事先就在数据库中设好的，必须实时结算。
【在 n******1 的大作中提到】
: 其实如果最粗鲁的办法就是分区分域，比如以终点省或者出发省份作为一个分开的标志
: ，因为这些数据本身不需要合并或者同步，集中式设计一开始就进入陷阱
: 不过说到底是商业模式问题，投资那么多只是为应付一段时间的高峰，这个特征在原有
: 设计思路下都是无解，最好的办法还是分给其他电商去做，铁路系统只需要应付平时需
: 求就行，这样的系统就谁都可以设计出来
|
u****u
发帖数: 229 | 83 gee, you definitely know the tricks of the business.
【在 y******i 的大作中提到】
: So it's gotta be someone living in the states.
: 雇佣兵就是干这个的呀。哈哈
:
: and
|
T**********t
发帖数: 449 | 84 你思想僵化呀，我前面说过了，dirty data我有自动修正机制，你真是一根筋。
【在 s*****e 的大作中提到】
: 所谓logically proven的，那就是严格保证了先后或者互锁的，跟你前面说的完全背道
: 而驰。假如不是，我真是替你们管理层感到悲哀。
:
: them
|
n******1
发帖数: 3756 | 85 我说我没了解过，你说的这两个我都不知道
你是说reddit用salesforce的服务发展的很成功？
【在 y******i 的大作中提到】
: 不是吧 reddit. salesforce.
: 已经挺成功的了啊。这个站点的SPIKY TRAFFIC 也很大了
|
s*****e
发帖数: 16824 | 86 我说了这个不行，你这种是偷工减料的方法，属于牺牲通用性和维护性来换取速度，看
起来是快了，但是一旦日后要插入别的系统，就会有极大的麻烦，会大大提高成本。
【在 T**********t 的大作中提到】
: 你思想僵化呀，我前面说过了，dirty data我有自动修正机制，你真是一根筋。
|
s*****r
发帖数: 43070 | 87 这会涉及大量的数据库交易，数据库里面的lock。code里面的lock倒真不多见，因为
session是必须可以并行的，除非很底层的东西，比如transation id。
【在 T**********t 的大作中提到】
: 当然严格，我自己算法自带thread safe check不行吗? 非要用系统那个慢的要死的
: mutex?
: 有的时候，你自己code多3到4个clock, 你就可以不用mutex了，这个要了解自己的程序
: ，不是mutex那样到处都能用的。
: 如果同时几个thread把数据改了，我如果自己能发现，再改回来行不行？同学你要换个
: 思路，码工也不是光是砌砖。
|
n******1
发帖数: 3756 | 88 我没有细想过火车票系统的设计
只要有某个维度办将数据分开，就可以分包给其他电商
如果全国所有的票需要各种表全部关联起来，我会考虑一下设计上有没有问题
这些都需要具体问题具体分析，思路是这样而已
【在 g*******g 的大作中提到】
: 分给其他的电商没意义，而且只会增加结算的复杂度。
: 因为，每一张火车票都不是独立的商品，而是与其它的票相关的。而总票数并不是一个
: 特别大的数，分给电商与增加服务器没区别。
: 比如某一趟车中间要停20站，乘客可能买任意两站之间的票，这样就把这一趟车分成了
: 好几段，这些票是不可能事先就在数据库中设好的，必须实时结算。
|
m*******y
发帖数: 48 | 89 有些同志连最基本的transaction management都不懂就开始喷了。。。。。颇有三哥风
范！ |
s*****r
发帖数: 43070 | 90 从你的发言来看，你的公司应该不是做网上交易的
【在 T**********t 的大作中提到】
: 那是你们公司，我们公司不是，谢谢
|
|
|
s*****e
发帖数: 16824 | 91 分包给电商只是减轻前端网络处理的负担，后台处理肯定还是要中心化的。这个跟商品
不一样，相互是影响的。比如说卖彩电，你可以分给每个电商若干台，只要电商自己控
制住不要卖超就可以。但是火车票不一样，一张票的卖出可能导致另一张票的减少，比
如你卖出一张北京到上海的票，那就等于减少了一张同一车次北京到南京的票。如果你
也是简单把北京到南京，北京到上海分给各个电商，那很容易卖超。
【在 n******1 的大作中提到】
: 我没有细想过火车票系统的设计
: 只要有某个维度办将数据分开，就可以分包给其他电商
: 如果全国所有的票需要各种表全部关联起来，我会考虑一下设计上有没有问题
: 这些都需要具体问题具体分析，思路是这样而已
|
l*******d
发帖数: 3343 | 92 12306的抢票和支付是相对独立的两个操作，先抢到票后再支付。至少抢票的时候完全
不用考虑支付等外部因素。
北美猥琐男没机会买国内火车票，估计也没真正使用过12306，都是在臆想
【在 s*****e 的大作中提到】
: 所以你这就是瞎搞嘛，根本就不能允许几个thread同时改数据，一旦允许后果就不可测
: 了，不是你说改回来就行的。一个大型系统不可能只有你的程序访问这些数据，你自己
: 搞的东西顶多保证自己的程序没问题，但是如果其他程序在你改回之前访问了这些数据
: 那就是大灾难。而且很多系统，你根本没有权力改回，就像火车购票，你说不好意思，
: 购票金额错了，我要改回来，你想改，人银行让吗？
|
r**********g
发帖数: 22734 | 93 每秒555次?搞屁啊
【在 T**********t 的大作中提到】
: 基本假设：
: （1）班次信息用点到点方式，5000个火车站，单个信息不到100字节，
: 5000X5000 = 25 M X 100 = 2500 M = 2.5G，这可以全部装入内存，不用考虑硬盘表现
: 了。
: （2）主要流量来自于对当天出来的票源的抢购。每天新增票源按照每两个连续站就算
: 一票，来存储
: 6000 班次 X 30站 /每班次= 18000区间 X 14车厢 X 5种位置 = 1.260M
: （3）每小时查询峰值：5000万次
: （4）每小时交易峰值：200万次， 每秒交易量： 555次
: 下面是基本架构：核心数据库、剩余票源发布服务器、中心城市订票端服务器
|
w****k
发帖数: 690 | 94 每秒555次应该不够吧，不是有数据说每秒访问量为20万次么？ |
h***y
发帖数: 4936 | 95 这楼主的专业订票系统都不需要春运，随便来个清明端午的小假期就瘫痪得一塌糊涂了
。 |
l*****i
发帖数: 20533 | 96 从lz估计的交易峰值来看，似乎比已知的峰值（20万/秒的用户登入量，访问量据说每
秒上千万）要低不少。算下来已经超出了lz建议的数据库以及其它一些设备的极限。那
么接下来lz这个2000万投资的系统会发生什么呢？ |
h******k
发帖数: 13418 | 97 OK个屁啊，狗屁不通还拽鸟语。你这总设计师让我想起了一个人，就是邓矬子。
你把30个服务器分配到了30个城市，还要再和中心的服务器通过广域网同步？
通过Ip确定位置用的着你说，中学生都知道，你还以为捡到宝了？
连我的问题都没听懂，这些请求必须先送达一个服务器，然后这个服务器确定了来自于
那里才能决定forward给那个网页服务器，这个关键环节你连提都没提，就扯神马分配
到每个城市的服务器了。
这个前端的服务器就是LB，所有大型网站都有LB处理请求，才能根据情况分配请求，没
有这个谁来判断Ip，山东民工的电脑自动就把请求发到济南的服务器去？
也没有脑残把30个前端服务器放到30个不同城市，靠广域网来和中心服务器交换信息。
都是尽量放在一个数据中心，30个城市是分布很广的，但没必要把处理业务的服务器分
配的那么远，逻辑分清就行了。
其实把业务分成30个城市就够脑残的，正确的设计应该是所有服务器平等，负载向LB报
告，由LB把新请求发给负担轻的服务器，这样才不会出线济南的忙死，新疆闲置的问题。
而服务器也不必是３０个，应该是由云计算虚拟机动态配置，当３０个服务器负载超过
一定阀值，自动增加服务器并向LB等级，LB将过剩负载发送给新增服务器。
所有这些服务器设备都尽量配置在一个数据中心，放到３０个城市根本是狗屁不通的蠢
才想的出来。
还尼玛专业框架，不抽死你就继续舔脸ＹＹ，还以为捡到宝了。
【在 T**********t 的大作中提到】
: 30个城市，每个城市一个网页服务器，每个网页服务器接一根专线，
: 30城市 X 1 专线/城市 = 30 专线， OK？
:
: 通过IP啊，IP查所在城市不是小菜，您电脑大菜鸟吧？呵呵
|
o********s
发帖数: 971 | 98 这里还真有明白人。
【在 h******k 的大作中提到】
: OK个屁啊，狗屁不通还拽鸟语。你这总设计师让我想起了一个人，就是邓矬子。
: 你把30个服务器分配到了30个城市，还要再和中心的服务器通过广域网同步？
: 通过Ip确定位置用的着你说，中学生都知道，你还以为捡到宝了？
: 连我的问题都没听懂，这些请求必须先送达一个服务器，然后这个服务器确定了来自于
: 那里才能决定forward给那个网页服务器，这个关键环节你连提都没提，就扯神马分配
: 到每个城市的服务器了。
: 这个前端的服务器就是LB，所有大型网站都有LB处理请求，才能根据情况分配请求，没
: 有这个谁来判断Ip，山东民工的电脑自动就把请求发到济南的服务器去？
: 也没有脑残把30个前端服务器放到30个不同城市，靠广域网来和中心服务器交换信息。
: 都是尽量放在一个数据中心，30个城市是分布很广的，但没必要把处理业务的服务器分
|
o********s
发帖数: 971 | 99 你的code能保证atomic operation并不能保证caller 也能atomic operation.
你们公司真倒霉。
【在 T**********t 的大作中提到】
: 我就是做底层library的，我的code没问题，上面的就也没问题。
|
