y****w 发帖数: 3747 | 1 一共就几十个州,这么多数据,分开挺好。
partition算是union all view的进化,把一部分职能从developer往dba那里动了动,
设计要求提高了不少。协调不好还不如分表应用自己玩得好。 |
|
w********m 发帖数: 1137 | 2 看到一组数据
On > 50 GB data
- MySQL
Writes 300 msavg
Reads 350 msavg
- Cassandra
Writes 0.12 msavg
Reads 15 msavg
如果DB不需要join的话, 即使数据量增加,性能也不会下降吧 |
|
s**********o 发帖数: 14359 | 3 一般DEVELOPER开发的时候,数据很少,PERFORMANCE都没问题
数据一多,多数都能不用了 |
|
|
c******0 发帖数: 881 | 5 从上个月1号开始正式找工作到现在已经一个月有余,晚睡早起,接发邮件,接打电话
,看书复习,GNS练手,说辛苦还真是挺辛苦的,不过好在总算慢慢的开始有结果了。
昨天今天各拿一个offer,虽然还有公司在继续走流程,但是这两个offer给的考虑时间
比较有限,加上也累了,想考虑着接受一个开始认真工作了。
大大小小的公司各种面试已经数不过来了,最多的一天连面四个技术面,加上HR的电话
,总共打了5个多小时。这其中能叫的上名字的,也就是那么几个公司cisco,juniper
,amazon,AT&T,还有一些pandora之类看起来貌似有一些规模的公司。
CISCO,面试题目最理论的公司。其实这是我没有想到的。跟juniper的面试风格截然相
反,
按理说应该得有一些经验相关的问题吧,而且要求上也是有要求工作经验的。总共三个
工程师
面,问的问题全部很理论很标准,类似ospf邻居建立过程,ospf E1/E1/N1/N2的区别,
bgp邻居建立过程,bgp包的类型总类等等,基本上对答如流,毫无压力。感觉应该是能
进入下一
轮的,但是时间战线还是一如继让的拉得很长,估计是没有时间等了。
AMAZ... 阅读全帖 |
|
M***0 发帖数: 1180 | 6 附件中的auto suggestion应该是根据popularity score来决定提示哪5条信息的吧?
实现上,是用SQL database(分表?)来存储每个item和search count好,还是用自己
的代码实现好?如果是用自己的代码,是用heapsort吗?
数据量100M条,这个功能要用在ajax auto suggestion上,速度不能太慢。 |
|
g*****g 发帖数: 34805 | 7 据报道说用户卡在用户注册上了,如果需要validate, validate跟产生用户本来就是分
开的,可以先
validate后建立用户。连UI都可以分两步。总之常识是UI应用不是真不得已不用后台批
处理,要提高性能分表是优先考虑的。而不是你这样上来就不分青红皂白来个async就
能解决,连Amazon跟obamacare数据特性的区别都没考虑。
据库 |
|
g*****g 发帖数: 34805 | 8 这用得着他吹吗?分表都分到每天几千张票了,一天几千个transaction 单线程也没压
力。事实上几秒就弄完了。还有向图呢。 |
|
g*****g 发帖数: 34805 | 9 分布式的只是web portal,前面的订单queue。到最后transaction是单机数据库处理的,
只不过单机数据库只处理一条线路一天,这就是我前面强调的分表。这个每天几万个写
,每秒一次的读,完全没压力不是。
我可没鼓吹过单机throughput,恰恰相反,我说的就是云上的VM就搞定了。 |
|
f****4 发帖数: 1359 | 10 老魏的方案就是你这分表的替代方案,然后代码比你的简单,需要的硬件比你的少多了。
你的方案是个通用方案,老魏的只是在卖火车票,股票的时候可以这么干。但可以这么
干的时候,比你的通用方案性能好。
的, |
|
f****4 发帖数: 1359 | 11 你先解释一下发生了,goodbug的分表数据库怎么处理吧。
你这是要弄死他方案的节奏啊。 |
|
f****4 发帖数: 1359 | 12 你的划分有问题。倒车的时候是第二天的车次是很正常的。用天这个粒度是分不开的。
我一直假定你是完美分表的。这样大家讨论起来可以方便一点。
辑。 |
|
f****4 发帖数: 1359 | 13 没变就好,不然懒得玩了。。。
数据库分表支持写,server cache支持查询,这是你最初给出的解决数据库IO瓶颈的方
案,间或回帖提到几次cassandra。回我贴的时候才给了个详细解释。 |
|
g*****g 发帖数: 34805 | 14 因为我从头就没把瓶颈放在订单数据库上。订单数据库没锁,上Cassandra,你要懂C*
咋回事,一句话就解决了。
server cache,分表,这些说的都是余票数据库,需要transaction。
这些对我不是问题,因为我把订单和余票完全分开了,魏老师就很忙。 |
|
g*****g 发帖数: 34805 | 15 我是说过,因为这个没有抢票问题。只要对数据库按用户分表。sync架构就可以。觉得
我错了的可以反驳。 |
|
f****4 发帖数: 1359 | 16 他可能是想说goodbug那个分表的思路吧
我一只没追究怎么分。我只问,分了之后怎么调整。
这部分工程的复杂度你不能不承认是实际存在的。 |
|
f****4 发帖数: 1359 | 17 你还是没想明白复杂在哪。
谁来决定买下来了没有?我买个分段票,跑到相关数据库上去查一下?
我一直假设你的分表是完美的,就是不想纠缠这个细节。但你非要说没有影响,我也没
有办法。 |
|
n****1 发帖数: 1136 | 18 一旦采用了cassandra架构,而且还加上goodbug说的分表,方案的思路基本限定死为
map-reduce approach了 |
|
f****4 发帖数: 1359 | 19 你这个功力还是赞的
我之前的分析是假设goodbug的4数据库分表,每个是单独的数据库。但没理解到
goodbug说的是分布式数据库,具体实现是数据库提供的。
我之前的假设,都是基于4个数据库是单独的数据库,认为这样能缩短排队时间。这样
有些case不再适用,我得再想想。
我们简单点说,排队时间。既然你要分段票买票上锁,你说实现的效率上,是分布式的
数据库快还是一个集中的主机快?更何况集中的主机上如果不上多线程的话都可以不用
上锁。这点我已经分析过了。
我之前的分析排队时间的时候举了个300人排队时间被拉长的例子,现在的情况一样糟
糕。搞不好还要糟糕。
换个话说,魏老师那个集中的出票自动机的实现,给goodbug的这个看似分布的实际概
念上集中的分布式数据库代替了。恩,就是这样。
了) |
|
f****4 发帖数: 1359 | 20 首先,一个设计方案肯定是有取舍的。这点你要是不承认,我就没法和你讲了。我只能
说,就算我相信你的方案每个方面都是最优的,但我认为你最优的过程是要增加系统复
杂度的,我还会认为这块地方实施有风险。
他们2个人其实多少都有提怎么处理票。我懒得去推了。
你去看我分析魏老师的方案的时候,新增车次,那个,我明确提到,牺牲时间,花一个
小时去导入。导入,简单吧,导入不成,再来一次。单机操作内存的事情。哪怕你U盘
拷贝失败,再来一次就是了。我还放了个假设在那,不在线兼容现有的票务系统,不然
讨论起来更复杂了。
分段票那块,魏老师的方案上主机。goodbug也认为主机能做的,只是他认为这么低的
成本的主机处理不了这么高的throughput。你看我那提的,90+CPUs,36G的server,5
万美金。我认为就是要实现,也得加点预算。不然讨论不下去了。然后就是单线程,多
线程实现的区别了。单线程,不需要加预算,好处内存不用加锁。多线程,要加预算,
坏处实现复杂一点。但是一个买票的,C++,单机的程序,实现起来你觉得这个风险大
么???
我看到后面goodbug的回帖,我知道他还是没明白他到底差了哪一... 阅读全帖 |
|
m****a 发帖数: 2593 | 21 http://www.ccthere.com/article/3965719
我曾在淘宝写过一段时间代码,2012年在一家百强民企做电商副总,当时在极为艰苦的
条件下带队开发了一个B2C网站,走支付宝和银联支付通道,年营业额千万级(当然实
在太少了,我只是说这个网站投入了实际的运营)。
也就在那个时候,我对12306嗤之以鼻,觉得他们做得太烂了,认为自己能带队花几百
万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个
星期时间思考建立数据模型,思考到库存这一步的时候,我才发现,12306的库存复杂
性比淘宝、京东高很多倍,运算量也大很多倍。传统的分布式数据库、缓存、负载均衡
技术并不能恰好满足12306的需求。
在平时,12306也就是个正常的电商网站。但一到黄金周,12306就是一个全站所有商品
都秒杀,所有SKU都是动态库存的变态。
即使不考虑线下既有的电话、代售点等渠道,要实现一个12306,最少最少也是千万级
别的硬件投入(这是当时的估算,没有精算,可能与实际相差较大,总之,我说得不一
定对,12306的业务也许没我说的那么复杂,但也绝不是某些人喷的那... 阅读全帖 |
|
s*****r 发帖数: 43070 | 22 1月11日起,12306网站开始销售除夕当日火车票。每到此时,铁路系统唯一的官方购票
网站12306就会成为众矢之的。今年也不例外,12306再次被淹没在一片埋怨声中。
1月5日,观察者网刊登了问答网站“知乎”上的用户王强的解答,回答“如果把12306
外包给IBM或者阿里巴巴来做的话,能不能比现在做得好?”这一问题。
1月10日,一位ID名为“代码狗”的前淘宝工程师,后来在一家电商公司做技术副总的
IT业内人士也在著名论坛“西西河”上发文,表达了他自己对12306系统的看法。
值得注意的是,“代码狗”在12306系统刚上线时也有过不少微词。为了证明12306系统
很容易搭建,“代码狗”甚至曾经发起过一个名为“替12306设计系统”的开源项目。
通过工作中的实践,“代码狗”对于12306系统也有了新的认识。
观察者网转载此文,供读者参考。
全文如下:
官方订票网站12306崩溃时的页面(资料图)
本人淘宝技术专家,2012年在一家百强民企做电商副总,当时在极为艰苦的条件下带队
开发了一个B2C(企业针对个人开展的电子商务活动——观察者网注)网站,走支付宝
和银联支付通道,年营业额千万级... 阅读全帖 |
|
b*******s 发帖数: 5216 | 23 实时性也是可以解决的,按车次分库分表,同样对订单加分队列,这个也是因为铁路系
统的物理限制,一列车一天也就几千个票可以卖。不过这样服务器的负载平衡要稍微复
杂一点。不过这也不是硬实时系统,能够十几秒响应也可以接受 |
|
w**z 发帖数: 8232 | 24 goodbug 一开始说的就是分表。不同目的地的车次不同的表。具体怎能分,看情况。同
理,C* message 也是分开的。 |
|
L*****e 发帖数: 8347 | 25 因为联票的原因,分表也分离不了数据耦合性。。。
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
c******3 发帖数: 296 | 26 淘宝内部人谈设计12306
一直觉得从讨论12306的设计,可以学到很多东西。本版俩大牛老魏和goodbug的设计各
有千秋,精彩绝伦。也很遗憾地看到,凭俩位这么多年的经验,居然设计中都有完全忽
视最最基本需求的地方。前者最初的设计不保证同车同座,后者的设计不保证实时。凭
这种低级硬伤,FLG面试设计一轮估计悬了。
俩大牛都搞不定,我等更没折了。坐下好好学习吧。搜到一篇淘宝内部人写的心得,在
此分享。不觉得他写的都对,例如超卖.淘宝大牛也比不上本版俩大牛,但毕竟是做过
类似系统的淘宝人,可能他的师哥师妹就曾帮12306做过,所以应该是有参考价值的。
===========http://www.cchere.com/topic/3965719==============
我曾在淘宝写过一段时间代码,2012年在一家百强民企做电商副总,当时在极为艰苦的
条件下带队开发了一个B2C网站,走支付宝和银联支付通道,年营业额千万级(当然实
在太少了,我只是说这个网站投入了实际的运营)。
也就在那个时候,我对12306嗤之以鼻,觉得他们做得太烂了,认为自己能带队花几百
万半年时间做个好的出来。于是我... 阅读全帖 |
|
|
p*****2 发帖数: 21240 | 28
分表之后一般join,transaction啥的咋搞呀? |
|
|
g*****g 发帖数: 34805 | 30 SQL的主要弱项就是scalability,一旦需要上来了,就是分库。比如用户之间如果没关
系,
横着分表就变小了。C*这东西就相当于built-in了。
不是NoSQL没好处,我的意思就是scalability要求不高,SQL够用了。可以满足各种设
计的时候想到没想到的需求。
option |
|
D*****r 发帖数: 6791 | 31 西西河 上的 代码狗 发文。
本人淘宝技术专家,2012年在一家百强民企做电商副总,当时在极为艰苦的条件下带队
开发了一个B2C(企业针对个人开展的电子商务活动——观察者网注)网站,走支付宝
和银联支付通道,年营业额千万级(作者注:当然实在太少了,我只是说这个网站投入
了实际的运营)。
也就在那个时候,我对12306嗤之以鼻,觉得他们做得太烂了,认为自己能带队花几百
万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个
星期时间思考建立数据模型,思考到库存这一步的时候,我才发现,12306的库存复杂
性比淘宝、京东高很多倍,运算量也大很多倍。传统的分布式数据库、缓存、负载均衡
技术并不能恰好满足12306的需求。
在平时,12306也就是个正常的电商网站。但一到黄金周,12306就是一个全站所有商品
都秒杀,所有SKU都是动态库存的变态。
即使不考虑线下既有的电话、代售点等渠道,要实现一个12306,最少最少也是千万级
别的硬件投入(作者注:这是当时的估算,没有精算,可能与实际相差较大,总之,我
说得不一定对,12306的业务也许没我说的那么复杂,但也绝不是某些... 阅读全帖 |
|
b*******s 发帖数: 5216 | 32 如果现有数据库那么好用,那些牛人重新发明轮子干什么?还不是在难以分库分表等的
应用下,现有数据库束手无策或者很笨拙? |
|
a9 发帖数: 21638 | 33 payment其实也没啥,关键是按规则分表就好了。比如aa*-az*一个表ba*-bz*一个表这
样。 |
|
w********m 发帖数: 1137 | 34 按stackoverflow的做法没错
SQL数据库处理scalable,
就是去买更牛逼的硬件。
一分钱,一分货。
什么shard,分表,分库都是哄人。
python现在是主流了吧
性能的话
都是用redis的数据结构
用天顶星的语言都差不多 |
|
p**2 发帖数: 613 | 35 多谢,分表分库还是有些提高的,就是sync的时候麻烦一些。
语言方面我用c#跑一样的data structure+loop,
c#基本都是100ms以上,java/c基本都是<10ms,
郁闷 |
|
s**a 发帖数: 293 | 36 跟director谈过了,她好像也觉得很惊讶,说这个教授来找她的时候把问题说的很严重
因为我上一个rotation老板给的评价是very good,打分表上根本没提到实验技术过。单独谈话的时候也从来没有说到过。 |
|
p**********w 发帖数: 16 | 37 形式:
各个公司不同。McK是三轮,第一轮笔试,后两轮面试。BCG没有笔试,只有两轮面
试。每一轮2-3个面试官。每个面试大约45分钟,15分钟behavior,25分钟case,5分钟
Q&A。
Guestimate:
顾名思义,以下纯粹是几个2007年面试朋友的推测,没有任何官方依据。而且2008
年的情况跟往年也有不同。我自己其实对这个估计也不是完全同意,只不过很多人问,
所以写上来。
McK第一轮笔试过40-50%,第二轮面试20%,最终面30%。BCG第一轮面试20%,最终
面30%。感觉McK的笔试会邀请比较多人参加,然后通过笔试来筛掉一大半人。而BCG则
在挑选简历上面更加苛刻,只邀请少数的候选人参加面试。(看看就好,参看个人意见
第二点。)
个人面试经历:
笔试:不难,就是考察基本的数理,还有一些common sense。但是阅读量蛮大的,
我基本上是刚刚做完,时间就到了,好像还有人没有做完。
初面:
完全按照以上介绍的形式进行。两个公司都是有详细具体的打分表。他们考察的每
一项你都会得到一个分数。一天最后他们会将所有候选 |
|
|
j******w 发帖数: 933 | 39 颗粒物的组成可以用EDS检测,结构用XRD。
我感觉IR不能区别这几种无机物,不过你可以用标准化合物测一下,如果有区别,再跟
微米颗粒对照。XRD应该能区分,如果颗粒物结晶度足够好的话。
没搞明白你是要判定什么?混合物中是否有表活剂吗?如果是的话,IR最好,XRD未必
好使,因为大部分表活剂都是有机物,量又很少,XRD上未必能有很强的衍射峰。 |
|
h***i 发帖数: 89031 | 40 体状诗:浮脉惟从肉上行,如循榆荚似毛轻;
三秋得令知无恙,久病逢之却可惊。
相类诗:浮如木在水中浮,浮大中空乃是芤,
拍拍而浮是洪脉,来时虽盛去悠悠。
浮脉轻平似捻葱,虚来迟大豁然空,
浮而柔细方为濡,散似杨花无定踪。
主病诗:浮脉为阳表病居,迟风数热紧寒拘;
浮而有力多风热,无力而浮是血虚。
寸浮头痛眩生风,或有风痰聚在胸,
关上土衰兼木旺,尺中溲便不流通。
■ 沉 脉
体状诗:水行润下脉来沉,筋骨之间软滑匀,
女子寸兮男子尺,四时如此号为平。
相类诗:沉帮筋骨自调匀,伏则推筋着骨寻;
沉细如绵真弱脉,弦长实大是牢形。
主病诗:沉潜水蓄阴经病,数热迟寒滑有痰,
无力而沉虚与气,沉而有力积并寒,
寸沉痰郁水停胸,关主中寒痛不通,
尺部浊遗并泻痢,肾虚腰及下元痛。
■ 迟 脉
体状诗:迟来一息至惟三,阳不胜阴气血寒,
但把浮沉分表里,消阴须益火之原。
相类诗:脉来三至号为迟,小快 |
|
t*n 发帖数: 14458 | 41 国内有种风热感冒冲剂
看成分表是桂枝麻黄之类的方子合一起的 |
|
z**n 发帖数: 22303 | 42 (十一)
但我奶奶不否定我母亲在外面的功绩。我记得在文革最激烈的时候,斗争无限升级。我
们大院有死的,有逃的,有进大狱的,形势已完全失控了。
我家当时也处于生死存亡的紧要关头,我奶站在大院中央,进行了一场气焰嚣张的演说
,三十多户人家,我奶逐家地骂,这个:“你生孩子难产,三天三夜没生下来,最后还
不是来找我家媳妇了?如果不是小宁她妈,你就憋死了!”然后踢一脚一个半大小子:
“还能轮到你今天来革奶奶的命?”那个:“你出麻诊,出不出来,四十多天下不了地
,最后是谁救了你?今天你当革命小将了?你要革谁的命?”“你们有一个算一个,都
拍着良心想一想,我们家孩子妈,对你们哪一家没恩?……。”
我奶这么干时,我是替她捏一把汗的。那时的人性何等脆薄,一旦被激怒,后果不堪设
想。可是全院的人都低下了头,听了奶奶的数落,大家都承认我母亲医术高,医德好,
真找不出一个对我母亲有一点微词的人。奶奶的指责,瓦解了人们的革命激情,把我们
家从困境中解救了出来。
小时候,在母亲身边的时候不多,时间也不长,加之对中医没什么兴趣,更讨厌整天一
屋子人,闹哄哄的。我对母亲做的事并不关注,,既便是这样,如果说母亲出门几日... 阅读全帖 |
|
D*******l 发帖数: 5462 | 43 表里(半表半里)、内外、阴阳、虚实、主客、本末之界说
表里之表者,指皮肤而言也。病毒集中于此部,所发之病证即称表证。用发汗
解热药,以病毒自汗腺排除为原则。若此发汗不彻则病毒转入呼吸、消化、泌尿等器,
惹起种种之疾病。里者,指消化管言(按消化管之一名词包括食道、胃、小肠、大肠等
而言)。病毒积集于此部而呈现实证,则用泻下药以驱逐病毒。不然,则病毒遂侵入内
部,往往诱发不治之难证。半表半里者,指胸腹二腔间,适当支气管、肺、心、肝、脾
、胰、胃等之所在。故若病毒集于此部,使上列诸脏器之一部或数部发病,即称为半表
半里证。此病毒用和剂以缓解之,同时以其一部由皮肤或呼吸、泌尿等器排泄为准绳。
是以病毒之传入也,有自表转入于半表半里,或转入于里,或自里转入于内,或自表转
入于内,自半表半里转入于内。然亦有正相反者,自内转出于里,或转出于半表半里,
或转出于表,或于里转出于半表半里或转出于表,或自半表半里转出于表者。盖人体活
动而至变,非单纯之理论所得而解决之也。
内外者,相对之辞也。所谓内者,系指皮肤、呼吸器、消化管以外之脏器组织
也。外者,系指内以外之脏器组织也。故... 阅读全帖 |
|
g***e 发帖数: 584 | 44 原本是念phd的,不想继续跟现在的老板做了,于是就准备拿个材料系的master毕业走
人了。现在想找工作了,但是没有什么头绪。我是做block coplymer的phase behavior
的。合成主要做过ATRP, Anionic polymerization以及一些基础的有机合成,大部分表
征仪器GPC,NMR, TEM,SEM,SAXS基本上都会用,没有工作经验,我想问下我这种是找
entry level的职位还是找engineering的职位呢?我这种背景的不知道要找chemistry
的工作,还是找polymer的工作更好一点?轻拍 |
|
l*******8 发帖数: 1745 | 45 我LD护士学校真BT, 有门课,LD在2007年8月修过了,LD是2007年五月入学,本来是加快班
的,结果药理fail了,进去了part time program,2010年五月毕业的.结果她们老师让他
把那门课今年秋天再重修,还说什么,will be two years since u had it, it will be
good to study it again since u will need it in clinic,简直是bull crap,呵呵:
-)三年内毕业,有必要把一门课给修两遍吗? 真BT,算了,俺们忍了.
因为下学期学分注册表早都交过了,因为要补修这门课,然后就要改注册学分表,结果竟
然和我LD说:u will have to change it right before fall semaster starts.LD告诉
我,我一听,就火了,没有的事情,就到注册办公室,那里的老师说,你补个表,老师签字就
行了,然后我拿了表,不需要硬等到秋季开学才能补注册表,
我拿来表,和LD说,找她们签字,理由有两个,一:暑假你在NYC,回不来,二:学校贷款的老
师说了 |
|
A*******s 发帖数: 3942 | 46 用的是打分表吧,凭经验和拍脑袋得来的。
来的?人类 |
|
a******n 发帖数: 1714 | 47 主页那个参样?不是有几十个学生童工吗?学mop不会阿?
term是不能放弃,但是适可而止,为何在此服务上增加投入不解?
接入服务器一定要多,不能只有一个。
后台数据库可以定期分表分流,存储不是问题,是你们守着以前几十年前的老bbs源代
码不动。哪个商业网站能跟你们的down机频率比?
哪个商业网站down机没有对自己用户的道歉?
wsn是真傻。哎。。。 |
|
c******l 发帖数: 18 | 48 有研究报告证实,在日本冲绳八重山地区发现有一种蜗牛,和壁虎、蚯蚓一样具有截断
身体部位的能力。该种蜗牛遇到敌人时会自行断尾,再缩进壳内逃生,等摆脱掉敌人之
後,在数星期内自行长回断尾。
日本《共同社》报导,此论文是居住於荷兰的日本学术振兴会研究员细正树所发表。论
文中指出,八重山诸岛的蜗牛(isshikimaimai)可能是因为生活在有蛇出没的地方,
所以进化出这种特殊能力。
据报导,具有断尾逃生能力的蜗牛,多是未完全长成的幼年蜗牛,壳已长成的成蜗牛不
常用这种方式逃生;细正树分析,「随着身体的成长,成蜗牛用坚硬的外壳,取代了断
尾逃生这种对付天敌的手段。」
研究指出,有60%的蜗牛能从蛇的捕食中逃脱,其中有45.5%都是自断尾部,让蛇先吃掉
「点心」转移注意力,然後成功逃脱;而且,蜗牛自行截断的部分,会再重新长出来,
疗癒时间约数星期。
过去这种截断身体部位的能力,过去从未在蜗牛身上发现过,该份研究已被细正树公布
在自己的网站,并同时刊载於英国科学期刊《皇家学会报告》。(下图红色部分表尾部)
原文及图片:
http://www.sohcradio.com/gb/2012/10/06/... 阅读全帖 |
|
k*z 发帖数: 4704 | 49 从大数据,到分布存储计算,到业务模型设计,到防机器人刷票,恶意攻击,分布式访
问。。。。。。
前淘宝工程师发帖:铁道部购票网站几乎是奇迹(图)
2014年01月12日19:05:48 [新闻大杂烩]
1月11日起,12306网站开始销售除夕当日火车票。每到此时,铁路系统唯一的官方购票
网站12306就会成为众矢之的。今年也不例外,12306再次被淹没在一片埋怨声中。
Mitbbs.com
1月5日,观察者网刊登了问答网站“知乎”上的用户王强的解答,回答“如果把12306
外包给IBM或者阿里巴巴来做的话,能不能比现在做得好?”这一问题。Mitbbs.com
1月10日,一位ID名为“代码狗”的前淘宝工程师,后来在一家电商公司做技术副总的
IT业内人士也在著名论坛“西西河”上发文,表达了他自己对12306系统的看法。
Mitbbs.com
值得注意的是,“代码狗”在12306系统刚上线时也有过不少微词。为了证明12306系统
很容易搭建,“代码狗”甚至曾经发起过一个名为“替12306设计系统”的开源项目。
通过工作中的实践,“代码狗”对于12306系统也有了新的认识。Mitbbs.com... 阅读全帖 |
|