n*****t 发帖数: 22014 | 1 基本思想就是流水线,把冲突的瓶颈简化,集中到单个节点。
客户服务器 A:UI、车次选定,向 B 查询
编码服务器 B:提供 web interface 给 A,转换协议,TCPIP 向 C 查询,
2bit 表示操作:查询、锁定、解锁(付款失败等)、确认售出,
1bit 表示后续地址方式:区段、枚举
24bit 表示一个地址,如北京到上海,则其中每个区间皆用一个地址表示,售出一张票
需更新 15 个 byte
中心节点 C:响应查询、锁票,如有必要,TCPIP 包的解析在 kernel 里做,SSD 的写
也单独建分区,做设备文件操作,避开 FS 开销。
注:
1、锁票后,由 A 更新数据库,完成收款、出票、记录等功能,并通过 B 通知中心节
点,交易完成。
2、A 对数据库的操作,可保证无冲突,并可按车次等分布到多台 DB SERVER |
n*****t 发帖数: 22014 | 2 大家看看这个实现靠谱不
【在 n*****t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 基本思想就是流水线,把冲突的瓶颈简化,集中到单个节点。 : 客户服务器 A:UI、车次选定,向 B 查询 : 编码服务器 B:提供 web interface 给 A,转换协议,TCPIP 向 C 查询, : 2bit 表示操作:查询、锁定、解锁(付款失败等)、确认售出, : 1bit 表示后续地址方式:区段、枚举 : 24bit 表示一个地址,如北京到上海,则其中每个区间皆用一个地址表示,售出一张票 : 需更新 15 个 byte : 中心节点 C:响应查询、锁票,如有必要,TCPIP 包的解析在 kernel 里做,SSD 的写 : 也单独建分区,做设备文件操作,避开 FS 开销。 : 注:
|
m**********j 发帖数: 8645 | 3 手机怎么订票?
电话怎么订票?
系统当了之后怎么订票?
系统怎么处理退票?
系统怎么处理改票?
【在 n*****t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 大家看看这个实现靠谱不
|
n*****t 发帖数: 22014 | 4 全都是 A 处理,到了中心节点就是 ++ 或者 --
【在 m**********j 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 手机怎么订票? : 电话怎么订票? : 系统当了之后怎么订票? : 系统怎么处理退票? : 系统怎么处理改票?
|
l*****9 发帖数: 9501 | |
m**********j 发帖数: 8645 | 6 不错。
可以考虑cloud
【在 n*****t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 全都是 A 处理,到了中心节点就是 ++ 或者 --
|
t******d 发帖数: 1383 | 7 我觉得不知道为什么会做如此差,貌似把priceline,任何一家航空公司的照搬来,几
乎都可以。也许我外行,还不是架构师 |
l*****9 发帖数: 9501 | 8 流量差得太多。而且12306搞成脑残的靠不断刷票抢票的应用,自己找堵,平白增加了
许多流量
【在 t******d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我觉得不知道为什么会做如此差,貌似把priceline,任何一家航空公司的照搬来,几 : 乎都可以。也许我外行,还不是架构师
|
x****u 发帖数: 44466 | 9 现在人家加了超级captca,还有AJAX,基本不需要刷票。
【在 l*****9 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 流量差得太多。而且12306搞成脑残的靠不断刷票抢票的应用,自己找堵,平白增加了 : 许多流量
|