f****4
发帖数: 1359 | 1 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
我都做了）。
先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
制，工期和预算。
需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
就是交货，客户签字了，加个功能就加了。
工期和预算，因为之前就讨论2个方案的技术可行性，这2块没怎么提.但魏老师的方案
，主要的主机实现，是黑盒，不能堆人上去，很可能因为这一块拖累整个工期。
goodbug的方案，工期上压力还可以，因为通用方案，堆人上去。但后果也很明显：人
工上去了，人的素质总有高低，最后得靠QA把关。
技术方案可行性，之前的讨论就集中在这一块。
魏老师的方案自己给自己下了套子（其实公允的说，goodbug没有否认单机能实现，只
是认为有通用方案没有必要再去做轮子）。除非铁道部认为P民买个车票，断个电，让
他们重新买就是了。不然真要做标书，魏老师最起码得把硬件failover的方案加进去，
比如emc。好处也是有的，主机的实现方案，只要硬件上的去，招标的时候，有说服力
。你难道指望几个小时的招标里面和行政领导讲解一下现在最流行的技术是如何如何的
牛叉？除非标的已经内定了，要找人陪标，不然用新技术的方案都进不了第二轮。。。
goodbug的方案技术可行。但真在天朝招标，进不了第二轮。
剩下来的就是实现难度和风险控制。
简化一点说，你觉得这块码工实现得小心的或者只是QA测试小心点，难度+1；你觉得码
工实现还得QA仔细测试的，难度+2；你觉得就那样，还是有点玄的，难度+3，风险上面
插面小红旗。有额外风险的，另插小红旗。大家都要QA测试，或者码工实现小心点的，
我就不写了，浪费字。
魏老师的方案：
首先，主机实现这块。1个人做，除非你已经积累了很高质量的code base，不然难度+3
，风险+1。但是假设魏老师自己去招标的话，那只能说是有高质量的代码库了，我就算
只需要QA仔细测试，但因为是一个人做，算额外风险。最后是难度+2，风险+2.
票的路径依赖问题。因为是单机，所有票都在一块，实现简单。
如果要上多线程，难度+2。
新增车次，逻辑简单，最多多花点时间刷新状态就是了
排队时间底，不需要额外工作
高throughput主机能不能撑住，风险+1
failover如果用方案解决，只算风险+1;自己解决难度+3，风险+1，还得再风险+1
goodbug的方案
都是通用方案，只要选择成熟的，只要QA帮着测试即可，难度+1；但是如果有bug，你
能不能在同期内得到解决？？风险+1。如果要自己解决得好好测测，难度+2。
票的路径依赖问题。终于理解了为什么goodbug的说分票不是问题。goodbug上的就是个
分布式的数据库。概念上讲相当于一个集中数据源。这个依赖问题是靠数据库本身解决
的。还算好，可行分析里面我一直做的是完美分表的假设，影响不大。就算个难度+2吧。
新增车次，这点根据goodbug给我的解释，我给你加一个调整分表的模块不算过分吧？
我就给个难度+2。
排队时间高，既然你是通过分布式数据库来抢票，那么排队时间比我估算的还要糟糕（
既然是上锁买分段票，是在单机内存里面上锁买了块还是分布式数据库买的快？）还有
我给的那个300个人排队时间被延长的case，你一直没给打补丁，现在情况可能更坏。
如果要降低排队时间，难度+3，但我不加风险了，应该属于可控制的范围。
高throughput不需要额外工作
failover，C***那块的风险开头已经算了，但是分布式数据库分表的同时，是不是会影
响数据库服务？failover数据库做得怎么样？单个数据库连不上怎么处理的？这些我不
是很清楚你这分布式数据库能做到什么地步。风险+1不算过分吧？
再小结一下：
魏老师用一个集中的主机做集中的数据源，靠硬件性能处理高throughput，缺一个
failover。
goodbug用一个分布式数据库来做集中的数据源C****保存高throughput的订票请求，提
供了failover。
====================================================================
我知道在美国，做需求的，做分析的，做架构的，做实现的，做项目管理的，都是分开
来的。不像我们以前都是胡子眉毛一把抓的。
但做项目本身讲穿了就是个取舍的过程。需求出来了，决定可行性方案之前把业务逻辑
都过过，复杂度，风险都比较一下。这是基本素质。
动不动就拿方案压人，也不是不行。但那样有意思么？去google一下，文科生都能攒一
堆方案。（我知道肯定有人要说这些方案都是多少人的心血，经过检验的，没必要怀疑
，谁怀疑谁就是错的）
魏老师给个方案就是上来要showoff，那你们这样就是天天在这showoff喽？
goodbug人品是好的，肯耐心和我这没背景的解释。没背景不代表不能理解。没背景不
代表不能上上业务逻辑检查一下。你再做架构也不能做到不服务业务逻辑的地步。不然
一讨论，大家空对空，世界真美好。
我估计会有人拍我这个国内只会做项目的土鳖，只会纠结业务逻辑，不理解世界上最先
进的技术潮流。哪天公司需要转型了我就去学一下，没什么复杂的，又不是要我去做个
新方案出来。 |
g*****g
发帖数: 34805 | 2 这不是又来给魏老师洗地。退一万步，我老那个设计，出票不分库了，你该上啥机器上
啥机器，反正总量亿级别，又是后台处理，没啥不行的。我分库的主要目的是减少处理
延迟。再慢一亿张票当天也处理了。
说到传统数据库分库，Oracle之类的都有很好支持，难度在于找个好的划分，实现是基
本对应用透明的，没有难度。如果分库性能比不分还差，就没人去分库了。在完美分库
的情况下，在大部分交易不跨库的情况下，性能都远高于不分。你也不想想Oracle折腾
这个feature干啥，你这个完全是无稽之谈。
再说责任，我Cassandra的订单系统，是一周可以Prototype一个，立马上量测试验证是
否可行的。NoSQL归NoSQL，好歹是无数前人用过的。魏老师是自己写了一个这样的
NoSQL系统，又log又rollback的。你凭啥相信他能比Cassandra写得好？failover,
fault tolerant, 都是很复杂的东西，10%的要求就能搞掉你90%的时间。
风险在哪里？魏老师大部分时间，都要花在这个NoSQL轮子上，没时间写商业逻辑。而
且不写好，没法上量测试。能不能行全靠他一张嘴。你要是一个好的项目负责人，就应
该知道难度最大的地方，要尽量早测试，出了问题有时间改。这个轮子不行，我可以换
轮子。你吭哧吭哧写个轮子出来不行，悲剧了。 |
z****e
发帖数: 54598 | 3 你在国内也混过，知道ibm这些外企主要在国企里面做什么吧？
基本上如果一个系统是从无到有，很少需要外企介入
或者说，外企可以介入的空间很少
你会写java，我也会写java，你会sql，我也会sql，没什么大不了的
顶多说买点websphere,oracle db这些产品
但是一旦做大了，国企那帮老爷们基本上就难堪大任了
这个时候就会跑去找ibm，找sun，找bea，找accenture，找各种外企
问，哎呀，这个不行啊，我这个做不下去了，怎么办怎么办？
ibm等公司这个时候就会派一队consultants过来
告诉这些老爷们怎么做，而其中一个最重要的考虑
就是不允许重建现有系统，因为成本太高以至于无法承受
所以必需在现有系统之上做后续开发
这恰好是一个低级码农和那些挂着各种构架师头衔的consultants的区别
低级码农遇到一个不熟悉的系统，就成天想着推翻重做
但是现实中不会允许你这么搞
所以就看你怎么办了，web service只是其中的一个手段
还有其它很多很多办法，当年ibm, sun这些构架师在一些大型国企里面
就是做这种事，而且如果去参加它们组织的seminar
那些人也会告诉你，我们ibm，我们sun，我们bea什么什么
比其它it企业强就强在，我们的方案不需要重构任何现有系统
会沿用现有系统，就这一个基本前提，把外企和一般搞外包民企给区分开来
码代码不要为了码而码，要明白为什么码，否则吃力不讨好
【在 f****4 的大作中提到】
: 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
: 码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
: 国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
: 做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
: 我都做了）。
: 先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
: 制，工期和预算。
: 需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
: 意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
: 实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
|
x****d
发帖数: 1766 | 4 所以现实可行的方案，没有唯一，哈哈，就是rest api，你说的我举双脚同意。
现有系统不可能一夜推翻。这个很关键。
考虑将来进一步赚钱，有了这个api做啥都好搞。把这个攥在手里，基本以后跟铁字有
关的项目都稳拿了。竞争对手谁会去做你api的下游？找死么？
公安部要是要做一个人口流动监控排查系统，没有这个api根本没有外企下手的地方。
肯定又是上新项目ETL倒数据做datawarehouse等等，等等。有了，你就忽悠去吧，
storm，cassandra都有的你搞。
改革开放，开放是什么？就是你做不了的让别人去做，铁道部搞这搞那，不叫开放，
rest api让能人去搞，那叫开放。
【在 z****e 的大作中提到】
: 你在国内也混过，知道ibm这些外企主要在国企里面做什么吧？
: 基本上如果一个系统是从无到有，很少需要外企介入
: 或者说，外企可以介入的空间很少
: 你会写java，我也会写java，你会sql，我也会sql，没什么大不了的
: 顶多说买点websphere,oracle db这些产品
: 但是一旦做大了，国企那帮老爷们基本上就难堪大任了
: 这个时候就会跑去找ibm，找sun，找bea，找accenture，找各种外企
: 问，哎呀，这个不行啊，我这个做不下去了，怎么办怎么办？
: ibm等公司这个时候就会派一队consultants过来
: 告诉这些老爷们怎么做，而其中一个最重要的考虑
|
p*****b
发帖数: 291 | 5 为什么没有人提Enterprise integration pattern(Message bus)? |
f****4
发帖数: 1359 | 6 可以展开说说么？谢谢
【在 p*****b 的大作中提到】
: 为什么没有人提Enterprise integration pattern(Message bus)?
|
f****4
发帖数: 1359 | 7 =这不是又来给魏老师洗地。退一万步，我老那个设计，出票不分库了，你该上啥机器上
=啥机器，反正总量亿级别，又是后台处理，没啥不行的。我分库的主要目的是减少处理
=延迟。再慢一亿张票当天也处理了。
别废话，我第一帖子里面就在等你打补丁。后面300个人因为你们的假设：queue排队必
须公平block在哪。这个假设你们放在那，不管你用什么东西实现数据库，分布的也好
，不分布的也好，延迟就在那。
前面有提到一个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前，一天一天放出来的。这样不必要的等待
时间会累积起来。这个问题是你们的假设引起的。欢迎打补丁。
=说到传统数据库分库，Oracle之类的都有很好支持，难度在于找个好的划分，实现是基
=本对应用透明的，没有难度。如果分库性能比不分还差，就没人去分库了。在完美分库
=的情况下，在大部分交易不跨库的情况下，性能都远高于不分。你也不想想Oracle折腾
=这个feature干啥，你这个完全是无稽之谈。
我一直不明白为什么zhaoc和你要说魏老师的方案要锁票。你给我解释了一下说是分布
式的数据库，然后买分段票要先lock再买，我才明白原因。魏老师那一台主机，epoll
之后，要是单线程实现，要锁什么？就因为你买分段票，数据库要先lock才能买，他那
一个内存计数器，单线程也要等你才行？他的内存计数器数据丢了，按照他的网络广播
然后等ack的log方式是可行的。哪怕他的上多线程，C++本地，多线程并发操作一些计
数器，比不过Oracle分布式读写表？？？
=再说责任，我Cassandra的订单系统，是一周可以Prototype一个，立马上量测试验证是
=否可行的。
=风险在哪里？魏老师大部分时间，都要花在这个NoSQL轮子上，没时间写商业逻辑。而
=且不写好，没法上量测试。
做人不能这样，一到自己就能上量测试，一到别人就没法上量测试。公平一点可以不？
？？
只要有硬件支持，你要多大的量，我帮你产生。OK? |
z****e
发帖数: 54598 | 8 你不上锁也可以啊
单线程就上咯，不早就说了单线程，魏老师又给否了罢了
如果多线程对同一票出现争抢怎么办？
主机，分布式，单线程什么都是魏老师否过的
现在魏老师又往分布式上发展
这不是自己打自己脸么？
器上
处理
【在 f****4 的大作中提到】
: =这不是又来给魏老师洗地。退一万步，我老那个设计，出票不分库了，你该上啥机器上
: =啥机器，反正总量亿级别，又是后台处理，没啥不行的。我分库的主要目的是减少处理
: =延迟。再慢一亿张票当天也处理了。
: 别废话，我第一帖子里面就在等你打补丁。后面300个人因为你们的假设：queue排队必
: 须公平block在哪。这个假设你们放在那，不管你用什么东西实现数据库，分布的也好
: ，不分布的也好，延迟就在那。
: 前面有提到一个queue排队公平的问题。这是zhaoc和goodbug一直要实现的。还是2个车
: 次，不同数据库的例子。1还是要先买K356然后K789到常熟。2只是买K789上海到南京。
: 2的请求在B数据库上晚于1.在A上面，1的请求之前已经有200个买票请求了。在B上面
: K789还有一张票，1排第一个，2排第二个，然后后面还有300个买票请求。因为排队公
|
T********i
发帖数: 2416 | 9 说你基本功不扎实你还不服气。
多线程抢票，每个路段是纳秒级别的。
假定100ns。如果某路段售完还要把其他路段强盗的还回去，也是每路段100ns。
别忘了，我有至少10个CPU core可用。
假定平均每张票跨度10个路段，我的系统的throughput是10/2 = 5 million requests/
second。
平均跨度20个路段，降为2.5 million requests/second。
明年二月份4 way sandy bridge server推出。瞬间增加一倍。
【在 z****e 的大作中提到】
: 你不上锁也可以啊
: 单线程就上咯，不早就说了单线程，魏老师又给否了罢了
: 如果多线程对同一票出现争抢怎么办？
: 主机，分布式，单线程什么都是魏老师否过的
: 现在魏老师又往分布式上发展
: 这不是自己打自己脸么？
:
: 器上
: 处理
|
z****e
发帖数: 54598 | 10 你不是说是单机么？不挑机器么？
现在现在又来10个cpu core？
分布式多几个core我信，但是你说随便一个server就10个cpu core，我不信
requests/
【在 T********i 的大作中提到】
: 说你基本功不扎实你还不服气。
: 多线程抢票，每个路段是纳秒级别的。
: 假定100ns。如果某路段售完还要把其他路段强盗的还回去，也是每路段100ns。
: 别忘了，我有至少10个CPU core可用。
: 假定平均每张票跨度10个路段，我的系统的throughput是10/2 = 5 million requests/
: second。
: 平均跨度20个路段，降为2.5 million requests/second。
: 明年二月份4 way sandy bridge server推出。瞬间增加一倍。
|
|
|
T********i
发帖数: 2416 | 11 双CPU xeon本来就是16个CPU core。两个给网卡。我给自己留10个不过分吧？
【在 z****e 的大作中提到】
: 你不是说是单机么？不挑机器么？
: 现在现在又来10个cpu core？
: 分布式多几个core我信，但是你说随便一个server就10个cpu core，我不信
:
: requests/
|
z****e
发帖数: 54598 | 12 那原来还是挑了机器的
xeon有的是124cores的
【在 T********i 的大作中提到】
: 双CPU xeon本来就是16个CPU core。两个给网卡。我给自己留10个不过分吧？
|
z****e
发帖数: 54598 | 13 你这种内存数据库，简单问题
原有系统怎么办？
你做事理想假设太多
内存数据库凭什么用你的？
那么多可以用，redis就蛮好
requests/
【在 T********i 的大作中提到】
: 说你基本功不扎实你还不服气。
: 多线程抢票，每个路段是纳秒级别的。
: 假定100ns。如果某路段售完还要把其他路段强盗的还回去，也是每路段100ns。
: 别忘了，我有至少10个CPU core可用。
: 假定平均每张票跨度10个路段，我的系统的throughput是10/2 = 5 million requests/
: second。
: 平均跨度20个路段，降为2.5 million requests/second。
: 明年二月份4 way sandy bridge server推出。瞬间增加一倍。
|
T********i
发帖数: 2416 | 14 希望你要点脸。
我说了，预算1-2万一台。自然知道我要买啥机器。
你不会指望给我一台计算器吧？
【在 z****e 的大作中提到】
: 那原来还是挑了机器的
: xeon有的是124cores的
|
T********i
发帖数: 2416 | 15 呵呵。抱歉。和内存数据库真的没有半毛钱关系。
你的基本功有大问题。
【在 z****e 的大作中提到】
: 你这种内存数据库，简单问题
: 原有系统怎么办？
: 你做事理想假设太多
: 内存数据库凭什么用你的？
: 那么多可以用，redis就蛮好
:
: requests/
|
z****e
发帖数: 54598 | 16 不好意思，我不挑机器，我是真不挑机器
随便一台server我就能用，真没怎么认真观察过机器是什么机器
【在 T********i 的大作中提到】
: 希望你要点脸。
: 我说了，预算1-2万一台。自然知道我要买啥机器。
: 你不会指望给我一台计算器吧？
|
g*****g
发帖数: 34805 | 17 现成的轮子，加一点商业逻辑，就可以立刻上量测试。魏老师自己写很难的轮子，自然
是要等，很奇怪吗？
器上
处理
【在 f****4 的大作中提到】
: =这不是又来给魏老师洗地。退一万步，我老那个设计，出票不分库了，你该上啥机器上
: =啥机器，反正总量亿级别，又是后台处理，没啥不行的。我分库的主要目的是减少处理
: =延迟。再慢一亿张票当天也处理了。
: 别废话，我第一帖子里面就在等你打补丁。后面300个人因为你们的假设：queue排队必
: 须公平block在哪。这个假设你们放在那，不管你用什么东西实现数据库，分布的也好
: ，不分布的也好，延迟就在那。
: 前面有提到一个queue排队公平的问题。这是zhaoc和goodbug一直要实现的。还是2个车
: 次，不同数据库的例子。1还是要先买K356然后K789到常熟。2只是买K789上海到南京。
: 2的请求在B数据库上晚于1.在A上面，1的请求之前已经有200个买票请求了。在B上面
: K789还有一张票，1排第一个，2排第二个，然后后面还有300个买票请求。因为排队公
|
z****e
发帖数: 54598 | 18 是没关系，没有必要用你的而已
【在 T********i 的大作中提到】
: 呵呵。抱歉。和内存数据库真的没有半毛钱关系。
: 你的基本功有大问题。
|
z****e
发帖数: 54598 | 19 俺是纯粹的不挑机器，你是伪的不挑机器
算了半死
【在 T********i 的大作中提到】
: 希望你要点脸。
: 我说了，预算1-2万一台。自然知道我要买啥机器。
: 你不会指望给我一台计算器吧？
|
f****4
发帖数: 1359 | 20 米高同学，你看，你们在showoff那些很酷的技术的时候，我一般不插话的，听听就好
，不定什么时候就用上了。
我知道你想showoff一下ibm，挂着架构师的consultants开个培训会是多么的牛叉。
但是，论到外企里面，做东西的牛叉程度，你怎么不提一下SAP呢？如果你不知道SAP有
多牛叉，我简单介绍一下：只要你给得起钱，你提需求，它给你产品，注意了，是产品
，不是方案。当然了，你非要一个给领导报销找小姐发票的功能，人家的实施人员需要
给你定制一下的。但前提还是是给得起钱！
还有关于ibm里面的头衔。不挂一个Sr Manager的头衔，不弄张架构师的名片，你知道
他们去了客户那连杯水都喝不到么？我下铺兄弟现在还奋战在ibm打单第一线，这是他
自己解释他Sr Manager头衔的时候和我说的。
看你的样子应该给国企做过，国企那预算不是问题，问题是要确保出了问题领导不能担
当责任。
你知道国内那会erp混战最乱的时候是个什么样子？客户指望你的系统啥都解决了，但
不付钱。
做个项目多少成本能做下来，这关系到你自己的位置，兄弟们的福利。
还“不需要重构任何现有系统会沿用现有系统”我知道你应该没做过标书，不过我可以
告诉你一下。大型企业/政府，招标的时候，第三方数据接口是标配。
然后我还知道你就知道web service这一个办法。我再教你一招：看看能不能破解对方
系统的数据库。只要不是同步更新表单，就够用了。哦，我给你解释一下啥叫表单，财
务上面，可能是一笔流水帐，用在零售业，就是一张pos机交易单，用在固定资产管理
上可能就是张调料单。头发少个十几根是很正常的。后来发现了个好办法，直接去挖人
。再不行大家出来喝喝茶吃吃饭，你懂的。
国内就是丛林法则。活下来就好。
要不是看到有些人张口架构师，闭口架构师，我都不想提国内经历。
怎么了，架构师就不用考虑业务逻辑实现的可能性了？？？
【在 z****e 的大作中提到】
: 你在国内也混过，知道ibm这些外企主要在国企里面做什么吧？
: 基本上如果一个系统是从无到有，很少需要外企介入
: 或者说，外企可以介入的空间很少
: 你会写java，我也会写java，你会sql，我也会sql，没什么大不了的
: 顶多说买点websphere,oracle db这些产品
: 但是一旦做大了，国企那帮老爷们基本上就难堪大任了
: 这个时候就会跑去找ibm，找sun，找bea，找accenture，找各种外企
: 问，哎呀，这个不行啊，我这个做不下去了，怎么办怎么办？
: ibm等公司这个时候就会派一队consultants过来
: 告诉这些老爷们怎么做，而其中一个最重要的考虑
|
|
|
w*******r
发帖数: 34 | 21 还是你的帖子有干货，总结的不错，顶一个。
zhaoce老扯做工程的事没意思，这玩艺不结合客户环境有啥用，现在说的就是从头开始
要怎么搞，老扯啥兼容老系统。
就魏老师这方案，单机性能肯定没得说，hot standby也说得过去，但failover做得不
像goodbug分布式那么可靠，这种系统的dr肯定得跨dc做，一旦要跨dc跨region的搞，
我没看到魏老师说到底要怎么搞，但goodbug已经说他们生产环境验证过，这很有说服
力。
【在 f****4 的大作中提到】
: 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
: 码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
: 国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
: 做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
: 我都做了）。
: 先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
: 制，工期和预算。
: 需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
: 意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
: 实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
|
z****e
发帖数: 54598 | 22 web service是一个笼统的概念
你什么都可以叫做web service
这不是一个具体的产品，你说我只会这一种？
但是这一种就涵盖了所有的可能呢？
我不是告诉你它们有多牛叉，我是告诉你它们是怎么做事的
ok？麻烦你阅读清楚
我不认为那些东西我来做会有多难，但是很显然
魏老师的做法是错的
【在 f****4 的大作中提到】
: 米高同学，你看，你们在showoff那些很酷的技术的时候，我一般不插话的，听听就好
: ，不定什么时候就用上了。
: 我知道你想showoff一下ibm，挂着架构师的consultants开个培训会是多么的牛叉。
: 但是，论到外企里面，做东西的牛叉程度，你怎么不提一下SAP呢？如果你不知道SAP有
: 多牛叉，我简单介绍一下：只要你给得起钱，你提需求，它给你产品，注意了，是产品
: ，不是方案。当然了，你非要一个给领导报销找小姐发票的功能，人家的实施人员需要
: 给你定制一下的。但前提还是是给得起钱！
: 还有关于ibm里面的头衔。不挂一个Sr Manager的头衔，不弄张架构师的名片，你知道
: 他们去了客户那连杯水都喝不到么？我下铺兄弟现在还奋战在ibm打单第一线，这是他
: 自己解释他Sr Manager头衔的时候和我说的。
|
z****e
发帖数: 54598 | 23 为什么是错的
就是因为没有办法从头搞
你今天随便找个flga进去干
有从头搞过么？
【在 w*******r 的大作中提到】
: 还是你的帖子有干货，总结的不错，顶一个。
: zhaoce老扯做工程的事没意思，这玩艺不结合客户环境有啥用，现在说的就是从头开始
: 要怎么搞，老扯啥兼容老系统。
: 就魏老师这方案，单机性能肯定没得说，hot standby也说得过去，但failover做得不
: 像goodbug分布式那么可靠，这种系统的dr肯定得跨dc做，一旦要跨dc跨region的搞，
: 我没看到魏老师说到底要怎么搞，但goodbug已经说他们生产环境验证过，这很有说服
: 力。
|
f****4
发帖数: 1359 | 24 哦，我道歉。我理解错了。
不过，请你回答一下另外的问题。我一直在等你们的补丁。
【在 g*****g 的大作中提到】
: 现成的轮子，加一点商业逻辑，就可以立刻上量测试。魏老师自己写很难的轮子，自然
: 是要等，很奇怪吗？
:
: 器上
: 处理
|
T********i
发帖数: 2416 | 25 http://www.mitbbs.com/article_t/Programming/31286477.html
这个是完整的跨DC的方案。反复说了几天了。没人注意而已。
【在 w*******r 的大作中提到】
: 还是你的帖子有干货，总结的不错，顶一个。
: zhaoce老扯做工程的事没意思，这玩艺不结合客户环境有啥用，现在说的就是从头开始
: 要怎么搞，老扯啥兼容老系统。
: 就魏老师这方案，单机性能肯定没得说，hot standby也说得过去，但failover做得不
: 像goodbug分布式那么可靠，这种系统的dr肯定得跨dc做，一旦要跨dc跨region的搞，
: 我没看到魏老师说到底要怎么搞，但goodbug已经说他们生产环境验证过，这很有说服
: 力。
|
z****e
发帖数: 54598 | 26 我一直告诉你的是
魏老师的前提就是错的
所以下面不用讨论了
前提就错了，假设就错了
做什么都是空的
这难道不是最实在的结合环境？
【在 f****4 的大作中提到】
: 米高同学，你看，你们在showoff那些很酷的技术的时候，我一般不插话的，听听就好
: ，不定什么时候就用上了。
: 我知道你想showoff一下ibm，挂着架构师的consultants开个培训会是多么的牛叉。
: 但是，论到外企里面，做东西的牛叉程度，你怎么不提一下SAP呢？如果你不知道SAP有
: 多牛叉，我简单介绍一下：只要你给得起钱，你提需求，它给你产品，注意了，是产品
: ，不是方案。当然了，你非要一个给领导报销找小姐发票的功能，人家的实施人员需要
: 给你定制一下的。但前提还是是给得起钱！
: 还有关于ibm里面的头衔。不挂一个Sr Manager的头衔，不弄张架构师的名片，你知道
: 他们去了客户那连杯水都喝不到么？我下铺兄弟现在还奋战在ibm打单第一线，这是他
: 自己解释他Sr Manager头衔的时候和我说的。
|
w*******r
发帖数: 34 | 27 我都说了，大家讨论的前提就是重新搞。我相信老魏跟goodbug也没考虑兼容现有系统
的情况。
你非要说实际做工程是啥情况啥情况，这明显是跑偏，goodbug的云在国内压根就不存
在，老魏这方案看上去就用不了几台机器，国内没哪个领导乐意你给他省钱。
【在 z****e 的大作中提到】
: 为什么是错的
: 就是因为没有办法从头搞
: 你今天随便找个flga进去干
: 有从头搞过么？
|
f****4
发帖数: 1359 | 28 所以，你的乐趣还是盯着人家错，使劲去打脸？
很fun是不是？
你知道我们破解客户数据库的时候，是被逼得没办法了，一个兄弟随口开了句玩笑么？
【在 z****e 的大作中提到】
: 我一直告诉你的是
: 魏老师的前提就是错的
: 所以下面不用讨论了
: 前提就错了，假设就错了
: 做什么都是空的
: 这难道不是最实在的结合环境？
|
z****e
发帖数: 54598 | 29 我也告诉你了，我说的就是你的前提就错了
这个可能性不存在
ok？
国内当然有cloud，马云和百度都有，新浪也有
amazon在国内也没有被封，rhcloud也进军天朝了，天天搞seminar
麻烦你不要想当然滴假设各种前提
【在 w*******r 的大作中提到】
: 我都说了，大家讨论的前提就是重新搞。我相信老魏跟goodbug也没考虑兼容现有系统
: 的情况。
: 你非要说实际做工程是啥情况啥情况，这明显是跑偏，goodbug的云在国内压根就不存
: 在，老魏这方案看上去就用不了几台机器，国内没哪个领导乐意你给他省钱。
|
w*******r
发帖数: 34 | 30 多谢多谢 我好好看一下
【在 T********i 的大作中提到】
: http://www.mitbbs.com/article_t/Programming/31286477.html
: 这个是完整的跨DC的方案。反复说了几天了。没人注意而已。
|
|
|
a****i
发帖数: 1182 | 31 我觉得你这个有点偏，goodbug里要做
票的路径依赖问题。要分票。要新增车次
这些TW方案怎么做的？他的数据从哪来，写到哪去？
只说了log、IO，高throughput
什么细节都没有，TW就不用解决路径、分票，新增车次……？
就着重说了IO，他是想把数据也放在那台机器上？
【在 f****4 的大作中提到】
: 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
: 码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
: 国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
: 做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
: 我都做了）。
: 先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
: 制，工期和预算。
: 需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
: 意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
: 实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
|
w*******r
发帖数: 34 | 32 行，你要说实际环境可以。国内自己做的云就别扯了，有啥成功的案例没？aws上的案
例他们能做到不。不能做到aws那种商业规模了就别谈给铁道部用的事。光支持跑个网
站啥的就别说自己那是云，ok？
国外aws,rhccloud出来搞seminar这也叫个事啊，服务器在哪国呢？铁道部能把数据放
到境外的服务器上么？goodbug那也就是得靠aws来搞，是放东京还是放新加坡啊
【在 z****e 的大作中提到】
: 我也告诉你了，我说的就是你的前提就错了
: 这个可能性不存在
: ok？
: 国内当然有cloud，马云和百度都有，新浪也有
: amazon在国内也没有被封，rhcloud也进军天朝了，天天搞seminar
: 麻烦你不要想当然滴假设各种前提
|
f****4
发帖数: 1359 | 33 明天回你吧，睡觉去了。
你说这mitbbs又不发我加班费，我熬夜，作啥。。。
【在 a****i 的大作中提到】
: 我觉得你这个有点偏，goodbug里要做
: 票的路径依赖问题。要分票。要新增车次
: 这些TW方案怎么做的？他的数据从哪来，写到哪去？
: 只说了log、IO，高throughput
: 什么细节都没有，TW就不用解决路径、分票，新增车次……？
: 就着重说了IO，他是想把数据也放在那台机器上？
|
z****e
发帖数: 54598 | 34 所以我只定位了web server到cloud上去用
这个成功的例子太多了
实际上真正解决这个问题的时候，铁道部就咨询了淘宝的架构
你看，其实我说的都是实实在在发生过的事
不是各种假设
【在 w*******r 的大作中提到】
: 行，你要说实际环境可以。国内自己做的云就别扯了，有啥成功的案例没？aws上的案
: 例他们能做到不。不能做到aws那种商业规模了就别谈给铁道部用的事。光支持跑个网
: 站啥的就别说自己那是云，ok？
: 国外aws,rhccloud出来搞seminar这也叫个事啊，服务器在哪国呢？铁道部能把数据放
: 到境外的服务器上么？goodbug那也就是得靠aws来搞，是放东京还是放新加坡啊
|
g*****g
发帖数: 34805 | 35 我考虑了，我的系统主要是订单系统，这个系统原来不存在。后台原来的支付出票系统，
只要能撑得住继续用我没意见。
【在 w*******r 的大作中提到】
: 我都说了，大家讨论的前提就是重新搞。我相信老魏跟goodbug也没考虑兼容现有系统
: 的情况。
: 你非要说实际做工程是啥情况啥情况，这明显是跑偏，goodbug的云在国内压根就不存
: 在，老魏这方案看上去就用不了几台机器，国内没哪个领导乐意你给他省钱。
|
g*****g
发帖数: 34805 | 36 我一直没弄明白你想要什么，合理分库下，分布式数据库比单数据库快是业界公认的。
你要我验证一个定理有意义吗？实在不能理解，我不说了，不分库，直接用原来的
legacy
出票系统。他们是有大机器的。
【在 f****4 的大作中提到】
: 哦，我道歉。我理解错了。
: 不过，请你回答一下另外的问题。我一直在等你们的补丁。
|
g*****g
发帖数: 34805 | 37 我是给个业界最火的cost efficient方案。铁道部不差钱，自己建几个DC不就完了吗。
机器当然还是可以继续平民硬件的。IBM那种主机，一台可以买x86 server一千台。
魏老师是打算一万块钱买硬件的，我没有那么扣。
【在 w*******r 的大作中提到】
: 行，你要说实际环境可以。国内自己做的云就别扯了，有啥成功的案例没？aws上的案
: 例他们能做到不。不能做到aws那种商业规模了就别谈给铁道部用的事。光支持跑个网
: 站啥的就别说自己那是云，ok？
: 国外aws,rhccloud出来搞seminar这也叫个事啊，服务器在哪国呢？铁道部能把数据放
: 到境外的服务器上么？goodbug那也就是得靠aws来搞，是放东京还是放新加坡啊
|
P********l
发帖数: 452 | |
d********u
发帖数: 5383 | 39 现在IT上所谓的最新技术，基本上就是骗子用来蒙外行的。搞那些技术的就更逗了，很
多毛都不懂也敢出来现。比如现在最热的所谓ML吧，10个有9个就是瞎蒙，还有1个以为
是make love...
【在 f****4 的大作中提到】
: 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
: 码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
: 国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
: 做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
: 我都做了）。
: 先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
: 制，工期和预算。
: 需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
: 意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
: 实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
|
W***o
发帖数: 6519 | 40 good post
【在 f****4 的大作中提到】
: 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
: 码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
: 国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
: 做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
: 我都做了）。
: 先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
: 制，工期和预算。
: 需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
: 意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
: 实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
|
|
|
z****e
发帖数: 54598 | 41 这叫打脸吗？
魏老师开始死不认账
昨天认账了之后，我就懒得再说了
是你们打酱油的不行，人家都认账了，你们还想帮着掩盖
【在 f****4 的大作中提到】
: 所以，你的乐趣还是盯着人家错，使劲去打脸？
: 很fun是不是？
: 你知道我们破解客户数据库的时候，是被逼得没办法了，一个兄弟随口开了句玩笑么？
|
b*******s
发帖数: 5216 | 42 redis不错，解决了我一个问题
【在 z****e 的大作中提到】
: 你这种内存数据库，简单问题
: 原有系统怎么办？
: 你做事理想假设太多
: 内存数据库凭什么用你的？
: 那么多可以用，redis就蛮好
:
: requests/
|
T****i
发帖数: 46 | 43 现在最流行的技术是这个吗：
http://phdtree.org/
http://phdtree.org/toplist/field/cs/
【在 f****4 的大作中提到】
: 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
: 码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
: 国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
: 做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
: 我都做了）。
: 先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
: 制，工期和预算。
: 需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
: 意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
: 实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
|
f****4
发帖数: 1359 | 44 首先，一个设计方案肯定是有取舍的。这点你要是不承认，我就没法和你讲了。我只能
说，就算我相信你的方案每个方面都是最优的，但我认为你最优的过程是要增加系统复
杂度的，我还会认为这块地方实施有风险。
他们2个人其实多少都有提怎么处理票。我懒得去推了。
你去看我分析魏老师的方案的时候，新增车次，那个，我明确提到，牺牲时间，花一个
小时去导入。导入，简单吧，导入不成，再来一次。单机操作内存的事情。哪怕你U盘
拷贝失败，再来一次就是了。我还放了个假设在那，不在线兼容现有的票务系统，不然
讨论起来更复杂了。
分段票那块，魏老师的方案上主机。goodbug也认为主机能做的，只是他认为这么低的
成本的主机处理不了这么高的throughput。你看我那提的，90+CPUs，36G的server，5
万美金。我认为就是要实现，也得加点预算。不然讨论不下去了。然后就是单线程，多
线程实现的区别了。单线程，不需要加预算，好处内存不用加锁。多线程，要加预算，
坏处实现复杂一点。但是一个买票的，C++，单机的程序，实现起来你觉得这个风险大
么？？？
我看到后面goodbug的回帖，我知道他还是没明白他到底差了哪一块——他的整体方案
，取得是每个技术的优点，没有任何的舍。就像我开头说的，就算我相信你能做到，但
你必然增加实现难度，增加风险。哪怕他舍掉如何一个东西，他的方案都比现在有说服
力。
他的方案，C*** 系统处理了高throughput，然后慢慢得feed那些买票请求到数据库上
面去。先不说这个数据库到底是分布的还是单机的。我们就当作是一个唯一的数据源。
简单点看就是一个能处理高throughput的message queue，这个queue还自带failvoer的
支持，然后加个数据源。这个数据源的throughput是更不上高峰的throughput的，不然
也不放这个message queue在这。那么你买票时间预期有个额外的delay，对不对？
先说分布式数据库。你既然是是分布式数据库，那就放在一台主机上应该不能发挥到极
致。他的分段票处理，是数据库分别去尝试锁各个段的票。都锁到了，出票成功。他说
为了抢票过程快，需要让大多数的分段票的Transaction在同一张表上。然后他说了，
为了提高数据处理的throughput，可以按照天，车次分表。这是矛盾的。2者只能有其
一。这里我都没有和他争论他估算的分段票的概率：以前我记得铁路主干网是3纵3横，
主干网上的车次，14节车厢能有2节卖给不需要转车的人，就谢天谢地了。春运码工都
是欠发达地区来的人，很少在主干网沿线的。
我相信你能把throughput和响应速度做到最佳平衡，但是你觉得要额外付出点系统复杂
度，增加点风险么？比如车次新增了怎么办？你要说我有点偏，我也没办法。好，我相
信分布式数据库是公认的多快好省：自带failover恢复，各种各种功能，实现简单。你
凭心而论，如果只是抢个票的话，多段票多点的情况下，是C++单机快，还是分布式的
数据库快？就算我相信了你分布式的数据库快，我再问一句，数据库出问题，需要客户
支持怎么办？你一直说魏老师的方案主机那块是黑盒，这块东西对你就是白盒？IBM
DB2挂了，等客户支持的事情又不是没碰到过。你然后再和我来一遍分布式数据库是公
认的多快好省？
后面goodbug说不行就上单机数据库。可以啊，你上单机数据库throughput更低了吧？
分段票的问题和数据库的类型其实没关系的，2种选择都需要处理的。新增车次也是。
我相信你现在单机数据库的实现，抢个票，和C++单机一样快。但是，你这是单机数据
库，你要做热备份吧？当机的机会有多大？单次当机时间会有多长？你上hot standby
，可以啊，你自己都说了，这个余票数据不能上C**** DB，你得给个方案吧？
还有个例子，你看看说的那300个人排队时间被延长的那个。就因为他们来了个全queue
排队公平。ok，你说可以有，我相信你可以有。但你怎么降低买票的等待时间？这个和
任何的方案实现没有关系，就是你们自己做的设计假设。我给魏老师的方案的假设是牺
牲一点排队的公平性，就是不管你划钱成功与否，后一个人来抢票就是失败的，一直要
等到交易不成功退票之后的人才能重新买到票。这就是取舍。
我说了，上现成技术的方案不是不行，但你上个方案就只要这个方案最优的地方，确不
考虑会对现有系统产生的影响是不行的。方案不可能是唯一的，只是取舍不同。但你一
点不舍，你的说服力不够。
又码了半天字，就在这一块回了googbug后面的提问吧。
【在 a****i 的大作中提到】
: 我觉得你这个有点偏，goodbug里要做
: 票的路径依赖问题。要分票。要新增车次
: 这些TW方案怎么做的？他的数据从哪来，写到哪去？
: 只说了log、IO，高throughput
: 什么细节都没有，TW就不用解决路径、分票，新增车次……？
: 就着重说了IO，他是想把数据也放在那台机器上？
|
a****i
发帖数: 1182 | 45 你的理解是有问题的。上锁肯定是内存里上，不是数据库上锁。
TW那块只是他有，只听他号称“我的系统”怎么怎么样，更进一步的细节一点没有，当
然是黑盒。GB那块要不是标准，要不是open source，怎么不是白盒？
如果你私下对TW的有了解，那是另外一回事。
我现在越来越糊涂了，TW一直说他的超级牛机只做核心业务，周边的付款啥的由别的机
器做。他这个核心业务到底是啥？
对了，他的牛机还嵌了一个web server，这是要把前端页面的活也干了？
5
【在 f****4 的大作中提到】
: 首先，一个设计方案肯定是有取舍的。这点你要是不承认，我就没法和你讲了。我只能
: 说，就算我相信你的方案每个方面都是最优的，但我认为你最优的过程是要增加系统复
: 杂度的，我还会认为这块地方实施有风险。
: 他们2个人其实多少都有提怎么处理票。我懒得去推了。
: 你去看我分析魏老师的方案的时候，新增车次，那个，我明确提到，牺牲时间，花一个
: 小时去导入。导入，简单吧，导入不成，再来一次。单机操作内存的事情。哪怕你U盘
: 拷贝失败，再来一次就是了。我还放了个假设在那，不在线兼容现有的票务系统，不然
: 讨论起来更复杂了。
: 分段票那块，魏老师的方案上主机。goodbug也认为主机能做的，只是他认为这么低的
: 成本的主机处理不了这么高的throughput。你看我那提的，90+CPUs，36G的server，5
|
a****i
发帖数: 1182 | 46 魏老师的方案：
首先，主机实现这块。1个人做，除非你已经积累了很高质量的code base，不然难度+3
，风险+1。但是假设魏老师自己去招标的话，那只能说是有高质量的代码库了，我就算
只需要QA仔细测试，但因为是一个人做，算额外风险。最后是难度+2，风险+2.
我觉得你太相信TW了。1个人做主机实现,你知道他积累了很高质量的code base,有高质
量的代码库? 接这样的标书，出了问题，怕是第一个就是查你和他有没有利益往来吧。
【在 f****4 的大作中提到】
: 说一下个人背景，各位自己判断是否有必要浪费时间看我码的字。
: 码完了比较之后码一点个人感想，有兴趣的就看，没兴趣的跳过，谢谢。
: 国内6年做项目的经历，做过通用财务（就是实现），石化行业固定资产（需求不是我
: 做的，别的归我负责的），服装行业预算和政府的财政预算（标书不是我写的，剩下的
: 我都做了）。
: 先说一下工程角度比较什么。需求分析，技术方案可行性，项目实现难度，项目风险控
: 制，工期和预算。
: 需求分析放这不伦不类，但需求是基础，基于需求给方案。你得了解用户想要个什么玩
: 意，哪些是必须实现的，哪些是可以讨价还价的。你学过的软件工程，课本上说的教条
: 实际行不通。国内的需求，更像agile开发过程。签了合同，用户想改需求就改了。你
|
f****4
发帖数: 1359 | 47
你自己去看GB回我的帖子。除非他心里想的是通过内存解决上锁问题，都拿到锁之后再
去更新数据库。但这和他讲的不一样。你的这个讲法，相当于他的C*** message queue
和数据源之间，加了一个内存的调度。GB一直说那些东西是数据库提供的，所以没有
实现难度。然后你的这个内存调度需要保存状态吧？这个状态用什么方案？throughput
能支持么？
这就是我一直废话的，你的设计不能不全局考虑，光用每个方案好的地方是不可能的。
或者你说的内存里上锁是指数据库的锁实现是跑在内存里面的？有点不确定。
我私下对TW没什么了解，就是看到他的方案有点意思，推敲了推敲。open source我算
你识白盒的。数据库，我一直按照oracle来的。这算是业界标准了吧？出个问题，只能
等客户支持。这不是白盒。你要是说他上的是开源数据库。行啊，代码是有了，出个问
题，你得等别人fix，还是你认为自己fix就是分分钟钟的事情？
一个高throughput的，查询/订票/退票的状态自动机。GD把峰值的买票请求延迟在C***
*（那个能够处理高throughput的message queue）里面。TW想让那个状态自动机来多少
请求尽快处理掉这些请求，然后再把慢的交易这部分分散到划钱上面。
GD在处理的入口扎了个口袋，TW在处理快到出口的地方扎了个口袋。
【在 a****i 的大作中提到】
: 你的理解是有问题的。上锁肯定是内存里上，不是数据库上锁。
: TW那块只是他有，只听他号称“我的系统”怎么怎么样，更进一步的细节一点没有，当
: 然是黑盒。GB那块要不是标准，要不是open source，怎么不是白盒？
: 如果你私下对TW的有了解，那是另外一回事。
: 我现在越来越糊涂了，TW一直说他的超级牛机只做核心业务，周边的付款啥的由别的机
: 器做。他这个核心业务到底是啥？
: 对了，他的牛机还嵌了一个web server，这是要把前端页面的活也干了？
:
: 5
|
a****i
发帖数: 1182 | 48
queue
throughput
cassandra扯不上内存调度吧,这个GB来说，我没用过。我的感觉类似一个in memory数
据库
这么说，TW一个人写server，一个人写数据库，然后你还对他有那么大的信心。我不知
道你这个信心从何而来。出个问题，你不也得等他fix，你认为他自己fix就是分分钟钟
的事情？要这样，我可以去mysql那挖人来啊。
即便是oracle，了解的人也比TW那个不知名的数据库多得多，还可以和oracle签合同，
出了问题，赔多少钱。TW赔得起不？
【在 f****4 的大作中提到】
:
: 你自己去看GB回我的帖子。除非他心里想的是通过内存解决上锁问题，都拿到锁之后再
: 去更新数据库。但这和他讲的不一样。你的这个讲法，相当于他的C*** message queue
: 和数据源之间，加了一个内存的调度。GB一直说那些东西是数据库提供的，所以没有
: 实现难度。然后你的这个内存调度需要保存状态吧？这个状态用什么方案？throughput
: 能支持么？
: 这就是我一直废话的，你的设计不能不全局考虑，光用每个方案好的地方是不可能的。
: 或者你说的内存里上锁是指数据库的锁实现是跑在内存里面的？有点不确定。
: 我私下对TW没什么了解，就是看到他的方案有点意思，推敲了推敲。open source我算
: 你识白盒的。数据库，我一直按照oracle来的。这算是业界标准了吧？出个问题，只能
|
g*****g
发帖数: 34805 | 49 我老不想跟fzzh24 继续纠缠，他属于学不会的学生。我再说一遍，我没有提出很多方
案，我只提了一个方案，不是他提出一个问题，我抛出一个新方案，而是他问了很多问
题，给他解释了还是不能理解。
我的方案是前端下订单Cassandra，后端处理订单传统数据库。Oracle之类的数据库支
持horizontal partition应该有10年以上历史，是业界成熟的方法。事实上，如果比较
我跟魏老师的做法，他根本就没提后端处理这一块，一直在吹牛逼他的下单系统。
fzzh24对我的所有后端的质疑，都可以用在魏老师身上。
魏老师已经说了，后端处理订单就算单线程写access，一天也弄完了。我的照做就是。 |
a****i
发帖数: 1182 | 50
我感觉前端后端有点疑惑，应该都是后端。in memory数据在cassandra，persist到
oracle。是这样吧？
【在 g*****g 的大作中提到】
: 我老不想跟fzzh24 继续纠缠，他属于学不会的学生。我再说一遍，我没有提出很多方
: 案，我只提了一个方案，不是他提出一个问题，我抛出一个新方案，而是他问了很多问
: 题，给他解释了还是不能理解。
: 我的方案是前端下订单Cassandra，后端处理订单传统数据库。Oracle之类的数据库支
: 持horizontal partition应该有10年以上历史，是业界成熟的方法。事实上，如果比较
: 我跟魏老师的做法，他根本就没提后端处理这一块，一直在吹牛逼他的下单系统。
: fzzh24对我的所有后端的质疑，都可以用在魏老师身上。
: 魏老师已经说了，后端处理订单就算单线程写access，一天也弄完了。我的照做就是。
|
|
|
g*****g
发帖数: 34805 | 51 这个前端后端的说法不是J2EE传统意义上的划分。我只是说前端来的订单数据存在
Cassandra里，这个不是内存数据库，是多DC同时写硬盘，至少2个说写好了，才算成功。
后端是出票系统，干的事情就是把单子从Cassandra读出来，把余票数据从Oracle读出
来，拿到银行去处理，更新余票。简单点单线程就好理解了。
我这里说的两个系统，唯一重叠的部分是Cassandra DB。一个写，一个读，没冲突。
【在 a****i 的大作中提到】
:
: 我感觉前端后端有点疑惑，应该都是后端。in memory数据在cassandra，persist到
: oracle。是这样吧？
|
f****4
发帖数: 1359 | 52
GB一直在喷TW的这个in memory的实现
你看，你好歹还承认了要出问题得去mysql去挖人来不是。GB连这个都不承认。他的问
题其实就一个：我的方案是最好的。
我写了那么长一段，你就没明白我到底在说什么？项目的每个环节，你得做取舍，你的
方案是不可能面面俱到的。你要靠堆方案做到面面俱到，最后的结果谁也不知道。因为
整个项目的变量太多了。
你要让人信服，你必须得舍弃一些，只要符合客户需求，通过设计降低实现的复杂度。
保证整个项目风险可控。
【在 a****i 的大作中提到】
:
: 我感觉前端后端有点疑惑，应该都是后端。in memory数据在cassandra，persist到
: oracle。是这样吧？
|
g*****g
发帖数: 34805 | 53 这不叫堆方案，这叫堆轮子。使用的方案我现在的产品环境里就有类似的。
一堆的应用给一个服务发audit log，同步写入Cassandra，数据可以高达每天1Billion
。后台另外一个应用，异步取出这些log，MapReduce做data mining。
我不会data mining，但auditlog service是我写的。
【在 f****4 的大作中提到】
:
: GB一直在喷TW的这个in memory的实现
: 你看，你好歹还承认了要出问题得去mysql去挖人来不是。GB连这个都不承认。他的问
: 题其实就一个：我的方案是最好的。
: 我写了那么长一段，你就没明白我到底在说什么？项目的每个环节，你得做取舍，你的
: 方案是不可能面面俱到的。你要靠堆方案做到面面俱到，最后的结果谁也不知道。因为
: 整个项目的变量太多了。
: 你要让人信服，你必须得舍弃一些，只要符合客户需求，通过设计降低实现的复杂度。
: 保证整个项目风险可控。
|
a****i
发帖数: 1182 | 54
GB说的是TW的IO，不是in memory
你这又说错了，说“我的方案是最好的”一直都是TW，他也一直这么说。GB反对的是这
个。
这也就是我奇怪你那么推崇TW方案的原因。他的单机方案，什么都自己做。基本上是没
有冗余的。
你说的舍弃，到底舍弃了什么？
【在 f****4 的大作中提到】
:
: GB一直在喷TW的这个in memory的实现
: 你看，你好歹还承认了要出问题得去mysql去挖人来不是。GB连这个都不承认。他的问
: 题其实就一个：我的方案是最好的。
: 我写了那么长一段，你就没明白我到底在说什么？项目的每个环节，你得做取舍，你的
: 方案是不可能面面俱到的。你要靠堆方案做到面面俱到，最后的结果谁也不知道。因为
: 整个项目的变量太多了。
: 你要让人信服，你必须得舍弃一些，只要符合客户需求，通过设计降低实现的复杂度。
: 保证整个项目风险可控。
|
z****e
发帖数: 54598 | 55 aaaiii说得没错
魏老师吹了半天得app server难道把web server的事也给做了？
没有啊
【在 a****i 的大作中提到】
:
: GB说的是TW的IO，不是in memory
: 你这又说错了，说“我的方案是最好的”一直都是TW，他也一直这么说。GB反对的是这
: 个。
: 这也就是我奇怪你那么推崇TW方案的原因。他的单机方案，什么都自己做。基本上是没
: 有冗余的。
: 你说的舍弃，到底舍弃了什么？
|
f****4
发帖数: 1359 | 56
你到底看明白GB指摘TW failover那块丢的是那块数据了么？
我给你写了个小结，从头到尾，GD是怎么用方案堆的。我说了好多遍，你上方案可以，
整个系统有考虑受到的影响么？
你再去看看那个300个人买票被延迟的case。这个已经和什么方案没关系了，纯的设计
漏洞。这就是GD啥都想要，包括全queue排队公平。
你还可以去看看GD提出的定票超卖的概念。那个完全就是设计上画蛇添足。
这2个例子我已经和具体实现方案分开来了。纯粹是设计能否简化实现了。
你要是再来和我谈方案，我也谈不出来了 -_-
【在 a****i 的大作中提到】
:
: GB说的是TW的IO，不是in memory
: 你这又说错了，说“我的方案是最好的”一直都是TW，他也一直这么说。GB反对的是这
: 个。
: 这也就是我奇怪你那么推崇TW方案的原因。他的单机方案，什么都自己做。基本上是没
: 有冗余的。
: 你说的舍弃，到底舍弃了什么？
|
f****4
发帖数: 1359 | 57 米糕同学，你又来顽皮
【在 z****e 的大作中提到】
: aaaiii说得没错
: 魏老师吹了半天得app server难道把web server的事也给做了？
: 没有啊
|
g*****g
发帖数: 34805 | 58 他就是背景跟魏老师相似，拼命给魏老师擦屁股想证明魏老师方案好的。
我老不像魏老师什么都会。什么硬件，low latency，客户端，datamining，我不会的
多了。
但春运系统，这种高并发服务器应用怎么弄，我说这个BBS上没几个比我懂的，至少
Java版没啥人会反对。
还是那句话，术业有专攻，我不装逼，但我喜欢打装逼的脸。
【在 a****i 的大作中提到】
:
: GB说的是TW的IO，不是in memory
: 你这又说错了，说“我的方案是最好的”一直都是TW，他也一直这么说。GB反对的是这
: 个。
: 这也就是我奇怪你那么推崇TW方案的原因。他的单机方案，什么都自己做。基本上是没
: 有冗余的。
: 你说的舍弃，到底舍弃了什么？
|
f****4
发帖数: 1359 | 59 屁，20行代码验证读写速度是谁提出来的？
你能把代码写成那样，我都没好意思去回帖。
你要是不放个春运的被纯讨论技术可行性，我看看你的东西也就是算了。你放个买车票
的背景在这，我推推复杂度，设计有没有漏洞怎么了？
要说做业务，我看这个BBS上还真没几个人比我懂的。有的话，我的帖子列举的也够详
细了，抓抓我的逻辑漏洞出来看看。我不管你到哪个版块去拉人。
我就借用你半句话，术业有专攻，我不装逼
我还不喜欢打装逼人的脸
米糕同学已经学会了不把脸凑过来了，这是进步。
【在 g*****g 的大作中提到】
: 他就是背景跟魏老师相似，拼命给魏老师擦屁股想证明魏老师方案好的。
: 我老不像魏老师什么都会。什么硬件，low latency，客户端，datamining，我不会的
: 多了。
: 但春运系统，这种高并发服务器应用怎么弄，我说这个BBS上没几个比我懂的，至少
: Java版没啥人会反对。
: 还是那句话，术业有专攻，我不装逼，但我喜欢打装逼的脸。
|
z****e
发帖数: 54598 | 60 我没有说错
你自己看看是不是
魏老师的server有没有做web server？
当然没有，加上web server，单机最多一个并发访问8w人
这还是静态页面的，动态页面效率要低于静态页面
我也给出数据了，如果web server撑不住，你谈什么都是空的
该挂还是要挂，魏老师没有解决任何问题
别忘了，魏老师上来就说要搞website
【在 f****4 的大作中提到】
: 米糕同学，你又来顽皮
|
|
|
g*****g
发帖数: 34805 | 61 那只是个伪码，让大家明白要做啥，魏老师要实现轮子，我是用轮子的。你要说我对IO
类库细节不够深入也行，我又没否认。这个跟架构设计没啥矛盾，你这就是黔驴技穷了。
你大可以推，可以问问题，但是你自己都承认过了。我的设计方案没有漏洞，是你背景
不足看不懂。现在又说我一遍一遍的方案推到重建，就是自己说的话当放屁了。
【在 f****4 的大作中提到】
: 屁，20行代码验证读写速度是谁提出来的？
: 你能把代码写成那样，我都没好意思去回帖。
: 你要是不放个春运的被纯讨论技术可行性，我看看你的东西也就是算了。你放个买车票
: 的背景在这，我推推复杂度，设计有没有漏洞怎么了？
: 要说做业务，我看这个BBS上还真没几个人比我懂的。有的话，我的帖子列举的也够详
: 细了，抓抓我的逻辑漏洞出来看看。我不管你到哪个版块去拉人。
: 我就借用你半句话，术业有专攻，我不装逼
: 我还不喜欢打装逼人的脸
: 米糕同学已经学会了不把脸凑过来了，这是进步。
|
f****4
发帖数: 1359 | 62 你是看贴不仔细，还是逗大家玩啊？
我是说你技术方案可行，但你没看到这贴讲的是工程考量啊？
我都已经避开具体实现细节了，就讲2个设计假设导致的2个问题，在等你打补丁。
ok？
我要是米糕同学附体，我会一直盯着你说的淘宝数据库是高耦合的，因为买了电脑还能
买尿片。LOL
IO
了。
【在 g*****g 的大作中提到】
: 那只是个伪码，让大家明白要做啥，魏老师要实现轮子，我是用轮子的。你要说我对IO
: 类库细节不够深入也行，我又没否认。这个跟架构设计没啥矛盾，你这就是黔驴技穷了。
: 你大可以推，可以问问题，但是你自己都承认过了。我的设计方案没有漏洞，是你背景
: 不足看不懂。现在又说我一遍一遍的方案推到重建，就是自己说的话当放屁了。
|
f****4
发帖数: 1359 | 63 你看，你要是回在我前面那个帖子呢，也就算了
我这个帖子是从工程角度比较实现难易度。
GD自己也说了，主机实现是没问题的。
【在 z****e 的大作中提到】
: 我没有说错
: 你自己看看是不是
: 魏老师的server有没有做web server？
: 当然没有，加上web server，单机最多一个并发访问8w人
: 这还是静态页面的，动态页面效率要低于静态页面
: 我也给出数据了，如果web server撑不住，你谈什么都是空的
: 该挂还是要挂，魏老师没有解决任何问题
: 别忘了，魏老师上来就说要搞website
|
g*****g
发帖数: 34805 | 64 你被打脸那么多次，还来，耦合是个概率问题。淘宝只要任意两件商品可以同时
checkout，
就不能杜绝distributed transaction。只要概率低就不叫高耦合，淘宝有概率低的分
法。
车票同样有。如果你相信车票是高耦合，那淘宝也是。这个叫做反证法，你是自己打脸。
你的工程考量就是完全相信魏老师，他说行就行。你是领导说了算。
【在 f****4 的大作中提到】
: 你是看贴不仔细，还是逗大家玩啊？
: 我是说你技术方案可行，但你没看到这贴讲的是工程考量啊？
: 我都已经避开具体实现细节了，就讲2个设计假设导致的2个问题，在等你打补丁。
: ok？
: 我要是米糕同学附体，我会一直盯着你说的淘宝数据库是高耦合的，因为买了电脑还能
: 买尿片。LOL
:
: IO
: 了。
|
f****4
发帖数: 1359 | 65 300个人排队时间被延长的那个补丁。
订票单超卖的画蛇添足。
你看，你这是多说多错啊，你一直有个全queue排队公平的假定在哪，现在还想让情况
更坏？？？
我一直在说，你的一堆方案每个都取最优的，不现实，你只要牺牲一个特性，就比现在
的有说服力。
你非要把脸凑过来，何苦？？？
脸。
【在 g*****g 的大作中提到】
: 你被打脸那么多次，还来，耦合是个概率问题。淘宝只要任意两件商品可以同时
: checkout，
: 就不能杜绝distributed transaction。只要概率低就不叫高耦合，淘宝有概率低的分
: 法。
: 车票同样有。如果你相信车票是高耦合，那淘宝也是。这个叫做反证法，你是自己打脸。
: 你的工程考量就是完全相信魏老师，他说行就行。你是领导说了算。
|
a****i
发帖数: 1182 | 66
这个我的理解是两个不同的情况啊，一个是单机，failover怎么做。另一个是单机怎么
scale，一旦出现高峰，超过单机处理能力，就必然丢数据。两个不挨着，也和in
memory没关系
整个系统叫方案，某一部分叫模块。MVC也叫堆方案？
300人买票被延迟，这又是什么状况，系统都没有真实存在过，怎么就知道300人排队了？
【在 f****4 的大作中提到】
: 300个人排队时间被延长的那个补丁。
: 订票单超卖的画蛇添足。
: 你看，你这是多说多错啊，你一直有个全queue排队公平的假定在哪，现在还想让情况
: 更坏？？？
: 我一直在说，你的一堆方案每个都取最优的，不现实，你只要牺牲一个特性，就比现在
: 的有说服力。
: 你非要把脸凑过来，何苦？？？
:
: 脸。
|
T********i
发帖数: 2416 | 67 Cassandra根本不适合实现queue，他这个query queue的时候还要排队。
现实中有谁用C****来实现message queue，直接fire没商量。
【在 f****4 的大作中提到】
: 300个人排队时间被延长的那个补丁。
: 订票单超卖的画蛇添足。
: 你看，你这是多说多错啊，你一直有个全queue排队公平的假定在哪，现在还想让情况
: 更坏？？？
: 我一直在说，你的一堆方案每个都取最优的，不现实，你只要牺牲一个特性，就比现在
: 的有说服力。
: 你非要把脸凑过来，何苦？？？
:
: 脸。
|
f****4
发帖数: 1359 | 68 术业有专攻，我不装逼，我不懂就问，我还不喜欢打装逼人的脸。
按照你的逻辑，我这再重复一下：
要说做业务，我看这个BBS上还真没几个人比我懂的。有的话，我的帖子列举的也够详
细了，抓抓我的逻辑漏洞出来看看。我不管你到哪个版块去拉人。
OK? |
g*****g
发帖数: 34805 | 69 我没有提并行而且所有queue完全公平，只能并行加上基本公平。你要所有queue公平，
单线程总可以了吧。你不能又要马儿跑，又要马儿不吃草吧。
【在 f****4 的大作中提到】
: 300个人排队时间被延长的那个补丁。
: 订票单超卖的画蛇添足。
: 你看，你这是多说多错啊，你一直有个全queue排队公平的假定在哪，现在还想让情况
: 更坏？？？
: 我一直在说，你的一堆方案每个都取最优的，不现实，你只要牺牲一个特性，就比现在
: 的有说服力。
: 你非要把脸凑过来，何苦？？？
:
: 脸。
|
f****4
发帖数: 1359 | 70 你这是来捣乱的，白费了我码的字
了？
【在 a****i 的大作中提到】
:
: 这个我的理解是两个不同的情况啊，一个是单机，failover怎么做。另一个是单机怎么
: scale，一旦出现高峰，超过单机处理能力，就必然丢数据。两个不挨着，也和in
: memory没关系
: 整个系统叫方案，某一部分叫模块。MVC也叫堆方案？
: 300人买票被延迟，这又是什么状况，系统都没有真实存在过，怎么就知道300人排队了？
|
|
|
g*****g
发帖数: 34805 | 71 你业务再好，你是在讨论server app架构，不专业呀，傻逼了吧。
【在 f****4 的大作中提到】
: 术业有专攻，我不装逼，我不懂就问，我还不喜欢打装逼人的脸。
: 按照你的逻辑，我这再重复一下：
: 要说做业务，我看这个BBS上还真没几个人比我懂的。有的话，我的帖子列举的也够详
: 细了，抓抓我的逻辑漏洞出来看看。我不管你到哪个版块去拉人。
: OK?
|
f****4
发帖数: 1359 | 72 你还是没看明白我给你的user case，只要按照我讲的，那个划钱失败的人，先hold住
票，在票退回来之前，后面买这张票的人直接失败，一直等票退回来才给后面的人买到
。这个结就解开了。
坏处就是做不到你的queue公平，因为有人该买到的没买到。买票的哪知道自己应该不
应该买到，你说是不是这个道理？
你也知道要马跑得给草吃啊？你的方案，每个都取最优结果，哪怕你有一个方案弱了一
点，但只要能降低实施复杂度，用户能接受。你的设计都比现在样样都好的有说服力。
你明白了没有？
你在想想为什么那个订票超卖的是多此一举吧，我解释过一次了。
【在 g*****g 的大作中提到】
: 我没有提并行而且所有queue完全公平，只能并行加上基本公平。你要所有queue公平，
: 单线程总可以了吧。你不能又要马儿跑，又要马儿不吃草吧。
|
f****4
发帖数: 1359 | 73 原来搞半天，你这高并发服务器应用就是放netflix的啊？
我一直以为你卖火车票的呢
【在 g*****g 的大作中提到】
: 你业务再好，你是在讨论server app架构，不专业呀，傻逼了吧。
|
f****4
发帖数: 1359 | 74 还是说那天netflix能卖春运火车票了？？？
【在 g*****g 的大作中提到】
: 你业务再好，你是在讨论server app架构，不专业呀，傻逼了吧。
|
g*****g
发帖数: 34805 | 75 要并行，是没有绝对公平的。这个是常识问题。大多数数据库也没有保证几乎同时到的
request
顺序处理。你要绝对公平，就单线程。你缺乏常识，纠结是你的事情。
【在 f****4 的大作中提到】
: 你还是没看明白我给你的user case，只要按照我讲的，那个划钱失败的人，先hold住
: 票，在票退回来之前，后面买这张票的人直接失败，一直等票退回来才给后面的人买到
: 。这个结就解开了。
: 坏处就是做不到你的queue公平，因为有人该买到的没买到。买票的哪知道自己应该不
: 应该买到，你说是不是这个道理？
: 你也知道要马跑得给草吃啊？你的方案，每个都取最优结果，哪怕你有一个方案弱了一
: 点，但只要能降低实施复杂度，用户能接受。你的设计都比现在样样都好的有说服力。
: 你明白了没有？
: 你在想想为什么那个订票超卖的是多此一举吧，我解释过一次了。
|
a****i
发帖数: 1182 | 76 我喜欢看打脸。
文章太多，300人那个我是漏看了。我不太能理解为什么要加queue。加锁不就完了？
再说一下状态机，我的想法是用不着，车次+座位状态就两种，有人，没人。人的状态
根本不是主要的。
【在 f****4 的大作中提到】
: 术业有专攻，我不装逼，我不懂就问，我还不喜欢打装逼人的脸。
: 按照你的逻辑，我这再重复一下：
: 要说做业务，我看这个BBS上还真没几个人比我懂的。有的话，我的帖子列举的也够详
: 细了，抓抓我的逻辑漏洞出来看看。我不管你到哪个版块去拉人。
: OK?
|
f****4
发帖数: 1359 | 77 你看，你连这个user case都打不上补丁。你就是嘴巴硬，我连一个方案都给你提出来
了，你都鸭子嘴，死硬。
那好吧，我再打一次：你的那个订票单超卖的设计还要不要？这可是你自己给我解释的
。这次能原上了么？我提示一下，我已经给你解释过一次为什么不需要了。你去看看我
的回帖仔细想想。
【在 g*****g 的大作中提到】
: 要并行，是没有绝对公平的。这个是常识问题。大多数数据库也没有保证几乎同时到的
: request
: 顺序处理。你要绝对公平，就单线程。你缺乏常识，纠结是你的事情。
|
f****4
发帖数: 1359 | 78 绝对公平是你们说的。我没给你们加这个假设，ok?
【在 g*****g 的大作中提到】
: 要并行，是没有绝对公平的。这个是常识问题。大多数数据库也没有保证几乎同时到的
: request
: 顺序处理。你要绝对公平，就单线程。你缺乏常识，纠结是你的事情。
|
g*****g
发帖数: 34805 | 79 你找出帖子我那个同时提到并发+绝对公平。纂改是人品问题。
【在 f****4 的大作中提到】
: 绝对公平是你们说的。我没给你们加这个假设，ok?
|
f****4
发帖数: 1359 | 80 你当时是说，做个排队，慢慢处理，前面的买到票了处理后面的（因为当时我提出不公
平的那个处理给你们狂喷，说你们的是公平的）
我得回去了，GD早点回家陪娃吧，mitbbs又不给发奖金
这事，你就算我人品有问题吧
算了，我就不拍你的那个订票超卖的问题了。
其实你去看看我的回帖，你订票超卖的设计假设是所有查询车票的数据必须做到实时同
步（你就是hit cache，cache也要同步的），这样才能判断什么时候开始超卖。但那样
一来，你车票查询的时候，数据同步的更新压力一下子就上去了。
其实你查询车票的时候，cache更新不用做到实时同步，那么必然有人看到还有1张票的
时候，递交了订单。虽然他的订单最后成交不了，给扔掉了。你看我不用做查询的时候
的实时同步，自然而然的就实现了超卖。
而你的超卖是有了实时同步，然后再放个20%的余量进来。这个你自己去看看你给我的
解释。
【在 g*****g 的大作中提到】
: 你找出帖子我那个同时提到并发+绝对公平。纂改是人品问题。
|
|
|
g*****g
发帖数: 34805 | 81 我从来没说过cache实时更新，你别又乱纂改我的设计。我说的是cache每秒更新一次，
由单个service去DB读，然后更新所有cache。每秒读DB一次不算啥。我的设计本来就不
禁止超额下单。
【在 f****4 的大作中提到】
: 你当时是说，做个排队，慢慢处理，前面的买到票了处理后面的（因为当时我提出不公
: 平的那个处理给你们狂喷，说你们的是公平的）
: 我得回去了，GD早点回家陪娃吧，mitbbs又不给发奖金
: 这事，你就算我人品有问题吧
: 算了，我就不拍你的那个订票超卖的问题了。
: 其实你去看看我的回帖，你订票超卖的设计假设是所有查询车票的数据必须做到实时同
: 步（你就是hit cache，cache也要同步的），这样才能判断什么时候开始超卖。但那样
: 一来，你车票查询的时候，数据同步的更新压力一下子就上去了。
: 其实你查询车票的时候，cache更新不用做到实时同步，那么必然有人看到还有1张票的
: 时候，递交了订单。虽然他的订单最后成交不了，给扔掉了。你看我不用做查询的时候
|
a****i
发帖数: 1182 | 82 你对超卖怨气很大啊，这个是照着买机票来的。不过就是要客户同意这个业务逻辑才行。
比如说，哪位站着回去，给个半价啥的。
【在 f****4 的大作中提到】
: 你当时是说，做个排队，慢慢处理，前面的买到票了处理后面的（因为当时我提出不公
: 平的那个处理给你们狂喷，说你们的是公平的）
: 我得回去了，GD早点回家陪娃吧，mitbbs又不给发奖金
: 这事，你就算我人品有问题吧
: 算了，我就不拍你的那个订票超卖的问题了。
: 其实你去看看我的回帖，你订票超卖的设计假设是所有查询车票的数据必须做到实时同
: 步（你就是hit cache，cache也要同步的），这样才能判断什么时候开始超卖。但那样
: 一来，你车票查询的时候，数据同步的更新压力一下子就上去了。
: 其实你查询车票的时候，cache更新不用做到实时同步，那么必然有人看到还有1张票的
: 时候，递交了订单。虽然他的订单最后成交不了，给扔掉了。你看我不用做查询的时候
|
f****4
发帖数: 1359 | 83 刚到家，想了想还是上来，打个补丁。
这要是真有业务达人上，切磋一下。下手轻一点。
术业有专攻，我不是业务出身。真来个SAP实施，秒我还是很轻松的。
真要有人要伸手拍拍我，就看我能不能把漏洞圆起来吧。毕竟不做业务很多年 ^_^
特此打个补丁。 |
f****4
发帖数: 1359 | 84 我都不想回你了，算是最后一贴，到此为止。
如果不做到实时更新，你的超卖20%的这个精确数字是哪来的？你自己说看到要卖光的
时候，多放点进来，20%也是你自己说的。我一直说你的设计，动一个地方，完全不考
虑对整个系统实现的影响。这是再一个例子。
【在 g*****g 的大作中提到】
: 我从来没说过cache实时更新，你别又乱纂改我的设计。我说的是cache每秒更新一次，
: 由单个service去DB读，然后更新所有cache。每秒读DB一次不算啥。我的设计本来就不
: 禁止超额下单。
|
f****4
发帖数: 1359 | 85 这是多收订票请求。你要么做到实时查询的数据同步，然后放个20%进来。不然的话你
的超卖是基于一个不准确的数据上放个20%进来。你既然是基于一个不准确的数据上，
并且只会多放进来，不会少放进来的情况下，本身就是超卖的好不好？？？
还要你加这么个超卖功能？
别和我说我只放进来这20%超出部分，后面的请求我就不收了。你的查询数据同步要是
延迟到能多放20%的订票请求进来，我们回头再讨论一下，你这同步效率导致的问题。
你做设计，不是开口来个名词，闭口来个数字。你的系统要能支撑的住的。光从技术可
行性上放余量，设计上不留点弹性是撑不住的。
行。
【在 a****i 的大作中提到】
: 你对超卖怨气很大啊，这个是照着买机票来的。不过就是要客户同意这个业务逻辑才行。
: 比如说，哪位站着回去，给个半价啥的。
|
h*****a
发帖数: 1718 | 86 Web application的架构本来就有相通的地方，在这种地方纠结没意思。否则大家都不
用讨论算法，讨论design pattern了。
【在 f****4 的大作中提到】
: 还是说那天netflix能卖春运火车票了？？？
|
f****4
发帖数: 1359 | 87 我给你解释一下机票超卖这个业务逻辑是怎么出来的，你自己看是否需要火车票超卖。
1.机票越早买越便宜，越到起飞前买，越贵（有个例外，如果起飞前还有一两个空座，
空着也是空着，卖50，就是赚了50），这是机票定价机制决定的：每趟航班的成本固定
，只有卖出尽可能高价/总价的机票才能赚钱。我忘记是那本书看到的了，可能是美国
企业财务入门，或者是经济学。米高同学有个经济学位，应该知道一点。
2.你这个航空公司航线的最后一张机票来了个订票请求，后面又来了个请求，如果你直
接拒绝，这个请求就可能去买别的航空公司的机票了。如果前面那个订票请求划钱失败
，这一张机票卖不出去，可能要抵前面便宜的10张机票。
所以，机票的超卖其实是为了盈利最大化。
火车票什么时候买都是一个价格；就算这个车次买不到，换下一个车次，钱都是铁道部
的；春运只有买不到车票，没有卖不出去车票的事情。
行。
【在 a****i 的大作中提到】
: 你对超卖怨气很大啊，这个是照着买机票来的。不过就是要客户同意这个业务逻辑才行。
: 比如说，哪位站着回去，给个半价啥的。
|
f****4
发帖数: 1359 | 88 你要是去看看我发的帖子，技术可行性和工程的我是分开来的。混在一块根本不可能比
较的。
弄到最后都已经和架构没关系了，就是两个简单的设计假设能够在没大违反需求的情况
下能够简化复杂度而已。也不是为了showoff，这东西就是个权衡的过程。大家看过就
算乐一个。
平心而论，GD是有技术积累在哪的。人品还是可以的，不然技术可行分析里面，我根本
不可能弄清楚他的方案（我没相关背景）。工程这块，我写那么多，讲穿了就一句话，
他的方案只要不是声称每样都是最优化的，说服力大多了。只要有一块的设计适当留点
弹性在哪，对新增的业务需求的适应度都会提高不少。你要是一点弹性不留，各种需求
上来之后会出问题的，不是有人看的，好像我在刁难他。我给得都还是常见的user
case。。。这是我的一点个人经验。就像GD说他做方案会留余量一样。
这倒好，又是架构师，又是打脸。呵呵。
【在 h*****a 的大作中提到】
: Web application的架构本来就有相通的地方，在这种地方纠结没意思。否则大家都不
: 用讨论算法，讨论design pattern了。
|
g*****g
发帖数: 34805 | 89 如果魏大师擅长吹牛逼，你则是喜欢撒谎，人品问题。如果说记忆出错一次也罢，一次
又一次把我没说过的话加到我身上批驳算什么事？前面刚弄出个莫须有的绝对不敢说了
，现在又弄出20%？
我说了我那个订单系统，可以无限收订单。什么时候不收单？当后台出票把钱从银行都
划走，票
都卖光为止。这之后还能有票那是因为退票，你把前面的队列留下做waiting list也行
，没有waiting list再现排队也行。我是不能实时更新余票，但是我不需要。大师的才
需要。
【在 f****4 的大作中提到】
: 我都不想回你了，算是最后一贴，到此为止。
: 如果不做到实时更新，你的超卖20%的这个精确数字是哪来的？你自己说看到要卖光的
: 时候，多放点进来，20%也是你自己说的。我一直说你的设计，动一个地方，完全不考
: 虑对整个系统实现的影响。这是再一个例子。
|
g*****g
发帖数: 34805 | 90 LOL。我300台机器，现成100万的benchmark拿出来准备对付10万并发是没余量的。大师
一句话，单机就500万并发了那可不余量大吗？
只要你信，就有余量。大师不是地球人，你是轮子。
【在 f****4 的大作中提到】
: 你要是去看看我发的帖子，技术可行性和工程的我是分开来的。混在一块根本不可能比
: 较的。
: 弄到最后都已经和架构没关系了，就是两个简单的设计假设能够在没大违反需求的情况
: 下能够简化复杂度而已。也不是为了showoff，这东西就是个权衡的过程。大家看过就
: 算乐一个。
: 平心而论，GD是有技术积累在哪的。人品还是可以的，不然技术可行分析里面，我根本
: 不可能弄清楚他的方案（我没相关背景）。工程这块，我写那么多，讲穿了就一句话，
: 他的方案只要不是声称每样都是最优化的，说服力大多了。只要有一块的设计适当留点
: 弹性在哪，对新增的业务需求的适应度都会提高不少。你要是一点弹性不留，各种需求
: 上来之后会出问题的，不是有人看的，好像我在刁难他。我给得都还是常见的user
|
