V2EX 年度金句评选

• 資深大佬 : littleylv

  多了去了。坐等下发言

• 資深大佬 : Lin0936

  富有科技

• 資深大佬 : killeder

  干人事的不干人事

• 資深大佬 : lbyo

  @Lin0936 #2 神了，到最后公布名字了吗

• 資深大佬 : tonytonychopper

  要么狠，要么忍，要么滚（出处不详

• 資深大佬 : killeder

  中惨阶级

• 資深大佬 : kiwier

  2019 年可能会是过去十年里最差的一年，也可能是未来十年里最好的一年

• 資深大佬 : 11ssss

  遇事不决，量子力学

• 資深大佬 : w292614191

  我知道主图片的发言人。哈哈哈哈

• 資深大佬 : 11ssss

  总看到中年危机，没想到到自己了（几乎日更）

• 資深大佬 : aabbcc112233

  迫于？

• 資深大佬 : koala9527

  不做程序员了做什么养活自己

• 資深大佬 : Zeonjl

  请关注最后时刻出现的

• 資深大佬 : Lin0936

  @lbyo #4 我反正是没看到结局

• 資深大佬 : HongJay

  看到别人裁员，没想到自己也被裁了

• 資深大佬 : Cielsky

  我好像都看过

• 資深大佬 : rizon

  话说 12306 的票，并发上我觉得问题确实不大啊，整体很多，但是具体到一个车次人数就没那么恐怖了吧？
  再者，12306 的票都是分批次的定期放票，因此我们可以假设他们的票是固定分区间销售的，每天晚上维护的时候再重新根据销售情况去重新分配各个区间票，和同步各个服务器的数据，少了动态分配的问题，就再次降低了并发的各种疑难杂症。。。

  换言之，12306 我觉得是从营销策略上来解决了分布式和并发的问题，是大家把 12306 想的太高级了，越是这种系统反而用最简单粗暴的方式去解决问题 。。

  系统的难点肯定是有的，但不至于问鼎巅峰吧。。。。

  难道是我想简单了？？？？

• 資深大佬 : lshero

  那个男人

• 資深大佬 : zro

  没有，没有，没有，通过~

• 資深大佬 : vZexc0m

  @rizon #17 您就是图上那位？

• 資深大佬 : KyonLi

  二本思维

• 資深大佬 : xmge

  富有幼儿园

• 資深大佬 : rizon

  @vZexc0m #20 并不是我，我看了原帖了，也是有很多人同意并发量并不高的， 至于图中所说的”也就是个小电商的水平”，我觉得这是原层主个人情感上的一时口舌之快而已，我一般都直接忽略了这种感性发言，只讨论技术

• 資深大佬 : tsui

  12306 抢票，和以前的无数代售点准点刷黄牛票有多大区别？反正票就那么多，仓空了结束。

• 資深大佬 : chuhemiao

  六字箴言？

• 資深大佬 : helionzzz

  @rizon 关于 12306，因为除了行内人没人能了解具体的票务流程，现在的猜测只能是猜测。但是，一个劝退了 IBM、阿里的系统（当然也曾经有不少程序员不服气想试试然后就没有然后了）如果真的可以被本站一些大佬这么轻视，那么要么我们可以说是 IBM 或者阿里的技术太水，要么就是本站一些大佬过于乐观。要是你，你选哪个。

• 資深大佬 : sugars

  “如何劝动老婆不要买 iPhone ？”
  “一样是乌烟瘴气的论坛。”

• 資深大佬 : manami

  APIJSON 3.2.0 发布，4K Star 与 Hibernate 拉开差距

• 資深大佬 : toeii

  出身 985，工作 996，离职 251，维权 404

• 資深大佬 : manami

  @manami 看了下这句是 2018 年末的……

• 資深大佬 : wwti9

  「这是毅种循环，租房找鸡是中国青年未来的出路。」

