|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-13
火车票才多少种啊，全放内存，哪里有压力啊
|
| 返回顶楼 | |
|
发表时间：2012-01-13
紧俏资源，摇号吧
大部分人都能提前一个月填写目的地、发车日前吧 |
| 返回顶楼 | |
|
发表时间：2012-01-13
其实查询了余票之后发现有票，再下单的时候发现又没有票
我觉得这个应该是可以容忍的 |
| 返回顶楼 | |
|
发表时间：2012-01-13
mikewang 写道 kimmking 写道 作为央行xxxx中心的前员工，表示此银行基本都是DB2 另外，你说的报数文件么？县级以下才是吧，往上都要集中入库的。 那是支行以下，到网点（有的在农村）， 现在应该没有报数文件了，都联网了。 支行以上（省行，央行），你可能没接触过，跨行交易都是在央行做的，“冲账” 这个词还记得把， 所谓的冲账就是改改文本文件了。 不是所有的跨行交易都在央行的 这个得看什么交易了 比如说银行间黄金交易就是在工商银行结算的 |
| 返回顶楼 | |
|
发表时间：2012-01-13
坏孩子 写道 火车票才多少种啊，全放内存，哪里有压力啊
这肯定不行，必须要持久化的，没有数据库支撑不了， |
| 返回顶楼 | |
|
发表时间：2012-01-13
zmcsut 写道 紧俏资源，摇号吧
大部分人都能提前一个月填写目的地、发车日前吧 行政手段也是好方法 |
| 返回顶楼 | |
|
发表时间：2012-01-13
yue19870813 写道 hueng512 写道 linliangyi2007 写道 wangda.cn 写道 楼主同志，你说的这些在网上随便一搜一大堆的方案啊。这些没有用，起不了关键作用。你要先了解铁路订票的业务以后才有资格说话。
订票这套业务肯定比你我想的都要复杂的多。 "订票这套业务肯定比你我想的都要复杂的多"多么冠冕堂皇的理由啊，有了这个理由，你说啥都没用！ 一句话，你们地球人的智商是做不了这个系统的！ 顶老林~！ 系统肯定是很复杂的，不仅仅是买票，它的很多数据接口都要和其他部门结合，比如公安、税务等，其他的系统做的就很烂，有的时候你必须去适应那些烂的，所以国家部门的系统真的是恶性循环，不统一，互相影响，没有最烂，只有更烂！ 根据国情，这个绝对可能，，否则大过年的，跑几个群众去北京‘游玩’，就有问题了 |
| 返回顶楼 | |
|
发表时间：2012-01-14
最后修改：2012-01-14
linliangyi2007 写道 楼上的大谈NoSQL+RDB是辛苦了，换我也会采用类似方案。但是 那帮子搞这套系统的人说不定连啥子redis都不知道呢。 不是哥小看人，而是体制内的事情就是这么荒唐！ 我们整天谈事物完整性，这个几乎是做IT数据库的基础知识和基本要求，当我看到CCAV 的新闻说，钱扣了，票没出，真是让哥大跌眼镜！这他x连最基本的东西都没了，还奢谈个屁的性能，高并发！ 这个可能是和网银之间的接口问题吧。 扣钱是在网银这里扣除的。银行这里成功支付扣钱之后，扣钱的事务可能就提交了。然后返回消息给铁道部系统，让他显示出票。这个时候票应该还是锁着的。但是如果铁道部系统这里一直灭有收到银行支付的返回信息，超时之后就做回滚操作了。然后是解锁。在这个过程中是否能够让银行的支付扣钱事务也进行回滚，就看银行这边的事务了。说不定是银行这边的问题。╮(╯▽╰)╭ |
| 返回顶楼 | |
|
发表时间：2012-01-14
jiaoronggui 写道 坏孩子 写道 火车票才多少种啊，全放内存，哪里有压力啊
这肯定不行，必须要持久化的，没有数据库支撑不了， 定时持久化咯，我100ms持久化一次可以吧 |
| 返回顶楼 | |
|
发表时间：2012-01-14
坏孩子 写道 jiaoronggui 写道 坏孩子 写道 火车票才多少种啊，全放内存，哪里有压力啊
这肯定不行，必须要持久化的，没有数据库支撑不了， 定时持久化咯，我100ms持久化一次可以吧 如果不是电子商务网站的话，可以考虑这种方式，但是因为是电子商务网站，万一出现断电，服务器重新等等情况，就比较难办了，值得商榷 |
| 返回顶楼 | |
