T********i
发帖数: 2416 | 1 Goodbug提出的：
全国一盘棋。每天1000车次，每车次简化就20段，每车三种票，卧铺，硬座，站票，每
种1000张。上下铺什么的我就不跟你计较了。联票也是支持最多两张
就好，或者说一次转车。用户自选，也不用你算什么最短路径。但是每个车次的票号得
一样。
反正不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
响应并出票。
qxc提出的协议
协议：
4 bytes transactionId
2 bytes trainId1
1 byte seatType
1 byte start1
1 byte end1
2 bytes trainId2
1 byte start2
1 byte end2
我的修改建议：
加上trainid2, start2, end2。因为goodbug要联票转车。
当然，联票转车要算出两张票才对。碰到联票，transaction算2个。
trainid是0表示不转车。
返回 {
4 bytes transactionId
1 byte isSuccess
}
那我们就上单机， 不断电， 只看看 perf.
我的增强版：
实时异步写盘。只要不断电，保证log都写到SSD盘上。
这个完全goodbug的条件。但是他要求实施优化车票分配。这样性能要打点折扣。因此
我提议性能定在1MM TPS，向5MM TPS努力。Goodbug接受了。
各位有意见么？
这是内部服务器：
1. transactionid要做到global unique。
2. 假定security有人管。我不负责安全性检查
3. 不限制同时连接的client，但是client要保证unique transactionid。
4. CLient要有礼貌，尽量pool message into same IP packet, DO NOT use TCP_
NODELAY。不能频繁连接断开。
5. Client如果断开，未发出的response将丢弃。但是买到的票依然保留。可以在
logfile中查到。
6. 这是简化实现，尽量测试核心性能。其他的技术要求（可靠性，信息一致，管理性
，商业逻辑）均可实现，对核心性能没有根本影响。请大家自重，尊重理论，不要用任
何不合理feature要求混淆是非。 |
L*****e
发帖数: 8347 | 2 赞！古德八的“要求车票优化分配”这句还是要明确以下，达到什么情况算优化分配了
。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 T********i 的大作中提到】
: Goodbug提出的：
: 全国一盘棋。每天1000车次，每车次简化就20段，每车三种票，卧铺，硬座，站票，每
: 种1000张。上下铺什么的我就不跟你计较了。联票也是支持最多两张
: 就好，或者说一次转车。用户自选，也不用你算什么最短路径。但是每个车次的票号得
: 一样。
: 反正不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
: 响应并出票。
: qxc提出的协议
: 协议：
: 4 bytes transactionId
|
g*****g
发帖数: 34805 | 3 举个例子，就是假定当前所有票的线段数是N（连着的算一段)，一个request进来，要
满足分配之后N'最小。其次，在N'一样的前提下，要从一个长度最短的线段里取。线段
长度一样可以任取一个。
这简单bruteforce最差情况是个O(N)的算法，N是座位数。
【在 L*****e 的大作中提到】
: 赞！古德八的“要求车票优化分配”这句还是要明确以下，达到什么情况算优化分配了
: 。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
L*****e
发帖数: 8347 | 4 另外，输出还应该有个座位号，否则无法验证座位分配有没有冲突，有没有优化。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 T********i 的大作中提到】
: Goodbug提出的：
: 全国一盘棋。每天1000车次，每车次简化就20段，每车三种票，卧铺，硬座，站票，每
: 种1000张。上下铺什么的我就不跟你计较了。联票也是支持最多两张
: 就好，或者说一次转车。用户自选，也不用你算什么最短路径。但是每个车次的票号得
: 一样。
: 反正不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
: 响应并出票。
: qxc提出的协议
: 协议：
: 4 bytes transactionId
|
L*****e
发帖数: 8347 | 5 嗯，我知道你的意思，我是说spec里这点要明确，否则最后又因为“理解”不同而争吵
。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 g*****g 的大作中提到】
: 举个例子，就是假定当前所有票的线段数是N（连着的算一段)，一个request进来，要
: 满足分配之后N'最小。其次，在N'一样的前提下，要从一个长度最短的线段里取。线段
: 长度一样可以任取一个。
: 这简单bruteforce最差情况是个O(N)的算法，N是座位数。
|
L*****e
发帖数: 8347 | 6 输出的isSuccess其实不用了，换成座位号就行，有座位号就是成功了，失败了发个0号
或负号。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 L*****e 的大作中提到】
: 另外，输出还应该有个座位号，否则无法验证座位分配有没有冲突，有没有优化。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
g*****g
发帖数: 34805 | 7 输出要有座位号，座位类型，和跟车次的关系。你要用编码，可以，我就提醒一下编码
也不是免费的。
另外是联票，所以最多俩座位。
【在 L*****e 的大作中提到】
: 另外，输出还应该有个座位号，否则无法验证座位分配有没有冲突，有没有优化。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
q*c
发帖数: 9453 | 8 right.
【在 L*****e 的大作中提到】
: 输出的isSuccess其实不用了，换成座位号就行，有座位号就是成功了，失败了发个0号
: 或负号。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
q*c
发帖数: 9453 | 9 座位号就行了，因为有 transactionid, transaction 请求里面有车次， 座位类型
和车次的关系是啥意思？
【在 g*****g 的大作中提到】
: 输出要有座位号，座位类型，和跟车次的关系。你要用编码，可以，我就提醒一下编码
: 也不是免费的。
: 另外是联票，所以最多俩座位。
|
g*****g
发帖数: 34805 | 10 另外，是100万的request，所以就算是100万联票，200万张票，也是100万的request。
我们一直说的是能够撑住外部来的百万request。 |
|
|
L*****e
发帖数: 8347 | 11 老魏说联票是当两个transactions的，而且联票难道不是要换车吗？这个座位是要变的
吧？
★ 发自iPhone App: ChineseWeb 8.2.2
【在 g*****g 的大作中提到】
: 输出要有座位号，座位类型，和跟车次的关系。你要用编码，可以，我就提醒一下编码
: 也不是免费的。
: 另外是联票，所以最多俩座位。
|
g*****g
发帖数: 34805 | 12 出两张票的话，要保持进来和出去的顺序一样。
【在 q*c 的大作中提到】
: 座位号就行了，因为有 transactionid, transaction 请求里面有车次， 座位类型
: 和车次的关系是啥意思？
|
g*****g
发帖数: 34805 | 13 我说的是支持100万request，如果一个request需要两个transaction，那也还是100万
request.
用户才不管你内部用几个transaction来实现呢，没有用内部数目来算需求的。
【在 L*****e 的大作中提到】
: 老魏说联票是当两个transactions的，而且联票难道不是要换车吗？这个座位是要变的
: 吧？
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
L*****e
发帖数: 8347 | 14 老魏的原话：当然，联票转车要算出两张票才对。碰到联票，transaction算2个。
你俩这个问题统一一下？
★ 发自iPhone App: ChineseWeb 8.2.2
【在 g*****g 的大作中提到】
: 另外，是100万的request，所以就算是100万联票，200万张票，也是100万的request。
: 我们一直说的是能够撑住外部来的百万request。
|
g*****g
发帖数: 34805 | 15 没有任何应用是这么算的，都是按request/response算。如果一个request有联票他只
能做一半，那他就最多能支持50万/秒的request。要先把话说在前头，不要吹牛。术语
要用业界术语，不能自定义吧。
我说我的系统能支持百万订单的时候，单个订单可比这个复杂多了。
【在 L*****e 的大作中提到】
: 老魏的原话：当然，联票转车要算出两张票才对。碰到联票，transaction算2个。
: 你俩这个问题统一一下？
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
g*****g
发帖数: 34805 | 16 还有，要能够支持多张一样的票(联票)吧。我不要求变态的，就最低要求两张票就
好，这也算一个单子。我和领导一块去探亲，你不能我买着了，领导买不到吧，这也是
不能分的transaction要求之一。
所以输入要加上票子数目，最多2张就好，还算一个单子。 |
q*c
发帖数: 9453 | 17 这个合理， 不过 10% 联票， 就算 20-30% 联票， 老魏的模型下也就 20-30%
overhead.
这都从 5MM 到 1MM了， 这点余量老魏应该没问题。
【在 g*****g 的大作中提到】
: 我说的是支持100万request，如果一个request需要两个transaction，那也还是100万
: request.
: 用户才不管你内部用几个transaction来实现呢，没有用内部数目来算需求的。
|
L*****e
发帖数: 8347 | 18 这个东西都在于人怎么定义，也可以说要求转车的request就是两个requests，等于是
订两张票，只是一起提交而已。
这个没啥倾向性，你们只要把定义统一了就好。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 g*****g 的大作中提到】
: 没有任何应用是这么算的，都是按request/response算。如果一个request有联票他只
: 能做一半，那他就最多能支持50万/秒的request。要先把话说在前头，不要吹牛。术语
: 要用业界术语，不能自定义吧。
: 我说我的系统能支持百万订单的时候，单个订单可比这个复杂多了。
|
g*****g
发帖数: 34805 | 19 这不是个人定义，这是一个transaction的基本要求。如果我只能买到一段，买不到联
票，我不买。
如果我只能自己一个人走，领导走不了，我不走。你没法分成两个request。要吗都成
功，要吗都不成功。
我没有难为他，我自己设计的系统，单子比这个复杂多了。
【在 L*****e 的大作中提到】
: 这个东西都在于人怎么定义，也可以说要求转车的request就是两个requests，等于是
: 订两张票，只是一起提交而已。
: 这个没啥倾向性，你们只要把定义统一了就好。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
q*c
发帖数: 9453 | 20 这个也是合理要求。 transaction.
我感觉 pm 不好做啊， 就这个 spec 估计都要很长时间，
【在 g*****g 的大作中提到】
: 还有，要能够支持多张一样的票(联票)吧。我不要求变态的，就最低要求两张票就
: 好，这也算一个单子。我和领导一块去探亲，你不能我买着了，领导买不到吧，这也是
: 不能分的transaction要求之一。
: 所以输入要加上票子数目，最多2张就好，还算一个单子。
|
|
|
L*****e
发帖数: 8347 | 21 这个其实对效率没有影响，机器处理的时候还是当两个人分别订票的，只是在处理时排
队把这两个请求排队在一起，然后对成功和失败多加一个限制，group里的多个请求都
成功才算成功。。。
这个要求只是在实现上增加了点繁琐，输入的信息略微增多（比如加个group id），对
performance没有大的影响，建议还是不加这个条件。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 g*****g 的大作中提到】
: 还有，要能够支持多张一样的票(联票)吧。我不要求变态的，就最低要求两张票就
: 好，这也算一个单子。我和领导一块去探亲，你不能我买着了，领导买不到吧，这也是
: 不能分的transaction要求之一。
: 所以输入要加上票子数目，最多2张就好，还算一个单子。
|
L*****e
发帖数: 8347 | 22 要求和具体实现是两码事。你可以要求只买到一段买不到另一段不能走，但不意味着实
现就必须把这两张票做为一个transaction才能满足要求。我上面举的的例子，可以对
联票分配一个group id，同一个group里的必须都成功才算订票成功。。。
★ 发自iPhone App: ChineseWeb 8.2.2
★ 发自iPhone App: ChineseWeb 8.2.2
★ 发自iPhone App: ChineseWeb 8.2.2
★ 发自iPhone App: ChineseWeb 8.2.2
【在 g*****g 的大作中提到】
: 这不是个人定义，这是一个transaction的基本要求。如果我只能买到一段，买不到联
: 票，我不买。
: 如果我只能自己一个人走，领导走不了，我不走。你没法分成两个request。要吗都成
: 功，要吗都不成功。
: 我没有难为他，我自己设计的系统，单子比这个复杂多了。
|
T********i
发帖数: 2416 | 23 行，你说了10%是联票。这个你控制不住是你的问题。
至于你说你的系统能支持100万订单啥意思？还比这个复杂多了？
这个你要说清楚。你是说实时百万么？不可以吹牛不上税的。
【在 g*****g 的大作中提到】
: 没有任何应用是这么算的，都是按request/response算。如果一个request有联票他只
: 能做一半，那他就最多能支持50万/秒的request。要先把话说在前头，不要吹牛。术语
: 要用业界术语，不能自定义吧。
: 我说我的系统能支持百万订单的时候，单个订单可比这个复杂多了。
|
T********i
发帖数: 2416 | 24 这个满足你。
【在 g*****g 的大作中提到】
: 举个例子，就是假定当前所有票的线段数是N（连着的算一段)，一个request进来，要
: 满足分配之后N'最小。其次，在N'一样的前提下，要从一个长度最短的线段里取。线段
: 长度一样可以任取一个。
: 这简单bruteforce最差情况是个O(N)的算法，N是座位数。
|
T********i
发帖数: 2416 | 25 其他的要求我就不管了。
你给我找各种各样的麻烦，又没人给钱，凭啥花时间都满足你。 |
d*******r
发帖数: 3299 | |
q*c
发帖数: 9453 | 27 我来作活雷锋 (下面得要实现了， server/test code 不开源真是天大浪费）。
全国一盘棋。每天1000车次，每车次简化就20段，
每车三种票，卧铺，硬座，站票，每种1000张。
联票也是支持最多两张。 10% 联票， 不能换座位。（联票内每个车次的票号得一样。）
不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
响应并出票。
联票算一个请求。 内部多少 transaction 不能管。(就 10% overhead, 老魏就别纠缠
了， 不是目标是 5MM 嘛！)
协议：
{
4 bytes transactionId
1 byte numberOfTickets ( 全家出门必须 aon )
1 byte seatType
2 bytes trainId1
1 byte start1
1 byte end1
2 bytes trainId2
1 byte start2
1 byte end2
}
不转车就没有 section 2.
返回
{
4 bytes transactionId
2 byte seatNumber (0 if failed)
}
实时异步写盘。只要不断电，保证相应得请求都写到SSD盘上。（也就是断电了能无损
恢复）
要求实施优化车票分配。
优化就是说造成最少碎片。
性能定在1MM TPS，向5MM TPS努力。
这是内部服务器：
1. transactionid要做到global unique。
2. 假定security有人管。我不负责安全性检查
3. 不限制同时连接的client，但是client要保证unique transactionid。
4. CLient要有礼貌，尽量pool message into same IP packet, DO NOT use TCP_
NODELAY。不能频繁连接断开。
5. Client如果断开，未发出的response将丢弃。但是买到的票依然保留。可以在
logfile中查到。
6. 这是简化实现，尽量测试核心性能。其他的技术要求（可靠性，信息一致，管理性
，商业逻辑）均可实现，对核心性能没有根本影响。请大家自重，尊重理论，不要用任
何不合理feature要求混淆是非。 |
z*******3
发帖数: 13709 | 28 30s内响应阿？
那这个跟real time差了太远了吧？
。）
【在 q*c 的大作中提到】
: 我来作活雷锋 (下面得要实现了， server/test code 不开源真是天大浪费）。
: 全国一盘棋。每天1000车次，每车次简化就20段，
: 每车三种票，卧铺，硬座，站票，每种1000张。
: 联票也是支持最多两张。 10% 联票， 不能换座位。（联票内每个车次的票号得一样。）
: 不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
: 响应并出票。
: 联票算一个请求。 内部多少 transaction 不能管。(就 10% overhead, 老魏就别纠缠
: 了， 不是目标是 5MM 嘛！)
: 协议：
: {
|
T********i
发帖数: 2416 | 29 行，把AON去掉。
我说了，优化满足，10%联票满足。其他的我就不管了。
AON确实增加点时间，但是marginal的。主要是懒的多写。
我都说了，那两样满足，其他不管。
。）
【在 q*c 的大作中提到】
: 我来作活雷锋 (下面得要实现了， server/test code 不开源真是天大浪费）。
: 全国一盘棋。每天1000车次，每车次简化就20段，
: 每车三种票，卧铺，硬座，站票，每种1000张。
: 联票也是支持最多两张。 10% 联票， 不能换座位。（联票内每个车次的票号得一样。）
: 不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
: 响应并出票。
: 联票算一个请求。 内部多少 transaction 不能管。(就 10% overhead, 老魏就别纠缠
: 了， 不是目标是 5MM 嘛！)
: 协议：
: {
|
b*******s
发帖数: 5216 | 30 什么叫realtime？
【在 z*******3 的大作中提到】
: 30s内响应阿？
: 那这个跟real time差了太远了吧？
:
: 。）
|
|
|
z*******3
发帖数: 13709 | 31 30s跟10m有什么本质区别？
【在 b*******s 的大作中提到】
: 什么叫realtime？
|
q*c
发帖数: 9453 | 32 你和 goodbug 商量商量？ 我就是个书记员 . 这基本都是网友提供得， 我就终结以下
。 pm 不好作啊。
我个人觉得aon 很重要， 这是个无法避免得 feature. 不能一家人买了一半得票。
。。
【在 T********i 的大作中提到】
: 行，把AON去掉。
: 我说了，优化满足，10%联票满足。其他的我就不管了。
: AON确实增加点时间，但是marginal的。主要是懒的多写。
: 我都说了，那两样满足，其他不管。
:
: 。）
|
g*****g
发帖数: 34805 | 33 你错了，如果不实时找座位没影响，实时找座位当然有影响。
【在 L*****e 的大作中提到】
: 这个其实对效率没有影响，机器处理的时候还是当两个人分别订票的，只是在处理时排
: 队把这两个请求排队在一起，然后对成功和失败多加一个限制，group里的多个请求都
: 成功才算成功。。。
: 这个要求只是在实现上增加了点繁琐，输入的信息略微增多（比如加个group id），对
: performance没有大的影响，建议还是不加这个条件。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
L*****e
发帖数: 8347 | 34 输出seatnumber还是应该同意吧？
★ 发自iPhone App: ChineseWeb 8.2.2
【在 T********i 的大作中提到】
: 行，把AON去掉。
: 我说了，优化满足，10%联票满足。其他的我就不管了。
: AON确实增加点时间，但是marginal的。主要是懒的多写。
: 我都说了，那两样满足，其他不管。
:
: 。）
|
T********i
发帖数: 2416 | 35 同意很重要。
任何功能都重要。但是做成了又没人给我半毛钱。
俺不想和你们做生意讨价还价。goodbug坚持联票算一个transaction我都认了。
但是AON原先SPEC里没有。
【在 q*c 的大作中提到】
: 你和 goodbug 商量商量？ 我就是个书记员 . 这基本都是网友提供得， 我就终结以下
: 。 pm 不好作啊。
: 我个人觉得aon 很重要， 这是个无法避免得 feature. 不能一家人买了一半得票。
: 。。
|
q*c
发帖数: 9453 | 36 这是老霸前面提得， 能保证 30s , 不延长， 持续 1 小时 1-5MM tps， 也是本事...
【在 z*******3 的大作中提到】
: 30s内响应阿？
: 那这个跟real time差了太远了吧？
:
: 。）
|
g*****g
发帖数: 34805 | 37 我的订单可以支持备份线路，可以支持最多5张。我从来没说过实时。实时是你说的。
【在 T********i 的大作中提到】
: 行，你说了10%是联票。这个你控制不住是你的问题。
: 至于你说你的系统能支持100万订单啥意思？还比这个复杂多了？
: 这个你要说清楚。你是说实时百万么？不可以吹牛不上税的。
|
q*c
发帖数: 9453 | 38 seat number 呢， 这是左眼提的， 我觉得其实是本来的要求啊， 我忘记写进去了。
【在 T********i 的大作中提到】
: 同意很重要。
: 任何功能都重要。但是做成了又没人给我半毛钱。
: 俺不想和你们做生意讨价还价。goodbug坚持联票算一个transaction我都认了。
: 但是AON原先SPEC里没有。
|
T********i
发帖数: 2416 | 39 我的这个性能只和线路数量有关。我说过系统硬件定下来不能无限提高负载。
所以你说联票站10%，我们就要按照10%测试。你要是按照100%测试当然不对。
【在 g*****g 的大作中提到】
: 我的订单可以支持备份线路，可以支持最多5张。我从来没说过实时。实时是你说的。
|
z*******3
发帖数: 13709 | 40 如果是这样一个步骤都要30s，我用老魏的干嘛？
用古德霸的都没不会这样，30s停滞的话，顾客直接关网页了
古德霸真是nice，条件这么宽
这简直就是一个web session的expire time了
老魏吹牛的那样，直接给他3ms反应时间都算是抬举他了
应该给3us才对
..
【在 q*c 的大作中提到】
: 这是老霸前面提得， 能保证 30s , 不延长， 持续 1 小时 1-5MM tps， 也是本事...
|
|
|
T********i
发帖数: 2416 | 41 seat number是必须的。
【在 q*c 的大作中提到】
: seat number 呢， 这是左眼提的， 我觉得其实是本来的要求啊， 我忘记写进去了。
|
g*****g
发帖数: 34805 | 42 既然最多4张票，联票加两人，你的出票spec得修改一下。我也不要求座位连着。
。）
【在 q*c 的大作中提到】
: 我来作活雷锋 (下面得要实现了， server/test code 不开源真是天大浪费）。
: 全国一盘棋。每天1000车次，每车次简化就20段，
: 每车三种票，卧铺，硬座，站票，每种1000张。
: 联票也是支持最多两张。 10% 联票， 不能换座位。（联票内每个车次的票号得一样。）
: 不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
: 响应并出票。
: 联票算一个请求。 内部多少 transaction 不能管。(就 10% overhead, 老魏就别纠缠
: 了， 不是目标是 5MM 嘛！)
: 协议：
: {
|
L*****e
发帖数: 8347 | 43 aon是个重要的feature，但是aon的number of tickets算几个transaction啊？如果算
number of tickets个transaction，这个条件只增加了点marginal cost，对评价老魏
的方案的效率只是增加点干扰因素而已，没有本质影响。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 q*c 的大作中提到】
: 你和 goodbug 商量商量？ 我就是个书记员 . 这基本都是网友提供得， 我就终结以下
: 。 pm 不好作啊。
: 我个人觉得aon 很重要， 这是个无法避免得 feature. 不能一家人买了一半得票。
: 。。
|
g*****g
发帖数: 34805 | 44 可以，但2张票all or nothing不能让了吧。
【在 T********i 的大作中提到】
: 我的这个性能只和线路数量有关。我说过系统硬件定下来不能无限提高负载。
: 所以你说联票站10%，我们就要按照10%测试。你要是按照100%测试当然不对。
|
g*****g
发帖数: 34805 | 45 我说了多少次，不是数票子，是数订单数目，或者说request/response数目。
事实上一个request就是一个transaction。你要是做网站的讨论性能就不会问这个问题。
【在 L*****e 的大作中提到】
: aon是个重要的feature，但是aon的number of tickets算几个transaction啊？如果算
: number of tickets个transaction，这个条件只增加了点marginal cost，对评价老魏
: 的方案的效率只是增加点干扰因素而已，没有本质影响。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
T********i
发帖数: 2416 | 46 3ms我也没意见。
问题是如果只有1G带宽，你上来10个1G的全速test session，那就是等一辈子的事情了。
跟你说这个，已经抬举你了。
【在 z*******3 的大作中提到】
: 如果是这样一个步骤都要30s，我用老魏的干嘛？
: 用古德霸的都没不会这样，30s停滞的话，顾客直接关网页了
: 古德霸真是nice，条件这么宽
: 这简直就是一个web session的expire time了
: 老魏吹牛的那样，直接给他3ms反应时间都算是抬举他了
: 应该给3us才对
:
: ..
|
T********i
发帖数: 2416 | 47 不做就是不做，没啥可商量的。2张和n张没啥区别。写起来麻烦。
【在 g*****g 的大作中提到】
: 可以，但2张票all or nothing不能让了吧。
|
z*******3
发帖数: 13709 | 48 原来你也知道这里有瓶颈哦
所以说，你整这么一个东西做什么用？
人家简单粗暴就满足要求了，要你干嘛？
了。
【在 T********i 的大作中提到】
: 3ms我也没意见。
: 问题是如果只有1G带宽，你上来10个1G的全速test session，那就是等一辈子的事情了。
: 跟你说这个，已经抬举你了。
|
q*c
发帖数: 9453 | 49 我有点没理解，你要不自己改改贴上来？
【在 g*****g 的大作中提到】
: 既然最多4张票，联票加两人，你的出票spec得修改一下。我也不要求座位连着。
:
: 。）
|
T********i
发帖数: 2416 | 50 要我就是打你这个屎一样的人的脸呀。
【在 z*******3 的大作中提到】
: 原来你也知道这里有瓶颈哦
: 所以说，你整这么一个东西做什么用？
: 人家简单粗暴就满足要求了，要你干嘛？
:
: 了。
|
|
|
q*c
发帖数: 9453 | 51 我只管搞个 spec 大家 move forward. 没影响最好。
【在 L*****e 的大作中提到】
: aon是个重要的feature，但是aon的number of tickets算几个transaction啊？如果算
: number of tickets个transaction，这个条件只增加了点marginal cost，对评价老魏
: 的方案的效率只是增加点干扰因素而已，没有本质影响。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
z*******3
发帖数: 13709 | 52 哈哈，你打着了么？
我站在这里等着你过来，你都不敢阿
怂阿
【在 T********i 的大作中提到】
: 要我就是打你这个屎一样的人的脸呀。
|
L*****e
发帖数: 8347 | 53 我对于你们怎么定义都没意见，只要你们统一就行。所以这个问题你不用说服我，而是
要说服老魏同意。。。貌似他现在没同意。。。
题。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 g*****g 的大作中提到】
: 我说了多少次，不是数票子，是数订单数目，或者说request/response数目。
: 事实上一个request就是一个transaction。你要是做网站的讨论性能就不会问这个问题。
|
T********i
发帖数: 2416 | 54 实话说，goodbug这个加两人基本不增加复杂度。但是我不会给他做。
不能惯着他，处处讨价还价。 |
z*******3
发帖数: 13709 | 55 问pm一个问题
如果需求双方无法一致的话
怎么办？
【在 L*****e 的大作中提到】
: 我对于你们怎么定义都没意见，只要你们统一就行。所以这个问题你不用说服我，而是
: 要说服老魏同意。。。貌似他现在没同意。。。
:
: 题。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
q*c
发帖数: 9453 | 56 到底最多几张票啊？2 张还是4张。 弄清楚了我们好写上。
【在 T********i 的大作中提到】
: 不做就是不做，没啥可商量的。2张和n张没啥区别。写起来麻烦。
|
q*c
发帖数: 9453 | 57 大家都等着看结果呢, 既然没啥,就顺手做了，看起来这是最后一个分歧了？
【在 T********i 的大作中提到】
: 实话说，goodbug这个加两人基本不增加复杂度。但是我不会给他做。
: 不能惯着他，处处讨价还价。
|
L*****e
发帖数: 8347 | 58 写支持n张的和写支持两张的，写起来也不会更麻烦。不过如果古德八的意思是这n张都
算一个request的话，你搜索找座的cost可是要增加不少。。。本来是一个transaction
里找一个座，现在要找N个座。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 T********i 的大作中提到】
: 不做就是不做，没啥可商量的。2张和n张没啥区别。写起来麻烦。
|
w**z
发帖数: 8232 | 59 快点，等着下注呢。
【在 q*c 的大作中提到】
: 到底最多几张票啊？2 张还是4张。 弄清楚了我们好写上。
|
z*******3
发帖数: 13709 | 60 当然要这样，要不然出一张票，大人走了
小孩子自己再单独走
不可能的，小孩子路上直接给人抱走了
transaction
【在 L*****e 的大作中提到】
: 写支持n张的和写支持两张的，写起来也不会更麻烦。不过如果古德八的意思是这n张都
: 算一个request的话，你搜索找座的cost可是要增加不少。。。本来是一个transaction
: 里找一个座，现在要找N个座。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
|
|
g*****g
发帖数: 34805 | 61 操，这都是合理要求，做不出来就别叫板。
【在 T********i 的大作中提到】
: 实话说，goodbug这个加两人基本不增加复杂度。但是我不会给他做。
: 不能惯着他，处处讨价还价。
|
g*****g
发帖数: 34805 | 62 联票最多两张，最多俩人。当然是最多4张。
【在 q*c 的大作中提到】
: 到底最多几张票啊？2 张还是4张。 弄清楚了我们好写上。
|
L*****e
发帖数: 8347 | 63 继续扯皮贝，反正都扯了三个月了。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 z*******3 的大作中提到】
: 问pm一个问题
: 如果需求双方无法一致的话
: 怎么办？
|
L*****e
发帖数: 8347 | 64 最大的分歧不是支持aon几张票，是这几张票算几个transaction。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 q*c 的大作中提到】
: 大家都等着看结果呢, 既然没啥,就顺手做了，看起来这是最后一个分歧了？
|
q*c
发帖数: 9453 | 65 老魏，这就搞上吧，合理而且也可以开张了。
【在 g*****g 的大作中提到】
: 联票最多两张，最多俩人。当然是最多4张。
|
q*c
发帖数: 9453 | 66 10% 的票联票，就算一半 4 张 一半 2张 也就 30%。 这不是底线 1 mm 向 5 mm 嘛，
老魏就上吧，也就 1.3 mm 起线。 哪怕最后老魏做了 850k, 就已经非常碉堡了！
而且这样 client 好算 tps。
【在 L*****e 的大作中提到】
: 最大的分歧不是支持aon几张票，是这几张票算几个transaction。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
n******1
发帖数: 3756 | 67 我觉得算一个，交易你买了，成功了就成功了
【在 L*****e 的大作中提到】
: 最大的分歧不是支持aon几张票，是这几张票算几个transaction。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
z*******3
发帖数: 13709 | 68 当然是一个，全家人一起走，哪有分开走的道理
【在 n******1 的大作中提到】
: 我觉得算一个，交易你买了，成功了就成功了
|
L*****e
发帖数: 8347 | 69 正是要增加30%的搜索分座时间啊，你票数可以一次加减n，你找座必须一个个找。。。
（或者找座上多线程？）这个搜索分座目测是当前抢票过程里最耗时的部分，增加30%
影响可不小。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 q*c 的大作中提到】
: 10% 的票联票，就算一半 4 张 一半 2张 也就 30%。 这不是底线 1 mm 向 5 mm 嘛，
: 老魏就上吧，也就 1.3 mm 起线。 哪怕最后老魏做了 850k, 就已经非常碉堡了！
: 而且这样 client 好算 tps。
|
i**i
发帖数: 1500 | 70 +1
【在 w**z 的大作中提到】
: 快点，等着下注呢。
|
|
|
i*****o
发帖数: 1714 | 71 你这个要求应该是前端做的，因为这样的要求太不一样了，有时三个人，有时四个人，
还有中途下车的。这都属于其它类要求。这种要求应该写特殊的应用服务来解决，不应
该由最后端的来做。
★ 发自iPhone App: ChineseWeb 8.6
【在 g*****g 的大作中提到】
: 联票最多两张，最多俩人。当然是最多4张。
|
q*c
发帖数: 9453 | 72 老魏不是说线性嘛，说的就是计划的 1mm tps 现在变成 1。3mm tps
没啥赶紧达成协议上手是正经。当初我可是下注 50k tps 的。
【在 L*****e 的大作中提到】
: 正是要增加30%的搜索分座时间啊，你票数可以一次加减n，你找座必须一个个找。。。
: （或者找座上多线程？）这个搜索分座目测是当前抢票过程里最耗时的部分，增加30%
: 影响可不小。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
q*c
发帖数: 9453 | 73 这必须抢票期做，因为要不然全走都抢到票不然都没有，就和联票一样。
【在 i*****o 的大作中提到】
: 你这个要求应该是前端做的，因为这样的要求太不一样了，有时三个人，有时四个人，
: 还有中途下车的。这都属于其它类要求。这种要求应该写特殊的应用服务来解决，不应
: 该由最后端的来做。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
z*******3
发帖数: 13709 | 74 你现实中写过这种特殊的服务么？
独立于系统而存在的，不太可能的
都是直接放到主流程里搞定的
要锁一起锁，要出一起出，一个小错误，全部回滚
【在 i*****o 的大作中提到】
: 你这个要求应该是前端做的，因为这样的要求太不一样了，有时三个人，有时四个人，
: 还有中途下车的。这都属于其它类要求。这种要求应该写特殊的应用服务来解决，不应
: 该由最后端的来做。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
t**********1
发帖数: 550 | 75 我说了，算两个transaction就做，否则不做。
为啥没事给自己找麻烦？ |
L*****e
发帖数: 8347 | 76 你说的算一个是从用户需求方面算一个，而他们的分歧在于从系统效率方面是否算一个
。实现aon并不难，难在到底是以每秒钟卖掉多少票来衡量老魏的系统效率还是以每秒
处理多少request来衡量。。。
好虫教育我说做过网站的都应该知道怎么衡量，怎么衡量我都没意见，他们统一就行。
其实这点不统一也没关系，东西做出来，结果出来后大家心里自己去衡量，不过就是到
时候板上免不了又是一番嘴仗。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 n******1 的大作中提到】
: 我觉得算一个，交易你买了，成功了就成功了
|
z*******3
发帖数: 13709 | 77 这个其实是client side&server side的主要区别
送单的才不管这些，接单的才需要想这些，这就是差异
这是server side，显然要考虑
【在 q*c 的大作中提到】
: 这必须抢票期做，因为要不然全走都抢到票不然都没有，就和联票一样。
|
i*****o
发帖数: 1714 | 78 靠当然是在流程里的。
★ 发自iPhone App: ChineseWeb 8.6
【在 z*******3 的大作中提到】
: 你现实中写过这种特殊的服务么？
: 独立于系统而存在的，不太可能的
: 都是直接放到主流程里搞定的
: 要锁一起锁，要出一起出，一个小错误，全部回滚
|
i*****o
发帖数: 1714 | 79 你确定可以做？我想不出什么好办法。
★ 发自iPhone App: ChineseWeb 8.6
【在 t**********1 的大作中提到】
: 我说了，算两个transaction就做，否则不做。
: 为啥没事给自己找麻烦？
|
z*******3
发帖数: 13709 | 80 你要作分布式的事务么？
这里做下去，老魏估计挂了
我让他做单机事务是为他好
分布式事务估计没戏，难度高太多了
【在 i*****o 的大作中提到】
: 靠当然是在流程里的。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
|
|
q*c
发帖数: 9453 | 81 算了老霸，他这就是把 1mm 最低变成 1mm/1.23
不是大问题。如果 aws 的机器都能这样，上牛逼机器就过线了。
你就 那 10% request 算两个或者四个算了。这各种最优出票，写 disk 保证能恢复，
不差这一点？
【在 t**********1 的大作中提到】
: 我说了，算两个transaction就做，否则不做。
: 为啥没事给自己找麻烦？
|
q*c
发帖数: 9453 | 82 算 两个 trans 是说计算 tps.
结果必须是 transactional.
【在 i*****o 的大作中提到】
: 你确定可以做？我想不出什么好办法。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
t**********1
发帖数: 550 | 83
【在 L*****e 的大作中提到】
: 你说的算一个是从用户需求方面算一个，而他们的分歧在于从系统效率方面是否算一个
: 。实现aon并不难，难在到底是以每秒钟卖掉多少票来衡量老魏的系统效率还是以每秒
: 处理多少request来衡量。。。
: 好虫教育我说做过网站的都应该知道怎么衡量，怎么衡量我都没意见，他们统一就行。
: 其实这点不统一也没关系，东西做出来，结果出来后大家心里自己去衡量，不过就是到
: 时候板上免不了又是一番嘴仗。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
c******3
发帖数: 296 | 84 这个算团体票吧。可以下个版本支持。
版本号1。0：抢购个人票
版本号2。0：支持团体票
这个项目就叫GOODWAY吧
【在 g*****g 的大作中提到】
: 操，这都是合理要求，做不出来就别叫板。
|
t**********1
发帖数: 550 | 85 这个同意。
【在 q*c 的大作中提到】
: 算 两个 trans 是说计算 tps.
: 结果必须是 transactional.
|
i*****o
发帖数: 1714 | 86 不知道你们为什么坚持这个要求，这完全属于特殊应用。前端的可以买完一张再买另一
张，买不到就退第一张。类似的要求多了，怎么可能都由最后端来处理。我要五十人一
起走呢？我要京西下车，再到东站换车怎么办？这种特殊要求都是前端的事吧。
★ 发自iPhone App: ChineseWeb 8.6
【在 q*c 的大作中提到】
: 算 两个 trans 是说计算 tps.
: 结果必须是 transactional.
|
n******1
发帖数: 3756 | 87 事务由前端负责？会不会更加复杂，起码在事务内的退票是可控的，如果不在同一个事
务里，你怎么标记哪一张成功了，应该退哪些？
事务的支持在oracle的第三版（1983年）已经支持
【在 i*****o 的大作中提到】
: 不知道你们为什么坚持这个要求，这完全属于特殊应用。前端的可以买完一张再买另一
: 张，买不到就退第一张。类似的要求多了，怎么可能都由最后端来处理。我要五十人一
: 起走呢？我要京西下车，再到东站换车怎么办？这种特殊要求都是前端的事吧。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
L***n
发帖数: 6727 | 88 LOL 支持
【在 c******3 的大作中提到】
: 这个算团体票吧。可以下个版本支持。
: 版本号1。0：抢购个人票
: 版本号2。0：支持团体票
: 这个项目就叫GOODWAY吧
|
i*****o
发帖数: 1714 | 89 本来就有退票的功能吧，而且出票机出的票五分钟之内没commit到db里要自动回收。
★ 发自iPhone App: ChineseWeb 8.6
【在 n******1 的大作中提到】
: 事务由前端负责？会不会更加复杂，起码在事务内的退票是可控的，如果不在同一个事
: 务里，你怎么标记哪一张成功了，应该退哪些？
: 事务的支持在oracle的第三版（1983年）已经支持
|
s***o
发帖数: 2191 | 90 钻风在瞎搞什么？骂的热火朝天的时候不管不问导致失控。现在这两位心平气和讨论具
体方案了，反而都给封了。是因为不打架就没流量吗？ |
|
|
q*c
发帖数: 9453 | 91 为啥，问题多了，你退票就有退票费啊，没退票费黄牛现在不是大爽。
交易交易，这种原子性必须的。我要是买了 10 张票最后一张没有，你叫我慢慢退，赔
大钱？浪费20倍时间？
【在 i*****o 的大作中提到】
: 不知道你们为什么坚持这个要求，这完全属于特殊应用。前端的可以买完一张再买另一
: 张，买不到就退第一张。类似的要求多了，怎么可能都由最后端来处理。我要五十人一
: 起走呢？我要京西下车，再到东站换车怎么办？这种特殊要求都是前端的事吧。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
q*c
发帖数: 9453 | 92 我看就是这原因。太邪恶了。
【在 s***o 的大作中提到】
: 钻风在瞎搞什么？骂的热火朝天的时候不管不问导致失控。现在这两位心平气和讨论具
: 体方案了，反而都给封了。是因为不打架就没流量吗？
|
i*****o
发帖数: 1714 | 93 靠，难道是我想错了？你们的约定是事先付款？
★ 发自iPhone App: ChineseWeb 8.6
【在 q*c 的大作中提到】
: 为啥，问题多了，你退票就有退票费啊，没退票费黄牛现在不是大爽。
: 交易交易，这种原子性必须的。我要是买了 10 张票最后一张没有，你叫我慢慢退，赔
: 大钱？浪费20倍时间？
|
L***n
发帖数: 6727 | 94 可能是mitbbs的latency，真烂
【在 s***o 的大作中提到】
: 钻风在瞎搞什么？骂的热火朝天的时候不管不问导致失控。现在这两位心平气和讨论具
: 体方案了，反而都给封了。是因为不打架就没流量吗？
|
q*c
发帖数: 9453 | 95 那当然，不然黄牛搞死你。
不过现在测试嘛，就当免费。
【在 i*****o 的大作中提到】
: 靠，难道是我想错了？你们的约定是事先付款？
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
i*****o
发帖数: 1714 | 96 好几天我都以为是先reserve票，再交钱，交钱的时候commit。
你们这样做对出票机的realibility要求提高的不是一点半点的啊！
★ 发自iPhone App: ChineseWeb 8.6
【在 q*c 的大作中提到】
: 那当然，不然黄牛搞死你。
: 不过现在测试嘛，就当免费。
|
q*c
发帖数: 9453 | 97 你那更高吧，要 rwserve, commit. 我们这里简化了直接 commit.
【在 i*****o 的大作中提到】
: 好几天我都以为是先reserve票，再交钱，交钱的时候commit。
: 你们这样做对出票机的realibility要求提高的不是一点半点的啊！
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
t**********1
发帖数: 550 | 98 啥要求都是合理的。我关心的是怎么算transaction。
不管啥牛逼数据库，写个运行半天的query都不是难事。
【在 q*c 的大作中提到】
: 你那更高吧，要 rwserve, commit. 我们这里简化了直接 commit.
|
i*****o
发帖数: 1714 | 99 问题是你这个commit没commit到db里，实在太危险了！
★ 发自iPhone App: ChineseWeb 8.6
【在 q*c 的大作中提到】
: 你那更高吧，要 rwserve, commit. 我们这里简化了直接 commit.
|
b*******g
发帖数: 603 | 100 是1M/2.2，最多两人，最多10%联票，worse case平均每单2.2张票。
transaction没有算内部操作的，要是oracle锁一个row算一个transaction, 那可就不
止10K tps了。
【在 q*c 的大作中提到】
: 算了老霸，他这就是把 1mm 最低变成 1mm/1.23
: 不是大问题。如果 aws 的机器都能这样，上牛逼机器就过线了。
: 你就 那 10% request 算两个或者四个算了。这各种最优出票，写 disk 保证能恢复，
: 不差这一点？
|
|
|
t**********1
发帖数: 550 | 101 我说了，算2个transaction就做，否则不做。
反正等着看热闹的多的是，你们看着办。。。
【在 b*******g 的大作中提到】
: 是1M/2.2，最多两人，最多10%联票，worse case平均每单2.2张票。
: transaction没有算内部操作的，要是oracle锁一个row算一个transaction, 那可就不
: 止10K tps了。
|
z*******3
发帖数: 13709 | 102 无赖阿
两个tran.毫无价值，该错时候还是错
明明是一个tran.
最重要的一个不做，还说啥呢？
【在 t**********1 的大作中提到】
: 我说了，算2个transaction就做，否则不做。
: 反正等着看热闹的多的是，你们看着办。。。
|
b*******g
发帖数: 603 | 103 爱做不做，整个thread都在提transaction没异议，到最后transaction变成ticket了。
LOL， 没常识害死人呀。
吹牛的是你，丢人的也是你。做不出来早说吧，死撑了这么久。
【在 t**********1 的大作中提到】
: 我说了，算2个transaction就做，否则不做。
: 反正等着看热闹的多的是，你们看着办。。。
|
b*******s
发帖数: 5216 | 104 看你们两个的新id，真好玩
【在 b*******g 的大作中提到】
: 爱做不做，整个thread都在提transaction没异议，到最后transaction变成ticket了。
: LOL， 没常识害死人呀。
: 吹牛的是你，丢人的也是你。做不出来早说吧，死撑了这么久。
|
b*******g
发帖数: 603 | 105 看到没，自己写的transaction id, 不是ticket id. 没常识害死人呀。
【在 T********i 的大作中提到】
: Goodbug提出的：
: 全国一盘棋。每天1000车次，每车次简化就20段，每车三种票，卧铺，硬座，站票，每
: 种1000张。上下铺什么的我就不跟你计较了。联票也是支持最多两张
: 就好，或者说一次转车。用户自选，也不用你算什么最短路径。但是每个车次的票号得
: 一样。
: 反正不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
: 响应并出票。
: qxc提出的协议
: 协议：
: 4 bytes transactionId
|
z*******3
发帖数: 13709 | 106 让前端负责会造成分布式事务
which是近乎无解的可能
从acid变成一个base
没有任何意义，连理论上的意义都不存在
直接扔掉transaction，上nosql
说白了，老魏要想装
tran.必需保证，否则就别玩了
最关键的就是tran.
【在 n******1 的大作中提到】
: 事务由前端负责？会不会更加复杂，起码在事务内的退票是可控的，如果不在同一个事
: 务里，你怎么标记哪一张成功了，应该退哪些？
: 事务的支持在oracle的第三版（1983年）已经支持
|
t**********1
发帖数: 550 | 107 你原帖没说。和你谈好1mm的条件时候也没说。
10%的联票也答应你了。
你不能得寸进尺。
这个在前端也不是不能做。凭啥非在后端做？
【在 b*******g 的大作中提到】
: 爱做不做，整个thread都在提transaction没异议，到最后transaction变成ticket了。
: LOL， 没常识害死人呀。
: 吹牛的是你，丢人的也是你。做不出来早说吧，死撑了这么久。
|
z*******3
发帖数: 13709 | 108 前端连这个都做了
你的这个就是纯粹的计数器了
毫无意义
【在 t**********1 的大作中提到】
: 你原帖没说。和你谈好1mm的条件时候也没说。
: 10%的联票也答应你了。
: 你不能得寸进尺。
: 这个在前端也不是不能做。凭啥非在后端做？
|
b*******g
发帖数: 603 | 109 啥没说，transaction id 不是你自己写的？你半路出家连啥叫transaction都不懂你怪
谁。
还前端能做，又要来distributed transaction了？
【在 t**********1 的大作中提到】
: 你原帖没说。和你谈好1mm的条件时候也没说。
: 10%的联票也答应你了。
: 你不能得寸进尺。
: 这个在前端也不是不能做。凭啥非在后端做？
|
i*****o
发帖数: 1714 | 110 你不停地加各种各样的transaction谁也没办法实现。
★ 发自iPhone App: ChineseWeb 8.6
【在 b*******g 的大作中提到】
: 啥没说，transaction id 不是你自己写的？你半路出家连啥叫transaction都不懂你怪
: 谁。
: 还前端能做，又要来distributed transaction了？
|
|
|
z*******3
发帖数: 13709 | 111 这不是不停的加
一个事务里面保证所有的执行都成功
不成功回滚
这是常识
如果真正做项目的话
我连transaction start point都可以自己控制
你要做这个么？
【在 i*****o 的大作中提到】
: 你不停地加各种各样的transaction谁也没办法实现。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
t**********1
发帖数: 550 | 112 transactionid是qxc写的。我只是照抄而已。
我们这里有性能指标。测的是特定条件下的性能。
和你谈条件的时候，是根据已知双方要求提出的性能指标。
你也答应了。事后变卦的是你不是我。这些都有帖子作证。
【在 b*******g 的大作中提到】
: 啥没说，transaction id 不是你自己写的？你半路出家连啥叫transaction都不懂你怪
: 谁。
: 还前端能做，又要来distributed transaction了？
|
b*******s
发帖数: 5216 | 113 这是个定性试验，没必要象他那样把具体的东西过多带进来
纯浪费
【在 t**********1 的大作中提到】
: transactionid是qxc写的。我只是照抄而已。
: 我们这里有性能指标。测的是特定条件下的性能。
: 和你谈条件的时候，是根据已知双方要求提出的性能指标。
: 你也答应了。事后变卦的是你不是我。这些都有帖子作证。
|
i**i
发帖数: 1500 | |
z*******3
发帖数: 13709 | 115 平常作项目
谁不用transaction阿？
是个网站就有这个东西
企业，web，谁都用，用烂掉了
这是常识
算了，想做计数器就明说
计数器定位太精确了
没有冤枉谁
【在 b*******s 的大作中提到】
: 这是个定性试验，没必要象他那样把具体的东西过多带进来
: 纯浪费
|
z*******3
发帖数: 13709 | 116 显然么
不难的话，谁看他吹牛的热闹
本来也不是什么容易的事
自己爱装
【在 i**i 的大作中提到】
: 大家都替对方想想, 老魏这头很难的.
|
i*****o
发帖数: 1714 | 117 我是不喜欢你后来加要求，有故意刁难的嫌疑。老魏好不容易jump了，这下又卡住了。
★ 发自iPhone App: ChineseWeb 8.6
【在 t**********1 的大作中提到】
: transactionid是qxc写的。我只是照抄而已。
: 我们这里有性能指标。测的是特定条件下的性能。
: 和你谈条件的时候，是根据已知双方要求提出的性能指标。
: 你也答应了。事后变卦的是你不是我。这些都有帖子作证。
|
b*******g
发帖数: 603 | 118 我没说容易呀，但吹牛说能做1m tps不是我对吧？早说不能做，我浪费这时间干啥？
我那系统，这样的单子1M/s就能接下不打折，这就是差距。
他要是承认做不了1M tps 努力一下做 450K tps, 大家可以再谈呀。
【在 i**i 的大作中提到】
: 大家都替对方想想, 老魏这头很难的.
|
t**********1
发帖数: 550 | 119 我最后一贴。
要么按照原先讲好的条件来。
要么重新评估指。
或者goodbug能做出100k以上的指标，不管用多少台机器都行，我都认输。
【在 b*******s 的大作中提到】
: 这是个定性试验，没必要象他那样把具体的东西过多带进来
: 纯浪费
|
z*******3
发帖数: 13709 | 120 天地良心，这个绝对不是后来加的
正常人都应该这么想
翻开transaction的定义
只会比这个更难，这个是最低级的要求
否则不要做transaction了
做一半的transaction做了干什么？
【在 i*****o 的大作中提到】
: 我是不喜欢你后来加要求，有故意刁难的嫌疑。老魏好不容易jump了，这下又卡住了。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
|
|
z*******3
发帖数: 13709 | 121 一个transaction变成两个transaction s
这个违背常理的，那你做transaction干什么？ |
b*******g
发帖数: 603 | 122 我那个能做1M tps不打折，不是实时系统。但是我从头就说不是实时的。我没装逼让人
赤裸裸打脸。
【在 t**********1 的大作中提到】
: 我最后一贴。
: 要么按照原先讲好的条件来。
: 要么重新评估指。
: 或者goodbug能做出100k以上的指标，不管用多少台机器都行，我都认输。
|
t**********1
发帖数: 550 | 123 正常人都应该想想自己连1/10都做不出来，加load是不是应该相应降低指标？
大家赌的是特定条件下的性能，又不是一个十全十美的系统。
【在 z*******3 的大作中提到】
: 天地良心，这个绝对不是后来加的
: 正常人都应该这么想
: 翻开transaction的定义
: 只会比这个更难，这个是最低级的要求
: 否则不要做transaction了
: 做一半的transaction做了干什么？
|
z*******3
发帖数: 13709 | 124 我认为大家赌的是一个12306的prototype
你要做计数器，我没话说
【在 t**********1 的大作中提到】
: 正常人都应该想想自己连1/10都做不出来，加load是不是应该相应降低指标？
: 大家赌的是特定条件下的性能，又不是一个十全十美的系统。
|
t**********1
发帖数: 550 | 125 装什么逼？
我的性能一直都建立在可以换坐的前提下。为了表示诚意才临时同意按照你的要求做的。
谈定了你后来又反悔涨猴儿。
你那个破烂谁都能做，我这个100k你能做出来么？
【在 b*******g 的大作中提到】
: 我那个能做1M tps不打折，不是实时系统。但是我从头就说不是实时的。我没装逼让人
: 赤裸裸打脸。
|
b*******g
发帖数: 603 | 126 做不出来别装逼呀，装逼了丢人现眼不是。有多少本事，说多少本事。
强实时宇宙第一的系统，在最基本的合理要求前不堪一击。
12306这么复杂的问题，我能设计一个系统，是个人都能做，就是很大的本事，比你那
个本事多了。
作架构不是装逼，你连基本transaction的概念都没有，还谈什么做架构。
的。
【在 t**********1 的大作中提到】
: 装什么逼？
: 我的性能一直都建立在可以换坐的前提下。为了表示诚意才临时同意按照你的要求做的。
: 谈定了你后来又反悔涨猴儿。
: 你那个破烂谁都能做，我这个100k你能做出来么？
|
t**********1
发帖数: 550 | 127 哦，你随便刁难，这我是做不出来。
条件谈好了，你提出新功能，导致出票数加一倍。这不是刁难是啥？
难道你提出票数加1000倍，我也要做？做不出也怪我？
我问你，事后反悔改条件的是你还是我？
为了自己能装逼，牺牲网友利益。你这种人，我不在你身上浪费时间也好。
【在 b*******g 的大作中提到】
: 做不出来别装逼呀，装逼了丢人现眼不是。有多少本事，说多少本事。
: 强实时宇宙第一的系统，在最基本的合理要求前不堪一击。
: 12306这么复杂的问题，我能设计一个系统，是个人都能做，就是很大的本事，比你那
: 个本事多了。
: 作架构不是装逼，你连基本transaction的概念都没有，还谈什么做架构。
:
: 的。
|
b*******g
发帖数: 603 | 128 我们从头到尾在谈transaction, 你不懂得什么叫transaction, 不能从一开始意识到
transaction的复杂性。
这叫你没常识，不叫做我刁难。事实上，我自己的1M 订单，我定得比这个更复杂。我
能做的，你做不了，这就是差距。
【在 t**********1 的大作中提到】
: 哦，你随便刁难，这我是做不出来。
: 条件谈好了，你提出新功能，导致出票数加一倍。这不是刁难是啥？
: 难道你提出票数加1000倍，我也要做？做不出也怪我？
: 我问你，事后反悔改条件的是你还是我？
: 为了自己能装逼，牺牲网友利益。你这种人，我不在你身上浪费时间也好。
|
t**********1
发帖数: 550 | 129 数据库测tpc都有确定的进程，这个意义上讲，不是所有的transaction都是那个T的。
条件讲好，才有指标。
条件变了，指标也要变。这个是常识懂不懂？
你后来加条件，可以，指标也要变。我也不是说不能做。没啥做不了的。只不过要调整
指标而已。
我们的差距是，你连我十分之一的性能都做不出来。
【在 b*******g 的大作中提到】
: 我们从头到尾在谈transaction, 你不懂得什么叫transaction, 不能从一开始意识到
: transaction的复杂性。
: 这叫你没常识，不叫做我刁难。事实上，我自己的1M 订单，我定得比这个更复杂。我
: 能做的，你做不了，这就是差距。
|
s*******y
发帖数: 851 | 130 就算2个好了，尽管是个马工都知道不对。还是先整出一哥能运行的系统最重要,细枝末
节可以再谈。
【在 b*******g 的大作中提到】
: 我们从头到尾在谈transaction, 你不懂得什么叫transaction, 不能从一开始意识到
: transaction的复杂性。
: 这叫你没常识，不叫做我刁难。事实上，我自己的1M 订单，我定得比这个更复杂。我
: 能做的，你做不了，这就是差距。
|
|
|
b*******g
发帖数: 603 | 131 不能算transaction, 可以算ticket.
【在 s*******y 的大作中提到】
: 就算2个好了，尽管是个马工都知道不对。还是先整出一哥能运行的系统最重要,细枝末
: 节可以再谈。
|
L*****e
发帖数: 8347 | 132 算统一意见了？能达到1mm tickets per second就算达到指标。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 b*******g 的大作中提到】
: 不能算transaction, 可以算ticket.
|
b*******g
发帖数: 603 | 133 不能算达到指标。我从第一天说的tps就是transaction的意思，我的系统能做到，他的
做不到，现在没有异议了。
在老魏承认做不到1M tps的前提下，我们可以看看他的系统能出多少票。
【在 L*****e 的大作中提到】
: 算统一意见了？能达到1mm tickets per second就算达到指标。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
n*****t
发帖数: 22014 | 134 买菜刚回来，我来提个建议
老魏不实现这个功能，指标提到 1.1
【在 b*******g 的大作中提到】
: 不能算达到指标。我从第一天说的tps就是transaction的意思，我的系统能做到，他的
: 做不到，现在没有异议了。
: 在老魏承认做不到1M tps的前提下，我们可以看看他的系统能出多少票。
|
