f****4
发帖数: 1359 | 1 讨论设计方案，必须有个背景才有意义。这个卖春运火车票的网站就是个很不错的例子。
比较方案的时候，可行性是根本，都可行的情况下考虑成本。可行性里面需要考虑到
performance，availability,scalability，工期还有系统的复杂度。这些都是讨论的
基础，你不能简单的说“你这方案比scalability比不上分布式，比响应比不上硬实时
系统”。没有方案是完美的，我们现在只是在给定的案例下面讨论两个不同的实现。如
果背离这个约定，那就又成为毫无意义的口水帖了。
因为有些人根本不仔细看别人帖子，我把2个不同方案的实现，大家提及的疑问及解答
，按照我的理解复述一下，也请魏老师和goodbug指正。当然了，我主要复述一下魏老
师的方案，毕竟分布式的大家多少都了解一点。
主机配置，4个10G/s网卡，全双工80G/s，对CPUS没特殊要求，内存没提，不过现在服
务器上到90+CPUS，36+G内存也就是5万美金，魏老师声称1万的主机还算靠谱。
魏老师在后面的帖子针对availability的问题提到了hot standby server，3zone，多
hot standby 的方案是有的。并且多zone同步的时候可以有2个选择，一个选择是简单
同步主机状态：用来查询是否有车票的向量图。这个选择的好处是同步压力不大，可做
增量同步；坏处就是全双工网卡的数据丢失。还有一个选择是failover的时候同步主机
状态，4个网卡的数据必须是一直同步的。这样才能实现failover之后无缝switch。但
这个选择难在网卡收到的数据请求必须是顺序一致的。比如说main主机上订票请求1,2,
3；standby上收到的请求也必须是1，2，3.因为这个顺序决定了买票的优先次序。这个
选择的解决方案必然增加系统复杂度和成本。（魏老师能否抛个砖？我以前公司的方案
支持美洲，亚洲，欧洲3地1G/s的同步。然后这部分他们申请到了3，4个专利 -_- 我只
能说，这部分就是能实现，复杂度和成本可能都不是线性增加的）
魏老师的主机实现
==================================
1. 查询:
输入： Route List + Constraint filter (时间段， 座位等级 etc)
输出： 没票：
或者有票： 每节点班次和剩余座位数
2. 订票：
输入： 上次查询结果
输出： 是否成功？（其他人可能抢先）
3. 退票： 或者几分钟后银行确认失败取消
输入： 班次座位列表
输出： 永远成功
就是这个server，这个是核心，我的方案比你的处理能力高两个数量级。
这个是Hard Realtime System，系统内部，每个请求的处理时间都guarantee是微秒级
别的。
剩下的，都是外围。用户账号管理。用户界面。支付系统。都可以是现成的。也容易分
布处理。
==================================
从方案上看，main和standby都可以回应查询。但是订票请求只能发给main。main上面
的message queue必须处理最高到80G/s的throughput。但是每个message就是一个订票
请求。先说坏处，就算用魏老师说的，该堆机器堆机器，改买带宽买带宽。这个方案和
分布式还是有个显著却别：这个方案的定票请求是集中到main上来的；goodbug分布式
的是细分到写票的数据库（这个数据库根据路线细分）。这样一来，这个方案对
availability和scalability又提出了新的要求。好处也很显著：没有了票的路线依赖
问题，实现简单，可以看作是高频交易的主场。票的路线依赖问题我在后面会再提到，
这个在分布式方案里面增加了复杂度，但不知道为什么没人要求zkss。
这个方案讲得很简单，后面回帖里面，魏老师确认了我的几个推测。但是有一块地方的
逻辑是有问题的：main上订票的动作和支付系统是分开的。goodbug和zhaoc针对这点的
疑问是很有道理的。就算魏老师说把慢的支付系统交给standby，那怕把支付系统部署
在分布式系统上，你mainserver的订票动作如果需要等待支付系统的确认，你这高
throughput就实现不了。除非像我推测的，你的订票之后的log不是整个transaction
log（魏老师，请展开说说）
Transaction和回滚是通过log做的。至于这到底是自己写的还是用现有工具实在是没啥
大差别。
main上面票卖出去了，更新本地状态，multicast log到standby，只要有一个standby
ack了这个log，这笔交易就成功，否则当作硬件故障，回滚。没收到log的standby可以
互相同步（这里本身就要做状态同步的！）。这里goodbug之前一直说要遍历log才能确
定是否有票，这是错误的，main直接可以查询是否有票。至于可靠性“现在的switch，
能够保证局域网内multicast永不丢包。因为都是物理连接。没有中间hop。而且存储转
发延迟两年前号称是500ns”这一部分做过的硬件的朋友可以确认一下。
还有一个推测就是“查询到有票，不代表你能抢到票”。这样一来，查询的
scalability问题可以用hot standby解决。最后买票都是在main上面。
针对订票和支付分开的问题，我试着打了个补丁：订票和付钱分开。
整个Transaction以支付成功为准。那样一来交易成功，订票成功划钱失败，订票失败
，退票分别如下所示：
查询->订票->multicast log->支付->Transaction log
查询->订票->multicast log->支付失败->退票->multicast log
查询->订票失败
退票->支付->退票->multicast log
这个补丁好处就是任何订票请求不会被block住。就是说请求1，2，3，4买最后一张票.
1买到了，去支付，处理2返回失败，处理3返回失败，1支付失败退票，处理4成功，4去
支付。这样还是高throughput，但是公平性值得考量。关于这个公平性，分布式的时候
我会再提一下。
puttyshell说支付失败，退票实际会是个噩梦。但这只是针对主机的额外操作。系统复
杂度增加了，风险高，但感觉还属于可控。不过要承认，不打这个补丁后面就没法继续
玩了。等待魏老师指正。
就像goodbug和zhaoc说的，光这样压根玩不转，魏老师的回答就是别的该堆机器堆机器
，买带宽买带宽。那只能假设，别的和架构网站的方案一致，那简单化一点，在外围子
系统也上分布式的。这样2个方案的可行性，费用，复杂度的差异就体现在魏老师的
main设计和goodbug的分布式数
据库上。
goodbug的设计
=========================================
架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的
=========================================
终极杀器就不讨论了，上了这个大家就都没得玩了-_-
有兴趣念到这的人，也不需要我废话分布式怎么实现了。goodbug这个无限分表是不实
际的，分得越多，成本，复杂度都会上去。折中一下，就算你分4个写的数据库。那么
你怎么解决路线依赖？请求1，2，第一段都是K356到上海，第二段K789，1到常熟，2到
南京。很不幸，K356K789在2个
数据库上A和B上。1,2各有2个买票请求到A和B上面。然后1的2个抢票请求都成功，去交
易。2的1个抢票请求失败，购票失败。你的设计得要有额外一块来解决怎么抢票，怎么
决定什么时候才是抢票成功，可以去支付系统转账。这个可以实现，但复杂度上去了。
前面有提到一个queue排队公平的问题。这是zhaoc和goodbug一直要实现的。还是2个车
次，不同数据库的例子。1还是要先买K356然后K789到常熟。2只是买K789上海到南京。
2的请求在B数据库上晚于1.在A上面，1的请求之前已经有200个买票请求了。在B上面
K789还有一张票，1排第一个，2排第二个，然后后面还有300个买票请求。因为排队公
平，2为了买到票，必须等1的银行交易要么成功，要么失败。1要完成交易，必须等在A
上的200个请求完成交易。这个交易是包含了慢的银行划款。2的排队时间被延长了。2
后面的300个买票请求都被延长。特别是春运这种，转车的时候
是第2天的情况很多，而可卖的票都是提前7前，一天一天放出来的。这样不必要的等待
时间会累积起来。这个问题是你们的假设引起的。欢迎打补丁。（但是既然对魏老师的
方案一说支付都搞得和拨号上网一样，就别说你的方案下支付能快到哪里去）
上面废话那么多，是为了对支持throughput做铺垫。魏老师的throughput集中在单机上
，是实打实的一个message就是一个请求。既然大家一直要求魏老师证明他的方案能支
持全双工80G，那么我们就假设春运买票高峰事情，买票的请求和回复是80G/s。分布式
分4个写数据库。那每个数据库的写请求是10G/s。就算goodbug你说80G/s的不合理，我
给你降一个数量级，8G/s。单个写数据库的写请求是1G/s。票的路径依赖，一个买票请
求可能会产生多个买票的写请求。农民工回家，倒个2，3次车的很正常。就算你分表分
到完美（复杂度上升），我只算增加个20%的余量。那就是1.2G/s的写请求。
好了，针对魏老师的方案，一讨论到到availability的问题，又是天灾，又是人祸。
goodbug你就解释一下你写数据库主机网卡那1.2G/s的写请求怎么做failover吧。用
zhaoc的话，那就是几百万的订单哪。数据库的内容，数据库本身的热同步完全可以做
。你只需要针对这1.2G/s的还没被
app处理的数据怎么做同步。（这块我很感兴趣，你要是有现成解决方案提一下，我自
己去查资料也可以）
要知道39天春运，当机超过5.616分钟，这系统就不是99.99%的availability了。这块
的要求其实对2个方案都是不小的压力。毕竟做春运火车票系统的预算不可能是无限的。
===========================================
zhaoc一直在追问如果增加班次，魏老师的主机怎么处理。在上面魏老师的方案我没提
这个，是因为春运火车票的系统，班次增加的这个并不是很关键的问题。班次的增加到
主机更新并不是硬实时的。从调度那里确认增加车次，到更新主机，你就是用1个小时
又如何？毕竟用户在你系统里看
到有新的车次才知道有新的车次。晚一点出不了事。
相反，goodbug的分表方案受到新增车次的影响更大。哪怕你之前分表分到极致。新车
次一出来，你得确定新的分表方案吧？就算只是简单的放到现在数据库里面，你得有模
块决定如果动态分表吧？复杂度上升。如果运气不好，需要重新划分数据库怎么办？我
假设你能够bug free的完成动
态划分，数据库数据迁移，数据迁移期间能够提供购票操作，完美的处理了数据迁移的
failover。复杂度上升了多少？？？
至于什么票的格式，兼容现有票务系统。这纯粹是需求分析抓不住主次。
至于新搞出来的，要做一个铁路售票网站，zhaoc，你又顽皮。我们一直在讨论卖春运
火车票。2013年春运就39天。。。
===========================================
换个方式小结一下。
从通用方案上讲，如果把goodbug给的方案，数据库分表这个设计改成唯一的集中式数
据源，goodbug的方案是可以从设计上简化的。goodbug的transaction如果可以break
down到抢票+支付成功，系统的响应速度是可以提高很多的，慢的支付动作可以细分细
分再细分下去（这块oop2其实已经提到了。不明白为什么就是没人看看，想想：
http://www.mitbbs.com/article_t/Programming/31282747.html）
魏老师给出的高频主机作为集中式数据源，抢票和支付分开本身在试图解决这2个问题
。至于有没有启发性，从工程上可行不可行。大家也只能根据各自背景做出判断。
最后废话一句：
在这，做个题，言必称N种解决方案，为什么耐心听听别人的意见就这么困难？
周末只能从周日晚上9点开始的人，码点字不容易啊
本来想拉个表比较一下的，困了，大家凑合看吧 -_- |
b*******s
发帖数: 5216 | |
f****4
发帖数: 1359 | |
L***n
发帖数: 6727 | 4 狂顶
子。
【在 f****4 的大作中提到】
: 讨论设计方案，必须有个背景才有意义。这个卖春运火车票的网站就是个很不错的例子。
: 比较方案的时候，可行性是根本，都可行的情况下考虑成本。可行性里面需要考虑到
: performance，availability,scalability，工期还有系统的复杂度。这些都是讨论的
: 基础，你不能简单的说“你这方案比scalability比不上分布式，比响应比不上硬实时
: 系统”。没有方案是完美的，我们现在只是在给定的案例下面讨论两个不同的实现。如
: 果背离这个约定，那就又成为毫无意义的口水帖了。
: 因为有些人根本不仔细看别人帖子，我把2个不同方案的实现，大家提及的疑问及解答
: ，按照我的理解复述一下，也请魏老师和goodbug指正。当然了，我主要复述一下魏老
: 师的方案，毕竟分布式的大家多少都了解一点。
: 主机配置，4个10G/s网卡，全双工80G/s，对CPUS没特殊要求，内存没提，不过现在服
|
T********i
发帖数: 2416 | 5 辛苦。关于你的订票付钱分开。我原意正是如此。
我的核心就是一个黑盒。如果你看我的输入输出，划账付钱根本不包含在内。
子。
【在 f****4 的大作中提到】
: 讨论设计方案，必须有个背景才有意义。这个卖春运火车票的网站就是个很不错的例子。
: 比较方案的时候，可行性是根本，都可行的情况下考虑成本。可行性里面需要考虑到
: performance，availability,scalability，工期还有系统的复杂度。这些都是讨论的
: 基础，你不能简单的说“你这方案比scalability比不上分布式，比响应比不上硬实时
: 系统”。没有方案是完美的，我们现在只是在给定的案例下面讨论两个不同的实现。如
: 果背离这个约定，那就又成为毫无意义的口水帖了。
: 因为有些人根本不仔细看别人帖子，我把2个不同方案的实现，大家提及的疑问及解答
: ，按照我的理解复述一下，也请魏老师和goodbug指正。当然了，我主要复述一下魏老
: 师的方案，毕竟分布式的大家多少都了解一点。
: 主机配置，4个10G/s网卡，全双工80G/s，对CPUS没特殊要求，内存没提，不过现在服
|
g*****g
发帖数: 34805 | 6 魏老师的设计问题多多，各个方面我都提了。一个致命的地方就是10万次每秒的峰值订
单他收
不了，至少1-2万的机器不行。而你质疑我1.2Gb怎么failover，这个其实没什么难理解
的。
Cassandra quorum写的时候就是在3个replica里写2个host，得到两个host ack才返回。
第三份会在后台写。正常情况下，第三份写了，硬盘坏了，还有两个备份。如果第三份
还没写好，硬盘已经坏了一个，仍然有一个备份。不影响CL1的读。
这里说的是availability。至于throughput，那纯粹就是堆机器。300个机器，每三个
存相同的数据。写的时候把key做hash，可以平均地写到不同的结点上。磁盘IO自然不
会是瓶颈。
子。
【在 f****4 的大作中提到】
: 讨论设计方案，必须有个背景才有意义。这个卖春运火车票的网站就是个很不错的例子。
: 比较方案的时候，可行性是根本，都可行的情况下考虑成本。可行性里面需要考虑到
: performance，availability,scalability，工期还有系统的复杂度。这些都是讨论的
: 基础，你不能简单的说“你这方案比scalability比不上分布式，比响应比不上硬实时
: 系统”。没有方案是完美的，我们现在只是在给定的案例下面讨论两个不同的实现。如
: 果背离这个约定，那就又成为毫无意义的口水帖了。
: 因为有些人根本不仔细看别人帖子，我把2个不同方案的实现，大家提及的疑问及解答
: ，按照我的理解复述一下，也请魏老师和goodbug指正。当然了，我主要复述一下魏老
: 师的方案，毕竟分布式的大家多少都了解一点。
: 主机配置，4个10G/s网卡，全双工80G/s，对CPUS没特殊要求，内存没提，不过现在服
|
T********i
发帖数: 2416 | 7 还说10万次我收不了？你非要我写盘我都接受了，而且100万次。你要被打几个耳光才
行？
回。
【在 g*****g 的大作中提到】
: 魏老师的设计问题多多，各个方面我都提了。一个致命的地方就是10万次每秒的峰值订
: 单他收
: 不了，至少1-2万的机器不行。而你质疑我1.2Gb怎么failover，这个其实没什么难理解
: 的。
: Cassandra quorum写的时候就是在3个replica里写2个host，得到两个host ack才返回。
: 第三份会在后台写。正常情况下，第三份写了，硬盘坏了，还有两个备份。如果第三份
: 还没写好，硬盘已经坏了一个，仍然有一个备份。不影响CL1的读。
: 这里说的是availability。至于throughput，那纯粹就是堆机器。300个机器，每三个
: 存相同的数据。写的时候把key做hash，可以平均地写到不同的结点上。磁盘IO自然不
: 会是瓶颈。
|
z****e
发帖数: 54598 | 8 again
回头把scope先定义一下
否则blablabla很烦
跟阿三一样，一堆bla
没有point，不知道丫的要干嘛
先分析问题，其次定义scope，最后再考虑implementation
否则做什么都是空的
先告诉别人，你要干什么
是做一个website呢还是做一个票的内存处理
我同意条条大路通罗马
问题是，丫貌似不是朝着罗马去的
楼主有一个很不错的开头，貌似打算告诉我们scope和背景
但是下面一段bla了半天之后，又不知道转哪里去了
swjtuer已经给出了项目背景
请你贴出来ok？
啥项目背景，目标，范围什么都不知道
上来就solution，解决啥？ |
g*****g
发帖数: 34805 | 9 你丫真是气急败坏，厂家同一数据连续写SSD的峰值速度。可以让你来当作网络IO？
你的数据每次一样，你的数据每次都512B？你每次写都连续？
【在 T********i 的大作中提到】
: 还说10万次我收不了？你非要我写盘我都接受了，而且100万次。你要被打几个耳光才
: 行？
:
: 回。
|
f****4
发帖数: 1359 | 10 魏老师，你要是能透露一点，就给个方案，或者类似的例子。
很多东西没做过，我们只能根据推理了。。。
其实这个问题不是讨论重点。goodbug你非要坚持10万次，你就zkss你的方案怎么支持
10万次。
【在 T********i 的大作中提到】
: 还说10万次我收不了？你非要我写盘我都接受了，而且100万次。你要被打几个耳光才
: 行？
:
: 回。
|
|
|
v*******e
发帖数: 11604 | 11 我门外汉哈，只是看到楼主这句话“你mainserver的订票动作如果需要等待支付系统的
确认，你这高throughput就实现不了。”这个我觉得不对。可以很简单地处理：买票的
人都要先login，然后先从银行划钱到帐上，然后才可以买票。这个帐就在你的订票系
统一起，不需要通过银行之类，因为事先已经从银行划过来了。这样确认帐上有足够钱
就很快了。买票前从银行划帐，买完票退款回银行的事情，都可以分布式慢慢做了。不
知道我是不是想错了。 |
g*****g
发帖数: 34805 | 12 我不说的很明白吗，我的硬件很烂，平民级硬件。每秒只能支持1000次的写。
堆300个结点的cassandra cluster，3 replica, quorum写。可以同时
支持high availablity和linear scale out。
你就想象一下数据平分到100个结点写，每个能撑1000次，100个就能撑10万次。
订单是完全没锁的。
【在 f****4 的大作中提到】
: 魏老师，你要是能透露一点，就给个方案，或者类似的例子。
: 很多东西没做过，我们只能根据推理了。。。
: 其实这个问题不是讨论重点。goodbug你非要坚持10万次，你就zkss你的方案怎么支持
: 10万次。
|
b*******s
发帖数: 5216 | 13 你这个和一般流程不一样，不过是可以的，就像京东之类的帐户余额
会比银行划账快很多，但这个还是需要transaction的
是一种思路
【在 v*******e 的大作中提到】
: 我门外汉哈，只是看到楼主这句话“你mainserver的订票动作如果需要等待支付系统的
: 确认，你这高throughput就实现不了。”这个我觉得不对。可以很简单地处理：买票的
: 人都要先login，然后先从银行划钱到帐上，然后才可以买票。这个帐就在你的订票系
: 统一起，不需要通过银行之类，因为事先已经从银行划过来了。这样确认帐上有足够钱
: 就很快了。买票前从银行划帐，买完票退款回银行的事情，都可以分布式慢慢做了。不
: 知道我是不是想错了。
|
T********i
发帖数: 2416 | 14 网络i/o基本上每块网卡，64byte payload，上5 million packets/s没压力。
这是solarflare的benchmark。
当然前提是sandy bridge的架构。前一代的带宽低好几倍。
【在 f****4 的大作中提到】
: 魏老师，你要是能透露一点，就给个方案，或者类似的例子。
: 很多东西没做过，我们只能根据推理了。。。
: 其实这个问题不是讨论重点。goodbug你非要坚持10万次，你就zkss你的方案怎么支持
: 10万次。
|
g*****g
发帖数: 34805 | 15 这是纯网络IO的事吗？不需要过CPU？还是那句话，2万budget，你benchmark出来我没
话说，
这2万我给你出了。
【在 T********i 的大作中提到】
: 网络i/o基本上每块网卡，64byte payload，上5 million packets/s没压力。
: 这是solarflare的benchmark。
: 当然前提是sandy bridge的架构。前一代的带宽低好几倍。
|
f****4
发帖数: 1359 | 16 我是很质疑你这1.2G/s的failover怎么实现的。。。
我已经提到了我前公司支持1G/s的failover，就为了支持这一个就搞到几个专利。
我很愿意倾向性的相信我们前公司的人都不牛B。
这块东西，我对魏老师的方案也半信半疑。起码这网卡里面全双工的数据能不能做到无
缝switch，我很怀疑。
坦白讲，我更愿意假设2个方案网卡里面全双工都丢失，然后比较failover需要花的时
间长短，来检验是否能做到99.99%的系统。
堆机器，是要花钱的，如果你要是去租机器，也牵涉到一个风险控制。为了卖39天火车
票，你越分散throughput，风险越大。考虑到天朝的实际情况，一纸合同有多少约束力
，我很怀疑。。。
这就是为什么同样假设堆机器的情况下，我会把throughput扔给你让你再解释一遍。
回。
【在 g*****g 的大作中提到】
: 魏老师的设计问题多多，各个方面我都提了。一个致命的地方就是10万次每秒的峰值订
: 单他收
: 不了，至少1-2万的机器不行。而你质疑我1.2Gb怎么failover，这个其实没什么难理解
: 的。
: Cassandra quorum写的时候就是在3个replica里写2个host，得到两个host ack才返回。
: 第三份会在后台写。正常情况下，第三份写了，硬盘坏了，还有两个备份。如果第三份
: 还没写好，硬盘已经坏了一个，仍然有一个备份。不影响CL1的读。
: 这里说的是availability。至于throughput，那纯粹就是堆机器。300个机器，每三个
: 存相同的数据。写的时候把key做hash，可以平均地写到不同的结点上。磁盘IO自然不
: 会是瓶颈。
|
f****4
发帖数: 1359 | 17 复杂度，钱到你网站上了，你得对它负责，银行支付完全可以只是转账，钱不在你网站
里面。
其实线下买火车票就是这么个逻辑。票出完了，收钱。。。
【在 v*******e 的大作中提到】
: 我门外汉哈，只是看到楼主这句话“你mainserver的订票动作如果需要等待支付系统的
: 确认，你这高throughput就实现不了。”这个我觉得不对。可以很简单地处理：买票的
: 人都要先login，然后先从银行划钱到帐上，然后才可以买票。这个帐就在你的订票系
: 统一起，不需要通过银行之类，因为事先已经从银行划过来了。这样确认帐上有足够钱
: 就很快了。买票前从银行划帐，买完票退款回银行的事情，都可以分布式慢慢做了。不
: 知道我是不是想错了。
|
f****4
发帖数: 1359 | 18 zhaoc我明天回你吧，不是我冷落你，我实在是困了。。。
【在 z****e 的大作中提到】
: again
: 回头把scope先定义一下
: 否则blablabla很烦
: 跟阿三一样，一堆bla
: 没有point，不知道丫的要干嘛
: 先分析问题，其次定义scope，最后再考虑implementation
: 否则做什么都是空的
: 先告诉别人，你要干什么
: 是做一个website呢还是做一个票的内存处理
: 我同意条条大路通罗马
|
z****e
发帖数: 54598 | 19 你先把swjtuer的文章找出来
里面有相对完整的背景描述
【在 f****4 的大作中提到】
: zhaoc我明天回你吧，不是我冷落你，我实在是困了。。。
|
T********i
发帖数: 2416 | 20 需要经过cpu。但是cpu比网络快太多了。
说实话，一台机器加网卡也就1万出头。两万都多说了。
【在 g*****g 的大作中提到】
: 这是纯网络IO的事吗？不需要过CPU？还是那句话，2万budget，你benchmark出来我没
: 话说，
: 这2万我给你出了。
|
|
|
g*****g
发帖数: 34805 | 21 I服了U，你明白Cassandra是怎么工作的吗？不明白能弄明白了再来吗？
每秒一百万次的写，图我都贴出来了，你不信我也没办法了。
【在 f****4 的大作中提到】
: 我是很质疑你这1.2G/s的failover怎么实现的。。。
: 我已经提到了我前公司支持1G/s的failover，就为了支持这一个就搞到几个专利。
: 我很愿意倾向性的相信我们前公司的人都不牛B。
: 这块东西，我对魏老师的方案也半信半疑。起码这网卡里面全双工的数据能不能做到无
: 缝switch，我很怀疑。
: 坦白讲，我更愿意假设2个方案网卡里面全双工都丢失，然后比较failover需要花的时
: 间长短，来检验是否能做到99.99%的系统。
: 堆机器，是要花钱的，如果你要是去租机器，也牵涉到一个风险控制。为了卖39天火车
: 票，你越分散throughput，风险越大。考虑到天朝的实际情况，一纸合同有多少约束力
: ，我很怀疑。。。
|
g*****g
发帖数: 34805 | 22 10万次/秒，还快多了。1万块能买几核的,context switch就慢死你。
你benchmark出来再说，瞎鸡巴吹谁不会？
【在 T********i 的大作中提到】
: 需要经过cpu。但是cpu比网络快太多了。
: 说实话，一台机器加网卡也就1万出头。两万都多说了。
|
T********i
发帖数: 2416 | 23 困了。明天接着教育你。
【在 g*****g 的大作中提到】
: 10万次/秒，还快多了。1万块能买几核的,context switch就慢死你。
: 你benchmark出来再说，瞎鸡巴吹谁不会？
|
d********u
发帖数: 5383 | 24 好文！
子。
【在 f****4 的大作中提到】
: 讨论设计方案，必须有个背景才有意义。这个卖春运火车票的网站就是个很不错的例子。
: 比较方案的时候，可行性是根本，都可行的情况下考虑成本。可行性里面需要考虑到
: performance，availability,scalability，工期还有系统的复杂度。这些都是讨论的
: 基础，你不能简单的说“你这方案比scalability比不上分布式，比响应比不上硬实时
: 系统”。没有方案是完美的，我们现在只是在给定的案例下面讨论两个不同的实现。如
: 果背离这个约定，那就又成为毫无意义的口水帖了。
: 因为有些人根本不仔细看别人帖子，我把2个不同方案的实现，大家提及的疑问及解答
: ，按照我的理解复述一下，也请魏老师和goodbug指正。当然了，我主要复述一下魏老
: 师的方案，毕竟分布式的大家多少都了解一点。
: 主机配置，4个10G/s网卡，全双工80G/s，对CPUS没特殊要求，内存没提，不过现在服
|
g*****g
发帖数: 34805 | 25 http://techblog.netflix.com/2011/11/benchmarking-cassandra-scal
你就好好读读这个帖子吧。还理解不了就真的不是我的问题了。这里demo了288个结点
的1M次/秒写。总的写速度在5GB，也就是40Gb. 数据不是越分散，风险越大，数据风险
大小完全取决于有几个备份。我给你举的这个例子，每份数据有三份。相同数据的三个
结点，即使坏了两个仍然不影响availability。而且三份数据在三个不同的zone，整个
数据中心没了都没事。
我说过很多次，我做架构喜欢有余量。如果预测100K/秒的峰值，我就要测试撑M/秒。
风险控制，就是不能把鸡蛋都放在同一个篮子里。像魏老师那样要拿厂家写完整sector
的峰值数据来证明可行的，已经近乎可笑了。
【在 f****4 的大作中提到】
: 我是很质疑你这1.2G/s的failover怎么实现的。。。
: 我已经提到了我前公司支持1G/s的failover，就为了支持这一个就搞到几个专利。
: 我很愿意倾向性的相信我们前公司的人都不牛B。
: 这块东西，我对魏老师的方案也半信半疑。起码这网卡里面全双工的数据能不能做到无
: 缝switch，我很怀疑。
: 坦白讲，我更愿意假设2个方案网卡里面全双工都丢失，然后比较failover需要花的时
: 间长短，来检验是否能做到99.99%的系统。
: 堆机器，是要花钱的，如果你要是去租机器，也牵涉到一个风险控制。为了卖39天火车
: 票，你越分散throughput，风险越大。考虑到天朝的实际情况，一纸合同有多少约束力
: ，我很怀疑。。。
|
f****4
发帖数: 1359 | 26 我是不明白Cassandra是怎么工作的。
我一直在问，你的failover方案里面是怎么做网卡IO里面的买票请求的failover的：
你的写数据库的server，网卡IO一收到订票请求就往Cassandra上面扔，写log？然后
failover的时候，重新从Cassandra上面吧这些网卡IO收到的，没处理的订票请求通过
log恢复？
如果这是你的failover方案，你的写数据库server完成一次failover得花多少时间？估
计一下就可以了。
我没和你争论每秒一百万次的写。如果连你给的这个假设都不信，我就不费那神看你方
案了。
【在 g*****g 的大作中提到】
: I服了U，你明白Cassandra是怎么工作的吗？不明白能弄明白了再来吗？
: 每秒一百万次的写，图我都贴出来了，你不信我也没办法了。
|
f****4
发帖数: 1359 | 27 你的图举了288个节点的1百万次/s的写。你给的方案是写数据库分表。
你难道说把车票表分成N个写数据库，用Cassandra来支持1百万次/s买票请求的log的写
，然后通过Cassandra慢慢的把这些throughput分给这N个写数据库？
或者说你压根不用你的写数据库分表的设计了，直接上Cassandra?如果那样的话，倒是
能讲通。但如果是那样的话，你的成本就从N个写数据库变成了288个server。
讨论方案的时候，你不能把每个方案的强项硬拉过来。
你一直说是写数据库分表+读数据库hit cache说魏老师的方案没节省多少钱。
一问throughput在写数据库分表怎么解决的时候，你就上Cassandra。
我这要是再一问Cassandra的成本，你估计得说不行去租。我告诉你天朝的商业合同的
约束力很弱，你就是事后去打官司判你赢，你都拿不到赔偿款的。
你这不是一个人在战斗，你这是一批方案在战斗 -_-
sector
【在 g*****g 的大作中提到】
: http://techblog.netflix.com/2011/11/benchmarking-cassandra-scal
: 你就好好读读这个帖子吧。还理解不了就真的不是我的问题了。这里demo了288个结点
: 的1M次/秒写。总的写速度在5GB，也就是40Gb. 数据不是越分散，风险越大，数据风险
: 大小完全取决于有几个备份。我给你举的这个例子，每份数据有三份。相同数据的三个
: 结点，即使坏了两个仍然不影响availability。而且三份数据在三个不同的zone，整个
: 数据中心没了都没事。
: 我说过很多次，我做架构喜欢有余量。如果预测100K/秒的峰值，我就要测试撑M/秒。
: 风险控制，就是不能把鸡蛋都放在同一个篮子里。像魏老师那样要拿厂家写完整sector
: 的峰值数据来证明可行的，已经近乎可笑了。
|
f****4
发帖数: 1359 | 28 swjtuer贴的背景和我知道的差不多。
不过我真不知道原来12306除了春运之外平时还在卖票。。。要承认这样一来客户预期
和一个只卖39天票的网站是有区别的。但预算会比原来估计的多，铁路系统那里得到的
支持会多很多。
不过，就算是那样，和讨论这2个方案有很大关系么？我一直在尽量客观的比较这2个方
案throughput，availability还有goodbug质疑的高峰时期写的速度。难道这系统复杂
度只对魏老师的方案存在？？？
你唯一能说的就是goodbug的方案对个人要求不高，在天朝满地都是做acm竞赛出身的码
工，往上堆人就可以了。但像对应的，测试的跟上去。
还有，我也想写个标书的格式，可有必要浪费那个精力么？你就看看你自己满屏的刷贴
吧，都是短平快，前后侧重点都不一致。
【在 z****e 的大作中提到】
: again
: 回头把scope先定义一下
: 否则blablabla很烦
: 跟阿三一样，一堆bla
: 没有point，不知道丫的要干嘛
: 先分析问题，其次定义scope，最后再考虑implementation
: 否则做什么都是空的
: 先告诉别人，你要干什么
: 是做一个website呢还是做一个票的内存处理
: 我同意条条大路通罗马
|
c****3
发帖数: 10787 | 29 感觉就是两种思路。
一种是死盯着传统的SQL的数据库，在这个基础上优化，但是传统SQL设计有缺陷，修修
补补也很难做的很好，属于费力不讨好。
还有一种是用新的NoSQL类型的数据库。这种数据库设计就是为了这种应用场景，自然
很容易处理这种应用。
感觉还是第二种方法比较好
子。
【在 f****4 的大作中提到】
: 讨论设计方案，必须有个背景才有意义。这个卖春运火车票的网站就是个很不错的例子。
: 比较方案的时候，可行性是根本，都可行的情况下考虑成本。可行性里面需要考虑到
: performance，availability,scalability，工期还有系统的复杂度。这些都是讨论的
: 基础，你不能简单的说“你这方案比scalability比不上分布式，比响应比不上硬实时
: 系统”。没有方案是完美的，我们现在只是在给定的案例下面讨论两个不同的实现。如
: 果背离这个约定，那就又成为毫无意义的口水帖了。
: 因为有些人根本不仔细看别人帖子，我把2个不同方案的实现，大家提及的疑问及解答
: ，按照我的理解复述一下，也请魏老师和goodbug指正。当然了，我主要复述一下魏老
: 师的方案，毕竟分布式的大家多少都了解一点。
: 主机配置，4个10G/s网卡，全双工80G/s，对CPUS没特殊要求，内存没提，不过现在服
|
f****4
发帖数: 1359 | 30 我承认魏老师的方案是属于修修补补的优化。就像我罗嗦的那么多一样，除了这一块，
别的东西2个方案都是一样的。
但之所以花时间就是觉得这个优化的思路有点意思，特别是在最初给定的卖39天火车票
（这是我当时的理解）的范围之内。很好奇单机的极限是多少。
码农要是连这么点好奇心都没有，和只猴子有什么区别。。。
【在 c****3 的大作中提到】
: 感觉就是两种思路。
: 一种是死盯着传统的SQL的数据库，在这个基础上优化，但是传统SQL设计有缺陷，修修
: 补补也很难做的很好，属于费力不讨好。
: 还有一种是用新的NoSQL类型的数据库。这种数据库设计就是为了这种应用场景，自然
: 很容易处理这种应用。
: 感觉还是第二种方法比较好
:
: 子。
|
|
|
p*u
发帖数: 2454 | 31
TeacherWei has mentioned that he does kernel bypass, which means primary
processing is in single thread reading/writing NIC, no extra context
switches caused by standard kernel.
100k per second means his system needs to process one packet within 10
microseconds; this number is not unheard of in hft systems.
【在 g*****g 的大作中提到】
: 10万次/秒，还快多了。1万块能买几核的,context switch就慢死你。
: 你benchmark出来再说，瞎鸡巴吹谁不会？
|
f****4
发帖数: 1359 | 32 goodbug，你这10万次/s到底是写动作还是处理订票的request？
你开了个新贴说不能10万次/s写（魏老师的不写数据库）
但又说处理不了10万次/s的订票request
【在 g*****g 的大作中提到】
: 10万次/秒，还快多了。1万块能买几核的,context switch就慢死你。
: 你benchmark出来再说，瞎鸡巴吹谁不会？
|
N******K
发帖数: 10202 | 33 每个电脑对应一种火车票？ 比如北京上海就是pc1来管？
【在 g*****g 的大作中提到】
: 我不说的很明白吗，我的硬件很烂，平民级硬件。每秒只能支持1000次的写。
: 堆300个结点的cassandra cluster，3 replica, quorum写。可以同时
: 支持high availablity和linear scale out。
: 你就想象一下数据平分到100个结点写，每个能撑1000次，100个就能撑10万次。
: 订单是完全没锁的。
|
P********l
发帖数: 452 | 34 差不多了．goodbug说一趟车／天n个电脑（n replica）.
【在 N******K 的大作中提到】
: 每个电脑对应一种火车票？ 比如北京上海就是pc1来管？
|
g*****g
发帖数: 34805 | 35 我说了又解释了那么多次的方案，你连最基本的都没明白？
确实就不是一个方案在战斗，从开头就是设计了两个数据库。一个存订单，一个存余票
计数器。
订单数据库写流量极大，但是订单本身互相不冲突，不需要锁，所以上Cassandra
余票数据库，总共每车次一万张票，每天一千车次的话，也就一千万张票。只有有余票
，银行付了钱，才会更新。这个东西涉及到钱，需要transaction，用得是RDBMS。不是
慢慢地写到N个余票数据库上，是慢慢地处理这些订单，因为银行很忙，成功的才写到
这些数据库上。
把余票数据库放到Cassandra上是不可行的。一个是做transaction不方便。更重要的是
，Cassandra读写高是因为读写的是不同的row，用户有多少单子，就有多少row，并行
读写不难。当你总共就几千行的计数器反复读写还加锁，就会产生Hotspot。什么数据
库都顶不住。魏老师那10万次读写，还要加锁更新计数器的，是纯粹打嘴炮。
说到成本，Cassandra是免费的。我说的整个架构可以在云上跑，是elastic的。如果
288个结点才能撑100万次/秒读写的话，非春运放三个结点就行了，结点多少是可以根
据load自动增减的。我给出的那个benchmark，每个小时的租机器成本是$120，100万次
秒读写一个小时的流量是$300，总共$420。你要是每秒10万次写，还租那么多机器，每
个小时$150，租1/10机器，每个小时就$42。你总共也就需要春运订票那几天，每天刚
放票的那一个小时拉出这么多结点来对付冲击而已。能花多少钱？非春运三结点，每个
小时成本$4，一天100块。一年三万多。你随便一个数据库的license一年都比这贵多了。
这还是假定你全年保持1万次/秒读写，实际上哪有那么多。
魏老师那个纯粹吹牛逼，nasdaq的流量都没有他单机能支持的大，你信吗？
【在 f****4 的大作中提到】
: 你的图举了288个节点的1百万次/s的写。你给的方案是写数据库分表。
: 你难道说把车票表分成N个写数据库，用Cassandra来支持1百万次/s买票请求的log的写
: ，然后通过Cassandra慢慢的把这些throughput分给这N个写数据库？
: 或者说你压根不用你的写数据库分表的设计了，直接上Cassandra?如果那样的话，倒是
: 能讲通。但如果是那样的话，你的成本就从N个写数据库变成了288个server。
: 讨论方案的时候，你不能把每个方案的强项硬拉过来。
: 你一直说是写数据库分表+读数据库hit cache说魏老师的方案没节省多少钱。
: 一问throughput在写数据库分表怎么解决的时候，你就上Cassandra。
: 我这要是再一问Cassandra的成本，你估计得说不行去租。我告诉你天朝的商业合同的
: 约束力很弱，你就是事后去打官司判你赢，你都拿不到赔偿款的。
|
g*****g
发帖数: 34805 | 36 那你就学习一下再来吧。基础知识没有很难说通。基本原理就是一次写俩结点，后台再
写一个。
坏了一个结点，完全不影响读写。failover完全不需要时间，对系统有1/N的性能影响
，因为丢了一个结点。
【在 f****4 的大作中提到】
: 我是不明白Cassandra是怎么工作的。
: 我一直在问，你的failover方案里面是怎么做网卡IO里面的买票请求的failover的：
: 你的写数据库的server，网卡IO一收到订票请求就往Cassandra上面扔，写log？然后
: failover的时候，重新从Cassandra上面吧这些网卡IO收到的，没处理的订票请求通过
: log恢复？
: 如果这是你的failover方案，你的写数据库server完成一次failover得花多少时间？估
: 计一下就可以了。
: 我没和你争论每秒一百万次的写。如果连你给的这个假设都不信，我就不费那神看你方
: 案了。
|
g*****g
发帖数: 34805 | 37 It's not processing, it's writing to disk, with counter updates too, and
counters are hot-contested. All on $10K box.
【在 p*u 的大作中提到】
:
: TeacherWei has mentioned that he does kernel bypass, which means primary
: processing is in single thread reading/writing NIC, no extra context
: switches caused by standard kernel.
: 100k per second means his system needs to process one packet within 10
: microseconds; this number is not unheard of in hft systems.
|
g*****g
发帖数: 34805 | 38 10万次/s是写订单的。他给的SSD连这个简单动作都顶不住。
http://www.neqx.com/product.asp?pf_id=HD405&gclid=CPe6_prBgLsCF
超过512B的单个request，理论上限140,000。加上处理和更新计数器，必挂。
【在 f****4 的大作中提到】
: goodbug，你这10万次/s到底是写动作还是处理订票的request？
: 你开了个新贴说不能10万次/s写（魏老师的不写数据库）
: 但又说处理不了10万次/s的订票request
|
N******K
发帖数: 10202 | 39 要解耦和 就得一趟车都集中到一个节点 我觉得这个方案挺简单的 然后这个节点配
上魏老师的软件 应该很nb了
【在 P********l 的大作中提到】
: 差不多了．goodbug说一趟车／天n个电脑（n replica）.
|
g*****g
发帖数: 34805 | 40 魏老师方案里，订票这块是要锁定计数器更新的。
“2. 订票：
输入： 上次查询结果
输出： 是否成功？（其他人可能抢先）”
而我的系统没有这个要求，这是我能达到scale out的原因之一。而他的10万次/秒纯粹
打嘴炮。 |
|
|
N******K
发帖数: 10202 | 41 魏老师的集中系统有个好处 就是进行动态规划非常方便
【在 N******K 的大作中提到】
: 要解耦和 就得一趟车都集中到一个节点 我觉得这个方案挺简单的 然后这个节点配
: 上魏老师的软件 应该很nb了
|
f****4
发帖数: 1359 | 42 我是没明白，因为你的方案前后不一致。逻辑上讲不通。打补丁是可以的，但是我要是
漏掉了你的哪个回帖，没更新到最新的方案，你也多包涵。
去翻你的旧方案，这纯粹就是口水仗，没有意思。我就更正你对魏老师方案的一个理解
错误，然后你正面回答我两个问题就可以了。
“魏老师那10万次读写，还要加锁更新计数器的”你这理解是错误的。魏老师的主机其
实就想替代你的余票数据库。但他不用数据库实现。你可以认为都放到内存里面了，主
机就是处理定票请求，返回订票成功与否。这个在魏老师的方案和我的小结里面都提过
的。因为他给了个高throughput的方案，所有订票请求都在一个queue里面，根据到达
先后入queue。任意时间如果是单线程的话，订票是不需要加锁的（加锁这个是你强加
给别人的-_-）
然后这个主机上面，完成定票本地需要写log，然后会把log广播到standby上面去。log
广播的速度应该不是主要问题，主要问题是本地的log写。然后就像你计算的那样，余
票的数量是到不了10万次/s的要求的。我不明白你为什么要人家实现10万次/s的写操作
，难道就因为Cassandra能实现1百万次/s的写？？？我今天有空的话我会试试看，普通
server上，写操作1s能到多少。
2个问题，请正面回答：
你现在就一个数据库存余票数据。然后"余票数据库放到Cassandra上是不可行的"，那
么在订票高峰的时候，我们算少一点，就10万/s的定票请求，这个throughput是谁在处
理？直接扔到这台余票数据库上面？？？（你也说了，这样一来需要"慢慢地处理这些
订单，因为银行很忙，成功的才写到这些数据库上"我都不让你估算用户在定票的排队
时间了 -_-）
还是这10万/s的定票请求，因为你需要慢慢处理这些订单。failover怎么处理？我一直
问你这些未被处理的订票请求怎么做failover（你和zhaoc一直盯这块的）。我本来以
为你用的是Cassandra，在看相关资料。但你既然明确指出了"余票数据库放到
Cassandra上是不可行的"，你就说说你的方案怎么做failover吧。
【在 g*****g 的大作中提到】
: 我说了又解释了那么多次的方案，你连最基本的都没明白？
: 确实就不是一个方案在战斗，从开头就是设计了两个数据库。一个存订单，一个存余票
: 计数器。
: 订单数据库写流量极大，但是订单本身互相不冲突，不需要锁，所以上Cassandra
: 余票数据库，总共每车次一万张票，每天一千车次的话，也就一千万张票。只有有余票
: ，银行付了钱，才会更新。这个东西涉及到钱，需要transaction，用得是RDBMS。不是
: 慢慢地写到N个余票数据库上，是慢慢地处理这些订单，因为银行很忙，成功的才写到
: 这些数据库上。
: 把余票数据库放到Cassandra上是不可行的。一个是做transaction不方便。更重要的是
: ，Cassandra读写高是因为读写的是不同的row，用户有多少单子，就有多少row，并行
|
p*u
发帖数: 2454 | 43
updating a counter can be done in one atomic operation like test_and_set,
which is wait-free.
i can only say it's impossible to do in 10 microseconds with sync disk
writing. if async disk writing, i have no idea abt latest hardware...
【在 g*****g 的大作中提到】
: 魏老师方案里，订票这块是要锁定计数器更新的。
: “2. 订票：
: 输入： 上次查询结果
: 输出： 是否成功？（其他人可能抢先）”
: 而我的系统没有这个要求，这是我能达到scale out的原因之一。而他的10万次/秒纯粹
: 打嘴炮。
|
g*****g
发帖数: 34805 | 44 我余票数据库分库是一个防范性的设计，如果只是每天1千万次写，RDMBS很轻松。
但实际应用中数据库不只是一个表，一个计数器那么简单。会有很多相关表，相关逻辑。
读写次数到票数的10-100次都是很常见的。这些紧耦合的逻辑不适合分库。宁可分在
天，车次，车票上。
一个好的架构师是瞻前顾后的，如果冲着硬件的理论读写上限设计，这个系统必挂。
【在 N******K 的大作中提到】
: 魏老师的集中系统有个好处 就是进行动态规划非常方便
|
g*****g
发帖数: 34805 | 45 you are talking in memory update, aren't you? The counter needs to be
written to disk to avoid loss every time. I can't see how that can be
achieved unless you start cheating. i.e. Persist every once a while. And I
remind you this is a $10K-20K hardware.
【在 p*u 的大作中提到】
:
: updating a counter can be done in one atomic operation like test_and_set,
: which is wait-free.
: i can only say it's impossible to do in 10 microseconds with sync disk
: writing. if async disk writing, i have no idea abt latest hardware...
|
f****4
发帖数: 1359 | 46 你的划分有问题。倒车的时候是第二天的车次是很正常的。用天这个粒度是分不开的。
我一直假定你是完美分表的。这样大家讨论起来可以方便一点。
辑。
【在 g*****g 的大作中提到】
: 我余票数据库分库是一个防范性的设计，如果只是每天1千万次写，RDMBS很轻松。
: 但实际应用中数据库不只是一个表，一个计数器那么简单。会有很多相关表，相关逻辑。
: 读写次数到票数的10-100次都是很常见的。这些紧耦合的逻辑不适合分库。宁可分在
: 天，车次，车票上。
: 一个好的架构师是瞻前顾后的，如果冲着硬件的理论读写上限设计，这个系统必挂。
|
f****4
发帖数: 1359 | 47 我知道你在质疑魏老师的方案里面本地log的写是否能支持他的高throughput。。。
【在 g*****g 的大作中提到】
: you are talking in memory update, aren't you? The counter needs to be
: written to disk to avoid loss every time. I can't see how that can be
: achieved unless you start cheating. i.e. Persist every once a while. And I
: remind you this is a $10K-20K hardware.
|
g*****g
发帖数: 34805 | 48 我的划分没有问题。我提了三种划分的方案，按天，按车次，分票。具体怎么分，是要
看商业逻辑和历史数据的。比如我提了聚类来看耦合。同时，我并不需要完美划分，我
只需要绝大部分transaction不跨库即可。
"倒车的时候是第二天的车次是很正常的"，这句话我没看懂。大部分车次是当天结束的
，如果要跨一天的车次，我不分不就完了吗。划分是个很灵活很有技巧的过程。
说到头，我不分库要碰到的性能问题，魏老师都要碰到。我只不过说没有不能分的库罢
了。
【在 f****4 的大作中提到】
: 你的划分有问题。倒车的时候是第二天的车次是很正常的。用天这个粒度是分不开的。
: 我一直假定你是完美分表的。这样大家讨论起来可以方便一点。
:
: 辑。
|
g*****g
发帖数: 34805 | 49 还是那句话，魏老师的counter放在内存里，一掉电就挂了。敏感的数据是必须写到硬
盘上的。每张票卖掉了，你都得更新。10万张票的订单进来，假定每订单一张票，你就
必须写硬
盘10万次。而且不更新就会超卖，这根他的设计不符。
我跟你说了无数次，订单直接写到了Cassandra上，Cassandra是fault tolerant的，只要
任何三个结点不坏两个，读写不会有任何影响，也没有丢任何1ms的数据。你还要我解
释failover我怎么解释？
余票数据库跟订单数据库不是一个，读写的只有后台的订单处理程序，不跟用户直接接
触。这里哪来的10万/秒的要求？我说了很多次，票卖完了，后面的订单直接扔掉就行
了，读Cassandra，扔掉，难道还会碰余票数据库？所以写余票数据库的上限就是票的
张数。
【在 f****4 的大作中提到】
: 我是没明白，因为你的方案前后不一致。逻辑上讲不通。打补丁是可以的，但是我要是
: 漏掉了你的哪个回帖，没更新到最新的方案，你也多包涵。
: 去翻你的旧方案，这纯粹就是口水仗，没有意思。我就更正你对魏老师方案的一个理解
: 错误，然后你正面回答我两个问题就可以了。
: “魏老师那10万次读写，还要加锁更新计数器的”你这理解是错误的。魏老师的主机其
: 实就想替代你的余票数据库。但他不用数据库实现。你可以认为都放到内存里面了，主
: 机就是处理定票请求，返回订票成功与否。这个在魏老师的方案和我的小结里面都提过
: 的。因为他给了个高throughput的方案，所有订票请求都在一个queue里面，根据到达
: 先后入queue。任意时间如果是单线程的话，订票是不需要加锁的（加锁这个是你强加
: 给别人的-_-）
|
g*****g
发帖数: 34805 | 50 不只是写，因为他订票的输出是成功与否，你不更新计数器哪里知道？计数器就是一个
需要lock, 而且每次需要写到硬盘的东西。
【在 f****4 的大作中提到】
: 我知道你在质疑魏老师的方案里面本地log的写是否能支持他的高throughput。。。
|
|
|
t*******y
发帖数: 1289 | 51 这样的支付还是比较不好搞得，如果他在你的系统里面有帐号，有钱，可以，从其它的
系统里面hold钱，很多复杂的事情会出来。不过这是一个比较好的思路。就好比在淘宝
和京东上面开店，只接受有钱的帐号。
【在 v*******e 的大作中提到】
: 我门外汉哈，只是看到楼主这句话“你mainserver的订票动作如果需要等待支付系统的
: 确认，你这高throughput就实现不了。”这个我觉得不对。可以很简单地处理：买票的
: 人都要先login，然后先从银行划钱到帐上，然后才可以买票。这个帐就在你的订票系
: 统一起，不需要通过银行之类，因为事先已经从银行划过来了。这样确认帐上有足够钱
: 就很快了。买票前从银行划帐，买完票退款回银行的事情，都可以分布式慢慢做了。不
: 知道我是不是想错了。
|
f****4
发帖数: 1359 | 52 先说这个"倒车的时候是第二天的车次是很正常的"
第一段，北京到南京，到南京11:30pm；第二段南京到福建，第二天早上3:00am
这种情况倒车很常见的。
你说你不需要完美划分，只需要绝大部分transaction不跨库即可。那好，新增的临时
客车次出来，到某一个时刻，让你绝大部分transaction跨库了。你需要重新划分了吧
？你怎么做重新划分的时候的数据同步，划分需要多久，划分的时候还能处理订票么，
重新划分失败了怎么failover。
我一直在说魏老师把余票信息放在一台机器上，从设计上解决了这个复杂性。然后他为
了弥补性能和throughput在单机的问题，试着在打补丁。。。
就像我小结说的，如果把余票数据库集中，你的方案可以大大简化。但是你没有对你的
方案怎么集中给出可行方案。。。
【在 g*****g 的大作中提到】
: 我的划分没有问题。我提了三种划分的方案，按天，按车次，分票。具体怎么分，是要
: 看商业逻辑和历史数据的。比如我提了聚类来看耦合。同时，我并不需要完美划分，我
: 只需要绝大部分transaction不跨库即可。
: "倒车的时候是第二天的车次是很正常的"，这句话我没看懂。大部分车次是当天结束的
: ，如果要跨一天的车次，我不分不就完了吗。划分是个很灵活很有技巧的过程。
: 说到头，我不分库要碰到的性能问题，魏老师都要碰到。我只不过说没有不能分的库罢
: 了。
|
c****3
发帖数: 10787 | 53 那么多开源的NoSQL类型的数据库，总能找到最适合火车票类型的数据库。实在不行还
可以在某个开源NoSQL类型的数据库项目的基础上改。
在传统的SQL数据库基础上修修补补搞优化，可能也会暂时行得通，但是长远还是可能
出问题，毕竟是设计缺陷，设计SQL的时候，根本没有web，也不是为这种应用设计的。
NoSQL类型的数据库和传统SQL数据库，在这种类型的应用上，一个是事倍功半，一个是
事半功倍，还是以新型的NoSQL类型的数据库为基础比较好。
【在 f****4 的大作中提到】
: 我承认魏老师的方案是属于修修补补的优化。就像我罗嗦的那么多一样，除了这一块，
: 别的东西2个方案都是一样的。
: 但之所以花时间就是觉得这个优化的思路有点意思，特别是在最初给定的卖39天火车票
: （这是我当时的理解）的范围之内。很好奇单机的极限是多少。
: 码农要是连这么点好奇心都没有，和只猴子有什么区别。。。
|
T*****e
发帖数: 361 | 54 同意。NoSQL也不是什么问题都能解决，网上骂NoSQL的也不少，但是这种应用的确是它
们的强项。
goodbug做这个，有这方面的经验，很自然就往这方面想。有些对NoSQL以及cassandra
没有太多的了解，是不容易明白这个方案的好处。
【在 c****3 的大作中提到】
: 感觉就是两种思路。
: 一种是死盯着传统的SQL的数据库，在这个基础上优化，但是传统SQL设计有缺陷，修修
: 补补也很难做的很好，属于费力不讨好。
: 还有一种是用新的NoSQL类型的数据库。这种数据库设计就是为了这种应用场景，自然
: 很容易处理这种应用。
: 感觉还是第二种方法比较好
:
: 子。
|
g*****g
发帖数: 34805 | 55 如果是一个数据库，一个transaction，否则distributed transaction。这东西
有啥好说的，java里面有现成的实现。应用完全不需要考虑这个。现成的类库就给处理
了。同样的表，不同的key。分库和同库是同一实现。一些数据库甚至把partition都
built-in了。
应用完全不需要知道这些。
再说一遍，你说的这些corner case，如果不好分库，可以不分，也可以distributed
transaction。你一个车次改了，也不过是1000个车次里的一个，如何就占据了主体？
更何况车次的号多半就改了，不是数据库意义上的统一车次。
corner case是不会占据主体的。amazon跟淘宝能分，车票就能分。没有
说买了电脑就不能同时买尿布的，就是个概率问题。大数统计底下概率都是很固定的。
【在 f****4 的大作中提到】
: 先说这个"倒车的时候是第二天的车次是很正常的"
: 第一段，北京到南京，到南京11:30pm；第二段南京到福建，第二天早上3:00am
: 这种情况倒车很常见的。
: 你说你不需要完美划分，只需要绝大部分transaction不跨库即可。那好，新增的临时
: 客车次出来，到某一个时刻，让你绝大部分transaction跨库了。你需要重新划分了吧
: ？你怎么做重新划分的时候的数据同步，划分需要多久，划分的时候还能处理订票么，
: 重新划分失败了怎么failover。
: 我一直在说魏老师把余票信息放在一台机器上，从设计上解决了这个复杂性。然后他为
: 了弥补性能和throughput在单机的问题，试着在打补丁。。。
: 就像我小结说的，如果把余票数据库集中，你的方案可以大大简化。但是你没有对你的
|
t*******y
发帖数: 1289 | 56 终于跟上了，讨论很nb，学习。
这样说话多好，非要用人身攻击多低俗，我们还是反三俗的好。
喜欢看一个帖子的讨论，没必要刷屏。 |
f****4
发帖数: 1359 | 57 我知道你在纠结什么了。
counter放在内存里，敏感的数据log到本地。魏老师的的高频方案是尽量做到0积累（
可行性另说）。我的理解就是网卡IO第一秒进来了10万请求，第二秒又是10万个，但是
第一秒到第二秒只能已经处理了第一秒的10万个请求。并没有对每秒进网卡IO的请求写
log，我在小结里面是认为这10万个请求failover会丢失。
我又看了一遍你的方案。你用Cassandra处理所有的订票请求（对应的是魏老师的网卡
IO进来的还没处理的订票message）。Cassandra能够处理高throughput，提供fault
tolerant。功能上相当于魏老师的单message queue，然后慢慢的把订单请求交给余票
数据库（数据又是集中的）处理。
恩，圆的不错。不过那样的话，这和你的离线终极大杀器还有什么区别？大家写封信，
寄给铁道部，按照邮戳先后时间，抢票。票抢光了，剩下来的信就卖废品了。然后买到
票的人凭收据去银行交钱。还要上Cassandra上web不是自寻烦恼么。
只要
【在 g*****g 的大作中提到】
: 还是那句话，魏老师的counter放在内存里，一掉电就挂了。敏感的数据是必须写到硬
: 盘上的。每张票卖掉了，你都得更新。10万张票的订单进来，假定每订单一张票，你就
: 必须写硬
: 盘10万次。而且不更新就会超卖，这根他的设计不符。
: 我跟你说了无数次，订单直接写到了Cassandra上，Cassandra是fault tolerant的，只要
: 任何三个结点不坏两个，读写不会有任何影响，也没有丢任何1ms的数据。你还要我解
: 释failover我怎么解释？
: 余票数据库跟订单数据库不是一个，读写的只有后台的订单处理程序，不跟用户直接接
: 触。这里哪来的10万/秒的要求？我说了很多次，票卖完了，后面的订单直接扔掉就行
: 了，读Cassandra，扔掉，难道还会碰余票数据库？所以写余票数据库的上限就是票的
|
m*******l
发帖数: 12782 | 58 晕,什么在内存里,掉电就挂了啊
内存数据库,按你这么说,都完蛋了,你看过么?
只要
【在 g*****g 的大作中提到】
: 还是那句话，魏老师的counter放在内存里，一掉电就挂了。敏感的数据是必须写到硬
: 盘上的。每张票卖掉了，你都得更新。10万张票的订单进来，假定每订单一张票，你就
: 必须写硬
: 盘10万次。而且不更新就会超卖，这根他的设计不符。
: 我跟你说了无数次，订单直接写到了Cassandra上，Cassandra是fault tolerant的，只要
: 任何三个结点不坏两个，读写不会有任何影响，也没有丢任何1ms的数据。你还要我解
: 释failover我怎么解释？
: 余票数据库跟订单数据库不是一个，读写的只有后台的订单处理程序，不跟用户直接接
: 触。这里哪来的10万/秒的要求？我说了很多次，票卖完了，后面的订单直接扔掉就行
: 了，读Cassandra，扔掉，难道还会碰余票数据库？所以写余票数据库的上限就是票的
|
m*******l
发帖数: 12782 | 59 每次都要写入硬盘?????
【在 g*****g 的大作中提到】
: 不只是写，因为他订票的输出是成功与否，你不更新计数器哪里知道？计数器就是一个
: 需要lock, 而且每次需要写到硬盘的东西。
|
P********l
发帖数: 452 | 60 给补充一个．有什么问题请指正．
车次和时刻表可以认为是固定的．所以这个时刻表可以每台机器可以存一份．买票的时
候根据这个时刻表计算得到该买的车次和时刻，然后下单．剩下的过程就和买直达车是
一样的了．
怎么分库不是特别要紧．
【在 g*****g 的大作中提到】
: 如果是一个数据库，一个transaction，否则distributed transaction。这东西
: 有啥好说的，java里面有现成的实现。应用完全不需要考虑这个。现成的类库就给处理
: 了。同样的表，不同的key。分库和同库是同一实现。一些数据库甚至把partition都
: built-in了。
: 应用完全不需要知道这些。
: 再说一遍，你说的这些corner case，如果不好分库，可以不分，也可以distributed
: transaction。你一个车次改了，也不过是1000个车次里的一个，如何就占据了主体？
: 更何况车次的号多半就改了，不是数据库意义上的统一车次。
: corner case是不会占据主体的。amazon跟淘宝能分，车票就能分。没有
: 说买了电脑就不能同时买尿布的，就是个概率问题。大数统计底下概率都是很固定的。
|
|
|
g*****g
发帖数: 34805 | 61 圆的不错？我一开始就这么设计，你一直理解不了好不好？
处理订单的瓶颈在银行那里，魏老师的方案再高频，难道有区别？
不处理是不知道票定下来没有的。
我说的离线终极大杀器，是高流量的时候用的。流量低的时候，前端网页可以自动刷新
去看cassandra数据库的订单结果，结果你马上就知道了。流量高的时候，前端网页不
刷新，改成后端发email/短信。通常几十分钟到一个小时内也知道了。
这跟大家写封信的区别。就跟去amazon抢东西和去walmart抢东西的区别，你要觉得没
区别那是死撑了。你就打心眼里不愿意承认这个设计能解决问题，有必要吗？
【在 f****4 的大作中提到】
: 我知道你在纠结什么了。
: counter放在内存里，敏感的数据log到本地。魏老师的的高频方案是尽量做到0积累（
: 可行性另说）。我的理解就是网卡IO第一秒进来了10万请求，第二秒又是10万个，但是
: 第一秒到第二秒只能已经处理了第一秒的10万个请求。并没有对每秒进网卡IO的请求写
: log，我在小结里面是认为这10万个请求failover会丢失。
: 我又看了一遍你的方案。你用Cassandra处理所有的订票请求（对应的是魏老师的网卡
: IO进来的还没处理的订票message）。Cassandra能够处理高throughput，提供fault
: tolerant。功能上相当于魏老师的单message queue，然后慢慢的把订单请求交给余票
: 数据库（数据又是集中的）处理。
: 恩，圆的不错。不过那样的话，这和你的离线终极大杀器还有什么区别？大家写封信，
|
g*****g
发帖数: 34805 | 62 没有都完蛋，但丢数据是必然的，达不到asic有没有？你不服找个financial用memory
DB的大家看看。
【在 m*******l 的大作中提到】
: 晕,什么在内存里,掉电就挂了啊
: 内存数据库,按你这么说,都完蛋了,你看过么?
:
: 只要
|
P********l
发帖数: 452 | 63 我也不明白这个余票数据库和Cassandra的关系．看起来挺多余的．
【在 f****4 的大作中提到】
: 我知道你在纠结什么了。
: counter放在内存里，敏感的数据log到本地。魏老师的的高频方案是尽量做到0积累（
: 可行性另说）。我的理解就是网卡IO第一秒进来了10万请求，第二秒又是10万个，但是
: 第一秒到第二秒只能已经处理了第一秒的10万个请求。并没有对每秒进网卡IO的请求写
: log，我在小结里面是认为这10万个请求failover会丢失。
: 我又看了一遍你的方案。你用Cassandra处理所有的订票请求（对应的是魏老师的网卡
: IO进来的还没处理的订票message）。Cassandra能够处理高throughput，提供fault
: tolerant。功能上相当于魏老师的单message queue，然后慢慢的把订单请求交给余票
: 数据库（数据又是集中的）处理。
: 恩，圆的不错。不过那样的话，这和你的离线终极大杀器还有什么区别？大家写封信，
|
g*****g
发帖数: 34805 | 64 因为本来就没有关系，余票数据库我是用RDMBS实现的。
【在 P********l 的大作中提到】
: 我也不明白这个余票数据库和Cassandra的关系．看起来挺多余的．
|
f****4
发帖数: 1359 | 65 你可能是心里这么设计的，但帖子里面一问就变来变去。
说道设计的高低，你就没看明白魏老师的方案里面试图把抢票和支付分成2块？如果可
行的话，支付完全是个异步的操作。你设计能力这么高的话，想必不会反对这样对系统
优化有多大帮助吧？？？至于可行性，值得商榷。因为这个毕竟不是现成的方案。
【在 g*****g 的大作中提到】
: 圆的不错？我一开始就这么设计，你一直理解不了好不好？
: 处理订单的瓶颈在银行那里，魏老师的方案再高频，难道有区别？
: 不处理是不知道票定下来没有的。
: 我说的离线终极大杀器，是高流量的时候用的。流量低的时候，前端网页可以自动刷新
: 去看cassandra数据库的订单结果，结果你马上就知道了。流量高的时候，前端网页不
: 刷新，改成后端发email/短信。通常几十分钟到一个小时内也知道了。
: 这跟大家写封信的区别。就跟去amazon抢东西和去walmart抢东西的区别，你要觉得没
: 区别那是死撑了。你就打心眼里不愿意承认这个设计能解决问题，有必要吗？
|
f****4
发帖数: 1359 | 66 你的方案到底是怎么实现的？？？
怎么一问就变了？？？？
别老玩你猜，你猜你再猜好不好？
【在 g*****g 的大作中提到】
: 因为本来就没有关系，余票数据库我是用RDMBS实现的。
|
P********l
发帖数: 452 | 67 你给补充的比魏老师的多多了．都快成fzz方案了．
【在 f****4 的大作中提到】
: 你可能是心里这么设计的，但帖子里面一问就变来变去。
: 说道设计的高低，你就没看明白魏老师的方案里面试图把抢票和支付分成2块？如果可
: 行的话，支付完全是个异步的操作。你设计能力这么高的话，想必不会反对这样对系统
: 优化有多大帮助吧？？？至于可行性，值得商榷。因为这个毕竟不是现成的方案。
|
g*****g
发帖数: 34805 | 68 我没有反对把抢票和支付分成两块，我只是反复地指出下订单这个流量，还要实时更新
计数，
他的单机系统撑不住。分布式设计和单机设计的目的是一样的，很多地方相似难道很奇
怪吗？
分布式只不过把瓶颈地方的流量分到多机上去了。
只于可行性，一个复杂系统实现会碰到很多问题。架构上可行，不一定可行。但是架构上
不可行的，一定不可行。这就是我跟魏老师方案的区别。
【在 f****4 的大作中提到】
: 你可能是心里这么设计的，但帖子里面一问就变来变去。
: 说道设计的高低，你就没看明白魏老师的方案里面试图把抢票和支付分成2块？如果可
: 行的话，支付完全是个异步的操作。你设计能力这么高的话，想必不会反对这样对系统
: 优化有多大帮助吧？？？至于可行性，值得商榷。因为这个毕竟不是现成的方案。
|
g*****g
发帖数: 34805 | 69 靠，我要说多少遍。
订单数据库->cassandra
余票数据库->RDBMS(mysql/oracle etc)
你去看我的帖子，从一开始就是这么设计的。
【在 f****4 的大作中提到】
: 你的方案到底是怎么实现的？？？
: 怎么一问就变了？？？？
: 别老玩你猜，你猜你再猜好不好？
|
f****4
发帖数: 1359 | 70 没有，这块分成2系统实现的，在魏老师的方案里面有提到：
"剩下的，都是外围。用户账号管理。用户界面。支付系统。"
那就作为设计的假设往下面推。至于是否能实现，oop2已经提到了“transactions如果
能组合”的话，分布式各种情况完全通用。
难得看到点干货，就为了争论而争论，太浪费了。
【在 P********l 的大作中提到】
: 你给补充的比魏老师的多多了．都快成fzz方案了．
|
|
|
f****4
发帖数: 1359 | 71 没变就好，不然懒得玩了。。。
数据库分表支持写，server cache支持查询，这是你最初给出的解决数据库IO瓶颈的方
案，间或回帖提到几次cassandra。回我贴的时候才给了个详细解释。
【在 g*****g 的大作中提到】
: 靠，我要说多少遍。
: 订单数据库->cassandra
: 余票数据库->RDBMS(mysql/oracle etc)
: 你去看我的帖子，从一开始就是这么设计的。
|
g*****g
发帖数: 34805 | 72 这种系统本来就是个流量问题，每秒10张票，一台破PC也能撑得住。每秒一千张，3层
架构，普通服务器。一万张，主机。10万张，只有分布式架构才能顶得住。
这就是个经验数字。
【在 f****4 的大作中提到】
: 没有，这块分成2系统实现的，在魏老师的方案里面有提到：
: "剩下的，都是外围。用户账号管理。用户界面。支付系统。"
: 那就作为设计的假设往下面推。至于是否能实现，oop2已经提到了“transactions如果
: 能组合”的话，分布式各种情况完全通用。
: 难得看到点干货，就为了争论而争论，太浪费了。
|
g*****g
发帖数: 34805 | 73 因为我从头就没把瓶颈放在订单数据库上。订单数据库没锁，上Cassandra，你要懂C*
咋回事，一句话就解决了。
server cache，分表，这些说的都是余票数据库，需要transaction。
这些对我不是问题，因为我把订单和余票完全分开了，魏老师就很忙。
【在 f****4 的大作中提到】
: 没变就好，不然懒得玩了。。。
: 数据库分表支持写，server cache支持查询，这是你最初给出的解决数据库IO瓶颈的方
: 案，间或回帖提到几次cassandra。回我贴的时候才给了个详细解释。
|
t*******y
发帖数: 1289 | 74 不是很懂，只是有一小问题：
你这里说的分布式，是不是各个节点有自己独立的数据库，查询和买票的时候联动，还
是各个节点复制成相同的。
谢谢。
这个问题的来源是现在国内铁路系统的商业和行政结构。
【在 g*****g 的大作中提到】
: 这种系统本来就是个流量问题，每秒10张票，一台破PC也能撑得住。每秒一千张，3层
: 架构，普通服务器。一万张，主机。10万张，只有分布式架构才能顶得住。
: 这就是个经验数字。
|
g*****g
发帖数: 34805 | 75 对于余票数据库而言，是独立的数据库。需要分布式交易的时候，可以由数据库提供
transaction
支持，也可以由应用(如底层类库JTA)来提供。
【在 t*******y 的大作中提到】
: 不是很懂，只是有一小问题：
: 你这里说的分布式，是不是各个节点有自己独立的数据库，查询和买票的时候联动，还
: 是各个节点复制成相同的。
: 谢谢。
: 这个问题的来源是现在国内铁路系统的商业和行政结构。
|
f****4
发帖数: 1359 | 76 你就没注意到把抢票和支付和支付分开之后，排队买票的等待时间大大降低了？？？
后面买票的只看当前有没有票，没票就失败。哪怕之前买到票的人支付失败，再后面的
一个人买到了票。
这样的不公平，用户是看不到。
这就是分开和不分开带来的区分。
构上
【在 g*****g 的大作中提到】
: 我没有反对把抢票和支付分成两块，我只是反复地指出下订单这个流量，还要实时更新
: 计数，
: 他的单机系统撑不住。分布式设计和单机设计的目的是一样的，很多地方相似难道很奇
: 怪吗？
: 分布式只不过把瓶颈地方的流量分到多机上去了。
: 只于可行性，一个复杂系统实现会碰到很多问题。架构上可行，不一定可行。但是架构上
: 不可行的，一定不可行。这就是我跟魏老师方案的区别。
|
g*****g
发帖数: 34805 | 77 抢票和支付我本来就是分开的，你到底想说啥。我否定魏老师的方案，并没有全盘否定
他的所有做法。而且我的做法，还是完全公平的。相当于先超卖，再去掉超卖的订单，跟
火车站排队的结果是一样的。
【在 f****4 的大作中提到】
: 你就没注意到把抢票和支付和支付分开之后，排队买票的等待时间大大降低了？？？
: 后面买票的只看当前有没有票，没票就失败。哪怕之前买到票的人支付失败，再后面的
: 一个人买到了票。
: 这样的不公平，用户是看不到。
: 这就是分开和不分开带来的区分。
:
: 构上
|
f****4
发帖数: 1359 | 78 你又来这个。。。
魏老师的方案除了个主机讲了一下，这东西能上web？
你用cassandra存订票订单（处理throughput）+单数据库的余票数据库；这才是我在比
较的2个方案。
【在 g*****g 的大作中提到】
: 这种系统本来就是个流量问题，每秒10张票，一台破PC也能撑得住。每秒一千张，3层
: 架构，普通服务器。一万张，主机。10万张，只有分布式架构才能顶得住。
: 这就是个经验数字。
|
t*******y
发帖数: 1289 | 79 谢谢回复，但是还有点不明白，希望能多说两句。
按照你前面说的，余票数据库->RDBMS(mysql/oracle etc)，那这个是分布式的吗（别
笑话我，从来没做过数据库，只是感兴趣你们讨论的话题，顺道学习）？我觉得应该不
是分布的。
最后这个提供支持不是很理解。是说交易的时候，通过另外的数据库 -- 订单数据库->
cassandra 提供支持。那么这两个数据库联动的问题，下定单就直接减余票数据库，还
是等订单数据库返回了再操作余票数据库？
谢谢。
【在 g*****g 的大作中提到】
: 对于余票数据库而言，是独立的数据库。需要分布式交易的时候，可以由数据库提供
: transaction
: 支持，也可以由应用(如底层类库JTA)来提供。
|
g*****g
发帖数: 34805 | 80 So，你到底想说啥？魏老师的方案需要下订单，更新余票数据，返回成功与否。
就这个操作，造成订单必须锁在余票技术器上等更新，我的不需要。不谈分布式架构，
光这个区别，就能造成高峰10倍以上throughput的区别，为什么你明白不？
【在 f****4 的大作中提到】
: 你又来这个。。。
: 魏老师的方案除了个主机讲了一下，这东西能上web？
: 你用cassandra存订票订单（处理throughput）+单数据库的余票数据库；这才是我在比
: 较的2个方案。
|
|
|
f****4
发帖数: 1359 | 81 你和zhaoc一口一个transaction结束是以支付完成为结束。这就是你的抢票和支付分开？
先超卖再取消？农民工买了票，交了钱开开心心回工地去了，你来一个取消超卖订单？
？？
我给的补丁，支付不成功，退票，已经给说死了。。。
，跟
【在 g*****g 的大作中提到】
: 抢票和支付我本来就是分开的，你到底想说啥。我否定魏老师的方案，并没有全盘否定
: 他的所有做法。而且我的做法，还是完全公平的。相当于先超卖，再去掉超卖的订单，跟
: 火车站排队的结果是一样的。
|
g*****g
发帖数: 34805 | 82 是分布式的，但具体怎么分，要看数据耦合度定最佳方案。你要通用的就是拿Oracle之
类的直接做horizontal partitioning。对应用透明。
->
【在 t*******y 的大作中提到】
: 谢谢回复，但是还有点不明白，希望能多说两句。
: 按照你前面说的，余票数据库->RDBMS(mysql/oracle etc)，那这个是分布式的吗（别
: 笑话我，从来没做过数据库，只是感兴趣你们讨论的话题，顺道学习）？我觉得应该不
: 是分布的。
:
: 最后这个提供支持不是很理解。是说交易的时候，通过另外的数据库 -- 订单数据库->
: cassandra 提供支持。那么这两个数据库联动的问题，下定单就直接减余票数据库，还
: 是等订单数据库返回了再操作余票数据库？
: 谢谢。
|
g*****g
发帖数: 34805 | 83 你也够不上道的，我哪里说了DB transaction必须支付完成？我只是说用户的一个交易
是以支付完成为标志的，这中间难道非得是一个DB transaction？我超卖，我又没说你
抢到没，我说得明明白白，回头我通知你。倒是你跟魏老师，跟用户说卖了。结果银行
账户没填对，悲剧了。LOL。
开？
【在 f****4 的大作中提到】
: 你和zhaoc一口一个transaction结束是以支付完成为结束。这就是你的抢票和支付分开？
: 先超卖再取消？农民工买了票，交了钱开开心心回工地去了，你来一个取消超卖订单？
: ？？
: 我给的补丁，支付不成功，退票，已经给说死了。。。
:
: ，跟
|
t*******y
发帖数: 1289 | 84 实话时说，对于超卖的问题我不同意你的意见。
平常超卖可能不多，但是节假日的超卖可能会很多，问题比较大了。
【在 g*****g 的大作中提到】
: 你也够不上道的，我哪里说了DB transaction必须支付完成？我只是说用户的一个交易
: 是以支付完成为标志的，这中间难道非得是一个DB transaction？我超卖，我又没说你
: 抢到没，我说得明明白白，回头我通知你。倒是你跟魏老师，跟用户说卖了。结果银行
: 账户没填对，悲剧了。LOL。
:
: 开？
|
f****4
发帖数: 1359 | 85 =========================================
架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的
=========================================
搜个cassandra出来我看看
【在 g*****g 的大作中提到】
: So，你到底想说啥？魏老师的方案需要下订单，更新余票数据，返回成功与否。
: 就这个操作，造成订单必须锁在余票技术器上等更新，我的不需要。不谈分布式架构，
: 光这个区别，就能造成高峰10倍以上throughput的区别，为什么你明白不？
|
f****4
发帖数: 1359 | 86 整个Transaction以支付成功为准。那样一来交易成功，订票成功划钱失败，订票失败
，退票分别如下所示：
查询->订票->multicast log->支付->Transaction log
查询->订票->multicast log->支付失败->退票->multicast log
查询->订票失败
退票->支付->退票->multicast log
那你的实现还比不上我打的补丁。划钱失败，返回的是没买到票。
【在 g*****g 的大作中提到】
: 你也够不上道的，我哪里说了DB transaction必须支付完成？我只是说用户的一个交易
: 是以支付完成为标志的，这中间难道非得是一个DB transaction？我超卖，我又没说你
: 抢到没，我说得明明白白，回头我通知你。倒是你跟魏老师，跟用户说卖了。结果银行
: 账户没填对，悲剧了。LOL。
:
: 开？
|
g*****g
发帖数: 34805 | 87 "发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。" 这个就说的是Cassandra，RDMBS不是这个性质。其余部分，说的是
RDMBS。我提commit log，不提C*，只不过想尽量说得通用一点。
cache
路&
【在 f****4 的大作中提到】
: =========================================
: 架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
: ，所有的数据库读都是cache发起的。用户读只hit cache。
: 接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
: 无限
: 分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
: 日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
: queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
: queue一秒钟就处理完了，票卖完了后面直接通知买不到。
: 这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
|
g*****g
发帖数: 34805 | 88 你还不明白，你的东西倒是理想，可是10万订单一来就崩了。我老弄得这么复杂，
难道是不懂得单机啥都处理了最简单吗？不就是为了能把订单和余票完整分开吗。
我还从头到尾，把连银行交易都做了一个sync操作最理想呢。做不到怎么办呀？
【在 f****4 的大作中提到】
: 整个Transaction以支付成功为准。那样一来交易成功，订票成功划钱失败，订票失败
: ，退票分别如下所示：
: 查询->订票->multicast log->支付->Transaction log
: 查询->订票->multicast log->支付失败->退票->multicast log
: 查询->订票失败
: 退票->支付->退票->multicast log
: 那你的实现还比不上我打的补丁。划钱失败，返回的是没买到票。
|
f****4
发帖数: 1359 | 89 同意，可以超卖的部分春运会留给各个站台现场出售的。不然一点票都不放，民工能砸
了你的售票室。
但这是可行性讨论，可以这么假设。
【在 t*******y 的大作中提到】
: 实话时说，对于超卖的问题我不同意你的意见。
: 平常超卖可能不多，但是节假日的超卖可能会很多，问题比较大了。
|
f****4
发帖数: 1359 | 90 所以，归根结底，你就是咬定了魏老师10万订单能不能挺住了是不是？
有点耍赖了，不过算是合理的质疑。
【在 g*****g 的大作中提到】
: 你还不明白，你的东西倒是理想，可是10万订单一来就崩了。我老弄得这么复杂，
: 难道是不懂得单机啥都处理了最简单吗？不就是为了能把订单和余票完整分开吗。
: 我还从头到尾，把连银行交易都做了一个sync操作最理想呢。做不到怎么办呀？
|
|
|
f****4
发帖数: 1359 | 91 所以，也请你理解一下我为什么不明白你的方案。
谢谢
【在 g*****g 的大作中提到】
: "发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
: queue就完了。" 这个就说的是Cassandra，RDMBS不是这个性质。其余部分，说的是
: RDMBS。我提commit log，不提C*，只不过想尽量说得通用一点。
:
: cache
: 路&
|
T********i
发帖数: 2416 | 92 你是真傻还是装傻？好好学学我的新经文。IOPS我的系统是上百万级别的。比你的200
多台服务器还要高几倍。而且你那个有dependency问题。实际用起来还要打一个数量级
的折扣。
http://www.mitbbs.com/article_t/Programming/31283785.html
【在 g*****g 的大作中提到】
: 你还不明白，你的东西倒是理想，可是10万订单一来就崩了。我老弄得这么复杂，
: 难道是不懂得单机啥都处理了最简单吗？不就是为了能把订单和余票完整分开吗。
: 我还从头到尾，把连银行交易都做了一个sync操作最理想呢。做不到怎么办呀？
|
g*****g
发帖数: 34805 | 93 这不是超卖，只是多收订单而已。我不挡着你订，但不能立刻跟你说订到没。
量小的时候，你几秒钟就知道结果。
量大的时候，是直接网站个屁，还是用email/短信过一会通知你好呢？
整个分布式设计，不是为了设计简单。而是为了撑住流量有取舍。
【在 t*******y 的大作中提到】
: 实话时说，对于超卖的问题我不同意你的意见。
: 平常超卖可能不多，但是节假日的超卖可能会很多，问题比较大了。
|
g*****g
发帖数: 34805 | 94 耍赖。所有分布式设计的假设，都是单机撑不住。单机都能撑住要分布式干啥？
你干脆说分布式设计都是耍赖了。
【在 f****4 的大作中提到】
: 所以，归根结底，你就是咬定了魏老师10万订单能不能挺住了是不是？
: 有点耍赖了，不过算是合理的质疑。
|
g*****g
发帖数: 34805 | 95 大家只要看看硬件的那一页，连硬盘/SSD都没提。就知道魏老师又开始新一轮的忽悠了，
尼玛不用写硬盘每秒100万次我信还不行吗？
200
【在 T********i 的大作中提到】
: 你是真傻还是装傻？好好学学我的新经文。IOPS我的系统是上百万级别的。比你的200
: 多台服务器还要高几倍。而且你那个有dependency问题。实际用起来还要打一个数量级
: 的折扣。
: http://www.mitbbs.com/article_t/Programming/31283785.html
|
t*******y
发帖数: 1289 | 96 那这样的话，这个订单只是一个wishlist型的，也是一个解决思路，但是同样的，本来
就已经处理不过来了，再不停的结束未结束的交易通话，接受新的交易，是不是更加剧
了系统的负荷？
这是一个两难的事情，特别大家对用户体验要求高的时候。
【在 g*****g 的大作中提到】
: 这不是超卖，只是多收订单而已。我不挡着你订，但不能立刻跟你说订到没。
: 量小的时候，你几秒钟就知道结果。
: 量大的时候，是直接网站个屁，还是用email/短信过一会通知你好呢？
: 整个分布式设计，不是为了设计简单。而是为了撑住流量有取舍。
|
f****4
发帖数: 1359 | 97 你这么一解释超卖，我就笑了 :D
因为余票查询这块要分流，那么必然导致了有些用户查询看到还剩下0张票，有用户看
到剩下1张票的情况。后者还能去抢票，但实际上他就是去了也抢不到票，除非前面的
人交易失败，或者有人退票。所以不需要额外画蛇添足的加个超卖功能。
这个设计不好。
【在 g*****g 的大作中提到】
: 这不是超卖，只是多收订单而已。我不挡着你订，但不能立刻跟你说订到没。
: 量小的时候，你几秒钟就知道结果。
: 量大的时候，是直接网站个屁，还是用email/短信过一会通知你好呢？
: 整个分布式设计，不是为了设计简单。而是为了撑住流量有取舍。
|
g*****g
发帖数: 34805 | 98 没有处理不过来，订单一旦不需要更新余票。就可以分布式写，100万次/秒的写都可以
对付。
不能对付这个流量的是RDBMS。架构的关键就是把流量分开。前端订单写进NoSQL DB，
后端低流量处理
需要transaction还是RDMBS。
【在 t*******y 的大作中提到】
: 那这样的话，这个订单只是一个wishlist型的，也是一个解决思路，但是同样的，本来
: 就已经处理不过来了，再不停的结束未结束的交易通话，接受新的交易，是不是更加剧
: 了系统的负荷？
: 这是一个两难的事情，特别大家对用户体验要求高的时候。
|
f****4
发帖数: 1359 | 99 你去看看魏老师帖子的我的更贴再说
====================================
魏老师，你的log通过网络出去这块应该问题不大。
现在解释一下你的实现，这个log你本地是否需要记录？如果需要记录的话，IO写盘能
不能支持10万/s的throughput。
如果本地不能log的，failover能否无缝switch？还有网卡里面还未处理的订票
messages，failover之后是否就丢掉了？
这是几个我想确认的地方。谢谢。
=====================================
【在 g*****g 的大作中提到】
: 耍赖。所有分布式设计的假设，都是单机撑不住。单机都能撑住要分布式干啥？
: 你干脆说分布式设计都是耍赖了。
|
g*****g
发帖数: 34805 | 100 我可以做到余票每秒更新一次，当后台处理模块处理到没票的时候，后面的人就下不了
订单了。
这就是说，银行处理慢，在银行交易卖掉所有票之前，我都让你试。我甚至可以给你一
个前面
排了多少人的大致数据。就是票还剩多少，你前面排了多少人。你愿不愿意试自己决定。
不管怎么设计，都比网站崩了强。
【在 f****4 的大作中提到】
: 你这么一解释超卖，我就笑了 :D
: 因为余票查询这块要分流，那么必然导致了有些用户查询看到还剩下0张票，有用户看
: 到剩下1张票的情况。后者还能去抢票，但实际上他就是去了也抢不到票，除非前面的
: 人交易失败，或者有人退票。所以不需要额外画蛇添足的加个超卖功能。
: 这个设计不好。
|
|
|
g*****g
发帖数: 34805 | 101 我对他的质疑不不只是在Log上，关键的是计数器更新写盘。他的设计是立刻知道有余
票与否的。
余票你不更新，不写硬盘，就有可能丢。
【在 f****4 的大作中提到】
: 你去看看魏老师帖子的我的更贴再说
: ====================================
: 魏老师，你的log通过网络出去这块应该问题不大。
: 现在解释一下你的实现，这个log你本地是否需要记录？如果需要记录的话，IO写盘能
: 不能支持10万/s的throughput。
: 如果本地不能log的，failover能否无缝switch？还有网卡里面还未处理的订票
: messages，failover之后是否就丢掉了？
: 这是几个我想确认的地方。谢谢。
: =====================================
|
t*******y
发帖数: 1289 | 102 我觉得最后还是一个商业模式的问题，同不同意只是把用户加到waiting list里面等结
果。
其实这也是一种解决方案啊。
交易中就直接减剩票，告知有多少在处理，如果愿意，加入waiting list，同时必须提
供相关的银行信息，等待处理。用户可以设置等待的时间。不知道加入中途取消的话好
实现吗？系统根据先到先得处理，处理好了通知用户。 |
g*****g
发帖数: 34805 | 103 就是这么回事。我同意不如买了直接知道结果体验好。可是银行处理不了你咋办呀？
等总比网站当强吧。
【在 t*******y 的大作中提到】
: 我觉得最后还是一个商业模式的问题，同不同意只是把用户加到waiting list里面等结
: 果。
: 其实这也是一种解决方案啊。
: 交易中就直接减剩票，告知有多少在处理，如果愿意，加入waiting list，同时必须提
: 供相关的银行信息，等待处理。用户可以设置等待的时间。不知道加入中途取消的话好
: 实现吗？系统根据先到先得处理，处理好了通知用户。
|
f****4
发帖数: 1359 | 104 我这的log就是他余票状态的本地log，不写到本地，就可能丢。就算failover做得再好
，也会有1票2卖的情况。
【在 g*****g 的大作中提到】
: 我对他的质疑不不只是在Log上，关键的是计数器更新写盘。他的设计是立刻知道有余
: 票与否的。
: 余票你不更新，不写硬盘，就有可能丢。
|
f****4
发帖数: 1359 | 105 不过你对这个10万次/s的写要求不合理。
他的方案里面可能只有卖掉的票才需要写log。
进来的订票请求不写log，丢了就丢了，failover之后重新排队。只要failover之后hot
standby 起来的速度快，应该还是能接受的。
【在 g*****g 的大作中提到】
: 我对他的质疑不不只是在Log上，关键的是计数器更新写盘。他的设计是立刻知道有余
: 票与否的。
: 余票你不更新，不写硬盘，就有可能丢。
|
f****4
发帖数: 1359 | 106 知道能做，不过，真的没必要做。。。
定。
【在 g*****g 的大作中提到】
: 我可以做到余票每秒更新一次，当后台处理模块处理到没票的时候，后面的人就下不了
: 订单了。
: 这就是说，银行处理慢，在银行交易卖掉所有票之前，我都让你试。我甚至可以给你一
: 个前面
: 排了多少人的大致数据。就是票还剩多少，你前面排了多少人。你愿不愿意试自己决定。
: 不管怎么设计，都比网站崩了强。
|
g*****g
发帖数: 34805 | 107 没啥不合理的，一天一千车次，几十天，一车次上万张票。总共几亿张票是有的，
顶峰一秒10万个能卖的订单出现是可能的。不成功的订单，不用写盘，不等于不用处理，
这些都会会降低系统的处理能力。
hot
【在 f****4 的大作中提到】
: 不过你对这个10万次/s的写要求不合理。
: 他的方案里面可能只有卖掉的票才需要写log。
: 进来的订票请求不写log，丢了就丢了，failover之后重新排队。只要failover之后hot
: standby 起来的速度快，应该还是能接受的。
|
w*******r
发帖数: 34 | 108 还是fzzh24的这个帖子解释的比较清楚 顶一个
先说我的立场，纯技术讨论我喜欢魏老师的思路，但真让我用肯定是goodbug的让实际
一点，因为有一个最重要的问题，魏老师都是自己造轮子，goodbug这有一群vendor，
没有陪绑的，心里不踏实啊。
goodbug的方案就是传统三层架构拓展到了aws，思路是没错但想跑出完美的效果得花很
大的力气去优化，因为涉及的环节太多，优化麻烦。最大好处就是failover的问题不用
太操心，方案是现成的，做到四个9问题不大，但latency多少就不好说了，就像
goodbug给的答案，最后成交用sms通知来人为创造一个延迟。
魏老师的方案简单高效，全部数据都在一个main server上完成，性能好是可以预见的
。但就像goodbug质疑的那样，掉电时候怎么保证不丢单，谈能处理多少io我信，但要
是在峰值的时候一脚把电源踢了, failover server上究竟能恢复到什么地步？这个问
题我没看到魏老师咋解决，希望给说说，毕竟大家说的是春运早上八点的事，从铁道部
到买票的都怕出事。
老赵你纯粹是灌水呢，呵呵 |
g*****g
发帖数: 34805 | 109 掉电只是一个问题，我反复问的，这个单机撑不住怎么办？流量超过了他的系统反应速
度，
只有扔单一个选择。
你要去竞标的话，系统复杂但可行，那是个工程问题。系统简单但要丢单，那是设计问
题。
【在 w*******r 的大作中提到】
: 还是fzzh24的这个帖子解释的比较清楚 顶一个
: 先说我的立场，纯技术讨论我喜欢魏老师的思路，但真让我用肯定是goodbug的让实际
: 一点，因为有一个最重要的问题，魏老师都是自己造轮子，goodbug这有一群vendor，
: 没有陪绑的，心里不踏实啊。
: goodbug的方案就是传统三层架构拓展到了aws，思路是没错但想跑出完美的效果得花很
: 大的力气去优化，因为涉及的环节太多，优化麻烦。最大好处就是failover的问题不用
: 太操心，方案是现成的，做到四个9问题不大，但latency多少就不好说了，就像
: goodbug给的答案，最后成交用sms通知来人为创造一个延迟。
: 魏老师的方案简单高效，全部数据都在一个main server上完成，性能好是可以预见的
: 。但就像goodbug质疑的那样，掉电时候怎么保证不丢单，谈能处理多少io我信，但要
|
w*******r
发帖数: 34 | 110 没错，你说的这个我完全同意。
我觉得魏老师开始提到单机这俩字，就是给自己挖了坑，就算单机硬件预算没上限，后
面他给的各种推演最后都很难绕过单机本身的物理限制。
要是他这个方案可以做成一个小型分布式集群就好了，那比cloud爽多了。不过金融机
构确实很多像魏老师说的这么干的，这跟拿平民硬件搭cloud是两种思路。
btw 听你讲的，我准备去看看cassandra了，呵呵
【在 g*****g 的大作中提到】
: 掉电只是一个问题，我反复问的，这个单机撑不住怎么办？流量超过了他的系统反应速
: 度，
: 只有扔单一个选择。
: 你要去竞标的话，系统复杂但可行，那是个工程问题。系统简单但要丢单，那是设计问
: 题。
|
|
|
a****i
发帖数: 1182 | 111 我觉得抢票买票过程全在内存上操作，不用写什么log。有票，确定，就在内存里设一
个状态。等用户点那个“Submit my order”了，再连一个place order的服务器,慢慢
处理银行，做persist。如果出问题，回滚数据库，把内存的状态释放。票又avaiable
，再一轮抢票
hot
【在 f****4 的大作中提到】
: 不过你对这个10万次/s的写要求不合理。
: 他的方案里面可能只有卖掉的票才需要写log。
: 进来的订票请求不写log，丢了就丢了，failover之后重新排队。只要failover之后hot
: standby 起来的速度快，应该还是能接受的。
|
g*****g
发帖数: 34805 | 112 魏老师这么做不是偶然的。单机什么东西都简单，加一个hot standby，还是单机，因
为所有东西都是单机处理，不需要分。一旦牵涉到多个机器，就是分布式系统。
transaction, distribution，大量的问题，都在他的知识范围之外。
【在 w*******r 的大作中提到】
: 没错，你说的这个我完全同意。
: 我觉得魏老师开始提到单机这俩字，就是给自己挖了坑，就算单机硬件预算没上限，后
: 面他给的各种推演最后都很难绕过单机本身的物理限制。
: 要是他这个方案可以做成一个小型分布式集群就好了，那比cloud爽多了。不过金融机
: 构确实很多像魏老师说的这么干的，这跟拿平民硬件搭cloud是两种思路。
: btw 听你讲的，我准备去看看cassandra了，呵呵
|
g*****g
发帖数: 34805 | 113 那么做，掉电了，你都不知道还剩几张。
avaiable
【在 a****i 的大作中提到】
: 我觉得抢票买票过程全在内存上操作，不用写什么log。有票，确定，就在内存里设一
: 个状态。等用户点那个“Submit my order”了，再连一个place order的服务器,慢慢
: 处理银行，做persist。如果出问题，回滚数据库，把内存的状态释放。票又avaiable
: ，再一轮抢票
:
: hot
|
w*******r
发帖数: 34 | 114 哈，内存操作是需要时间的，除非你一个tick能完成从读到写全部的事情，否则就得做
failover的准备。魏老师这么牛逼的方案，还都说不圆呢。
avaiable
【在 a****i 的大作中提到】
: 我觉得抢票买票过程全在内存上操作，不用写什么log。有票，确定，就在内存里设一
: 个状态。等用户点那个“Submit my order”了，再连一个place order的服务器,慢慢
: 处理银行，做persist。如果出问题，回滚数据库，把内存的状态释放。票又avaiable
: ，再一轮抢票
:
: hot
|
a****i
发帖数: 1182 | 115 你当我是单机咩？
另外，数据库里查啊，没收钱的就没写
【在 g*****g 的大作中提到】
: 那么做，掉电了，你都不知道还剩几张。
:
: avaiable
|
w*******r
发帖数: 34 | 116 哥，硬盘以外的任何数据有可能丢失，就你描述的这个过程，假设打标点的地方有50%
都fail了，怎么办。真心觉得你都没搞懂他们在吵啥，建议好好看看一楼的那篇分析。
avaiable
【在 a****i 的大作中提到】
: 我觉得抢票买票过程全在内存上操作，不用写什么log。有票，确定，就在内存里设一
: 个状态。等用户点那个“Submit my order”了，再连一个place order的服务器,慢慢
: 处理银行，做persist。如果出问题，回滚数据库，把内存的状态释放。票又avaiable
: ，再一轮抢票
:
: hot
|
f****4
发帖数: 1359 | 117 要做failover，重要数据写到硬盘是最低限度。写到硬盘都可以会丢。
所以要做好failover，复杂度，成本都会上去的。
avaiable
【在 a****i 的大作中提到】
: 我觉得抢票买票过程全在内存上操作，不用写什么log。有票，确定，就在内存里设一
: 个状态。等用户点那个“Submit my order”了，再连一个place order的服务器,慢慢
: 处理银行，做persist。如果出问题，回滚数据库，把内存的状态释放。票又avaiable
: ，再一轮抢票
:
: hot
|
a****i
发帖数: 1182 | 118 弟，你没看明白我在说啥才是
一楼分析买票是这样：
查询->订票->multicast log->支付->Transaction log
查询->订票->multicast log->支付失败->退票->multicast log
我的意思就是这个基础上，做两重
查询->订票->multicast log(memory)->tx开始->支付->multicast log(persist)->Tx
结束
查询->订票->multicast log(memroy)->tx开始->支付失败->退票->multicast log回滚
(memory)->tx结束
那个multicast log在整个买票过程成功之前就不用persist，就这个区别
【在 w*******r 的大作中提到】
: 哥，硬盘以外的任何数据有可能丢失，就你描述的这个过程，假设打标点的地方有50%
: 都fail了，怎么办。真心觉得你都没搞懂他们在吵啥，建议好好看看一楼的那篇分析。
:
: avaiable
|
w*******r
发帖数: 34 | 119 几重无所谓，重越多越麻烦。再说你这tx是分布式的不？不支持纯单机就是重复魏老师
说的法子，走分布式的话性能不会有魏老师那种好。
你这还把支付放事务里面了，性能不会太好，网银接口花个一两秒钟很正常，就这一秒
新的请求过来排队都受不了。再带个退票环节，这是要给每张票加锁是不，这不就更不
靠谱了，本来就是要减少火车票实体状态，你还人为的加了个锁上去。
Tx
【在 a****i 的大作中提到】
: 弟，你没看明白我在说啥才是
: 一楼分析买票是这样：
: 查询->订票->multicast log->支付->Transaction log
: 查询->订票->multicast log->支付失败->退票->multicast log
: 我的意思就是这个基础上，做两重
: 查询->订票->multicast log(memory)->tx开始->支付->multicast log(persist)->Tx
: 结束
: 查询->订票->multicast log(memroy)->tx开始->支付失败->退票->multicast log回滚
: (memory)->tx结束
: 那个multicast log在整个买票过程成功之前就不用persist，就这个区别
|
a****i
发帖数: 1182 | 120 TW的主要就是那个log，说他的机器性能好，每秒多少次的IO
那我直接放到内存里会不会更快？
因为没有买成票的话，log其实没有用，也就是起到一个加锁的作用
所以有说要对log查询的
他的方案里，付款也是另外机器做的
所以有两个环节，一个是查询－抢票－抢到（订票）
然后开始付款
【在 w*******r 的大作中提到】
: 几重无所谓，重越多越麻烦。再说你这tx是分布式的不？不支持纯单机就是重复魏老师
: 说的法子，走分布式的话性能不会有魏老师那种好。
: 你这还把支付放事务里面了，性能不会太好，网银接口花个一两秒钟很正常，就这一秒
: 新的请求过来排队都受不了。再带个退票环节，这是要给每张票加锁是不，这不就更不
: 靠谱了，本来就是要减少火车票实体状态，你还人为的加了个锁上去。
:
: Tx
|
|
|
w*******r
发帖数: 34 | 121 那抱歉我没看到老魏说的交易放其他机器处理 漏掉了
那你这跟老魏的有啥区别？我觉得他那个法子如果能扩展到同一dc的小集群上，性能不
会下降太多，但是可靠性上去，唯一麻烦就是要跨dc了怎么办
【在 a****i 的大作中提到】
: TW的主要就是那个log，说他的机器性能好，每秒多少次的IO
: 那我直接放到内存里会不会更快？
: 因为没有买成票的话，log其实没有用，也就是起到一个加锁的作用
: 所以有说要对log查询的
: 他的方案里，付款也是另外机器做的
: 所以有两个环节，一个是查询－抢票－抢到（订票）
: 然后开始付款
|
f****4
发帖数: 1359 | 122 不用猜了，log这部分标记交易完成的，逻辑没错。
goodbug他们一直在问进来的订票messagefailover怎么办
http://www.mitbbs.com/article_t/Programming/31286477.html
看了一下，应该没有大问题
Tx
【在 a****i 的大作中提到】
: 弟，你没看明白我在说啥才是
: 一楼分析买票是这样：
: 查询->订票->multicast log->支付->Transaction log
: 查询->订票->multicast log->支付失败->退票->multicast log
: 我的意思就是这个基础上，做两重
: 查询->订票->multicast log(memory)->tx开始->支付->multicast log(persist)->Tx
: 结束
: 查询->订票->multicast log(memroy)->tx开始->支付失败->退票->multicast log回滚
: (memory)->tx结束
: 那个multicast log在整个买票过程成功之前就不用persist，就这个区别
|
a****i
发帖数: 1182 | 123 这个意思是买没买到票其实不知道，回去等消息？
不然的话银行那边的速度慢了，他这儿想快也快不起来啊
【在 f****4 的大作中提到】
: 不用猜了，log这部分标记交易完成的，逻辑没错。
: goodbug他们一直在问进来的订票messagefailover怎么办
: http://www.mitbbs.com/article_t/Programming/31286477.html
: 看了一下，应该没有大问题
:
: Tx
|
f****4
发帖数: 1359 | 124 我重新看一下你的帖子再回你，我好像把你的问题理解错了
【在 a****i 的大作中提到】
: 这个意思是买没买到票其实不知道，回去等消息？
: 不然的话银行那边的速度慢了，他这儿想快也快不起来啊
|
