是多用 4 ＊ 21 亿字节。 前一条说得不完整

50 亿行记录，用 long ，也就 4 * 21 亿字节 ， 8G 硬盘。 内存不知道，多 8G ？

其实既然有人提出出了用 long ， 我觉得也不麻烦，是好事。

@firefox254 上周买的，应该还可以。 12 元还是很值。

我刚刚才看到。。。 汗，

求官方公告地址。 如果找不到这个消息来源，就别讨论了。

@FinalTheory 但是，网站响应很快，不用被千夫所指，几个人会懂什么缓存。。哈哈哈
要是网站直接打不开，那就一片骂来了

回车就出去了。。。。
有人跟我争论，说是分布式内存数据库，解决了海量查询问题。我就在网上搜到了这个，感觉是软文。。
有没有同学能给点意见？

@akira 以前方向错了。 12306 以前崩就蹦在余票查询上，当时可能觉得余票查询不能缓存。所以都直接到了数据库。现在余票查询用了 cdn ，就不崩了。点对点的余票数据记录条数固定并且可控。所以后来就缓存了余票结果。

@xJogger 意思是，出票需要读写数据库，这个时候是把每个出票当作单个任务，控制任务处理速度，就可以保证数据库不被拖垮。

最开始，设置回三指拖移， 最后 force touch 功能习惯了后，就又把三指拖移取消了，三指可以给其他功能用。。

@raysonx 总结的很到位。

说人话，就是流量由月结，变成了 2 个月结算一次。
如果非要用不清零来表述，那就是耍花招。
噱头

@pada007 的确。 搞得人离职了，好像就必须受了委屈样。真委屈了，就照价还回去。

@xi_lin 的确。
客户端总想通过一个接口拿到所有想要的数据。

例如客户端会觉得，注册的接口，同时要提供登录功能。（注册成功，返回登录 token 给客户端）。

没办法解释。

如果算作重复，那肯定只能当作 bug 来对待拉。我已经知道怎么解决这个问题了。谢谢各位。