@picone #78
所以啊，1 天才对应 32M 内存呢。不同天的数据是可以分布式的，1 台机器只处理 1 天的订票工作不就可以减轻负担了吗？

按照前楼的说法，买了 A-D 的票不影响买 A-B 的票，内存还可以减少。20 个站，两两形成 200 个起点-终点对，每个起点-终点对维护一个剩余票数，2*200=400 字节就够了。

其实把这个问题简化，很多都是可以并发的，而且是完全的并发，不需要同步。
- 5000 个车次，分给 5000 台机器，每个机器处理 1 个车次的订票操作，互不干扰
- 20 天内的订票，分给 20 台机器，每个机器只处理某 1 天的订票
- 20 个站，两两之间形成 200 个起点-终点对，彼此之间的剩余票数也是独立的(按照前楼说法)，分给 200 台机器去各自处理。

按照每天发送 1000 万次旅客的高峰，5000*200 台机器并发，每台机器只需要响应 10 次订票请求就可以了。

我觉得#1 说的很对，难度被夸大了。

直到现在，12306 的余票数量还是像量子力学一样，一会儿显示有票一会儿又突然消失一会儿又出现那个数字，然后点进去买票，就显示出票失败。
所以，同步加锁并没有想象的那么严酷。

另外，铁路看起来那么多条挺吓人，但是各个线路是没有关系的啊，所以考虑难度的话，只考虑 1 条线路就好了，1 条还觉得很难吗？

内存方面#1 楼也论证了，几个 G 的内存就足够了，1 台机器不行的话，就多加几台，内存纠错，大带宽同步传输。挺快的。:doge

@picone #5
#1 楼说的是区间是不是有票，比如 A11 这个座位的值是 00111100 ，就表示 A11 座位从第 3 站到第 6 站这 4 站的票已经有人占用了。余票数量跟这个没关系。

graphviz
官网： https://graphviz.org/gallery/
可编辑示例： https://dreampuf.github.io/GraphvizOnline/

@byewind 感谢回复。虽然它的名字一直叫 Framer ，但是功能一直在变 🤷‍♂️，一开始是原型工具 Framer.js ，后来大改了一次思路变成了 Framer X ，现在看起来又转型了。