k****i
发帖数: 101 | 1 大道至简，老魏谈春运设计思路时开宗明义：车票和沿线各站数据高依赖，所以紧耦合
系统最适合，全局状态有向图可以化解。
好虫基于CAP原理的现成通用方案，解决了throughput的问题，系统可以scale out并且
highly available。
但用RDBMS及sharding来解决数据高依赖，如同oop2所讲，多个transactions难以组合
，还是要定制。
好虫也提到了淘宝用户同时购买多件商品，也是数据高依赖。但fzzh24指出，淘宝双十
一会出现一货多卖的。
所以，春运这个具体问题，首先要争论解决的，是高并发下数据的高依赖性。其他方面
，套用fzzh24的话，是补丁，可以逐步完善。
祝各位节日快乐。 |
m********s
发帖数: 55301 | 2 春运？
超过1亿人在大年26、27、28、29集体南北东西移动。
几十万人在查看、预订、退订某一趟火车的车票。
什么样的系统也抗不下来。
【在 k****i 的大作中提到】
: 大道至简，老魏谈春运设计思路时开宗明义：车票和沿线各站数据高依赖，所以紧耦合
: 系统最适合，全局状态有向图可以化解。
: 好虫基于CAP原理的现成通用方案，解决了throughput的问题，系统可以scale out并且
: highly available。
: 但用RDBMS及sharding来解决数据高依赖，如同oop2所讲，多个transactions难以组合
: ，还是要定制。
: 好虫也提到了淘宝用户同时购买多件商品，也是数据高依赖。但fzzh24指出，淘宝双十
: 一会出现一货多卖的。
: 所以，春运这个具体问题，首先要争论解决的，是高并发下数据的高依赖性。其他方面
: ，套用fzzh24的话，是补丁，可以逐步完善。
|
g*****g
发帖数: 34805 | 3 别纠结了，订单多，票少，1000万而已，后台当天怎么都处理了。前台用户触发高并发
不可控，后台是异步处理程序产生的低并发，爱几个线程都可以，单线程也可以。不愿
意相信能分，就不分好了。
【在 k****i 的大作中提到】
: 大道至简，老魏谈春运设计思路时开宗明义：车票和沿线各站数据高依赖，所以紧耦合
: 系统最适合，全局状态有向图可以化解。
: 好虫基于CAP原理的现成通用方案，解决了throughput的问题，系统可以scale out并且
: highly available。
: 但用RDBMS及sharding来解决数据高依赖，如同oop2所讲，多个transactions难以组合
: ，还是要定制。
: 好虫也提到了淘宝用户同时购买多件商品，也是数据高依赖。但fzzh24指出，淘宝双十
: 一会出现一货多卖的。
: 所以，春运这个具体问题，首先要争论解决的，是高并发下数据的高依赖性。其他方面
: ，套用fzzh24的话，是补丁，可以逐步完善。
|
k**********g
发帖数: 989 | 4
体质问题。还不如凭银行存根领号（可全年开放登记），数字加密认证，全国摇号。要
不然，挨家挨户配给车票都是可行的。
【在 g*****g 的大作中提到】
: 别纠结了，订单多，票少，1000万而已，后台当天怎么都处理了。前台用户触发高并发
: 不可控，后台是异步处理程序产生的低并发，爱几个线程都可以，单线程也可以。不愿
: 意相信能分，就不分好了。
|
N******K
发帖数: 10202 | 5 c++完胜java
【在 k****i 的大作中提到】
: 大道至简，老魏谈春运设计思路时开宗明义：车票和沿线各站数据高依赖，所以紧耦合
: 系统最适合，全局状态有向图可以化解。
: 好虫基于CAP原理的现成通用方案，解决了throughput的问题，系统可以scale out并且
: highly available。
: 但用RDBMS及sharding来解决数据高依赖，如同oop2所讲，多个transactions难以组合
: ，还是要定制。
: 好虫也提到了淘宝用户同时购买多件商品，也是数据高依赖。但fzzh24指出，淘宝双十
: 一会出现一货多卖的。
: 所以，春运这个具体问题，首先要争论解决的，是高并发下数据的高依赖性。其他方面
: ，套用fzzh24的话，是补丁，可以逐步完善。
|
z****e
发帖数: 54598 | 6 魏老师还会ejb，现在加上了cloud之后
接近流氓会武术了，你这种如果不跟上时代，抓紧时间跳船
小心以后工作都危险
【在 N******K 的大作中提到】
: c++完胜java
|
