由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Military版 - 好吧,发个专业的火车订票系统框架,带预算的
相关主题
苹果itunes服务器被中国屏蔽中科网威副总李源:在网安领域 我们能替换国外CPU(ZZ)
Google通讯服务可能在印度遭禁商品的高利润都是消费者普遍犯贱造成的
看来微博是社会动荡的罪魁祸首啊.新燃战火:美国能打赢“中国之声”吗
纽约时报沦为打手 网民:别把中国人当成笨蛋感谢党感谢人民感谢fbi FBI重启路由器的建议失效 僵尸网络感染了更多设备
以总理花12.7万美元在航班上搭双人床引争议张小浪涉窃密苹果事件的几个细节
[ZGPT]用苹果手机计算弹道 外军创造2548米狙击记录(图) (转载)偷了苹果核心技术想回国高就?登机前被FBI逮捕,毁自己更毁华人声誉!
以色列拟为总统总理购买专机 由两人共享为什么白人靠一张脸就能在全世界被优待?原因可能是这个
中国当局两会期间封锁VPN服务偷了苹果核心技术想回国高就!登机前被FBI逮捕,毁自己更毁华人声誉!
相关话题的讨论汇总
话题: 服务器话题: 订票话题: 数据库话题: 系统话题: 30
进入Military版参与讨论
1 (共1页)
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
3
你怎么解决火车票供小于求的问题?
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次
: 下面是基本架构:核心数据库、剩余票源发布服务器、中心城市订票端服务器

相关主题
[ZGPT]用苹果手机计算弹道 外军创造2548米狙击记录(图) (转载)中科网威副总李源:在网安领域 我们能替换国外CPU(ZZ)
以色列拟为总统总理购买专机 由两人共享商品的高利润都是消费者普遍犯贱造成的
中国当局两会期间封锁VPN服务新燃战火:美国能打赢“中国之声”吗
进入Military版参与讨论
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 的大作中提到】
:
: 实时查询不?

相关主题
感谢党感谢人民感谢fbi FBI重启路由器的建议失效 僵尸网络感染了更多设备为什么白人靠一张脸就能在全世界被优待?原因可能是这个
张小浪涉窃密苹果事件的几个细节偷了苹果核心技术想回国高就!登机前被FBI逮捕,毁自己更毁华人声誉!
偷了苹果核心技术想回国高就?登机前被FBI逮捕,毁自己更毁华人声誉!根据我党签署的信息技术产品协议所有IT产品均为0关税
进入Military版参与讨论
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,就是大家都会去做,也做的大同小异,没必要考虑那么仔细。
: 我就是这个意思。
: 除非你觉得有技术难点,拿出来讨论讨论,我向您学习。

相关主题
雨夹雪:沉痛悼念金正日同志Google通讯服务可能在印度遭禁
【原创】中美贸易逆差的计算方法有严重问题,结果根本靠不住。看来微博是社会动荡的罪魁祸首啊.
苹果itunes服务器被中国屏蔽纽约时报沦为打手 网民:别把中国人当成笨蛋
进入Military版参与讨论
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

相关主题
纽约时报沦为打手 网民:别把中国人当成笨蛋以色列拟为总统总理购买专机 由两人共享
以总理花12.7万美元在航班上搭双人床引争议中国当局两会期间封锁VPN服务
[ZGPT]用苹果手机计算弹道 外军创造2548米狙击记录(图) (转载)中科网威副总李源:在网安领域 我们能替换国外CPU(ZZ)
进入Military版参与讨论
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 的大作中提到】
: 这是瞎搞,如果不是严格保证了互锁和先后的话,小规模可能永远碰不上问题,一旦规
: 模大了问题就指数上升。

相关主题
商品的高利润都是消费者普遍犯贱造成的张小浪涉窃密苹果事件的几个细节
新燃战火:美国能打赢“中国之声”吗偷了苹果核心技术想回国高就?登机前被FBI逮捕,毁自己更毁华人声誉!
感谢党感谢人民感谢fbi FBI重启路由器的建议失效 僵尸网络感染了更多设备为什么白人靠一张脸就能在全世界被优待?原因可能是这个
进入Military版参与讨论
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的
: 内存以上都不是问题,但是随着时间的推进,内存里面是什么情况你完全没有把握

