n**x
发帖数: 606 | 1 大家只管围观，都没搞清需求是什么。 我把两位的需求搞清楚了，我看没有必要吵下
去了。
http://www.mitbbs.com/article_t0/Programming/31312325.html
==========================
老魏的前提是：
- 我要买北京-〉上海， 直达还是联程票用户自己选。如果选直达没票，用户就自己选
择是否可以买到”北京->济南“ ”济南-〉上海“的连票。
所以系统不负责动态计算。
古德霸的前提是：
- 用户要买“北京-〉上海” ，系统动态计算。
所以这两个需求没有可比性。不要吵了。 |
T********i
发帖数: 2416 | 2 如果还要动态计算，goodbug那个方案根本不能用。
这个人如果有一点脸，也不至于还在这里打滚。 |
T********i
发帖数: 2416 | 3 如果还要动态计算，goodbug那个方案根本不能用。
这个人如果有一点脸，也不至于还在这里打滚。 |
l*****9
发帖数: 9501 | 4 据我的理解, 客户可以提出最多中转一次的组合票，中转站由客户给出。
500万应用处理除客户界面以外的所有逻辑计算，对外接口是web service interface
这个应用和简单计数器区别还是挺大的 |
n*****t
发帖数: 22014 | 5 Web interface 到 tcp 中间加几台机器就行了，这个问题不大
【在 l*****9 的大作中提到】
: 据我的理解, 客户可以提出最多中转一次的组合票，中转站由客户给出。
: 500万应用处理除客户界面以外的所有逻辑计算，对外接口是web service interface
: 这个应用和简单计数器区别还是挺大的
|
i*****o
发帖数: 1714 | 6 动态计算最短路径的要求有点强人为难了。这个算法本身就无上限的。
实际中都是用户要求去哪里转车的吧？而且大部分都是先query一下。
★ 发自iPhone App: ChineseWeb 8.6
【在 n**x 的大作中提到】
: 大家只管围观，都没搞清需求是什么。 我把两位的需求搞清楚了，我看没有必要吵下
: 去了。
: http://www.mitbbs.com/article_t0/Programming/31312325.html
: ==========================
: 老魏的前提是：
: - 我要买北京-〉上海， 直达还是联程票用户自己选。如果选直达没票，用户就自己选
: 择是否可以买到”北京->济南“ ”济南-〉上海“的连票。
: 所以系统不负责动态计算。
: 古德霸的前提是：
: - 用户要买“北京-〉上海” ，系统动态计算。
|
g*****g
发帖数: 34805 | 7 强耦合在于票数有限，联程票有冲突，不能简单分开。耦合的线路指数而不是线性递增。
这本来就是很清楚的事情。太监非要混淆视听。
【在 l*****9 的大作中提到】
: 据我的理解, 客户可以提出最多中转一次的组合票，中转站由客户给出。
: 500万应用处理除客户界面以外的所有逻辑计算，对外接口是web service interface
: 这个应用和简单计数器区别还是挺大的
|
l*****9
发帖数: 9501 | 8 说实在的，看不出干TCP什么事
【在 n*****t 的大作中提到】
: Web interface 到 tcp 中间加几台机器就行了，这个问题不大
|
n**x
发帖数: 606 | 9 确实。就算让用户选择中专次数，这个复杂度也是不是线性的。 老魏的实现是用户直
接指定我要北京->济南，济南->上海。那实现起来就简单多了。
【在 i*****o 的大作中提到】
: 动态计算最短路径的要求有点强人为难了。这个算法本身就无上限的。
: 实际中都是用户要求去哪里转车的吧？而且大部分都是先query一下。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
n*****t
发帖数: 22014 | 10 开销低很多啊，一个 request 只有 4-8 个字节，1 byte reap，完全可以放到 kernel
里了，web interface 平白增加瓶颈的工作，可以分出去
【在 l*****9 的大作中提到】
: 说实在的，看不出干TCP什么事
|
|
|
n*****t
发帖数: 22014 | 11 现在 12306 就是这么干的，给出起始站，系统告诉你哪些直达车有票，你选定车次下
单，这符合用户习惯
【在 n**x 的大作中提到】
: 确实。就算让用户选择中专次数，这个复杂度也是不是线性的。 老魏的实现是用户直
: 接指定我要北京->济南，济南->上海。那实现起来就简单多了。
|
a***e
发帖数: 27968 | 12 seat assignment actually requires very complex dynamic scheduling.
say, from A to B, in theory, you could one seat all the way, the normal one.
or you could have to switch seats couple times along the way, which genrally
not considered as valid ticket.
【在 n**x 的大作中提到】
: 大家只管围观，都没搞清需求是什么。 我把两位的需求搞清楚了，我看没有必要吵下
: 去了。
: http://www.mitbbs.com/article_t0/Programming/31312325.html
: ==========================
: 老魏的前提是：
: - 我要买北京-〉上海， 直达还是联程票用户自己选。如果选直达没票，用户就自己选
: 择是否可以买到”北京->济南“ ”济南-〉上海“的连票。
: 所以系统不负责动态计算。
: 古德霸的前提是：
: - 用户要买“北京-〉上海” ，系统动态计算。
|
n**x
发帖数: 606 | 13 座位分配不在老魏的抢票系统里，座位分配由另外系统delay实现
one.
genrally
【在 a***e 的大作中提到】
: seat assignment actually requires very complex dynamic scheduling.
: say, from A to B, in theory, you could one seat all the way, the normal one.
: or you could have to switch seats couple times along the way, which genrally
: not considered as valid ticket.
|
g*****g
发帖数: 34805 | 14 啥，没有同样的座号，就意味着后面没法出票。不是计数器满足就能有一种让所有锁了
计数器人都能出票的方案。我需求里写得很清楚。太监差了不是一点半点。
【在 n**x 的大作中提到】
: 座位分配不在老魏的抢票系统里，座位分配由另外系统delay实现
:
: one.
: genrally
|
z****e
发帖数: 54598 | 15 TCP是有状态的连接
所以如果从节省角度出发
UDP更合适
但是可靠性就差多了
kernel
【在 n*****t 的大作中提到】
: 开销低很多啊，一个 request 只有 4-8 个字节，1 byte reap，完全可以放到 kernel
: 里了，web interface 平白增加瓶颈的工作，可以分出去
|
n**x
发帖数: 606 | 16 呵呵。他是那么说的。 我早就说了他的方案就是1+1 (literally). 作为分配在搞个系
统后台慢慢分配。我估计他的目的是抢到票在说。
【在 g*****g 的大作中提到】
: 啥，没有同样的座号，就意味着后面没法出票。不是计数器满足就能有一种让所有锁了
: 计数器人都能出票的方案。我需求里写得很清楚。太监差了不是一点半点。
|
n*****t
发帖数: 22014 | 17 UDP 也不是不能考虑，前端 timeout retry，后端 timeout refresh
不过我估计每个 request 就 2 个 frame，不需要重新建立连接啥的，10M/s pkt 问题
不大，我是说纯 network IO，毕竟才不到 100M 流量
【在 z****e 的大作中提到】
: TCP是有状态的连接
: 所以如果从节省角度出发
: UDP更合适
: 但是可靠性就差多了
:
: kernel
|
