> “正如 Snow Dashboard UI Kit, 它就是为了让中小微企业更快地搭建更为先进的中后台产品.”
对楼主的东西比较感兴趣，想进一步了解一下，但“中后台产品”这个名词，把我吓着了😂，具体是做什么的呢？看示意图也没有看明白。

大家都是划水高手，你怎么捍卫护城河？

@0o0o0o0 #129
改签是先买后退，不涉及同步。因为票总是能退的：买不到就改签失败，无需退票；买到了就改签成功，总能退掉原票；
买多张票也是一个道理。

@0o0o0o0 #107
你说的这些里面，都不会影响各车次、各区间、各时间的并发独立性啊。我这里说的并发独立性，是指数据的写入。

比如“铁路一个人买两张票时间不能有重合”，这个只要查询一下这个人已经买的和将要买的票的信息就可以了，只涉及读取数据。

@watzds #115
预设的票数更合理吧，
一是因为预设票数有背后统计数据的支撑；
二是实时计算有明显的问题：因为订单是按时间先后提交的，如果短途先提交订单，那么长途就都给占用了。分配车票肯定不能这么明显的受订单次序的影响，如果要给长途票预留一定的数量，那不又回到统计长短途比例的思路了嘛。

@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 ，现在看起来又转型了。