相关主题
偷了苹果核心技术想回国高就!登机前被FBI逮捕,毁自己更毁华人声誉!【原创】中美贸易逆差的计算方法有严重问题,结果根本靠不住。
根据我党签署的信息技术产品协议所有IT产品均为0关税苹果itunes服务器被中国屏蔽
雨夹雪:沉痛悼念金正日同志Google通讯服务可能在印度遭禁
进入Military版参与讨论
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没问题,上面的就也没问题。
相关主题
Google通讯服务可能在印度遭禁以总理花12.7万美元在航班上搭双人床引争议
看来微博是社会动荡的罪魁祸首啊.[ZGPT]用苹果手机计算弹道 外军创造2548米狙击记录(图) (转载)
纽约时报沦为打手 网民:别把中国人当成笨蛋以色列拟为总统总理购买专机 由两人共享
进入Military版参与讨论
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就是想卖这种临时的计算和内存,但是目前看
: 到大规模可以应用在第三方系统上的我没了解过
: 我意思是云计算系统很多,但成功的都是自建自用为主,因为通常做大了就做大了

相关主题
中国当局两会期间封锁VPN服务新燃战火:美国能打赢“中国之声”吗
中科网威副总李源:在网安领域 我们能替换国外CPU(ZZ)感谢党感谢人民感谢fbi FBI重启路由器的建议失效 僵尸网络感染了更多设备
商品的高利润都是消费者普遍犯贱造成的张小浪涉窃密苹果事件的几个细节
进入Military版参与讨论
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 的大作中提到】
: 那是你们公司,我们公司不是,谢谢
相关主题
偷了苹果核心技术想回国高就?登机前被FBI逮捕,毁自己更毁华人声誉!根据我党签署的信息技术产品协议所有IT产品均为0关税
为什么白人靠一张脸就能在全世界被优待?原因可能是这个雨夹雪:沉痛悼念金正日同志
偷了苹果核心技术想回国高就!登机前被FBI逮捕,毁自己更毁华人声誉!【原创】中美贸易逆差的计算方法有严重问题,结果根本靠不住。
进入Military版参与讨论
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把新请求发给负担轻的服务器,这样才不会出线济南的忙死,新疆闲置的问题。
而服务器也不必是30个,应该是由云计算虚拟机动态配置,当30个服务器负载超过
一定阀值,自动增加服务器并向LB等级,LB将过剩负载发送给新增服务器。
所有这些服务器设备都尽量配置在一个数据中心,放到30个城市根本是狗屁不通的蠢
才想的出来。
还尼玛专业框架,不抽死你就继续舔脸YY,还以为捡到宝了。

【在 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没问题,上面的就也没问题。
1 (共1页)
进入Military版参与讨论
相关主题
偷了苹果核心技术想回国高就!登机前被FBI逮捕,毁自己更毁华人声誉!以总理花12.7万美元在航班上搭双人床引争议
根据我党签署的信息技术产品协议所有IT产品均为0关税[ZGPT]用苹果手机计算弹道 外军创造2548米狙击记录(图) (转载)
雨夹雪:沉痛悼念金正日同志以色列拟为总统总理购买专机 由两人共享
【原创】中美贸易逆差的计算方法有严重问题,结果根本靠不住。中国当局两会期间封锁VPN服务
苹果itunes服务器被中国屏蔽中科网威副总李源:在网安领域 我们能替换国外CPU(ZZ)
Google通讯服务可能在印度遭禁商品的高利润都是消费者普遍犯贱造成的
看来微博是社会动荡的罪魁祸首啊.新燃战火:美国能打赢“中国之声”吗
纽约时报沦为打手 网民:别把中国人当成笨蛋感谢党感谢人民感谢fbi FBI重启路由器的建议失效 僵尸网络感染了更多设备
相关话题的讨论汇总
话题: 服务器话题: 订票话题: 数据库话题: 系统话题: 30