相关推荐
-
社区专家谈 12306
由于春运,铁道部官方订票网站12306流量暴增,其Alexa排名一度进入前200,网友戏称,12306已经成为“全球最大、最牛的电商网站”。由于流量激增,12306系统频频瘫痪,一度出现登不上去、登上去抢不了票、抢到票需...
-
社区专家谈12306
专家访谈12306 目录(?)[-] 您是否在春节国庆期间在12306上买过票谈谈该系统的用户体验在去年国庆之前12306进行了改版加入了排队系统您认为加入排队系统的目的是什么缓解了哪些问题春运购票与淘宝天猫在...
-
基于的手势识别系统可控制灯的亮_3.zip
基于的手势识别系统可控制灯的亮_3
-
untitled2.zip
untitled2.zip
-
S7-1500和分布式外围系统ET200MP模块数据
S7-1500和分布式外围系统ET200MP模块数据
-
anaconda配置pytorch.zip
anaconda配置pytorch环境
-
基于Python的Django-vue高校教室管理系统源码-说明文档.zip
高校教室管理系统,主要的模块包括查看首页、个人中心、教师管理、学生管理、教室信息管理、教师申请管理、学生申请管理、课时表管理、教师取消预约管理、学生取消预约管理等功能。
-
半挂汽车列车横向稳定性控制研究:基于模糊PID与制动力矩分配的联合仿真分析在典型工况下的表现,半挂汽车列车在典型工况下的横向稳定性控制研究:基于模糊PID与制动力矩分配的联合仿真分析,半挂汽车列车4自
半挂汽车列车横向稳定性控制研究:基于模糊PID与制动力矩分配的联合仿真分析在典型工况下的表现,半挂汽车列车在典型工况下的横向稳定性控制研究:基于模糊PID与制动力矩分配的联合仿真分析,半挂汽车列车4自由度6轴整车model,横向稳定性控制,在低附着系数路面,进行典型3个工况,角阶跃,双移线,方向盘转角。 采用算法:模糊PID,制动力矩分配,最优滑移率滑膜控制。 以上基于trucksim和simulink联合仿真,有对应 p-a-p-e-r参考 ,关键词: 1. 半挂汽车列车 2. 4自由度6轴整车model 3. 横向稳定性控制 4. 低附着系数路面 5. 典型工况(角阶跃、双移线、方向盘转角) 6. 模糊PID算法 7. 制动力矩分配 8. 最优滑移率滑膜控制 9. Trucksim和Simulink联合仿真 10. P-A-P-E-R参考; 用分号隔开上述关键词为:半挂汽车列车; 4自由度6轴整车model; 横向稳定性控制; 低附着系数路面; 典型工况; 模糊PID算法; 制动力矩分配; 最优滑移率滑膜控制; Trucksim和Simulink联合仿真; P-A-P-E-R参考
-
路径规划人工势场法及其改进算法Matlab代码实现,路径规划人工势场法及其改进算法Matlab代码实现,路径规划人工势场法以及改进人工势场法matlab代码,包含了
,路径规划; 人工势场法; 改进人
路径规划人工势场法及其改进算法Matlab代码实现,路径规划人工势场法及其改进算法Matlab代码实现,路径规划人工势场法以及改进人工势场法matlab代码,包含了 ,路径规划; 人工势场法; 改进人工势场法; MATLAB代码; 分隔词“;”。,基于Matlab的改进人工势场法路径规划算法研究
-
VU-DBS项目:深脑刺激器的全程辅助
本文介绍了范德堡大学深脑刺激器(DBS)项目,该项目旨在开发和临床评估一个系统,以辅助从规划到编程的整个过程。DBS是一种高频刺激治疗,用于治疗运动障碍,如帕金森病。由于目标区域在现有成像技术中可见性差,因此DBS电极的植入和编程过程复杂且耗时。项目涉及使用计算机辅助手术技术,以及一个定制的微定位平台(StarFix),该平台允许在术前进行图像采集和目标规划,提高了手术的精确性和效率。此外,文章还讨论了系统架构和各个模块的功能,以及如何通过中央数据库和网络接口实现信息共享。
-
三菱FX3U步进电机FB块的应用:模块化程序实现电机换算,提高稳定性和移植性,三菱FX3U步进电机换算FB块:模块化编程实现电机控制的高效性与稳定性提升,三菱FX3U 步进电机算FB块
FB块的使用
三菱FX3U步进电机FB块的应用:模块化程序实现电机换算,提高稳定性和移植性,三菱FX3U步进电机换算FB块:模块化编程实现电机控制的高效性与稳定性提升,三菱FX3U 步进电机算FB块 FB块的使用可以使程序模块化简单化,进而提高了程序的稳定性和可移植性。 此例中使用FB块,可以实现步进电机的算,已知距离求得脉冲数,已知速度可以求得频率。 程序中包含有FB和ST内容;移植方便,在其他程序中可以直接添加已写好的FB块。 ,三菱FX3U;步进电机换算;FB块;程序模块化;稳定性;可移植性;距离与脉冲数换算;速度与频率换算;FB和ST内容;移植方便。,三菱FX3U步进电机换算FB块:程序模块化与高稳定性实现
-
光伏逆变器TMS320F28335设计方案:Boost升压与单相全桥逆变,PWM与SPWM控制,MPPT恒压跟踪法实现,基于TMS320F28335DSP的光伏逆变器设计方案:Boost升压与单相全桥
光伏逆变器TMS320F28335设计方案:Boost升压与单相全桥逆变,PWM与SPWM控制,MPPT恒压跟踪法实现,基于TMS320F28335DSP的光伏逆变器设计方案:Boost升压与单相全桥逆变电路实现及MPPT技术解析,光伏逆变器设计方案TMS320F28335-176资料 PCB 原理图 源代码 1. 本设计DC-DC采用Boost升压,DCAC采用单相全桥逆变电路结构。 2. 以TI公司的浮点数字信号控制器TMS320F28335DSP为控制电路核心,采用规则采样法和DSP片内ePWM模块功能实现PWM和SPWM波。 3. PV最大功率点跟踪(MPPT)采用了恒压跟踪法(CVT法)来实现,并用软件锁相环进行系统的同频、同相控制,控制灵活简单。 4.资料包含: 原理图,PCB(Protel或者AD打开),源程序代码(CCS打开),BOM清单,参考资料 ,核心关键词:TMS320F28335-176; 光伏逆变器; 升压; 逆变电路; 数字信号控制器; 规则采样法; ePWM模块; PWM; SPWM波; MPPT; 恒压跟踪法; 原理图; PCB; 源程序代码; BOM
-
kernel-modules-core-5.14.0-474.el9.x86-64.rpm
centos9内核安装包
-
昆仑通态触摸屏与两台台达VFD-M变频器通讯实现:频率设定、启停控制与状态指示功能接线及设置说明,昆仑通态TPC7062KD触摸屏与两台台达VFD-M变频器通讯程序:实现频率设定、启停控制与状态指示
昆仑通态触摸屏与两台台达VFD-M变频器通讯实现:频率设定、启停控制与状态指示功能接线及设置说明,昆仑通态TPC7062KD触摸屏与两台台达VFD-M变频器通讯程序:实现频率设定、启停控制与状态指示,昆仑通态MCGS与2台台达VFD-M变频器通讯程序实现昆仑通态触摸屏与2台台达VFD-M变频器通讯,程序稳定可靠 器件:昆仑通态TPC7062KD触摸屏,2台台达VFD-M变频器,附送接线说明和设置说明 功能:实现频率设定,启停控制,实际频率读取等,状态指示 ,昆仑通态MCGS; 台达VFD-M变频器; 通讯程序; 稳定可靠; 频率设定; 启停控制; 实际频率读取; 状态指示; 接线说明; 设置说明,昆仑通态MCGS与台达VFD-M变频器通讯程序:稳定可靠,双机控制全实现
-
研控步进电机驱动器方案验证通过,核心技术成熟可生产,咨询优惠价格!硬件原理图与PCB源代码全包括 ,研控步进电机驱动器方案验证通过,核心技术掌握,生产准备,咨询实际价格,包含硬件原理图及PCB源代码
研控步进电机驱动器方案验证通过,核心技术成熟可生产,咨询优惠价格!硬件原理图与PCB源代码全包括。,研控步进电机驱动器方案验证通过,核心技术掌握,生产准备,咨询实际价格,包含硬件原理图及PCB源代码。,研控步进电机驱动器方案 验证可用,可以生产,欢迎咨询实际价格,快速掌握核心技术。 包括硬件原理图 PCB源代码 ,研控步进电机驱动器方案; 验证可用; 可生产; 核心技术; 硬件原理图; PCB源代码,研控步进电机驱动器方案验证通过,现可生产供应,快速掌握核心技术,附硬件原理图及PCB源代码。
-
高质量的OPCClient-UA源码分享:基于C#的OPC客户端开发源码集(测试稳定、多行业应用实例、VS编辑器支持),高质量OPC客户端源码解析:OPCClient-UA C#开发,适用于VS201
高质量的OPCClient_UA源码分享:基于C#的OPC客户端开发源码集(测试稳定、多行业应用实例、VS编辑器支持),高质量OPC客户端源码解析:OPCClient_UA C#开发,适用于VS2019及多行业现场应用源码分享,OPCClient_UA源码OPC客户端源码(c#开发) 另外有opcserver,opcclient的da,ua版本的见其他链接。 本项目为VS2019开发,可用VS其他版本的编辑器打开项目。 已应用到多个行业的几百个应用现场,长时间运行稳定,可靠。 本项目中提供测试OPCClient的软件开发源码,有详细的注释,二次开发清晰明了。 ,OPCClient_UA; OPC客户端源码; C#开发; VS2019项目; 稳定可靠; 详细注释; 二次开发,OPC客户端源码:稳定可靠的C#开发实现,含详细注释支持二次开发
-
167.JSP+SQL飞机票网上订票系统 javabean.zip
毕业设计
-
三菱FX3U六轴标准程序:六轴控制特色及转盘多工位流水作业功能实现,三菱FX3U六轴标准程序:实现3轴本体控制与3个1PG定位模块,轴点动控制、回零控制及定位功能,结合气缸与DD马达控制转盘的多工位流
三菱FX3U六轴标准程序:六轴控制特色及转盘多工位流水作业功能实现,三菱FX3U六轴标准程序:实现3轴本体控制与3个1PG定位模块,轴点动控制、回零控制及定位功能,结合气缸与DD马达控制转盘的多工位流水作业模式,三菱FX3U六轴标准程序,程序包含本体3轴控制,扩展3个1PG定位模块,一共六轴。 程序有轴点动控制,回零控制,相对定位,绝对定位。 另有气缸数个,一个大是DD马达控制的转盘,整个是转盘多工位流水作业方式 ,三菱FX3U;六轴控制;轴点动控制;回零控制;定位模块;DD马达转盘;流水作业方式,三菱FX3U六轴程序控制:转盘流水作业的机械多轴系统
25 楼 runfriends 2013-02-07 14:49
调用开放平台的接口,把买票整合进自己的网站成为自身业务的一部分,应该是一种更好的方式。
我的意思很简单,开放式平台的前提条件是可用资源有可选性,对于航空有多家航空公司,所以才会有竞争,价格才会有调整空间,才会有携程网等平台提供便宜机票。铁路没有这方便的资源,所以开放平台没有用,所以才说你本末倒置。
24 楼 nick.s.ni 2013-02-07 14:18
飞机票价票量也不是携程网、去哪儿网定的。它们不是一样存在了吗?既然它们能存在,为什么车票开放平台就不行?开放平台可以降低铁道部的维护成本,让我们有更多买票渠道的选择,能选择体验最好,折扣最多的买票渠道。即使买票没有折扣,至少用户体验更容易改善。
你可能会说,所有卖票网站都抬价怎么办?所以我说,谁要经营这样的网站谁就得遵守游戏规则,游戏规则限定这些东西。不遵守者出局。
我的意思很简单,开放式平台的前提条件是可用资源有可选性,对于航空有多家航空公司,所以才会有竞争,价格才会有调整空间,才会有携程网等平台提供便宜机票。铁路没有这方便的资源,所以开放平台没有用,所以才说你本末倒置。
23 楼 runfriends 2013-02-04 13:33
本末倒置了,决定票价和有多少票的,不是网站,不是程式,开放API更是瞎扯,火车只此一家别无分号,再多的网站卖票也不会让火车票降价。除非像电信、联通那样多建几个铁路局,多几个铁路线,不然根本没有所谓竞争关系。
你会错我意。
我没说用这种方式让车票降价。
你说的开放平台会造成各种抬价,那么是谁会抬价?
至少类似票贩黄牛那种抬价的情况可以限制。而且铁道部实现这种限制比消灭真人黄牛党要容易的多。
票价和票量当然不是网站或程序决定,这些东西跟开放平台没有关系。
飞机票价票量也不是携程网、去哪儿网定的。它们不是一样存在了吗?既然它们能存在,为什么车票开放平台就不行?开放平台可以降低铁道部的维护成本,让我们有更多买票渠道的选择,能选择体验最好,折扣最多的买票渠道。即使买票没有折扣,至少用户体验更容易改善。
你可能会说,所有卖票网站都抬价怎么办?所以我说,谁要经营这样的网站谁就得遵守游戏规则,游戏规则限定这些东西。不遵守者出局。
22 楼 nick.s.ni 2013-02-04 13:16
酷壳博主说,就为了一年那么几次,十几天的高访问量,花那么多钱开发一个购票网站,也就铁道部能做的出来了。
个人觉的,更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。
这样访问压力分散到了不同公司的服务器,而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。
另外,通过云计算将根据一年中不同时段的压力弹性改变计算资源,也可以节省成本。
看你就是不买票的叫你大冬天的去排队买回家的票你就不会这么说,以现在的运力火车票是无法满足需求的,开放平台会造成各种抬价,造成的各种社会问题谁买单?花这么多钱还是值得的,
我买票,但是我从来不排队买。我从来不在高峰期买票。没必要非要挤那一天走。
火车运力不足我认同。但是开放平台会抬价我不敢苟同。
如果开放平台,可以限定开发者资质。可以限制最高售价、最低售价等等,怎么可能会有社会问题。
花这么多钱真不值得,明明有性价比更高的做法。
就为了一年那么几个高峰期花那么钱就是扯淡。
历史事实多次证明,放开市场、自由竞争更容易带来良性竞争,而不是越来越恶化;可能刚一开始会有各种问题出现,但是整体趋势是越来越好。为了能有一个更良好的未来,在一定历史阶段做出一定牺牲是值得的。
本末倒置了,决定票价和有多少票的,不是网站,不是程式,开放API更是瞎扯,火车只此一家别无分号,再多的网站卖票也不会让火车票降价。除非像电信、联通那样多建几个铁路局,多几个铁路线,不然根本没有所谓竞争关系。
21 楼 nick.s.ni 2013-02-04 13:11
这位老兄。我只是想引用我想说的部分。自认为没有改变你发表的主题。我只是删了一部分我不想讨论的内容。
如果你觉的是冒犯,我只有抱歉了
删除没有关系,引一部分也没有关系,但
20 楼 runfriends 2013-02-04 12:20
看你就是不买票的叫你大冬天的去排队买回家的票你就不会这么说,以现在的运力火车票是无法满足需求的,开放平台会造成各种抬价,造成的各种社会问题谁买单?花这么多钱还是值得的,
我买票,但是我从来不排队买。我从来不在高峰期买票。没必要非要挤那一天走。
火车运力不足我认同。但是开放平台会抬价我不敢苟同。
如果开放平台,可以限定开发者资质。可以限制最高售价、最低售价等等,怎么可能会有社会问题。
花这么多钱真不值得,明明有性价比更高的做法。
就为了一年那么几个高峰期花那么钱就是扯淡。
历史事实多次证明,放开市场、自由竞争更容易带来良性竞争,而不是越来越恶化;可能刚一开始会有各种问题出现,但是整体趋势是越来越好。为了能有一个更良好的未来,在一定历史阶段做出一定牺牲是值得的。
19 楼 hymagic 2013-02-04 11:25
酷壳博主说,就为了一年那么几次,十几天的高访问量,花那么多钱开发一个购票网站,也就铁道部能做的出来了。
个人觉的,更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。
这样访问压力分散到了不同公司的服务器,而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。
另外,通过云计算将根据一年中不同时段的压力弹性改变计算资源,也可以节省成本。
看你就是不买票的叫你大冬天的去排队买回家的票你就不会这么说,以现在的运力火车票是无法满足需求的,开放平台会造成各种抬价,造成的各种社会问题谁买单?花这么多钱还是值得的,
18 楼 runfriends 2013-02-03 15:14
当然应该是这样。问题就是官方没有提供,所以才有了抢票工具。反过来官方还说抢票工具不好,而不是考虑改进自己。
插件作者自己都说了,如果官方觉的自己的插件有功能是他们想要添加的,他可以把源码提供出来。结果却没想到插件遭到了禁止。官方的思维逻辑确实不是常人能揣度的。
我自己做的东西不好,别人也不能让它变好;谁想让它变好我弄死谁。
17 楼 runfriends 2013-02-03 15:11
这位老兄。我只是想引用我想说的部分。自认为没有改变你发表的主题。我只是删了一部分我不想讨论的内容。
如果你觉的是冒犯,我只有抱歉了
16 楼 马晨辉 2013-02-02 15:21
15 楼 nick.s.ni 2013-02-02 14:12
存款机制个人觉的不是很有必要。就像从携程网买飞机票,也没有存钱机制。不过如果用户觉的存钱更方便,而又是经常需要乘火车的人,存款倒是可以作为一个辅助功能。
个人认为取消排队机制,细化事务粒度更重要一些。
对于存
应带有存款机制,向淘宝学习,不要每次都是到网银去支付,浪费大量时间。而且缩短排队时间。
抢票工具不是网站要改善的东西。用户体验才是。
可能很多人认为本来网站效率就不高,抢票插件更是大大增加了服务器的压力。
其实插件作者如果是个聪明人,才不会不断的疯狂重试呢。那样没有什么实际意义。实际上一个优秀的抢票插件只是在模拟人的行为,将人的行为自动化。比如隔几秒钟自动刷新一次、保存查询条件、自动支付等等。这些东西才是一个优秀的插件应该有的功能,要是疯狂重试那就成了攻击了,而插件的目的是帮助网站改善用户体验,把用户机械的重复操作自动化,让用户容易买到票。
甚至网站完全可以取消注册才能购买,购买时要输入验证码这些功能,改善网站本身的效率才是关键。
从目前来看,您认为12306需要着重改善哪些方面?如果让您来设计,您会如何做?
浏览器自动抢票插件问题,解决方法每个页面的提交按钮换成Java Applet 或 Flash,提交在进行加密,只要不是纯HTML就不会有问题。实现也最简单。
14 楼 runfriends 2013-02-02 10:39
存款机制个人觉的不是很有必要。就像从携程网买飞机票,也没有存钱机制。不过如果用户觉的存钱更方便,而又是经常需要乘火车的人,存款倒是可以作为一个辅助功能。
个人认为取消排队机制,细化事务粒度更重要一些。
对于存
应带有存款机制,向淘宝学习,不要每次都是到网银去支付,浪费大量时间。而且缩短排队时间。
抢票工具不是网站要改善的东西。用户体验才是。
可能很多人认为本来网站效率就不高,抢票插件更是大大增加了服务器的压力。
其实插件作者如果是个聪明人,才不会不断的疯狂重试呢。那样没有什么实际意义。实际上一个优秀的抢票插件只是在模拟人的行为,将人的行为自动化。比如隔几秒钟自动刷新一次、保存查询条件、自动支付等等。这些东西才是一个优秀的插件应该有的功能,要是疯狂重试那就成了攻击了,而插件的目的是帮助网站改善用户体验,把用户机械的重复操作自动化,让用户容易买到票。
甚至网站完全可以取消注册才能购买,购买时要输入验证码这些功能,改善网站本身的效率才是关键。
从目前来看,您认为12306需要着重改善哪些方面?如果让您来设计,您会如何做?
浏览器自动抢票插件问题,解决方法每个页面的提交按钮换成Java Applet 或 Flash,提交在进行加密,只要不是纯HTML就不会有问题。实现也最简单。
13 楼 nick.s.ni 2013-02-02 09:00
应带有存款机制,向淘宝学习,不要每次都是到网银去支付,浪费大量时间。而且缩短排队时间。
12306在系统、业务设计上,还存在哪些问题与挑战?
本身逻辑判断很复杂,除了现有的每趟车次分段购票的基本逻辑,还有各个铁路局之间、各
个站点之间预留票问题。有时候是人的问题而不是系统逻辑问题,所以需要人去沟通解决。
通过12306的现状您认为高性能并发系统架构应该如何设计?关键是什么?
首先不是软件架构,是硬件架构,假设并发是1亿,需要多大的带宽处理请求、响应的
数据,之后是交换机、服务器的硬件配置。在之后才是软件层面。使用数据库集群并进行逻辑处理,Web程式的ORM框架就不能用数据缓存,都交给数据库,其实没几张表,用ORM 实在没必要。 考虑到全国的网络现况,还可以做异地數據庫同步(Oracle Stream)。 Web程式不要进行数据库相关的逻辑判断。
从目前来看,您认为12306需要着重改善哪些方面?如果让您来设计,您会如何做?
浏览器自动抢票插件问题,解决方法每个页面的提交按钮换成Java Applet 或 Flash,提交在进行加密,只要不是纯HTML就不会有问题。实现也最简单。
12 楼 chinaagan 2013-02-01 19:19
11 楼 xisuchi 2013-02-01 17:30
10 楼 Leon.Wood 2013-02-01 15:47
9 楼 loveyunwt 2013-02-01 15:32
8 楼 runfriends 2013-02-01 15:17
酷壳博主说,就为了一年那么几次,十几天的高访问量,花那么多钱开发一个购票网站,也就铁道部能做的出来了。
个人觉的,更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。
这样访问压力分散到了不同公司的服务器,而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。
另外,通过云计算将根据一年中不同时段的压力弹性改变计算资源,也可以节省成本。
7 楼 runfriends 2013-02-01 15:11
动态、静态内容用不同的服务器完成。静态内容由CDN缓存。
6 楼 runfriends 2013-02-01 15:05
我知道它很难用,所以我从来用它买过票。去年国庆节查询个票,慢的要命。
从sql的拼写到页面优化,从程序架构到服务器架构都需要全面重构。
完全是一群业余选手的习作。
居然不是参数化查询sql,而是查询参数拼到sql里的。
应该采用js、css、图片、html都应该启用gzip压缩,所有css应减少到一个,js文件该合并的合并,能重用的重用,页面背景图应尽量合并成一个文件。尽量减少http请求数。
12306在去年国庆之前进行了改版,加入了排队系统,您认为排队系统的增加目的是什么?
12306在系统、业务设计上,还存在哪些问题与挑战?
通过12306的现状您认为高性能并发系统架构应该如何设计?关键是什么?
高性能并发系统技术实现的关键是什么?
这四个问题一块回答。
刚开始的时候看到网上很多人说它有一个巨大的事务。后来又加入了排队系统。
至于为什么个人猜测可能是为了降低数据库压力。
而实际上,用户并发量并没有变化,排队导致大量访问不能尽快返回,占用了大量系统资源。实际上这样做降低了系统吞吐量。数据库压力有没有降低先不说,系统吞吐量肯定会降低。
铁道部应该对每节车厢、每个车次要卖出多少站票、软座、硬座、卧铺有一个规划。
购买同一车次和票种的人不会造成太高的并发。
因此关键在于查询和买票服务器集群的设计和实现。
设计一个票池系统,按照车次、线路、区域划分票池,按照车次、站、软、硬、卧分类不同票种,将每个票种分配到票池集群的某台服务器上。买票时肯定已经确定了票种,通过一致性哈希准确定位指定票种所在的服务器。
票池系统完全采用内存储存预售票票种、票量信息。
查询、购买分开不同的集群,两个集群之间实现余票量同步。
保证每个操作迅速返回,不必保证查询和购买实时同步,也不必保证查到的票在购买的时候一定能买到。
有人提议12306采用NoSQL存储,您认为是否可行?
事务的粒度应做到购买行为是原子性的,即保证两个人不会买到相同的票即可。
每个票种的优先级是一样的,应不同的查询条件保证能尽快的返回。
实际上每天出售的票种总和远达不到海量的程度。但是每年有几个时段并发量特别大。如果使用大量nosql数据库集群,票量致性恐怕难以保证;如果使用单台nosql,恐怕吞吐量和实时响应也会像mysql一样难以做到。
不论什么数据库,都难以完成这么少的数据量却要完成这么大并发量的情况。
个人认为还是把不同票种分散在不同票池服务器中,完全由程序操作内存完成查询和购买更合适一些,虽然数据结构可能要复杂很多。
最后根据每个票种的余票量要限制每个票种的查询和购买并发量。超过的就拒绝访问,以节省资源。早死早超生,而不是所有人都耗在买票这个事上。
从目前来看,您认为12306需要着重改善哪些方面?如果让您来设计,您会如何做?
前面都已经说过了。
其他您想说的话!
第一:专业的事就应该找专家来做。不论招标也好,还是私下里寻找合作伙伴也好,都应该挑选有高并发、高吞吐量这方面的专家完成。而这样的人只存在于大型电商公司。铁道部花了那么多钱却没去找正确的人来做这件事。
第二:关键在于目的是什么。目的是花钱,还是为了方便买票,还是其它目的?
第三:关于抢票插件的问题。如果网站本身响应迅速,抢票插件也没什么市场了。关键在于要去考虑怎么改善用户体验,而不是要去禁抢票插件。上头意识从来都没有做正确的事。