z***t
发帖数: 10817 | 1 【 以下文字转载自 Military 讨论区 】
发信人: swjtuer (码农的小船说翻就翻), 信区: Military
标 题: 12306平稳渡过抢票高峰期 最多每秒售出近700张
发信站: BBS 未名空间站 (Sun Feb 4 09:33:07 2018, 美东)
央广网北京2月3日消息(记者郭淼)据中国之声《全国新闻联播》报道，铁路客服中
心12306负责人今天表示，12306最高峰抢票时段已经平稳渡过，今年春运12306售票系
统首次没有出现卡断现象，技术团队为自己打90分以上。
今年春运全国铁路预计发送旅客3.9亿人次，日均955万人次。12306数据显示，1月
3日发售春运车票以来，截止2月1日共发售车票3.5亿张，其中互联网售票为2.8亿张。
中国铁道科学研究院电子所副总工程师兼12306技术部主任单杏花介绍，通过售票情况
来看，高峰日售票量已经创出了新高，高峰时日售出1135.7万张，占全渠道售票量的80
%以上。高峰时段最高秒级售出将近700张，相当于一趟热门动车组列车的车票几乎在1
秒钟内售完。
单杏花说，由于今年春运回程会出现多重客流叠加现象，因此，年后返程车票明显
比节前要更为紧俏。1月24日预售2月22日车票，节后初六(22日)是返程高峰，早上8:00
开始放票，每半点会放票，售票高峰日同时是放票高峰节点，可以每秒售出近700张的
数量。
铁路12306售票系统于2012年春运开始上线运行，由于当时系统能力较差，卡断严
重，因此秒级售出是几十张的水平，低的时候甚至只有几张。单杏花说，随着12306系
统的不断优化，12306日售票量有望达到1500万张。秒级没有设定目标，而是在日售票
张数上有预估，下一步随着系统能力的提升，每天售票量可以达到1500万张。
对于有网友提出，12306可以设置抢票概率一事，单杏花解释说，没有设置抢票概
率，2018年售春运票期间铁路部门上了一套风控系统，对系统的稳定运行进行了保护，
对抢票中给系统带来危害的行为予以一定的防范。从网络情况来看，发现第三方抢票软
件的成功率相比2017年春运有所下降。 |
h**********c
发帖数: 4120 | 2 我15年第一次回国在飞机上捡了份报纸，正好说12306，也正是老魏和古霸争计数器半
路，叔撤了。
12306从来没考虑过未经验证架构，好像说过峰值保证10000Ttransct/S就行
毕竟铁路这种工程传统还是有的。
报纸我剪下来留着了，忘了放哪里了。 |
l**********0
发帖数: 150 | 3 有谁讲讲架构，数据库等等？那阵大家疯狂讨论的时候忙别的来着。 |
N********n
发帖数: 8363 | 4
这个问题的核心在于强耦合情况下的高频操作，老魏的思路是对的。当年几个硅
谷来的不懂装懂硬拿CANSANDRA之类在强耦合环境下无任何帮助的SOLUTION生搬
硬套，还自以为很对。结果吵翻天。
【在 l**********0 的大作中提到】
: 有谁讲讲架构，数据库等等？那阵大家疯狂讨论的时候忙别的来着。
|
b*******s
发帖数: 5216 | 5 java限制了他们的想象力
【在 N********n 的大作中提到】
:
: 这个问题的核心在于强耦合情况下的高频操作，老魏的思路是对的。当年几个硅
: 谷来的不懂装懂硬拿CANSANDRA之类在强耦合环境下无任何帮助的SOLUTION生搬
: 硬套，还自以为很对。结果吵翻天。
|
a****i
发帖数: 1182 | 6 单机计数器算个屁思路
离solution更是差得远了
【在 N********n 的大作中提到】
:
: 这个问题的核心在于强耦合情况下的高频操作，老魏的思路是对的。当年几个硅
: 谷来的不懂装懂硬拿CANSANDRA之类在强耦合环境下无任何帮助的SOLUTION生搬
: 硬套，还自以为很对。结果吵翻天。
|
N********n
发帖数: 8363 | 7
拿多机的HASHTABLE来做强耦合属于门都没摸着呢。
【在 a****i 的大作中提到】
: 单机计数器算个屁思路
: 离solution更是差得远了
|
a****i
发帖数: 1182 | 8 咋滴了？12306现在用的gemfire
你来说门都没摸到？
【在 N********n 的大作中提到】
:
: 拿多机的HASHTABLE来做强耦合属于门都没摸着呢。
|
w**z
发帖数: 8232 | 9 这年头还有人说单机， 搞笑呐吧。
【在 a****i 的大作中提到】
: 咋滴了？12306现在用的gemfire
: 你来说门都没摸到？
|
a****i
发帖数: 1182 | 10 人可是很严肃地要干掉nest的
【在 w**z 的大作中提到】
: 这年头还有人说单机， 搞笑呐吧。
|
|
|
w**z
发帖数: 8232 | 11 魏老师的臭脚，还是有一大堆人捧的。
【在 a****i 的大作中提到】
: 人可是很严肃地要干掉nest的
|
g*******u
发帖数: 3948 | 12 美国现在做不好是因为没这个需求吧
真要有这个需求 ， 我相信会做的也很好 |
T********i
发帖数: 2416 | 13 如果铁道部有人吃人中黄，你是不是就要断定吃屎是好的？吃屎是对的？
进而推断出吃屎是最好的？
干掉nest也不算啥大目标。要搞就搞大的。你说呢？
不服气的自挂东南枝了。前车之鉴啊！
【在 a****i 的大作中提到】
: 人可是很严肃地要干掉nest的
|
w**z
发帖数: 8232 | 14 现在要搞，就搞 Alexa 了
【在 T********i 的大作中提到】
: 如果铁道部有人吃人中黄，你是不是就要断定吃屎是好的？吃屎是对的？
: 进而推断出吃屎是最好的？
: 干掉nest也不算啥大目标。要搞就搞大的。你说呢？
: 不服气的自挂东南枝了。前车之鉴啊！
|
a****i
发帖数: 1182 | 15 你就没有什么credit
跟人打赌只弄个计数器来当solution，完全两个层次的概念
也就是好虫认了你的作弊
【在 T********i 的大作中提到】
: 如果铁道部有人吃人中黄，你是不是就要断定吃屎是好的？吃屎是对的？
: 进而推断出吃屎是最好的？
: 干掉nest也不算啥大目标。要搞就搞大的。你说呢？
: 不服气的自挂东南枝了。前车之鉴啊！
|
T********i
发帖数: 2416 | 16 你悲愤也木有用。
你要不服气也可以做做题么！还是和好虫打赌的那个题目。代码说话。别的都是扯淡。
我好歹还公开代码，一切可验证。并且得到了绝大多数网友的认可的。
你连这辈子有没有干过一件人事儿都没有证明，凭啥来叫板啊？
【在 a****i 的大作中提到】
: 你就没有什么credit
: 跟人打赌只弄个计数器来当solution，完全两个层次的概念
: 也就是好虫认了你的作弊
|
a****i
发帖数: 1182 | 17 作弊就是作弊，狡辩没用
赌一个产品，你给一个hello world
这种狗屎就算了
这个话题我不再回了，免得被你拉低智商
那样你经验太丰富了
【在 T********i 的大作中提到】
: 你悲愤也木有用。
: 你要不服气也可以做做题么！还是和好虫打赌的那个题目。代码说话。别的都是扯淡。
: 我好歹还公开代码，一切可验证。并且得到了绝大多数网友的认可的。
: 你连这辈子有没有干过一件人事儿都没有证明，凭啥来叫板啊？
|
T********i
发帖数: 2416 | 18 你不是说的挺起劲的么？
产品也好，solution也好，代码一个人100%控制，上billion在上面跑的，你做过一个
么？
不是我小瞧你，我那几百行代码你根本就不可能看懂。估计你这辈子也不会懂了。几百
行代码你都读不懂，还好意思谈什么智商？
【在 a****i 的大作中提到】
: 作弊就是作弊，狡辩没用
: 赌一个产品，你给一个hello world
: 这种狗屎就算了
: 这个话题我不再回了，免得被你拉低智商
: 那样你经验太丰富了
|
N********n
发帖数: 8363 | 19
GF是IN-MEMORY DB。为啥要IN-MEMORY？就是要提升单节点计算能力。12306
的后台数据库也是尽量走IN-MEMORY提升单节点吞吐量。你们吹的CANSANDRA
属于门都没摸着还瞎套。
【在 a****i 的大作中提到】
: 咋滴了？12306现在用的gemfire
: 你来说门都没摸到？
|
d***a
发帖数: 13752 | 20 简单地说，这个问题碰巧可以用一个简单精巧的小程序，来做猜测性的预调度。与数据
库系统配合，可以同时做到高性能和可靠性。那个小程序，在一个CPU core运行就够了
，性能绰绰有余。
【在 l**********0 的大作中提到】
: 有谁讲讲架构，数据库等等？那阵大家疯狂讨论的时候忙别的来着。
|
|
|
T********i
发帖数: 2416 | 21 确切地说，这一类数据强耦合的transaction问题，单机核心是最优方案。Period！
如果单机不能解决，那就需要一个更大的单机！Period！
【在 d***a 的大作中提到】
: 简单地说，这个问题碰巧可以用一个简单精巧的小程序，来做猜测性的预调度。与数据
: 库系统配合，可以同时做到高性能和可靠性。那个小程序，在一个CPU core运行就够了
: ，性能绰绰有余。
|
a****i
发帖数: 1182 | 22 你得先说说为啥要GF，然后才能说到为啥要 in memory
【在 N********n 的大作中提到】
:
: GF是IN-MEMORY DB。为啥要IN-MEMORY？就是要提升单节点计算能力。12306
: 的后台数据库也是尽量走IN-MEMORY提升单节点吞吐量。你们吹的CANSANDRA
: 属于门都没摸着还瞎套。
|
d***a
发帖数: 13752 | 23 老魏，前提是存在一个计算复杂度低的解法。几千万的problem size，如果算法复
杂度是N^3大圈，再强的耦合，单机也不行啊。
这个问题正好有这样一个解法。大多数问题其实是没有的，这是好虫为什么失误的
一个侧面原因。
【在 T********i 的大作中提到】
: 确切地说，这一类数据强耦合的transaction问题，单机核心是最优方案。Period！
: 如果单机不能解决，那就需要一个更大的单机！Period！
|
T********i
发帖数: 2416 | 24 很多business transaction，都能落到这个范围内。
而且problem size再大几个数量级都没关系。
至于科学计算，那是另外的问题。
谁也没指望NB单机走天下。具体问题具体分析而已。
: 老魏，前提是存在一个计算复杂度低的解法。几千万的problem size，如果算法复
: 杂度是N^3大圈，再强的耦合，单机也不行啊。
: 这个问题正好有这样一个解法。大多数问题其实是没有的，这是好虫为什么失误的
: 一个侧面原因。
【在 d***a 的大作中提到】
: 老魏，前提是存在一个计算复杂度低的解法。几千万的problem size，如果算法复
: 杂度是N^3大圈，再强的耦合，单机也不行啊。
: 这个问题正好有这样一个解法。大多数问题其实是没有的，这是好虫为什么失误的
: 一个侧面原因。
|
