八风不动的12306改进思路确实不错

mallon 发布于 2014/02/03 10:10
阅读 1K+
收藏 9
@八风不动 仔细想了一下你的掩码思路,确实不错。每趟车每个座位设置一个64位的存储,64位应该够了,而且和主流CPU位宽一致,从始发到终点,每一位代表一站,0表示无人,1表示有人,初始全0。购票的时候,按旅客报出的起点和终点生成64位码,和座位的64位码做一次“与”运算就能知道该座位能不能用,全0能,否则不能。票售出后做一次“或”运算更新座位的64位码即可。这其实已经用到了CPU的“并行”能力了。至于如何一次查询所有座位,可以map-reduce甚至利用GPU FPGA之类的定制硬件完成并发。两次并发下来,万倍的速度提高肯定不是问题。
加载中
0
yak
yak
思路完全反了,跟需求南辕北撤,这种利用cpu运算能力提升效率的思路还停留在单机app时代码农坐在电脑前,在命令行前敲一下回车键看程序运行优化了多少毫秒的阶段,如果12306系统是用传统app时代运行个程序返回个输出结果,这样的优化有一点点用,可惜12306的瓶颈并不是因为这套系统用的cpu太次了,运算速度没跟上的而导致买票难,所以码农的思路永远是优化优化再优化,每次都为敲回车以后提高几毫秒而兴奋不已,还没看清需求就在优化想象中“正确”的方案,等到提交测试了,老板说你做的这是什么,根本不是我要的,结果傻眼了
黑狗
黑狗
但是。。。你不要出触碰咱广大码农的痛点啊啊啊啊啊啊啊啊 戳脊梁骨啊
黑狗
黑狗
这是明白人
0
mallon
mallon

引用来自“yak”的答案

思路完全反了,跟需求南辕北撤,这种利用cpu运算能力提升效率的思路还停留在单机app时代码农坐在电脑前,在命令行前敲一下回车键看程序运行优化了多少毫秒的阶段,如果12306系统是用传统app时代运行个程序返回个输出结果,这样的优化有一点点用,可惜12306的瓶颈并不是因为这套系统用的cpu太次了,运算速度没跟上的而导致买票难,所以码农的思路永远是优化优化再优化,每次都为敲回车以后提高几毫秒而兴奋不已,还没看清需求就在优化想象中“正确”的方案,等到提交测试了,老板说你做的这是什么,根本不是我要的,结果傻眼了
买票难是人都知道不是12306的问题,你难道以为我不知道?别扯到其他地方,这里仅仅讨论的是性能如何改进,仅此而已。
0
yak
yak
性能改进为什么要在 cpu上琢磨怎么位存储 ,从什么地方看出来的12306的问题是因为cpu的原因而导致的? 优化也应该是优化网络吞吐量,而实际上从去年的改进看到的12306放弃了小型机而采用x86平台,为什么我说在cpu优化的思路是南辕北撤,从 http://server.chinabyte.com/151/12820151.shtml 透露出来的信息可以得知,从小型机到x86 平台转变,余票计算和查询能力相当,只是提高了系统吞吐量,所以思路反了,性能改进的结果也一样南辕北撤,一谈性能优化就琢磨怎么在cpu上位存储,这还是单机时代版的思路
0
mallon
mallon

引用来自“yak”的答案

性能改进为什么要在 cpu上琢磨怎么位存储 ,从什么地方看出来的12306的问题是因为cpu的原因而导致的? 优化也应该是优化网络吞吐量,而实际上从去年的改进看到的12306放弃了小型机而采用x86平台,为什么我说在cpu优化的思路是南辕北撤,从 http://server.chinabyte.com/151/12820151.shtml 透露出来的信息可以得知,从小型机到x86 平台转变,余票计算和查询能力相当,只是提高了系统吞吐量,所以思路反了,性能改进的结果也一样南辕北撤,一谈性能优化就琢磨怎么在cpu上位存储,这还是单机时代版的思路

什么叫单机时代的思路?

你觉得整天胡吹海侃什么虚拟化分布式云之类的有意义吗?

你知不知道高并发的简单访问从架构上调整并不难,难在高并发的交易运算?

是不是成天看那些所谓的“高性能架构”就让你找不到北了?

你知不知道你所不屑的单机时代版的思路恰恰用在很多关键场合,比如关系型数据库?

yak
yak
成天看那些所谓的“高性能架构”就会让人找不到北? 答案是不会,我不用成天看,就是看一次一样可以分清楚东西南北,为什么呢,因为可以观察太阳啊,树冠的茂密程度啊,还可以用指南针,高德地图什么啥的,所以,你看扯谈其实是很容易的,难的是什么,不是交易运算,是分析问题,找到整个系统的瓶颈在哪里
yak
yak
另外你说架构调整简单,难在计算我真不知道,我只知道去年12306升级没有升级cpu,另外我还知道具体问题需要具体分析,没有放之四海皆准的原则,另外我还知道讨论问题就是讨论问题,不能恼羞成怒,说别人觉得整天这如何如何,是不是成天看xxx,纠正一下你的错误认识,我并不觉得xxx,我也不成天看所谓ooo,我只认为提供方案和思路首先要分析需求,先分析问题出在哪里,而不是一上来就给出想当然“正确的”的方案
yak
yak
首先回答你的问题,单机时代的性能思路就是更新换代升级cpu 另外弱弱地问一声,你从哪里看出我 “整天胡吹海侃什么虚拟化分布式云之类”了?
0
修改登录密码
修改登录密码

我赞同yak的观点

高层设计带来的性能改善比底层一个数据结构带来的改善要显著的多

这也就是不要过早优化 的原则

0
jingshishengxu
jingshishengxu
这就叫闲吃萝卜淡操心
mallon
mallon
你把它当作智力题就可以了
0
mallon
mallon
@yak 12306的慢有两个方面,一个是页面打开慢,查询速度慢,这个调整12306自己的架构就可以了。另一个是购票慢,这个就涉及到核心交易算法了,事实上跟12306关系不大,它只是整个铁路售票系统的一个前端而已。我为什么说前者简单?套路都是固定的: 骨干线路扩容、负载均衡、哈希表…
yak
yak
查票慢,购票慢的原因是什么? 是因为cpu运算慢吗?
0
mallon
mallon
什么GemFire之类的,也离不开这些套路,说实话,就算没有这些通用软件,让你写一个专用的哈希表、二叉树,难吗?
yak
yak
只跑在单机上的demo程序很简单,但是能跑在一个多个节点组成一个统一的逻辑结构,并能在生产环境中实用的,保证数据一致性,能运行稳定,对我来说很难,简直是难上加难
0
mallon
mallon
@eel 我也喜欢通用的套路,但是极端情况就得上特定做法。为什么数据库、文件系统还在不断改进?为什么那么多人研究GPU计算?为什么高并发的负载均衡、SSL加密要上硬件?
0
mallon
mallon
@yak 我什么时候说过是因为CPU慢了?换CPU是你强加给我的吧?
yak
yak
好吧,我误解了,查票慢,购票慢不是因为cpu慢,那是什么原因
返回顶部
顶部