• 資深大佬 : rizon

  @helionzzz #26 你说的对，技术上我们外行人也只是讨论个可能性的东西，这种系统也不只是技术问题，还有很多现实问题等别的各种问题纠缠在里面，难度一定是有的，值得称赞的地方也一定是有的。不过技术上到底有没有带来巨大的革新或突破，也是不清楚的，作为外行人也只能从表象来猜测了。反正大家也就这么猜猜聊聊了，下不了定论就是了。

• 資深大佬 : Leonard

  今日热榜

• 資深大佬 : bunnyblueair

  华为基本法

• 資深大佬 : centipede

  那个富有科技的着实惊到我了，v 友提了好多页的建议，结果到最后主一句轻飘飘朋友起的最合适就打发了。。。

• 資深大佬 : daozhihun

  @rizon 你说的有道理，从表面上看，这种系统确实很容易做成分布式。
  但是问题是铁路经过几十年的发展，业务相当复杂（比如各种不为乘客知的区间限售、解禁等业务），涉及到账务的肯定更复杂，只是不由我们开发，不了解而已。
  另外还有一点是 12306 的查询量非常大（我觉得大部分是爬虫），要把这些流量扛下来也不容易。
  我觉得吧，不了解业务的人有这个疑问是很正常的事，上那些说 12306 难做的貌似也没说出个所以然来，也只有业内人士现身说法才能知道难点在哪吧。

• 資深大佬 : Dosenf

  @Lin0936
  @centipede
  富有科技是个什么梗

• 資深大佬 : Vegetable

  打码没啥用,搜索引擎搜一下全找到了,还是别挂别人了吧,太不友好了…

• 資深大佬 : centipede

  @Dosenf “需要为一个富有科技感的公司起名，采纳者有红包”的一个帖子，结合结果来看像极了白嫖。

• 資深大佬 : herozzm

  正规军来了，首先是剿匪—论区块链国家队

• 資深大佬 : hirasawayui

  顺风车撩妹，不想生孩子因怕长得像老婆太丑了嫁不出去。

• 資深大佬 : catinsides

  如果 v2 能列出“我感谢过的回复”找起来还方便一些

• 資深大佬 : wxl1380610

  经常拿 12306 的排队 ， 做例子 ， 典型的把技术上的难题，从改需求来解决 , 自从开始排队以后 ， 就不死了

• 資深大佬 : heaunter

  @tonytonychopper 这不是华为三字真言么？

• 資深大佬 : fkue587

  @daozhihun 我一不是干 IT 和程序员得外行都感觉 12306 花那么多钱就是扯淡,早几年那崩溃得页面交给阿里不好吗??每年双 11 淘宝被全国人民 DDOS 也扛住了….

• 資深大佬 : codespots

  @helionzzz 我寻思这玩意劝退 IBM 可以理解。毕竟做出了苏宁那么烂的网站，但你要说劝退阿里，我还真就不信了

• 資深大佬 : rizon

  @daozhihun #36 是这样，技术上有难点，非技术上的问题也肯定盘综错节的。非内行人，也就是猜猜聊聊而已，是下不了定论的

• 資深大佬 : hzgit

  “你哪怕吃一口菜也不至于喝成这样”
  “别光喝酒，吃点头孢”
• 資深大佬 : windyCity

  @fkue587 淘宝没抗住，春晚的流量，服务器出问题了

  就在那天晚上，微信服务器也出问题了

  爆发的大流量，哪有那么简单解决的

• 資深大佬 : hzgit

  “有糖尿病的往后稍稍，不能让 LZ 尝到一点甜头”
  “我尿黄，让我来”

• 資深大佬 : lance6716

  @Vegetable 人要为自己的发言负责。要不为什么 v 站不能删评论？

• 資深大佬 : S4msara

  《为什么说我抛弃了 “单词开头大写” 式的命名规则，转向了 “单词下划线分割命名”》
  每使用一次这种命名规则就要为此付出多按两次[caps lock]按键的代价。
  但以 “单词下划线分割命名” 方式写就要方便的多,你只需同时按下[shift]+[-],既减少了键盘使用寿命，又充分的锻炼了左右手的协调能力。太棒了!

