s**x
发帖数: 7506 | 1 锁票跟票卖不出去了差不多，只是还没真正卖出去，锁票应该有合理的时间限制，比如
10 分钟，差不多是支付交割完成的两三倍吧。
锁票是实时响应的关键，买票必须锁票，一旦锁票，票就相当于卖出了，万一用户支付
失败，就把票解锁，释放票源。
有了锁票，联票问题应刃而解，100 张联票，就并行发100个锁票请求，有一个失败，
就告诉用户失败，成功了，就进入支付交割，完成购票，支付失败，就把所有先前锁住
的票解锁。
整个购票时间应该取决于支付交割，支付交割期间不应该影响别人的买票过程。
有什么问题吗？ |
|
y******u
发帖数: 804 | 2 请定义下我的“丢票”好吗？（中文确实不够精确）
只要用户开始支付行为，肯定要锁票了，直到支付成功，finalize出票，或者支付失败
，rollback票。涉及钱的不能瞎来。
在此之前票卖完了没了，你做好前端交互解释清楚就行了。 |
|
g*****g
发帖数: 34805 | 3 就你这个锁票过程，你觉得能每秒20万？你丫就没写过啥高并发系统，别出来现了。 |
|
g*****y
发帖数: 7271 | 4 这个功能和买飞机票的实现也没什么区别吧。
买飞机票都是给起点和终点，计算机帮助查询有票能走通的路线。这个时候
我估计一般不会立刻锁票。有的查询网站会写一下多少available的seats。
如果很少，用户就得尽快定下线路，抢票。用户如果花不少时间才选定了某
一个联票路线，估计可能会到下单时就已经被抢走了。
如果查询到的可行路线的票都锁住，就不会出现列出来的路线得不到的情况。
但是查询的人很多的话，早一点查很可能会正好没票，晚点查倒有了（因为
有人选定了一个路线，其它线上的票就解锁了）。会给用户很不公平的感觉。
所以比较好的可能是帮锁一条最佳的路线（用户自定义标准，比方快车，
慢车，转车次数之类的），其它路线仅供参考，不帮锁票，不保证
availability。 |
|
g*****g
发帖数: 34805 | 5 俩菜鸟还死撑。我说得一个小时就是个上限，撑死这么久票也卖光了。12306为啥要分
时抢票呀，不就是为了把票数下一个数量级。本来最多一个小时处理完，立马变成5分
钟，再弄个高大上的内存数据库，你要的实时出来了。
我老人家不喜欢这个设计。早上起来下个单子，出门的时候就知道买没买着多省事。你
还让我跟钟摆似的每个小时去刷一次。但内部异步队列，前后分离还是一样的，这些都
看不出来也别出来丢人现眼了。 |
|
s**x
发帖数: 7506 | 6
第二根本不是事，看锁票是关键一文的办法。
架构根本就不会讨论数据结构的细节问题。
过分注重细节就肯定忽视了整体架构。 |
|
s**x
发帖数: 7506 | 7 联票问题很简单，也可以看成一个nice to have feature, not a must to have.
借口联票很难，把系统做成批处理要求用戸等一小时，更是愚不可及。
有了实时的非联票系统，用户可以自己顶联票，有几段没票，就全部退票，这有点笨，
也证明联票其实是可有可无的feature. 一个实时系统才是关键。
购团体票，联票一个道理。 |
|
y******u
发帖数: 804 | 8 i'm with sdlx on this.
不要忘了支付跟银行或支付宝打一个来回，也是秒级的。再高并发，你也得cope with
这个事实。各位，请去12306买一张票再喷吧 |
|
|
|
s**x
发帖数: 7506 | 10
你连什么是分布式都不知道，一个车次，算一台机器，一万张票，算10秒订完好了，后
来的全是read only, 全部并发。
我说你还是去实现我那个简化版吧，联票你脑子不够使。 |
|
s**x
发帖数: 7506 | 11
你连什么是分布式都不知道，一个车次，算一台机器，一万张票，算10秒订完好了，后
来的全是read only, 全部并发。
我说你还是去实现我那个简化版吧，联票你脑子不够使。 |
|
g*****g
发帖数: 34805 | 12 还分着写，你有没有考虑过一个车次几十段，中间不能换座位。有没有考虑过联票。有
没有考虑一单几张票要尽量一个车厢里。我老就不说这种调度系统都是 legacy稳定测
试了
几十年大家都不敢动。
尼玛刷了几道题懂个 lock就不知天高地厚了。我老人家好歹 title是 architect, 你
不服怎地？ |
|
g*****g
发帖数: 34805 | 13 这当然可以，今年12306也在提前预售期。我老人家无非讨论一下峰值超过处理能力该
怎么做而已。事实就是12306如果能真做到实时，又何必做分时抢票这种脱裤子放屁的
事情。前两年没内存数据库的时候，下单更是丢得一塌糊涂。 |
|
p**2
发帖数: 613 | 14 从设计上来说，
B直接没票的情况不但公平，而且对出票速度有利
因为如果说等A，那就要设一个max等待值（比如说3秒），
无论这个时间多少，它终究会过去的，>maxValue之后的1毫秒，
C上来拿到1次票，对B来说和直接没票是一样的公正性，
但是却牺牲了N个人的时间，所以，我个人感觉是直接没票。
或者在等票这块可以写个公式处理，
等票数：RequestCount
锁票数：HoldCount
等待时间：TimeOfWaiting
最大锁票时间：maxHoldTime(锁票不买的最大值)
TimeOfWaiting=f(RequestCount,HoldCount,maxHoldTime)
根据实际情况加个参数，动态load一个等待时间，相对比较好一些。
类似1万等票，10张锁票的情况，直接过，
如果10张等票，1万锁票，那可以考虑等一会儿，
具体参数，肯定要实际情况中调整。
票， |
|
n****j
发帖数: 1708 | 15 技术问题可以讨论，打滚的请绕道吧。
1、结构：前端 -- 抢票 -- 后端，前端和后端可以直连、两者均可无限 scale。
2、职能：前端负责 web 服务，抢票负责锁定票源，后端负责数据库服务等
3、查询：前端可计算路径，并直接向后端查询余票数量。
4、订票：乘客选定路径后，向抢票提交订单，锁定该座位全程。因数据动态变化，可
能发生无票情况，返回 3
5、出票：支付，出票。如支付失败或超时，通知抢票解锁。支付成功通知抢票，标记
售出路段后，余票放回票库。
最后说一下抢票节点的作用。传统的订票系统，因并发关系，在订票的时候可能发生多
个请求互锁。引入抢票节点后，锁票顺序执行，避免了锁记录，大幅提高效率。 |
|
s**x
发帖数: 7506 | 16
这个联票问题大家想的太复杂了，应该没必要。
一种办法就是联票跟单张票一样锁票，有一张锁票失败，整个联票购买失败，解锁已锁
的票。
联票之间没有相关性，不互锁。各车次锁票完全独立。
这么做应该足够了，实在不行，各车次可预留一定比例的票专门做联票。 |
|
q*c
发帖数: 9453 | 17 终于放假了， 你们这些单机党也太猖獗了。 有点时间给你们个堆机器版的。 不过时
间很少所以剩余的自己脑补。
老魏你说的能达到你的单机版的 1/10 就了得了，你的也就几M/s. 你看看我这个版本。
用的全是 proven technology. 有点经验的一看就知道肯定能 work. 全套卖票。
当然你也说了， 我这个酒不需要实现了， 因为比较麻烦。 不过你看看就知道肯定无
问题
实现的和你那个功能完全一样。
前段， 无状态的 web server. 接受订票. 受到订票直接转到相应的中间集群。
中间， 是按照用户 id hash 的 用户数据库群 ＋ 用户 controller.
收到订单然后在数据库中产生该用户的订票信息. 比如有三张连票，
userid, orderID, start1, end1, status = processing
userid, orderID, start2, end2, status = processing
userid, orderID, start3, end3, status = processing
后端， 是按照车次hash ... 阅读全帖 |
|
n*****t
发帖数: 22014 | 18 1、抢票：
前段很容易针对 pattern 进行限制，比如你 100ms 识别出校验码，滚粗去；2 秒钟查
询 10 个车次，滚粗去 。。。
2、联程：
现在已经有大量数据可以分析，针对可能的联程构建虚拟车次，比如北京到广州经上海
转，加个车次 V102120，小概率的比如北京经乌鲁木齐到天津就不加了。
3、预充值：
购买前先充值到账户，5 毛钱余额的不准查北京到莫斯科的，充值后退款需 24 小时，
这样可以挡住部分黄牛。充值凭身份证到火车站窗口或者支付宝，这样也可以绑定真实
性。
4、查询、锁票预分析：
如某车次在特定时间段超过一定数量的查询，比如 5 秒内超过 10000 人，查询直接返
回 NULL。所有查询基于实际、虚拟车次，减少实时运算量。查询结果编译成锁票操作
码：车次+锁定站点，估摸 8 bytes 就够了。
5、锁票：
不同车次用不同 ASIC，虚拟车次使用 ASIC 级联，数据库操作不需要构建 SQL 神马的
，就是 2 个 cycle 的 I/O：write/read。
6、出票：
锁定成功直接出票
基本上除了锁票，其他都可以分布处理，各位大牛看看如何？ |
|
发帖数: 1 | 19
都过去快三年了，还有一堆不懂的
12306的难点在于快速查询剩票和锁票， 只要锁定了票， 出票可以直接转发给出票服
务器进行操作
到现在还没意识到这一点，我估计工作中也就能拿java轮子搭一搭了
这事情在本版搞大最大的作用也就是暴露了一大批智商不够的大水B
当年还有人搞笑的要在锁票期解决连续座位的问题，我都不知道这种智商是怎么混到美
国来的，偷渡吗， 显然只要一座一票，后期自然可以安排座位，为什么一定要在锁票
期消耗资源
说实话，这不是个技术问题，纯属智商问题
强耦合问题非要上分布式数据库，这都不只是技术没学好了 ，这是基因出大问题了 |
|
T********i
发帖数: 2416 | 20 我看基本上都不会。
会的话还讨论啥锁不锁的？interlocked本身就是锁了，而且是最低粒度锁。
后面区段没有票再把前面的InterlockedIncrement还回去。
最差性能是前面区段都有票，最后一个没票。要基本上Interlock两次。
区段数就是停靠站数加一。和联程票有关系么？
这么做，已经比现有的方案好多了。这么简单的，goodbug懂么？ |
|
s**x
发帖数: 7506 | 21 我在job 版已经说过了，一帮人还在讨论。联票很多个人同时买一样的票唯一的区别是
保证联票all or none 就可以了。
先锁票，有一个不成功，整个联票就报失败就好了。
锁票只考虑单车次，根本没有死锁的问题。
联票锁票可以并发，也可以按一定顺序比如从车次由大到小锁。
有什么问题吗？ |
|
L*****e
发帖数: 8347 | 22 讨论的锁票数就是为了简化讨论而已，实现时当然得锁座位，即使还有很多票，你也不
能同一个座位卖两次不是？不过不觉得锁座位在计算上比锁票数有啥不同，在剩最后一
张票需要抢时，本质是一样的。。。也许我没理解你说的方案？在哪个楼里？楼实在太
多了，眼晕。。。
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
f****4
发帖数: 1359 | 23 =这不是又来给魏老师洗地。退一万步，我老那个设计，出票不分库了，你该上啥机器上
=啥机器，反正总量亿级别，又是后台处理，没啥不行的。我分库的主要目的是减少处理
=延迟。再慢一亿张票当天也处理了。
别废话，我第一帖子里面就在等你打补丁。后面300个人因为你们的假设：queue排队必
须公平block在哪。这个假设你们放在那，不管你用什么东西实现数据库，分布的也好
，不分布的也好，延迟就在那。
前面有提到一个queue排队公平的问题。这是zhaoc和goodbug一直要实现的。还是2个车
次，不同数据库的例子。1还是要先买K356然后K789到常熟。2只是买K789上海到南京。
2的请求在B数据库上晚于1.在A上面，1的请求之前已经有200个买票请求了。在B上面
K789还有一张票，1排第一个，2排第二个，然后后面还有300个买票请求。因为排队公
平，2为了买到票，必须等1的银行交易要么成功，要么失败。1要完成交易，必须等在A
上的200个请求完成交易。这个交易是包含了慢的银行划款。2的排队时间被延长了。2
后面的300个买票请求都被延长。特别是春运这种，转车的时候
是第2天的情况很多，而... 阅读全帖 |
|
n*****t
发帖数: 22014 | 24 基本思想就是流水线，把冲突的瓶颈简化，集中到单个节点。
客户服务器 A：UI、车次选定，向 B 查询
编码服务器 B：提供 web interface 给 A，转换协议，TCPIP 向 C 查询，
2bit 表示操作：查询、锁定、解锁（付款失败等）、确认售出，
1bit 表示后续地址方式：区段、枚举
24bit 表示一个地址，如北京到上海，则其中每个区间皆用一个地址表示，售出一张票
需更新 15 个 byte
中心节点 C：响应查询、锁票，如有必要，TCPIP 包的解析在 kernel 里做，SSD 的写
也单独建分区，做设备文件操作，避开 FS 开销。
注：
1、锁票后，由 A 更新数据库，完成收款、出票、记录等功能，并通过 B 通知中心节
点，交易完成。
2、A 对数据库的操作，可保证无冲突，并可按车次等分布到多台 DB SERVER |
|
T********i
发帖数: 2416 | 25 看看我刚回goodbug的。
你的帖子说明你也不懂interlocked。
短短几秒钟，goodbug又PA两次。家教下作呀。
发信人: TeacherWei (TW), 信区: Programming
标 题: Re: 总结贴
发信站: BBS 未名空间站 (Tue Feb 4 17:18:04 2014, 美东)
AtomicInteger是java你都理解不了？
我20个段1个都不用锁。
10个线程，每线程20个段用时2us就足够了。
这个你能理解么？叫锁也不是一般意义exclusive的锁，而是锁定一张票，2us以后可能
再把这张票还回去而已。
declare
C |
|
N*n
发帖数: 456 | 26 这个不难解决。。从算法上要修一下
1。 是要按车次加锁。
2。是出连票时要把相关的两趟车一起加锁。。一个连票出完后，两车次一起解锁。
两个条件都满足，应该就可以解决你那个问题。 |
|
n*****t
发帖数: 22014 | 27 中心节点处理冲突的部分，也就是重票问题，具体就是每张票每个区间的锁票，一张票
过 5 个站就锁 5 个 byte，一旦锁定了，前段就可以慢慢处理了 |
|
g*****y
发帖数: 7271 | 28 没看懂你是怎么保证公平性的。能不能就下面例子解释一下：
1. A最先提交买票请求，买1， 3，5次车的联票。
2. B紧接着要买1次车票。
3. C也要求买1次车票。
如果A先锁了1次车的最后一张票，然后去要3次和5次车票。B需不需要等A的联票结果
出来再开始尝试锁票？
如果等，出票速度可能会相当慢。
如果不等，那B就直接得到没票的回答。然后A的3次车或5次车没票，rollback 1次车票，
C正好赶上就买走了。而B就很惨了，只能重新排到队尾去递交新的request。
本。 |
|
n*******7
发帖数: 181 | 29 再来讨论“后面”。：）
先探讨一下在qxc方案里什么是关键核心部分。应该不是web界面，不是对5000 后端db
分发锁票请求的中间服务器，而就是那存着所有余票的找票锁票的5000 后端 db。这应该
没有什么异议吧？
老魏的code直接就是那5000 db的drop-in replacement，以高得多的效率完成同样的功
能。 你说qxc 方案是完整的一套。那么老魏code 加上 qxc 方案去掉5000 db后的其它
非关键外围逻辑，是不是就是完整的一套？
所以，老魏code就是实现了qxc的12306的方案的关键核心部分。后面就是qxc方案里的
那些外围逻辑。怎么能说后面没有了？ |
|
b*******g
发帖数: 603 | 30 两个cluster.
一个上随便多台机器，从cassandra读取订单。简单验证单子有效性等，然后发到分票
的cluster.
上3000台机器分票，每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
对于联票，request并发发给两台不同机器，都成功返回后写入数据库。一个成功一个
不成功则发撤销request.
分票只需要在内存里搜索，单线程即可，1000张票，20段，简单的O(N) bruteforce算
法即可，还可以满足多票，保证满足同车厢，尽量满足连号没问题。有多少规则，支持
多少规则。分票结果无锁写入后台数据库，无冲突极快。
异步通知另外一个线程合并数据库结果，从数据库里读出分配座位信息，更新座位覆盖
状况。并定时(比如5秒）更新分票服务器内存。
对于所有可能的网络问题，硬件问题，导致分票结果不能存入数据库。不会有重票错票
，会暂时丢票。5秒后跟数据库sync恢复。
像这样的架构能达到什么样的分票速度？
如果一个单张票分票算法只能到0.1ms, 太监的单机单线程算法只能分10000张票。我这
个算网络延迟0.1ms, 一个单子2张票，0.2ms, 联票并发进行无影响... 阅读全帖 |
|
s**x
发帖数: 7506 | 31
当然锁票了，并行锁，联票跟非联票一样处理，谁也没有优先权。
有一个锁票失败，联票就失败，开锁。 |
|
n*******7
发帖数: 181 | 32 仔细看了你的方法。“从小到大的顺序开始去后端数据库锁票”和“任何异常情况，
返回失败， 已经
索票的数据库自动回卷”归结到数据库底层的实现，都是需要锁的，只是高层应用看不
到罢了。我同意“这些都是自动功能， well tested in real world.”。但实际做出
来，肯定不会有老魏的做法快。你一个车次一个数据库，老魏也一个core只管一个车次
，他的速度快上百倍都是很可能的。
再换一个做法，就用单机，直接实现用C实现roll lock和自动回卷，因为用锁了，比老
魏的做法慢，但是，因为省去数据库的overhead，还是应该比你的方法快。
当然，你的方法是在通用方面是有优势的，就是不要比性能了。 |
|
b*******8
发帖数: 37364 | 33 【 以下文字转载自 Sex2 讨论区 】
发信人: marzman (火星人), 信区: Sex2
标 题: 去女票家玩，被老丈人捉啪在床
发信站: BBS 未名空间站 (Thu Jan 17 20:14:15 2019, 美东)
不是我的，朋友的，朋友的，朋友的，重要的事情说三遍。
我朋友和女票在一起一个多月，感情很好，当然是什么做过了。不久前，他们一起去女
朋友家玩，家里没人，于是去了女朋友的卧室，女朋友卧室有钢琴，就在那里弹琴。
朋友的女朋友的钢琴谈的不错，可是弹着谈着，朋友就去坐在女朋友背后，通用手从后
面去抓女朋友的胸，抓了一会，女朋友是忍不住了，说痒，不弹了。再后来朋友就把手
放到女朋友的衣服里面，再后来女朋友就主动了，直接上床了。
在上床前，还想去锁门，结果们锁了几次锁不上，坏了，心想应该不会有什么人进来的
，不会这么运气不好吧，结果尼玛就出鬼了，就在两人脱光了啪啪的是，还没啪啪完毕
，朋友女朋友的父亲进来了，开了门，看了两人一眼，说道，尼玛睡得很安逸呀……
这父亲也不好说什么，假装没看到两人在啪啪。朋友是当时以激动，就射了，射了，射
了……
朋友说，绝对没想到出现这么... 阅读全帖 |
|
n*****t
发帖数: 22014 | 34 所谓看到能买到这个定义有歧义：查询的时候有票买不到，还是票源锁定后买不到？
前者当然没法保证也没人能保证，这个是 biz logic 决定的不是系统做不到（查询的
时候就给你锁票？）
后者除非 server 当机了，否则不会有问题。如果是前台当掉了，重新刷一次就没事了
，这个估计谁都习惯了，哈哈。
现在实际的问题，就是都在一个节点查询、锁票，一个大的 DBMS 显然搞不定，应该把
bottleneck 拆出来。 |
|
a***n
发帖数: 538 | 35 减少单个变量更新的contention. 比如有100张票，那么分成3个变量33,33,34，就可以
3个进程
都同时更新，最后一张票的时候会比较慢，因为要3个变量都检查。但是大部分情况只
要锁住一个变量就可以保证有票了。 |
|
y*******9
发帖数: 641 | 36 给LZ拜了，要不是LZ，我可怜的钱（也许已经没了）就没了，我明天还要跟银行核实
我正在跟他交易，他先票，我后钱（看起来很安全），他也是本来说chase。然后到讨
论付钱的时候，各种理由，变成了PNC。然后又各种理由，转成了一个小银行。我一共
做了3次wire，两次都是他说要改东西，所以我手动cancel，最后一次wire了，但是好
像是又给退回来了（今天wire的过程中回答安全问题错了2次，把自己的citi在wire之
后就看不到Checking和Saving account了，要明天带ID去citi，才能解锁，才能确切问
清楚wire是否真的退回，祈祷！）
最后说是要我买walmart的moneypak。这个时候，我犹豫了下，感觉很像骗子，然后他
又催着我去买，搞的很急似的。
就在这个危急关头，我果断的看到了LZ救命的帖子。（虽然已经太晚了，折腾这票2天
了，这才看到LZ的救命贴。）
最后我揭穿他，他一直表示不知道我在说什么，装懵懂，我连帖子链接都发给他了，他
还装不知道我说啥。本来我们在skype语音的，他最后可以回避语音，改成打字了。。。
最后我跟他说，如果票留着，我妻子上了飞机... 阅读全帖 |
|
y*******9
发帖数: 641 | 37 给LZ拜了，要不是LZ，我可怜的钱（也许已经没了）就没了，我明天还要跟银行核实
我正在跟他交易，他先票，我后钱（看起来很安全），他也是本来说chase。然后到讨
论付钱的时候，各种理由，变成了PNC。然后又各种理由，转成了一个小银行。我一共
做了3次wire，两次都是他说要改东西，所以我手动cancel，最后一次wire了，但是好
像是又给退回来了（今天wire的过程中回答安全问题错了2次，把自己的citi在wire之
后就看不到Checking和Saving account了，要明天带ID去citi，才能解锁，才能确切问
清楚wire是否真的退回，祈祷！）
最后说是要我买walmart的moneypak。这个时候，我犹豫了下，感觉很像骗子，然后他
又催着我去买，搞的很急似的。
就在这个危急关头，我果断的看到了LZ救命的帖子。（虽然已经太晚了，折腾这票2天
了，这才看到LZ的救命贴。）
最后我揭穿他，他一直表示不知道我在说什么，装懵懂，我连帖子链接都发给他了，他
还装不知道我说啥。本来我们在skype语音的，他最后可以回避语音，改成打字了。。。
最后我跟他说，如果票留着，我妻子上了飞机... 阅读全帖 |
|
S*********s
发帖数: 1963 | 38 记得以前买票可以要求agent把票hold个7天左右再出票，这两天定里程票的时候agent
说没法hold票，只能定了之后24小时内可以免费cancel，而且还有$25的电话手续费。
所以干脆就网上自己订了 （UA订票网上面也没有可以免费hold的选择）。
是现在改政策了，还是一直这样？有什么窍门可以hold票几天吗？我的hold票是指hold
住座位，不是锁住价格。
谢谢。 |
|
c**g
发帖数: 565 | 39 说吧， 建党你要多少，再给大家讲讲你那个编号10年消耗是怎么出来的？好票空了？
猴版你要么？ 不多要你的，按照国内市场价咱们马上进行交割。
还有什么东西你要找的？ 说个数量价格，光这里说虚的有意思么？
所谓的好票从来不缺，价格上涨了，货都捂起来了，现在你给我找点06的和谐铁路，98
总理看看？ 你说这东西也是缺货？
说实话，现在涨的东西都是有量的东西， 庄家手里一把一把的，王国强敢这么拉编号
，你知道他收了多少进去么，你知道他怎么操作么？你去四达看看就知道了，他那这些
东西抵押拆出来的资金来拉升，有货的人替他锁仓而已。
你也知道06有几百版轮船出来，最近公司出来3000张飞天你不会不知道吧，这叫没量么
？ 这东西被一家主力接了，当然不会砸下来。编号的版票你见过多少？ 卢工黄胖手上
的巴黎版票你去打听一下有多厚。
也许这东西还会涨，但是我知道这些东西从来不会缺货，就是炒作品种而已，你不同意
可以举出反例来，证明这些东西或者销毁或者沉淀几十年不会出来，光在这里靠想象误
导大家有什么意思？还是那句话，你觉得什么好票量少找不到，你说品种价格，我给你
找货，OK？ |
|
发帖数: 1 | 40 转点之前一直可以搜票，自从MR账户解锁转了1000迈之后这两天登ANA账户就上不去了。
昨天给客服打电话，姑娘人挺好的但也不知道怎么回事，告诉我我的账户一直是active
的，里面还有我的1K里程。
后来实在不行了，我们就重新建了一个新号，然后她说会帮我把信息整合过来。
但是昨天搜票系统一直告诉我用不了。
到了今天，新的账号也用不了了……
在Reward Booking里登陆的时候显示的是
Your member information cannot be confirmed. Please contact ANA. (E_G02F07_
0005)
直接在主页登陆显示的则是
This service is not available for this particular card.
不知道版上有没有人碰到过这种情况啊？ANA每次打电话都要排队好久，而且小姑娘们
也都不知道怎么回事QAQ，我还等着给父母订机票呢 |
|
发帖数: 1 | 41 转点之前一直可以搜票，自从MR账户解锁转了1000迈之后这两天登ANA账户就上不去了。
昨天给客服打电话，姑娘人挺好的但也不知道怎么回事，告诉我我的账户一直是active
的，里面还有我的1K里程。
后来实在不行了，我们就重新建了一个新号，然后她说会帮我把信息整合过来。
但是昨天搜票系统一直告诉我用不了。
到了今天，新的账号也用不了了……
在Reward Booking里登陆的时候显示的是
Your member information cannot be confirmed. Please contact ANA. (E_G02F07_
0005)
直接在主页登陆显示的则是
This service is not available for this particular card.
不知道版上有没有人碰到过这种情况啊？ANA每次打电话都要排队好久，而且小姑娘们
也都不知道怎么回事QAQ，我还等着给父母订机票呢 |
|
g*****g
发帖数: 34805 | 42 傻逼锁票就要ACID，你丫把ACID做到前端去，就得前端锁票。 |
|
n*****t
发帖数: 22014 | 43 先到北京局锁一张票，再到上海局锁，失败就放弃北京那张，反馈 false，完全可以分布 |
|
t**********1
发帖数: 550 | 44 给我个理由，我为啥要锁票？
我不锁票能不能找到空座位？
满脑子屎。我也不指望你能要脸了。 |
|
n*****t
发帖数: 22014 | 45 黄牛问题是 business logic，跟锁票不锁票没关系 |
|
m********s
发帖数: 55301 | 46 2还要加上，一旦某票被查询完成并且有票，就要锁票并且所有与此票经停站有关联的
各票信息都要被更新。
另外，peak时，不是每分钟，是每5秒就会有上亿次的查询。 |
|
n****j
发帖数: 1708 | 47 1、抢票鸡是系统的唯一瓶颈，如果达不到一定性能，比如 1M 这个设计就失去意义了。
2、我个人认为没这么高要求，如果没记错的话，双十一高峰好像也不需要。不过可以
肯定的是，能做到、哪怕接近，这个设计理论上就有可行性。
3、理论可行性和实际是两码事，比如你不认识部长小姨子，什么天顶星技术可能都白
瞎。但我们是技术男，不关心这个。
好了，啰哩啰嗦一堆，大家要看的就是老魏的抢票鸡能不能响应 1M，对所有人都是一
个实践、学习。基于这个出发点：
1、不要扯多少个连接的蛋，抢票鸡完全可以不跟前端直连，由预处理鸡负责收集、协
议编码，返回结果。
2、预处理鸡的数量一般可以固定的，比如 1000 台前端，20 台预处理。老魏准备对接
200 个连接已经足够足够了，扯什么 http 的蛋纯属耍流氓。
3、测试限于抢票，所以别扯什么身份证号码或者短信校验的蛋，都超出赌局范围。
4、测试要尽量模拟实际情况，你不能订一张退一张，每张还就一个站就下。实际情况
，12306 的负荷 90 来自查询，锁票后支付失败的比例很低，订票再退票的比例更低，
测试前这个比例要明确。
5、基于模拟的目的，实际上出票不一定是严... 阅读全帖 |
|
n*****t
发帖数: 22014 | 48 国内支付手段忒落后了，尼玛交个钱又是短信又是图形校验，还说不定要用优盾等等等
等。
既然如此，干脆先充值，再查询，最后 1 click place order，这样就不需要锁票，你
下单的时候能看到剩余票多少，上中下铺各几张，手快就能抢到。
现在这样，刚查没票的，过一会又有了，逼得大家没事就刷票，能不折腾嘛 |
|
L*****e
发帖数: 8347 | 49 先不说你都无法做到完全同时在两个数据库上锁一条row，也不说你判断需要调票时，
时间戳晚的有冲突非联票请求都可能已经完成了。只说我上面已经给你解释了，这个冲
突不是等待调票的第一个联票请求和非联票请求才有，排第二第三的联票请求和相应的
单票请求都可能有冲突，你都锁？
btw，我基本上没啥数据库知识，也就是在坛子上看大牛们扯，就照猫画虎，一知半解
地胡诌，别介意哈。。。
着。
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
n*****t
发帖数: 22014 | 50 其实这套东西两年前大家都吵过了，逻辑没问题，分歧就是性能，否则抢票节点会成为
瓶颈。赌局涉及的也就是证明是否能满足需要。
实际上，真正需要锁票的是下单，12306 流量虽然大，但业内人士说了，90% 都是查询
。目前看来，抢票节点满足下单的需求，至少理论上绰绰有余。至于有人质疑这里面没
有身份证号、没有短信认证，已经超出抢票节点的需要。
画图就免了吧，哥们是 pad 刷版 。。。。。。 |
|
