Jinnyu

电脑 普瑞声纳 E3.5
客厅 普乐之声 Magnifi Max AX SR

月工资 30%
今年元旦买的房 公积金够覆盖贷款 (还有剩余

@Lexgni #119
那么在巨大的流量面前
如何保证数据的同步性呢 (笑

@caqiko #113
我说的这个检查不是只余票数量的检查
是一些属性 /规则 /()保密)上的检查

余票数量不是在这一步计算的

@0o0o0o0 #107 席位种类计算规则不对
铁路局只管放票, 具体什么席位铁路局是不 care 的
只有 12306 才 care 是什么席位

@RedisMasterNode #103
明面上不允许招人, 所以是进的下级单位, 但都是做 12306 的业务.
这些公司统一归属 中国铁道科学研究院 . 在海淀大柳树 (北交大旁边)

@0bSer7er #64
现在除了重大节日 其他时间放票都是 98%互联网放票

前员工答一波
Q: 技术难点有哪些?
A: 1. 全局性事务
2. 流量压力
3. 前置检查
4. 车票区段售卖

1. 全局性事务
现阶段最难的是全局性事务, 因为保密原因, 不能说太多, 一句话概述就是整个系统存在事务问题导致的性能低下
2. 流量压力
众所周知
3. 前置检查
你买一张票的前置检查多到你无法想象, 目前的做法是线性检查, 提过并行检查的意见, 被否了
4. 车票区段售卖
其实车票不是 12306 卖的, 实际卖票的是 18 个铁路局, 12306 只是一个售卖平台.
12306 只是拿到票然后根据用户提交的席位来分配这些票.

总体来说 12306 目前的复杂性都是因为技术债务导致的.
如果抛弃全部包袱, 重新开发需要 200 人的团队开发大概 3 年左右.