能不拍就不拍
后期真的一眼都不会看的

实在想拍的话
去个景色好的城市, 在当地找个小工作室拍拍照就够了.
还能玩一玩

@paopjian #4 已经通勤半年多了 还可以
早上 6.30 起 车上可以眯大概 30 分钟

牛马三件套 套上 2 个了
在北京再租房 没太大意义 放着自己家不住 去外边组个啥啥都不喜欢的小房间 我宁可选择通勤

我和你差不多, 不过我是在中关村上班.
现在天天京津通勤上班(家在天津南站附近)
早上在南站 7.11 的车, 8.50 能到公司.

我之前是在角门西住, 离的很近, 附近基本生活都能满足, 4+10 双地铁很方便, 离南站就 2 站, 而且也能直达西直门.

![https://i.imgur.com/O5uS6qm.jpeg]

电脑 普瑞声纳 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 年左右.

@Jinnyu #90 房租是核算下来的单月价格

@Danswerme #5
base 帝都 国企数字化部 955
日常消费 月账单 3500-4500 (包含日常购物和吃喝)
房租 单间季付 2500-3000 (看个人选择)
其他 按 1000 算

每个月大概还能攒个 15K 左右

@ojbkojbk #63 参数对齐 个人喜好