T********i
发帖数: 2416 | 1 源代码不可能给你，binary给你。
而且还带实时写盘。你事后可以核对检验，不可能赖皮的。
做出来怎么办？ |
w***g
发帖数: 5958 | 2 不少人已经知道你很牛了，我觉得你做出来也不能怎么办。难道还有人愿意出钱给你？
【在 T********i 的大作中提到】
: 源代码不可能给你，binary给你。
: 而且还带实时写盘。你事后可以核对检验，不可能赖皮的。
: 做出来怎么办？
|
T********i
发帖数: 2416 | 3 我觉得我们应该给goodbug之流一个闭关学习的机会。
给zhaoce一个到其他地方全堆忽悠的机会。
给年轻人一个避免被这些人误导的机会。
【在 w***g 的大作中提到】
: 不少人已经知道你很牛了，我觉得你做出来也不能怎么办。难道还有人愿意出钱给你？
|
q*c
发帖数: 9453 | 4 我相信你的计数器能做到这么快，但是我不相信一个带写盘的完整服务器能这么快。
可是我没做过 socket based transaction, 所以我不能和你赌。 要我赌，你就得上
acid, 数据库支持的那些性能，断电丢包恢复什么的。
你有 binary 也行，我给你开机器，你给我个界面我来学习学习？ tcp based? 给个配
置文件什么的，启动的时候好控制车次票样数量。别 hard coded
【在 T********i 的大作中提到】
: 源代码不可能给你，binary给你。
: 而且还带实时写盘。你事后可以核对检验，不可能赖皮的。
: 做出来怎么办？
|
i*****o
发帖数: 1714 | 5 你没明白他的设计，或者我不明白？
反正我觉得他这个东西死就死了，重启就是，根本不用persist任何东西。所有的出票
，退票都是前端在做。
★ 发自iPhone App: ChineseWeb 8.6
【在 q*c 的大作中提到】
: 我相信你的计数器能做到这么快，但是我不相信一个带写盘的完整服务器能这么快。
: 可是我没做过 socket based transaction, 所以我不能和你赌。 要我赌，你就得上
: acid, 数据库支持的那些性能，断电丢包恢复什么的。
: 你有 binary 也行，我给你开机器，你给我个界面我来学习学习？ tcp based? 给个配
: 置文件什么的，启动的时候好控制车次票样数量。别 hard coded
|
l*********s
发帖数: 5409 | 6 en, all mouse gun; who will be childish enough to bet with real money?
【在 w***g 的大作中提到】
: 不少人已经知道你很牛了，我觉得你做出来也不能怎么办。难道还有人愿意出钱给你？
|
g*****g
发帖数: 34805 | 7 不persist任何东西就可能超卖。太监是试图多DC内存数据库备份。
【在 i*****o 的大作中提到】
: 你没明白他的设计，或者我不明白？
: 反正我觉得他这个东西死就死了，重启就是，根本不用persist任何东西。所有的出票
: ，退票都是前端在做。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
T********i
发帖数: 2416 | 8 ACID是要同步写盘的。
你肯出钱买一块最新的FusionIO + SDK，我就给你ACID的。
搞两台机器也行。但是你只能搞死一台。你忙我也忙，你搞死一台我可以毫秒级恢复。
但是死掉那台的rejoin就不给你做了。反正让你看到这个意思就好了。你要我提供全套
服务，我的hourly rate你付不起。
两台机器就不是ACID了。而是BASE。上的都做不到的事情，我没必要吹牛。
【在 q*c 的大作中提到】
: 我相信你的计数器能做到这么快，但是我不相信一个带写盘的完整服务器能这么快。
: 可是我没做过 socket based transaction, 所以我不能和你赌。 要我赌，你就得上
: acid, 数据库支持的那些性能，断电丢包恢复什么的。
: 你有 binary 也行，我给你开机器，你给我个界面我来学习学习？ tcp based? 给个配
: 置文件什么的，启动的时候好控制车次票样数量。别 hard coded
|
T********i
发帖数: 2416 | 9 ACID是要同步写盘的。
你肯出钱买一块最新的FusionIO + SDK，我就给你ACID的。
搞两台机器也行。但是你只能搞死一台。你忙我也忙，你搞死一台我可以毫秒级恢复。
但是死掉那台的rejoin就不给你做了。反正让你看到这个意思就好了。你要我提供全套
服务，我的hourly rate你付不起。
两台机器就不是ACID了。而是BASE。上的都做不到的事情，我没必要吹牛。
【在 q*c 的大作中提到】
: 我相信你的计数器能做到这么快，但是我不相信一个带写盘的完整服务器能这么快。
: 可是我没做过 socket based transaction, 所以我不能和你赌。 要我赌，你就得上
: acid, 数据库支持的那些性能，断电丢包恢复什么的。
: 你有 binary 也行，我给你开机器，你给我个界面我来学习学习？ tcp based? 给个配
: 置文件什么的，启动的时候好控制车次票样数量。别 hard coded
|
i*****o
发帖数: 1714 | 10 没必要啊，重启的时候让前端的机器们各自报个数就好了。
★ 发自iPhone App: ChineseWeb 8.6
【在 g*****g 的大作中提到】
: 不persist任何东西就可能超卖。太监是试图多DC内存数据库备份。
|
|
|
q*c
发帖数: 9453 | 11 没仔细看， 不过要是抢票起抢到了票， 但是反馈给下游出票服务器的时候包丢了，
咋办？ 这票不久没了嘛？ 计数器加上了， 但是票没出。
如果交易整段时间里面抢票起都锁定等待确认， 那系统就完了。
【在 i*****o 的大作中提到】
: 你没明白他的设计，或者我不明白？
: 反正我觉得他这个东西死就死了，重启就是，根本不用persist任何东西。所有的出票
: ，退票都是前端在做。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
g*****g
发帖数: 34805 | 12 那你这就是很大的downtime了。没有HA。
【在 i*****o 的大作中提到】
: 没必要啊，重启的时候让前端的机器们各自报个数就好了。
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
g*****g
发帖数: 34805 | 13 nickmit说是抢票服务器要等确认，问题是前端确认，票出给用户了，结果包丢了没回
到抢票服
务器
上，抢票服务器reset，票重卖了。
没transaction，这就是个无底洞。
【在 q*c 的大作中提到】
: 没仔细看， 不过要是抢票起抢到了票， 但是反馈给下游出票服务器的时候包丢了，
: 咋办？ 这票不久没了嘛？ 计数器加上了， 但是票没出。
: 如果交易整段时间里面抢票起都锁定等待确认， 那系统就完了。
|
c****3
发帖数: 10787 | 14 他用TCP，所以除非服务器或者程序出毛病了，一般情况下包丢不了。
不过为了保证数据库票数和计数器一致，别的程序更改数据库的票，必须先去更改计数
器，这个很讨厌，觉得很麻烦，但也不是不可以做到。
【在 g*****g 的大作中提到】
: nickmit说是抢票服务器要等确认，问题是前端确认，票出给用户了，结果包丢了没回
: 到抢票服
: 务器
: 上，抢票服务器reset，票重卖了。
: 没transaction，这就是个无底洞。
|
g*****g
发帖数: 34805 | 15 你没做过大规模网站吧，机器当是天天出现的事情。我们的做法就是non peak hour主
动用chaos monkey在产品环境里随机杀instance，确保各种问题早出现，出现的时候影
响小。而不是指望机器不当。
【在 c****3 的大作中提到】
: 他用TCP，所以除非服务器或者程序出毛病了，一般情况下包丢不了。
: 不过为了保证数据库票数和计数器一致，别的程序更改数据库的票，必须先去更改计数
: 器，这个很讨厌，觉得很麻烦，但也不是不可以做到。
|
c****3
发帖数: 10787 | 16 要做到能够应付复杂网络环境，魏的设计肯定还要改不少细节。比如魏说其他程序更改
数据库，票数变化要发admin message。这种message肯定要有优先级，不能跟在其他
message后面排队，否则会出问题。
不过这里不就是为了proof of concept。
【在 g*****g 的大作中提到】
: 你没做过大规模网站吧，机器当是天天出现的事情。我们的做法就是non peak hour主
: 动用chaos monkey在产品环境里随机杀instance，确保各种问题早出现，出现的时候影
: 响小。而不是指望机器不当。
|
g*****g
发帖数: 34805 | 17 架构如果是scale out的，实现上的诸多复杂细节都可以慢慢考虑。最多不过单机慢点
，多堆机器。
如果不是scale out，所有这些都直接影响了单机瓶颈，你没法随便简化呀。
【在 c****3 的大作中提到】
: 要做到能够应付复杂网络环境，魏的设计肯定还要改不少细节。比如魏说其他程序更改
: 数据库，票数变化要发admin message。这种message肯定要有优先级，不能跟在其他
: message后面排队，否则会出问题。
: 不过这里不就是为了proof of concept。
|
q*c
发帖数: 9453 | 18 细节是魔鬼啊。
我没看， 就是那个计数器要和外围一堆交易数据库完全一致， 这个就是 distributed
transaction, 不知道他咋能保证， 而且 5MM tps.
【在 c****3 的大作中提到】
: 要做到能够应付复杂网络环境，魏的设计肯定还要改不少细节。比如魏说其他程序更改
: 数据库，票数变化要发admin message。这种message肯定要有优先级，不能跟在其他
: message后面排队，否则会出问题。
: 不过这里不就是为了proof of concept。
|
w**z
发帖数: 8232 | 19 强烈要求上代码！！！
distributed
【在 q*c 的大作中提到】
: 细节是魔鬼啊。
: 我没看， 就是那个计数器要和外围一堆交易数据库完全一致， 这个就是 distributed
: transaction, 不知道他咋能保证， 而且 5MM tps.
|
c****3
发帖数: 10787 | 20 所以为了保证可靠性，最好还有个程序在外围，不停比较计数器和数据库票数的差别，
发admin消息，或改数据库纠正可能的错误。admin 消息要有优先级，为了不阻塞，最
好走另一个网卡。
总之计数器虽然简单，外围感觉很复杂，有相当多的工作量。不过计数器确实把这个特
定情况下，数据库锁的瓶颈给转移出去了。
【在 g*****g 的大作中提到】
: 架构如果是scale out的，实现上的诸多复杂细节都可以慢慢考虑。最多不过单机慢点
: ，多堆机器。
: 如果不是scale out，所有这些都直接影响了单机瓶颈，你没法随便简化呀。
|
|
|
q*c
发帖数: 9453 | 21 你这办法都是不行， 根本上的问题就是 distributed transaction
你无论怎么打布丁， 总有各种变态问题出现。
数据库的锁为什么是瓶颈？就是为了 transaction. 不然为什么oracle 这么多年， 这
么多钱人力， 常用的数据库才 10k tps 而不是 5MM? 你把这个根本的东西去了， 然
后说我够快， 就是外围复杂。。。。你最后为了保证正确性， 满足 transaction, 还
是和数据库的
锁一样。还没人家做的好。
如果 oracle 不管 transaction, 我看保证比老魏的东西快， 就凭人家这么多年的惊
艳， 无数高手在里面。
【在 c****3 的大作中提到】
: 所以为了保证可靠性，最好还有个程序在外围，不停比较计数器和数据库票数的差别，
: 发admin消息，或改数据库纠正可能的错误。admin 消息要有优先级，为了不阻塞，最
: 好走另一个网卡。
: 总之计数器虽然简单，外围感觉很复杂，有相当多的工作量。不过计数器确实把这个特
: 定情况下，数据库锁的瓶颈给转移出去了。
|
w**z
发帖数: 8232 | 22 问题是那本来就不是瓶颈。 这票应该不难shard的。再看看古德霸德方案？
http://www.mitbbs.com/article/Programming/31281313_0.html
我觉得全国一盘棋本身是一个错误的design
【在 c****3 的大作中提到】
: 所以为了保证可靠性，最好还有个程序在外围，不停比较计数器和数据库票数的差别，
: 发admin消息，或改数据库纠正可能的错误。admin 消息要有优先级，为了不阻塞，最
: 好走另一个网卡。
: 总之计数器虽然简单，外围感觉很复杂，有相当多的工作量。不过计数器确实把这个特
: 定情况下，数据库锁的瓶颈给转移出去了。
|
c****3
发帖数: 10787 | 23 是瓶颈啊，原来抢票，不管能抢到还是不能抢到，都要锁住整个数据库，数据库操作涉
及IO很慢，拖慢了整个系统。
魏的设计，把抢票这个过程，简化成计数器，抢到就好，其他操作后做，抢不到的人不
会去操作数据库。
本来就是proof of concept，就看细节有啥致命问题。
【在 w**z 的大作中提到】
: 问题是那本来就不是瓶颈。 这票应该不难shard的。再看看古德霸德方案？
: http://www.mitbbs.com/article/Programming/31281313_0.html
: 我觉得全国一盘棋本身是一个错误的design
|
g*****g
发帖数: 34805 | 24 这里唯一能提高的不是distributed transaction，而是像12306那样上gemfire做内存
数据库。
即使真能做，自己写一个gemfire不得做好几年的。12306推迟3年上马？
【在 q*c 的大作中提到】
: 你这办法都是不行， 根本上的问题就是 distributed transaction
: 你无论怎么打布丁， 总有各种变态问题出现。
: 数据库的锁为什么是瓶颈？就是为了 transaction. 不然为什么oracle 这么多年， 这
: 么多钱人力， 常用的数据库才 10k tps 而不是 5MM? 你把这个根本的东西去了， 然
: 后说我够快， 就是外围复杂。。。。你最后为了保证正确性， 满足 transaction, 还
: 是和数据库的
: 锁一样。还没人家做的好。
: 如果 oracle 不管 transaction, 我看保证比老魏的东西快， 就凭人家这么多年的惊
: 艳， 无数高手在里面。
|
g*****g
发帖数: 34805 | 25 他不写盘，要网络备份，光这个细节就很致命了。你自己想想看写个gemfire要多久。
【在 c****3 的大作中提到】
: 是瓶颈啊，原来抢票，不管能抢到还是不能抢到，都要锁住整个数据库，数据库操作涉
: 及IO很慢，拖慢了整个系统。
: 魏的设计，把抢票这个过程，简化成计数器，抢到就好，其他操作后做，抢不到的人不
: 会去操作数据库。
: 本来就是proof of concept，就看细节有啥致命问题。
|
q*c
发帖数: 9453 | 26 我是说老魏那种计数器和外围数据库混合使用， 是 distributed transaction.
整在一个里面自然就没有了。
【在 g*****g 的大作中提到】
: 这里唯一能提高的不是distributed transaction，而是像12306那样上gemfire做内存
: 数据库。
: 即使真能做，自己写一个gemfire不得做好几年的。12306推迟3年上马？
|
c****3
发帖数: 10787 | 27 要稳定工作，工作量是不少。不过他这是home brew的设计，就为这个特定需求。这不
像通用平台，很多情况他可以不考虑，相应能简化不少。
【在 g*****g 的大作中提到】
: 他不写盘，要网络备份，光这个细节就很致命了。你自己想想看写个gemfire要多久。
|
g*****g
发帖数: 34805 | 28 distributed transaction是没可能做5M的。
【在 q*c 的大作中提到】
: 我是说老魏那种计数器和外围数据库混合使用， 是 distributed transaction.
: 整在一个里面自然就没有了。
|
w**z
发帖数: 8232 | 29 这个瓶颈是他自己想出来的，号称非要全国一盘棋。把DB shard 一下不就结了？
【在 c****3 的大作中提到】
: 是瓶颈啊，原来抢票，不管能抢到还是不能抢到，都要锁住整个数据库，数据库操作涉
: 及IO很慢，拖慢了整个系统。
: 魏的设计，把抢票这个过程，简化成计数器，抢到就好，其他操作后做，抢不到的人不
: 会去操作数据库。
: 本来就是proof of concept，就看细节有啥致命问题。
|
T********i
发帖数: 2416 | 30 你们都要好好学习我的帖子。
外围数据库就是一个slave，也是异步写的。
就是给领导看着玩的行不行？其实啥作用都不起。
你们说这种应用内存数据库啥干不了？ |
