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... 阅读全帖 |
|