• 資深大佬 : helionzzz

  @codespots 老新闻都有。当初好像是铁道部召集国内外大企业商讨方案，钱管够。但是没一家愿意接下来的。12306 没办法只能自己想办法搞，然后阿里提出了部分解决方案加入帮忙一起搞。

• 資深大佬 : helionzzz

  @fkue587 铁道部一开始也想外包啊，没企业接的下来啊。。只不过后来阿里抗了几次双 11 有经验了加入进来一起搞了。

• 資深大佬 : aguesuka

  教科书般的掩耳盗铃

• 資深大佬 : codergrowing

  ……你们的回复每一条我都看过原贴，原来今年我摸了这么多鱼

• 資深大佬 : winglight2016

  @S4msara #50 这一

• 資深大佬 : sarices

  程序员不是人系列，例如下图
  https://sm.ms/image/Xh6WtBmZJgCbcDL

• 資深大佬 : iamwho

  V2 金句：
  打字慢但是代码靠脑子，你们打字快的都没脑子。

• 資深大佬 : mejee

  你那是馋人家身子

• 資深大佬 : HunterPan

  没有真正的朋友 都是利益

• 資深大佬 : oneisall8955

  @mejee 虎扑步行街的吧

• 資深大佬 : Raynard

  富有科技感有限公司

  哈哈哈哈

• 資深大佬 : daozhihun

  @fkue587 说真的，12306 难做我是认同的。
  你说的之前砸钱没做好，这个也确实是事实，就刚做出来的那几版还真不值砸下去的几个亿，后来才逐渐完善了。至于其中的缘由，大家心里清楚就好。

• 資深大佬 : daozhihun

  @rizon 是的，我想说有质疑是正常现象，毕竟大家都不了解业务。只是不太懂那些不了解业务的急于去洗地的人是怎么想的，大家都分享自己的思路不行吗？

• 資深大佬 : kimwang

  迫于～～

• 資深大佬 : CoderGeek

  出身 985，工作 996，离职 251，维权 404

• 資深大佬 : liuzhaowei55

  @killeder 不要 at 下作者吗，哈哈 just for fun

• 資深大佬 : uxff

  前公司有个女同事怼领导：

  公司工资就给我开这么多，我怎么可能能干那么多活呢。
  工资限制了我不能干这么多活呀。
  你这些活应该分给那些工资高的人呀。

  绝对真实。

• 資深大佬 : Yorkzhu

  好玩饺子店

• 資深大佬 : nathanw

  搞 AI 的面临失业的问题，要比 AI 带来失业的问题更严重。

• 資深大佬 : Messiv2

  @Lin0936 不懂，求解释。

• 資深大佬 : simuhunluo

  你说的这个朋友？

• 資深大佬 : CivAx

  这种规模的爆发 TCP 要能敲个回车就解决，那还要 DDoS CC 清洗公司干什么

• 資深大佬 : hiya5

  别看你今天闹得欢，小心今后拉清单！

• 資深大佬 : zhjie

  垂死病中惊坐起，谈笑风生又一年。

• 資深大佬 : realpg

  @rizon #17
  连 TRS 是啥都不知道的 就不要评论 12306 了……

  如果 9102 年让你带头 带一个 400 人左右团队 1.5 年左右周期，从 0 开始做一整套铁路客票系统（卖票只是其中最小的一环 连带的财务才是大头） 连带全套的安全系统 各种评定 那之后扩展网络订票可能就像你想象的一样容易。

• 資深大佬 : realpg

  @daozhihun #64
  其实懂铁路售票系统的话，是十分反直觉的，12306 的系统最好的时候就是完全抢不到票 工具比啥人都好使的 2010 年~2011 年 包含了 2010 春运和 2011 春运两个大高峰

  至于其中的道道 不说也罢
  之后的各种看起来越来越好的修改，都是为了维持表面的不崩溃而严重劣化订票流程和后台交互……

  12306 不能孤立的去看 其实 2013 年我就想写一个长片讲讲 12306 和 TRS 的那些故事，总是懒……

• 資深大佬 : wangchonglie

  @CoderGeek #67 横批 1024

