d********g
发帖数: 10550 | 1 这当然是趋势，REST这块并不是单纯异步抗高并发就能解决的，Java系所谓backend
business logic，换Node可以放在对transaction要求不高的环境比如social类并发高
但是数据不敏感的情况。有交易的Node大多是用来做个REST的壳 |
|
z****e
发帖数: 54598 | 2 不过看大并发，貌似erlang系有点搞头
我看lyce或者lyme，据说可以支撑起大并发
会fp的话，erlang倒是一个相对可以的选择
stack比较完整，一下子可以捅进去
有点java full stack的感觉 |
|
g*****g
发帖数: 34805 | 3 别纠结了，订单多，票少，1000万而已，后台当天怎么都处理了。前台用户触发高并发
不可控，后台是异步处理程序产生的低并发，爱几个线程都可以，单线程也可以。不愿
意相信能分，就不分好了。 |
|
c*****a
发帖数: 1638 | 4 我还真不信所谓资金管够的情况下这个会做不出来。估摸着就是没人敢接免得得罪那个
搞这个网站的太子党。
LZ说的也不太对，这个本身和大数据啥关系没有（别说4千万用户了，就算再加10倍，
也算不了啥大数据的问题）。不过用nosql可以提高并发读的扩展性。事实上铁路数据
本身很小，直接cache就完了，available的ticket部分存到cassandra里面（cassandra
在写并发啥是不是号称最好的nosql？）
关键是，查询部分是只读的情况，只有reserve票的时候涉及事务。模式和机票类似，
走eventually consistent就行了。
耦合是关键，很明显他们的系统是没法扩展的，给铁道部洗地的文章里面也说到只能做
到说scale up（提升节点硬件和软件）而不是scale out（增加节点）。所以就是说他
们那个破框架设计本身到20个节点自己不行了
这种情况下，只能重做
他这个东西和淘宝还是不能比的，他的业务其实简单多了，后台数据的查询路径基本是
固定的，比起来淘宝那个网站要实现的用户需求比他这个难很多个数量级。
确实来说，国内IT水平其实挺高的都在几个大公司里面，断档... 阅读全帖 |
|
z****e
发帖数: 54598 | 5 先说几点,其它有空再说
第一,语言语法本身跟最后编译成什么玩艺没有关系
JAVA一样可以编译成NATIVE CODE,实际上JAVAFX的一个主要特征就是NATIVE COMPILING
反过来,脚本比如RUBY,PYTHON这些,也可以编译成BYTE CODE给JVM去执行
所以语言本身已经逐步独立于各种平台了,变成一种规范
剩下的各个平台各自实现,所以说RUBY,PYTHON这些是NATIVE层什么就是一个大joke
有些人应该好好回学校去学习一下语言到底是怎么回事
然后jvm相比OS上的NATIVE,有GC,JIT和跨平台三大特性
GC就是所谓的内存管理,JIT是针对JVM做的优化,跨平台可以让程序独立于os而存在
这三个特性其实也被其它语言的VM所借鉴,但是一般来说,做得远不如JVM
比较接近JVM的应该说是CLR,其它的python什么都差得很远,但是CLR比起jvm人为阻挡跨
平台
那这个就是大问题了
第二,异步
异步只是一种机制,C时代就有人这么搞了
老魏说得没有错,他的程序早就是异步了
不知道有什么好惊讶的
spring等J2EE框架早就有了异步机制
用起来太简单了,一... 阅读全帖 |
|
z****e
发帖数: 54598 | 6 王垠的结语：
程序语言与政治
很多人都曾经妄想着所谓的“社会主义”和“共产主义”能拯救全人类，就像很多程序
员都妄想着某一种最近流行的语言能够把他们从繁琐的编程工作里拯救出来一样。几十
年前，所谓的“革命者”为了这些很酷很炫的名词，试图把从前的一切文化都焚毁掉。
腐朽的资本主义！吃人的旧社会！这就像现在很多 Scala/Clojure/Go 的狂热分子对
Java 之类的语言充满了敌意，一提到这些语言心里就是火。腐朽的 Java，不思进取的
Lisp，Scala/Clojure/Go 就是你们的掘墓人！然而他们没有发现，那些他们试图完全
抛弃的语言里面其实有科学合理之处。他们没有看到这些东西之所以存在于那些语言里
，是经过了历史的经验教训。这些教训如果不被理解和吸取，当遇到同样的问题，这些
新语言就会一样的堕落掉。
有些程序员妄想着 Clojure 和 Go 所谓的 “纯函数式数据结构”，“transactional
memory”，“goroutine”等酷毙帅呆的新概念能够一劳永逸的解决并发计算的重重困
难，妄想着 Scala 能够让面向对象和函数式编程完美的结合。可是他们没有看到... 阅读全帖 |
|
d*******r
发帖数: 3299 | 7 "
有些程序员妄想着 Clojure 和 Go 所谓的 “纯函数式数据结构”，“transactional
memory”，“goroutine”等酷毙帅呆的新概念能够一劳永逸的解决并发计算的重重困
难，妄想着 Scala 能够让面向对象和函数式编程完美的结合。可是他们没有看到的是
人心的险恶，他们就像那些革命者和红卫兵一样，被别有企图的人利用了。
在经过深入的研究之后，你会发现这些炫名词其实并不能解决并发计算的关键问题。并
行计算之所
以困难，是因为物理决定了信息通道的性质。信息只能是单向的，顺序的通过这些信道
，而信道的通过速率是有限的。不管你用多么炫的新方式让信息通过它，都不会改变这
个事实。
"
上面这个“信息流动”没看懂，求大牛解释 |
|
T********i
发帖数: 2416 | 8 一趟车同时跑100个线路？
我看是你的大脑大规模并发吧？你丫把火车都能并发到平行宇宙中去？ |
|
q*c
发帖数: 9453 | 9 在高并发下，回造成巨量错误操作。
比如有 a b c 三段， 无数请求一起近来 （如果你是单线程， 那当然没问题， 但是
单线程要 5mm/second 不可能）。 req1 锁了 a, 接着锁 b, 然后锁 c 得时候失败了
， 于是取消 a,b (这里都不谈万一取消得时候出错了， a,b 得票就丢一张）。 但是
在 取消a,b 得之前， req 要求 锁 a, 失败。
这就是有票不能出。 在巨大并发下， 这种情况就会成为常态， 造成大量有票不能出
， 用户的反复试验刷票的局面， |
|
c****3
发帖数: 10787 | 10 并发也没有问题。中转城市的票本来就是抢。原来全国一个统一数据库里才变成瓶颈。
现在变成每个城市一个数据库，只包含和这个城市直达的城市的票。这是比较合乎逻辑
的划分。
中转经过多个城市，算好路径后，从始发站开始抢。但每一段的抢票，都只和所经过的
这个城市数据库有关。所以即使并发，因为大家的路径不同，大家是在不同城市的数据
库上抢票。
如果抢不到最后一段票，就把前面抢到的中转路径票release回去，这个操作瞬间就完
成了。你也可以算另一个中转路径，继续抢票。
所以这个锁就是标准的数据库写操作需要的锁而已，不会出错的。其他人又可以继续抢
这些被release的票。 |
|
z****e
发帖数: 54598 | 11 第一，控制并发线程数，控制在16个左右
第二，用计数器来替换锁，因为并发线程数量少，所以也很难出现一些互斥的情况
想表达的就是这么一回事吧？
什么全国一盘棋，太过于拗口了，忽悠
当然这样会有问题，牛逼网卡能解决，至于是不是真行
老魏担保，信不信就看你自己了 |
|
g*****g
发帖数: 34805 | 12 外行说内行不懂，先想想自己配吗？1万并发的网站都没做过，开口就是500万并发，纯
粹不知天高地厚。 |
|
g*****g
发帖数: 34805 | 13 没有啥长时间一说，就是几分钟。
后台我当然是做并发得，只不过是单关系数据库，用transaction来保证acid。把单子
按车次排序分队列，这个前端写单子存入得时候就做好了。后端得处理服务器是一个集
群，每次可以从cassandra批量读。另外每隔一秒从数据库里拿出个所有余票的
snapshot，cache到
各个处理服务器上。处理先跟这个cache比较，确认各段都有票，再发到数据库交易。
所以处理是并发得，如果没票的话，不用写入关系数据库，写回cassandra确认订单失
败。
尽管订单很多，峰值达到百万／秒，可用的票很少，根据新闻每天千万人次，一半
12306出，每天不过500万张。这500万张，在一台大机器上，oracle数据库，5k－10k/
秒的速度是一个常规的估计。按5k算的话，也不过1000秒，17分钟。12306其实每天是
分多个时段分票的，结果就是延迟更少，如果每天放票8次，那就是2分钟。这是数据库
的延迟。无效订单有延迟，每次处理无非是查内存里一个数组是否有0，有0就可以放弃
，单操作毫秒级的处理。。而且是多核集群并行处理，完全scale out, 订单很多可以
... 阅读全帖 |
|
b*******g
发帖数: 603 | 14 号称是宇宙第一的强耦合实时算法，可以把银河系的票都卖了。一到实践，什么八十老
妪抗大包，黄毛小儿自己走都出来了。反正太监算法虽然宇宙第一，一个单子就是卖不
了两张票。
我老人家在BBS上混了这么久，从没有看到嘴皮子和能力差距这么大的。偏偏还有一堆
捧臭脚的民科。你们也不想想，为嘛但凡有点高并发经验的一边倒地觉得太监的系统不
行呢？我个人能力不行有可能，是个内行都错了？大家都有自己地两亩三分地。你要搞
OS，嵌入式，高频都好。做高并发网站，你真会吗？ |
|
b*******g
发帖数: 603 | 15 给你96核也是96核的并发度，俺这个是3000的并发度呀。哈哈，强了无数倍。 |
|
T********i
发帖数: 2416 | 16 是不是后端只能单线程呢？
再问你一次，你那后端6000台机器并发分票是不是扯淡？
单线程，和6000台并发很不一样呀。 |
|
c******3
发帖数: 296 | 17 把核改成机，把多核改成多机，把CPU调度简化成C*调度。都在cluster里，都是单机单
线程，都用bitmap分票。你俩相互看看，多相似呀。简单就是美。 |
|
T********i
发帖数: 2416 | 18 你的这个审美毫无情趣可言。
你咋不随便拿一个串行程序分布到6000台机器上去，看看慢多少倍？
加速比不是总大于一的。
要是能分布，我早就分布了。 |
|
c******3
发帖数: 296 | 19 你仔细想想goodbug的方按。他的是每台机器上只跑同一次车。全国3000次车，所以要
3000台机器。
去掉无足轻重的跑冷门车次的机器，对热门车次，你俩基本上是单机对决。
他的单机仅仅只分一次车的票（eg.京广线），你的单机要分全国的车次的票。
他的单机要承受上MM次的压力。你的单机则要承受上百倍他的单机的压力。
分票算法也大同小异。他的机器间通信开销和你的承受差了多几个数量级的处理请求相
抵。
真难说谁胜呀。
还是老话，合起来一起做，可能更能发挥各自优点。 |
|
T********i
发帖数: 2416 | 20 goodbug都明白自己错了。你要是不明白，可以私信问他。 |
|
c******3
发帖数: 296 | 21 goodbug早承认就单机效率而言，对同样数量的请求，他的比不过你的。但这前提是都
在同样压力下。
只需要处理一次车的压力和要处理3000次车的压力能比吗？
好虎难敌群狼呀。 |
|
z****e
发帖数: 54598 | 22 古德霸的多机直接爆虚拟机的instances就好了
爆硬件配置就是纯粹浪费钱，无论爆的是网卡还是cpu
单机那个做下去，费用无法承受，这个很多人都看出来了
digua不是说得很清楚了，就老魏死不承认而已 |
|
z****e
发帖数: 54598 | 23 我说你不敢承认有错么？
古德霸那些东西要scale out很容易阿
你有半点让人scale out的部分么？
拼命去渣取硬件的性能，所以你要拼命算
因为要算上限是多少，才能决定你的预算
可人家不用算，这就是差距阿
说你外行你还不信 |
|
z****g
发帖数: 75 | 24 蛋蛋主要问题是脑子不大灵光，浆糊较多, 基本问题总是搞糊涂，Y计算机基础课没学
明白过 |
|
T********i
发帖数: 2416 | 25 这个zhaoce似乎计算机基础课从来没学过。也能忽悠出几个粉丝出来。 |
|
|
z****g
发帖数: 75 | 27 魏老师已经把问题分析的很透彻了，且对一些性能问题做了测试和讲解，这nm还叫光说
不练啊
那个蛋蛋除了会骂人，还会干啥？ |
|
z****e
发帖数: 54598 | 28 啧啧，你知道我在说什么么？
老魏一开始丫的要扇我耳光呢
我当时就回复他，有种你过来
更不要说这个家伙搞私信，冲人邮箱发垃圾，爆个人隐私
这都是买买提上最为人所不齿的行径
你以为有几个人真看得起这种行为的？ |
|
z****e
发帖数: 54598 | 29 给你普及一下买买提常识
老魏干的这种下三滥的行径
在买买提上有个专有名词，叫作老大爷
八区一堆人听到这三个字，那都是准备操家伙的
你自己学习一下 |
|
c******3
发帖数: 296 | 30 能理解你说的。理论上是这样。但实际上要联程票的是少数。对冷门车次，联程票基本
不是问题，座位多的是。对热门车次，为处理联程票而在多车次间加锁，会降低整个系
统的出票率。有点得不偿失。 |
|
T********i
发帖数: 2416 | 31 扒你皮，砸你饭碗需要过去么？你太把自己当任人物了。 |
|
T********i
发帖数: 2416 | 32 这辈子，碰到我算你倒霉。
古德吧要不是连续PA我3个月，我也懒得理他。 |
|
|
b*******s
发帖数: 5216 | 34 他的粉丝，比如1989，也挺好玩的，估计也都是非科班的 |
|
|
b*******s
发帖数: 5216 | 36 这人还是沉不住气，几个实际问题一讨论露馅了就开始各种嘴脸都出来了
估计是军版那种粪坑练出来的
高人没能装到底，还是养气功夫欠缺 |
|
|
|
b*******s
发帖数: 5216 | 39 屁都不懂，嘴巴还这么大，啧啧
我5年前就从医疗转出来了
哪怕是医疗，其实研发也是很不错的，压力小，收入在传统行业里算高的
基本都是百分之几百的毛利
低的是制造，售后这些没技术含量的 |
|
|
|
|
|
T********i
发帖数: 2416 | 44 既然你提到了。我就说一下。
当时有个蒙脸的，成天转发轮子的造谣贴。我就利用公开资料，统计了此人的IP和出没
规律。当时还没有大数据的概念，我那也算早期应用吧。
结果look不满封我。我就用注册机对付。很简单，他滥用权力，我就要夺回权力。他还
试图联系我的毕业学校和我工作的投行。还有人用公司的网络攻击我家电脑。这些我都
有硬证据也放他一马，没有向FBI举报。
后来的举报盗版，也和我无关。
总之，你丫蒙脸，我可以实名搞你。我不会背后使劲的。 |
|
|
|
|
z****e
发帖数: 54598 | 48 你什么权力少了？你放look啥一马了？
跟fbi举报？举报什么？举报look是间谍？ |
|
z****e
发帖数: 54598 | 49 我消停什么？我没装，我也不需要装什么高人
装了干什么？我来这里是来玩的，从来没装 |
|
|
