我第一次听说海量事物高速处理系统这个提法，我曾听说过“Massively Parallel Transaction Systems”可以翻译成“大规模并发事务系统”。“海量事物高速处理系统”这个提法最重要的问题是“高速”，这个就错了，而且错得很大很大，我这个博客主要吐槽这一点。

    我相信很多人已经在某世界级订票网站上体验过了，据说平均买一张票要500次点击，我们买一个数码相机，如果淘宝商城说请稍后再试，憋一天再买，有什么不同，但火车票不一样，这个是有时效性的，哪怕迟个1分钟，票就买完鸟，这样就会造成访问雪崩性指数放大，这是可怕的。

    其实需求不是这样的，如果我告诉你，有一张票属于你了，让你放心了，等待交易的时间，你是可以接受的。或者如果告诉你，在网络上的队伍，你在第几名，你每次等待，都在往前走，你会耐心排队的。我们都知道这个系统很特别，但绝不是非得要“高速”，这是对车票这种特殊商品交易的误解。因为大部分对系统的伤害，都是在大家不知道情况，焦急万分，反复尝试，反复点击，反复刷新的结果。

    吐槽之后，说说我的观点。

    1）需要引入网络排队的概念。而不是现在一窝蜂各博各的人品。所有公平的排队系统都是先进先出的。但这种先进先出并不需要绝对公平，也就是没必要大家都排一个队（虽然一个队是绝对公平的），可以有多个队，每个队可以理解为一个进程，独立的占用资源，队列后的用户排队等待，不占用系统，每个队的队头并发访问系统，比如可以有1万个队，后来的人可以选择任意一个队去排，排队之前都确定了车票，简称一个deal。我们将这个deal放到队列中，可以刷新页面看进度，也可以当这个deal完成后，弹框通知。每个deal都有身份证来确保唯一性。

    2）前端系统需要能够档掉一部分访问，比如随时生成一个火车各线路车票余量图，这个图定时生成，缓存起来，每个购票这可以先进行了解，比如我要买1月20日的票，我可以从1月18日，19日的趋势，来做一个分析和判断，选择什么线路来做deal，定票的成功率大。

    3）后端系统需要支持高并发，有读有写的场合下，并发本不容易做，这里面方案也非常多，我也说不好，但主要是解决一致性的问题，这些两句话也讨论不出结果。如果政府需要，我相信会有很多这方面牛差的公司会拿出足够好的方案。

    最近一直在想这个系统该怎么做，但总也没有什么头绪，但我个人认为核心思想是可操作的公平性；能安抚群众情绪；减少无谓的读写请求；发挥系统的最大性能；一个好的系统要能做到这一点是真心不容易，今天就吐槽这么多。