T********i
发帖数: 2416 | 1 goodbug和zhaoce都是输不起的。而且辩论的品格非常不好。本来不打算回应就算了。
之所以回应就是因为害怕谬种流传。很多不明真相的网友把谬误当作真理。当然也包括
这两位。
goodbug号称用cassandra方案解决我提出的春运售票问题。在我提出我的方案
performance的throughput比他的高1-2个数量级的情况下。他认为他的方案可靠性比我
的好。理由是能够同步写log到磁盘。在我提出用磁盘（磁盘是机械式的，SSD不是磁盘
，是基于半导体的）同步写每秒不到千的情况下，他给我一个链接和一张图。号称【
quote】写一个结点能到1000，写100个就可以接近10万。【quote】
我只能这种人的基本功连做一个普通程序员都不见得够格。如何能有人追捧他？看来公
共论坛水的嗓门大貌似水有理。
简单说一下：
1. 操作系统下普通的文件写操作一般是写到缓冲区，然后由OS schedule磁盘的写操作
。要强制flush缓冲区需要特殊API fsync。这个过程很费时，而且是blocking的。因为
普通磁盘的寻道时间都在5ms以上。IOPS(IO per second)不会很高。
2. 现在的SSD逐渐普及。有一些插卡型的SSD号称IOPS达到9 million。我认识一个朋友
就开了一家startup做通用的messaging系统。前几个月还看到他在blog上讨论他的team
优化SSD的事情。
3. 现在说到磁盘。goodbug号称写一个结点能到1000，写100个就可以接近10万。问题
是我的问题不适合分布式处理。不是一般性。假定我们就卖一种单程票。你goodbug用
cassandra一个节点1000TPS同步写磁盘。请问以怎么能用100个同步写同时还保持数据
一致性？一种单程票你都搞不定，凭什么说票种类多了你反倒搞定了？
4. SSD理论上可以做到内存性能的同步写。但是我仍然没兴趣。为什么？因为第一这东
西不是通用的commodity hardware。价格昂贵。我尽量不想我的系统对这东西有依赖性
。第二，其实根本没必要。在更高层business logic有很多更好的方法来保持灾难后的
数据一致性。
A） 写到磁盘到底比写到局域网内另外一台机器安全多少？答案基本半斤八两。写
磁盘确实能断电保存。但是现代数据中心每个rack都有UPS。这两者对于其他形式的物
理损害比如核爆的结果都一样。
B) 远程异步复制数据是必须的。其实transaction的大多数过程都能很好地分布。
毕竟保持session的概念就好了。这个session做成跨地区的就能保证数据一致性了。为
什么？比如前端的web服务器，中心数据库和后台交易数据库分别放在三个地方。任何
一个毁掉了，仅靠异步复制，就可以保证数据一致性。这就是所谓reconciliation
process。用网络协议大哥比方。底层协议可以是不可靠的。但是可以在上层通过高层
协议实现可靠。这个reconciliation process其实比灰烬里面扒硬盘可靠多了。这也是
我们为什么不在乎没要同步保持一致性的原因。真的出现灾难，能迅速从证交所得到我
们的交易记录。如果和证交所一起被nuke了，谁都没记录的交易算交易么？何况到那时
候，谁还在乎你的生意呢？
这个论坛上风起现在很不好。别的我就不多说了。反正输不起的会再来一轮人身攻击。
主要是给热心支持和希望严肃讨论的网友们一个交代。
http://www.datastax.com/dev/blog/2012-in-review-performance
当然是100%保持，如果你不知道cassandra是怎么工作，自己去读一读吧。
写一个结点能到1000，写100个就可以接近10万。
你丫就这点货，还有脸吹一个DB throughput秒杀Casandra。完全不懂得scale out怎么
回事。 |
p*****2
发帖数: 21240 | |
p*****2
发帖数: 21240 | 3 假定我们就卖一种单程票。你goodbug用
cassandra一个节点1000TPS同步写磁盘。请问以怎么能用100个同步写同时还保持数据
一致性？
一种单程票的剩余数量能不能分布式出去？ |
T********i
发帖数: 2416 | 4 你说呢？任何一个节点的状态的改变要同时可靠地复制到其他99个才叫同步。
这个goodbug脑袋一团浆糊。那个zhaoce还不如他。
【在 p*****2 的大作中提到】
: 假定我们就卖一种单程票。你goodbug用
: cassandra一个节点1000TPS同步写磁盘。请问以怎么能用100个同步写同时还保持数据
: 一致性？
: 一种单程票的剩余数量能不能分布式出去？
|
p*****2
发帖数: 21240 | 5
比如有个master是分布车票的，有很多slave是卖票的。slave从master拿票，然后卖，
卖完了再拿。这样slave之间就不需要做sync了。这个系统大了可以有hierarchy。
【在 T********i 的大作中提到】
: 你说呢？任何一个节点的状态的改变要同时可靠地复制到其他99个才叫同步。
: 这个goodbug脑袋一团浆糊。那个zhaoce还不如他。
|
m*******l
发帖数: 12782 | 6 顶魏老师
【在 T********i 的大作中提到】
: goodbug和zhaoce都是输不起的。而且辩论的品格非常不好。本来不打算回应就算了。
: 之所以回应就是因为害怕谬种流传。很多不明真相的网友把谬误当作真理。当然也包括
: 这两位。
: goodbug号称用cassandra方案解决我提出的春运售票问题。在我提出我的方案
: performance的throughput比他的高1-2个数量级的情况下。他认为他的方案可靠性比我
: 的好。理由是能够同步写log到磁盘。在我提出用磁盘（磁盘是机械式的，SSD不是磁盘
: ，是基于半导体的）同步写每秒不到千的情况下，他给我一个链接和一张图。号称【
: quote】写一个结点能到1000，写100个就可以接近10万。【quote】
: 我只能这种人的基本功连做一个普通程序员都不见得够格。如何能有人追捧他？看来公
: 共论坛水的嗓门大貌似水有理。
|
T********i
发帖数: 2416 | 7 卖多段相关票怎么办？
【在 p*****2 的大作中提到】
:
: 比如有个master是分布车票的，有很多slave是卖票的。slave从master拿票，然后卖，
: 卖完了再拿。这样slave之间就不需要做sync了。这个系统大了可以有hierarchy。
|
p*****2
发帖数: 21240 | 8
supervisor做统计。slave 卖了就通知supervisor
【在 T********i 的大作中提到】
: 卖多段相关票怎么办？
|
T********i
发帖数: 2416 | 9 不知道zhaoce和goodbug有没有那个知耻的勇气。
【在 m*******l 的大作中提到】
: 顶魏老师
|
m*******l
发帖数: 12782 | 10 上次吵架你是自杀ID, 还是被老邢杀的?
【在 T********i 的大作中提到】
: 不知道zhaoce和goodbug有没有那个知耻的勇气。
|
|
|
T********i
发帖数: 2416 | 11 supervisor的throughput你算算？
【在 p*****2 的大作中提到】
:
: supervisor做统计。slave 卖了就通知supervisor
|
p*****2
发帖数: 21240 | 12
我不是说分层吗？一个supervisor上边还可以有supervisor。保证每个supervisor可以
管理可管理数量的slave。
【在 T********i 的大作中提到】
: supervisor的throughput你算算？
|
T********i
发帖数: 2416 | 13 你这个思路卖多段相关性紧耦合的票性能还是比不上单机。因为distributed
transaction的开销比内存遍历有向图的开销高几个数量级。
【在 p*****2 的大作中提到】
:
: 我不是说分层吗？一个supervisor上边还可以有supervisor。保证每个supervisor可以
: 管理可管理数量的slave。
|
p*****2
发帖数: 21240 | 14
有可能。不过买票等个几秒钟也无所谓吧。甚至等个1分钟我觉得也能接受。
【在 T********i 的大作中提到】
: 你这个思路卖多段相关性紧耦合的票性能还是比不上单机。因为distributed
: transaction的开销比内存遍历有向图的开销高几个数量级。
|
N******K
发帖数: 10202 | 15 好 bbs讨论要坚持到底 不然就输了
【在 T********i 的大作中提到】
: goodbug和zhaoce都是输不起的。而且辩论的品格非常不好。本来不打算回应就算了。
: 之所以回应就是因为害怕谬种流传。很多不明真相的网友把谬误当作真理。当然也包括
: 这两位。
: goodbug号称用cassandra方案解决我提出的春运售票问题。在我提出我的方案
: performance的throughput比他的高1-2个数量级的情况下。他认为他的方案可靠性比我
: 的好。理由是能够同步写log到磁盘。在我提出用磁盘（磁盘是机械式的，SSD不是磁盘
: ，是基于半导体的）同步写每秒不到千的情况下，他给我一个链接和一张图。号称【
: quote】写一个结点能到1000，写100个就可以接近10万。【quote】
: 我只能这种人的基本功连做一个普通程序员都不见得够格。如何能有人追捧他？看来公
: 共论坛水的嗓门大貌似水有理。
|
g*****g
发帖数: 34805 | 16 你丫也有脸谈基本功，你丢人要丢人多少次才够？我说的Cassandra是用来接受客户订
单的。
客户订单每个都是独立的，又没有锁。如果每个结点1000 tps，100个结点为啥不能做
到10万次每秒的写？
后台处理余票的数据库，我用的是传统数据库。我说了每车次每天只要每天处理一万次的
写就够了，所以哪怕把所有车次放在一块，也就一千万次而已，对于后台处理不需要
low latency的，完全够用。我说了多少遍了，用户是不直接hit余票数据库的，这个是
个异步的处理。用多少个线程，数据库怎么分，都是可控的。如果只卖一种票，难道还
不能分成10个，每个卖1/10的票。
反过来，你的单机撑不住10万/秒的订单，难道内存数据库也敢用？一断电，几百万的
订单就丢了。谁
敢用？
【在 T********i 的大作中提到】
: goodbug和zhaoce都是输不起的。而且辩论的品格非常不好。本来不打算回应就算了。
: 之所以回应就是因为害怕谬种流传。很多不明真相的网友把谬误当作真理。当然也包括
: 这两位。
: goodbug号称用cassandra方案解决我提出的春运售票问题。在我提出我的方案
: performance的throughput比他的高1-2个数量级的情况下。他认为他的方案可靠性比我
: 的好。理由是能够同步写log到磁盘。在我提出用磁盘（磁盘是机械式的，SSD不是磁盘
: ，是基于半导体的）同步写每秒不到千的情况下，他给我一个链接和一张图。号称【
: quote】写一个结点能到1000，写100个就可以接近10万。【quote】
: 我只能这种人的基本功连做一个普通程序员都不见得够格。如何能有人追捧他？看来公
: 共论坛水的嗓门大貌似水有理。
|
g*****g
发帖数: 34805 | 17 魏老师一脑子的浆糊，非要把客户下订单和订单处理放在同一个数据库里。
从丢人走向更丢人是不奇怪的。整个scalability的要素，本来就是把需要
transaction的数据单独拿出来，把不需要的拿到RDBMS外面去。再把
RDMBS根据数据耦合度尽量细分。
我老解释了这半天，魏老师连客户订单这个东西，不需要在RDBMS里都没弄明白，
踩他也实在没意思。实在连基础知识都没掌握。 |
z****e
发帖数: 54598 | 18 啥？我输不起？
你就回答一个最基本的问题
你到底打算解决什么问题
你原帖标题和首段首句都是订票网站
你自己看看你说了有半点web server的东西么？
要不你说说web server负载最重的是哪块？
【在 T********i 的大作中提到】
: goodbug和zhaoce都是输不起的。而且辩论的品格非常不好。本来不打算回应就算了。
: 之所以回应就是因为害怕谬种流传。很多不明真相的网友把谬误当作真理。当然也包括
: 这两位。
: goodbug号称用cassandra方案解决我提出的春运售票问题。在我提出我的方案
: performance的throughput比他的高1-2个数量级的情况下。他认为他的方案可靠性比我
: 的好。理由是能够同步写log到磁盘。在我提出用磁盘（磁盘是机械式的，SSD不是磁盘
: ，是基于半导体的）同步写每秒不到千的情况下，他给我一个链接和一张图。号称【
: quote】写一个结点能到1000，写100个就可以接近10万。【quote】
: 我只能这种人的基本功连做一个普通程序员都不见得够格。如何能有人追捧他？看来公
: 共论坛水的嗓门大貌似水有理。
|
m******t
发帖数: 635 | 19 看你提过几次断电的问题，比较奇怪，难道这个还是问题吗？不是有UPS加备用电源么
，真要是十年前美东那样大面积停电，那也是小概率事件啊。
订单就丢了。谁敢用？
【在 g*****g 的大作中提到】
: 魏老师一脑子的浆糊，非要把客户下订单和订单处理放在同一个数据库里。
: 从丢人走向更丢人是不奇怪的。整个scalability的要素，本来就是把需要
: transaction的数据单独拿出来，把不需要的拿到RDBMS外面去。再把
: RDMBS根据数据耦合度尽量细分。
: 我老解释了这半天，魏老师连客户订单这个东西，不需要在RDBMS里都没弄明白，
: 踩他也实在没意思。实在连基础知识都没掌握。
|
T********i
发帖数: 2416 | 20 客户订单是独立的，可以并行分布到100台处理每秒10万次写。
后台处理余票的数据库，你说用的是传统数据库。难道每个订单余票数据库不需要写至少
一次？你还是给我说说每秒10万订单触发的数据库每秒10万次写咋做吧？咱们谈的不就是
这个数据库咋做么？独立的客户订单分布管理我没兴趣。
一脑子浆糊！
次的
【在 g*****g 的大作中提到】
: 你丫也有脸谈基本功，你丢人要丢人多少次才够？我说的Cassandra是用来接受客户订
: 单的。
: 客户订单每个都是独立的，又没有锁。如果每个结点1000 tps，100个结点为啥不能做
: 到10万次每秒的写？
: 后台处理余票的数据库，我用的是传统数据库。我说了每车次每天只要每天处理一万次的
: 写就够了，所以哪怕把所有车次放在一块，也就一千万次而已，对于后台处理不需要
: low latency的，完全够用。我说了多少遍了，用户是不直接hit余票数据库的，这个是
: 个异步的处理。用多少个线程，数据库怎么分，都是可控的。如果只卖一种票，难道还
: 不能分成10个，每个卖1/10的票。
: 反过来，你的单机撑不住10万/秒的订单，难道内存数据库也敢用？一断电，几百万的
|
|
|
g*****g
发帖数: 34805 | 21 小概率事件归小概率事件，你要看到发生了出的问题有多大。你听说过有任何金钱相关
的应用用in memory DB的吗？有点common sense好不好？
【在 m******t 的大作中提到】
: 看你提过几次断电的问题，比较奇怪，难道这个还是问题吗？不是有UPS加备用电源么
: ，真要是十年前美东那样大面积停电，那也是小概率事件啊。
:
: 订单就丢了。谁敢用？
|
z****e
发帖数: 54598 | 22 老魏，你还记得1－2ms内响应这个承诺么？
还有1-2万预算的承诺么？
你貌似越加越多东西啊，这样搞不行啊
项目会失败的，你一直在追加项目成本啊
至少
就是
【在 T********i 的大作中提到】
: 客户订单是独立的，可以并行分布到100台处理每秒10万次写。
: 后台处理余票的数据库，你说用的是传统数据库。难道每个订单余票数据库不需要写至少
: 一次？你还是给我说说每秒10万订单触发的数据库每秒10万次写咋做吧？咱们谈的不就是
: 这个数据库咋做么？独立的客户订单分布管理我没兴趣。
: 一脑子浆糊！
:
: 次的
|
T********i
发帖数: 2416 | 23 你要是还有一点脸的话。就把我的原贴翻出来。
看看我说1-2ms内响应是指哪两台机器间的通信。
还有我何时说过预算1-2万的话？
为了造谣脸都不要了。品性这么恶劣真不知道什么样的爹妈生养出来的。
【在 z****e 的大作中提到】
: 老魏，你还记得1－2ms内响应这个承诺么？
: 还有1-2万预算的承诺么？
: 你貌似越加越多东西啊，这样搞不行啊
: 项目会失败的，你一直在追加项目成本啊
:
: 至少
: 就是
|
m******t
发帖数: 635 | 24 你的分布式系统也不能保证万无一失吧，都是trade off而已
【在 g*****g 的大作中提到】
: 小概率事件归小概率事件，你要看到发生了出的问题有多大。你听说过有任何金钱相关
: 的应用用in memory DB的吗？有点common sense好不好？
|
g*****g
发帖数: 34805 | 25 你怎么这么弱智呀。订单的数目远远大于票数。订单写到Cassandra里。处理订单的模块
又不是在线处理的，Cassandra每秒写10万订单，处理订单的模块不需要处理每秒10万
订单。
传统数据库最多最多也不过要写票的数目罢了，让你1000条线* 1万张票，一天也不过
1000万
次写。这1千万次写是由订单处理模块触发的，速度完全可控。票卖没了，后面的订单
，自然直接
杀掉，回写Cassandra DB标志位也好，发email通知也好，不会碰到传统数据库
且不提种种数据划分都可以降低每个独立系统需要处理的订单数目，远不如1千万张。
尼玛一个东西，说了这么多次都不上道，理解能力太低了吧。
至少
就是
【在 T********i 的大作中提到】
: 客户订单是独立的，可以并行分布到100台处理每秒10万次写。
: 后台处理余票的数据库，你说用的是传统数据库。难道每个订单余票数据库不需要写至少
: 一次？你还是给我说说每秒10万订单触发的数据库每秒10万次写咋做吧？咱们谈的不就是
: 这个数据库咋做么？独立的客户订单分布管理我没兴趣。
: 一脑子浆糊！
:
: 次的
|
z****e
发帖数: 54598 | 26 hot standby是你先说的？
你敢说你没说过单机？
好像别人给你擦了不少屁股啊
你不是不挑机器么？怎么现在又在不停地增加各种预算？
1－2万行代码也是你说的
还有udp协议，我听了就跪了，您老太牛了
连网游都做不好啊
【在 T********i 的大作中提到】
: 你要是还有一点脸的话。就把我的原贴翻出来。
: 看看我说1-2ms内响应是指哪两台机器间的通信。
: 还有我何时说过预算1-2万的话？
: 为了造谣脸都不要了。品性这么恶劣真不知道什么样的爹妈生养出来的。
|
p*****2
发帖数: 21240 | 27
靠。还真是10年前呀。
【在 m******t 的大作中提到】
: 看你提过几次断电的问题，比较奇怪，难道这个还是问题吗？不是有UPS加备用电源么
: ，真要是十年前美东那样大面积停电，那也是小概率事件啊。
:
: 订单就丢了。谁敢用？
|
g*****g
发帖数: 34805 | 28 没有万无一失，但是出了事是不可能丢几百万订单这种事。下的了单子总归还在硬盘上，
最多网站当了不继续接受订单罢了。
【在 m******t 的大作中提到】
: 你的分布式系统也不能保证万无一失吧，都是trade off而已
|
z****e
发帖数: 54598 | 29 魏老师的单机走向分布式是被逼的
一开始没想那么远
【在 m******t 的大作中提到】
: 你的分布式系统也不能保证万无一失吧，都是trade off而已
|
T********i
发帖数: 2416 | 30 我说的是可以单机处理，剩下的是打酱油用的。不服你把我的原贴找出来。
你这个人没教养。说实话我瞧不起你爹妈。
【在 z****e 的大作中提到】
: hot standby是你先说的？
: 你敢说你没说过单机？
: 好像别人给你擦了不少屁股啊
: 你不是不挑机器么？怎么现在又在不停地增加各种预算？
: 1－2万行代码也是你说的
: 还有udp协议，我听了就跪了，您老太牛了
: 连网游都做不好啊
|
|
|
z****e
发帖数: 54598 | 31 那就是hot standby不是必需了是不是这个意思？
不要扭扭捏捏，说话说一半半，搞得别人总给你擦屁股
没意思，还不愿意承认
【在 T********i 的大作中提到】
: 我说的是可以单机处理，剩下的是打酱油用的。不服你把我的原贴找出来。
: 你这个人没教养。说实话我瞧不起你爹妈。
|
g*****g
发帖数: 34805 | 32 问题是你丫单机处理不了10万次/秒的订单。你躲来躲去，先把这个问题解决了好不好？
你提内存数据库不是认真的吧？你那些stock exchange，哪个使用内存数据库的你举个
例子我就服。
【在 T********i 的大作中提到】
: 我说的是可以单机处理，剩下的是打酱油用的。不服你把我的原贴找出来。
: 你这个人没教养。说实话我瞧不起你爹妈。
|
m******t
发帖数: 635 | 33 你们前面得讨论我没有跟，不过魏老师那个单机方案应该还是比较粗略得设计，完全可
以建个local的cluster，一拨queue进来的订单，一拨queue处理后的单子，这两个
cluster应该可以把对硬盘写的压力给分散掉，可能最后的方案是你们两个的折衷也未
可知。
上，
【在 g*****g 的大作中提到】
: 没有万无一失，但是出了事是不可能丢几百万订单这种事。下的了单子总归还在硬盘上，
: 最多网站当了不继续接受订单罢了。
|
T********i
发帖数: 2416 | 34 打酱油就是在旁边看着。你咋不说standby也是旁边看不是必须呢？有意思么？爹妈咋
教育的？
【在 z****e 的大作中提到】
: 那就是hot standby不是必需了是不是这个意思？
: 不要扭扭捏捏，说话说一半半，搞得别人总给你擦屁股
: 没意思，还不愿意承认
|
g*****g
发帖数: 34805 | 35 别折衷了行不行，Cassandra线性scale out是公认的事实。现有的成熟方案不用，
弄来弄去不得已弄个山寨版的，早干嘛去了。
【在 m******t 的大作中提到】
: 你们前面得讨论我没有跟，不过魏老师那个单机方案应该还是比较粗略得设计，完全可
: 以建个local的cluster，一拨queue进来的订单，一拨queue处理后的单子，这两个
: cluster应该可以把对硬盘写的压力给分散掉，可能最后的方案是你们两个的折衷也未
: 可知。
:
: 上，
|
z****e
发帖数: 54598 | 36 不好意思，魏老师，我爹妈教育我不要说大话
不要给别人带去麻烦，自己把自己的事做好，不要给别人制造不必要的麻烦
不象你，总是要别人给你擦屁股
【在 T********i 的大作中提到】
: 打酱油就是在旁边看着。你咋不说standby也是旁边看不是必须呢？有意思么？爹妈咋
: 教育的？
|
z****e
发帖数: 54598 | 37 魏老师，你知道现实中，95％的事其实都是很繁琐琐碎的事不？
谁不想只做那5％啊，我写个ejb，定义一下输入输出，然后写那么十行不到的处理逻辑
你把剩下的全搞定，那你就是打酱油的了，对不？
回到最初的问题，scope是什么？你先定义你的scope
【在 T********i 的大作中提到】
: 打酱油就是在旁边看着。你咋不说standby也是旁边看不是必须呢？有意思么？爹妈咋
: 教育的？
|
h*****a
发帖数: 1718 | 38 顶这个，数据和app的nodes还是要分开的。数据的scalability要通过sharding来解决
，这个goodbug也提了。
【在 p*****2 的大作中提到】
:
: 靠。还真是10年前呀。
|
z***e
发帖数: 5393 | 39 看了半天，觉得。。。好虫讲的比较有道理。。。因为。。。
那个为老师扯啥ssd读写我看不懂关订票系统scalability啥事。。。好虫写的我看得懂
。。。 |