• 資深大佬 : NeinChn

  @realpg +1，感觉以前的 12306 还是个正正经经的系统
  数据有一致性，告诉你没票就是没票，告诉你有票，点得快可能买得到可能买不到
  现在的 12306 看着有票，购买告知无票，刷新还是有票状态，连基本的数据一致性都不要了，还有乱七八糟的排队，中等候选。。。。

• 資深大佬 : JerryCha

  @rizon 不用假设了，票额的确是预先分配好的而不是实时计算产生复用。铁路开始这么干的时候压根就没有什么 12306。
  另一个不太明确的事实是：真正的票务服务器到底是分割在各路局各自管理还是放在北京由总公司统一管理。

• 資深大佬 : bigbigsman

  求骂醒

• 資深大佬 : limingjie138

  12306 不是线性问题吗，假设车次只有一个座儿，那这个票会被分成首尾不确定的区间，我可能是菜，还没想到哪个数据结构能解决存储和计算（比如一条线随机划出一段，剩下的划线方法不能跨过被划走的这一段）一个座儿如此，一趟车次多少座儿，高 DDOS 会导致运算余票的时间不够用，所以大问题应该不在并发，是并发踩在难解决的计算余票上了。没计算完余票只能先把你拦截了，不然超卖怎么办，这不像电商把库存拉出来扔缓存就行了；这玩意库存可能是（假设全为满区间票） 1 千，也有可能是（全小区间票） 1 万。相比 12306 电商才算是简单粗暴的解决方案吧。

• 資深大佬 : exip

  推荐金句：“开 ssh，让我上去看看。”
  推荐理由：
  在 V 站上，只要有人问到 linux 服务器相关的问题，几乎都能看到这句简单、朴实、真诚又富有调侃意味的回答。
  这位老哥因为这句话，账号被降权、封禁，后来经被他帮助过的 V 友作证，账号才恢复正常。
  时到今日这位老哥依然言能践行，故推荐此句!

• 資深大佬 : exip

  @exip 时到今日—> 时至今日

• 資深大佬 : realpg

  @JerryCha
  近似理解 基本票额数据在局网数据库
  上路网票额和复用自动上路网票额推到全路统一数据库

  由于现在 12306 比普通窗口预售期长 2 天 所以高峰优化前 2 天可以把票额数据缓冲一下

• 資深大佬 : shenyuanlaolarou

  @killeder 不干人事的干人事

• 資深大佬 : liyang5945

  我会关注轮子哥，跟着他逛知乎；我会在步行街潜水，看看老阿姨们的腿；我会在 nga 刷刷马桶，看看每周五的傻吊图、顺带提提肛；我会在 V2EX 右上角的进度条变绿的时候想起来不能再摸鱼了；我会在干完当天的活，打开 github 看看通知里的 issue，去对各大 repo 批判一番，尝试与大牛们谈笑风生；我会在每天八点十分的时候收到 medium 的推送，有心情了就去看看圈内的车轱辘文章，假装自己精通 c++；我会在深夜打开 p 站，稍微骗一骗自己孤独的小兄弟…

  来源： https://www.v2ex.com/t/619061

• 資深大佬 : hyy1995

  V 站金句可太多了，这里都是大神。。。

• 資深大佬 : fewok

  12306，如果设计成 动态路段 实时计算可购票量，确实非常难扛住几百万 QPS。
  但现在明显是，准实时更新固定路段分配固定票数的票量变化，这样就跟商品秒杀模式一样了，而且比淘宝秒杀简单多了（毕竟同一个路段的火车数和座位类型数，可比同一件商品的卖家数和购买选项数少太多了）。
  举个例子，2020 年 1 月 24 日，北京到上海，途径南京的高铁。商品模式可设置为：
  产品：北京到上海。库存：一千张商务舱、一千张一等坐、一千张二等坐
  产品：北京到南京。库存：三百张商务舱、三百张一等坐、三百张二等坐
  产品：南京到上海。库存：一百张商务舱、一百张一等坐、一百张二等坐

  其实大家买票的时候，就没有注意到，多买几站地就有票，甚至非常充足。