双11 后台技术 & mapreduce过时否

比如用percolator做增量索引构建、比如用dremel做列状存储全量检索、比如用Spark做交互式、迭代式任务……

就像一群人在证券所盯着股票大盘一样，看着红红绿绿的各种数字曲线跳动波动然后跟着兴奋紧张。

我就是做这些大盘的
所以…… 过来刷刷知乎缓解下情绪 。

对我们这个岗位，双十一就像高考，而我每年都要复读， 每年题目还都比去年难很多 。


---------------------------------------------
过完高峰来修改下：

系统没挂！哈哈哈哈哈哈哈

----------------------------------------------
白天值班很轻松再来修改下：

本人一共历经5年双十一（是的，每一年我都参与了）。数据很敏感，代码无国界，不匿名说一些技术上的感受，无伤大雅。

妄自揣测回答一个题主可能关心的问题，相信这个问题能从侧面衬托出作为员工亲历双十一的感受—— 纯粹从技术角度，为什么需要这么多员工通宵达旦灯火通明的一起来支撑双十一 ？为什么不安排几个运维同学值班就够了？

第一个例子：

如果你是个程序员，你做了一个最简单的B2C网站，网站的主流功能必然是面向用户的订单、购物车等“前台业务”；同时也必然会有一个“后台”，给你的小二（运营人员）提供 运营管理功能（新增营销活动、编辑店铺信息、修改商品信息、查询历史订单 ）。然后有一天你们要办一个非常重要的促销活动，用户蜂拥而至，突然一个小二做了一个 非常复杂的历史订单查询（产生了一个嵌套好几层的SQL ），而不幸的是你的系统又 没做读写分离（读写操作在同一个DB） ，DB负载本来就飙升好几倍了，这一下直接干倒，多米诺效应拖垮了web前台，网页404——促销成了微博上茶余饭后的笑话。 

怎么避免这种事情？

第二个例子：

程序员应该都熟悉 淘宝的tair缓存技术（双十一能成功，它居功至伟，大量的商品信息都是缓存其中 ，细节不多介绍了）。

如果量少，怎么玩都可以。
但是如果量大呢？

假如你有100台机器可用于部署tair。然后你参与大促的商品一共有100W件。按照最简单的负载均衡思想，应该把100W件商品的信息，平摊到100台tair上，每台缓存1W件商品详情（我们假设一台tair是缓存不了100W件全部商品的，那就必然要有所分工，即使不是按商品的粒度，也可能会按其他更粗的粒度来分工）

现在你的 运营过来告诉你，根据市场行情的调查和营销力度的把控，今年大促秒杀iPhone5的PV可能会达到几百万 、iPhone4会达到....、电饭锅的PV应该是500，电吹风是200……同时今年又是iPhone5刚刚推出、正值风口浪尖。 

如果是我，我肯定拼了老命、赔了老本也要保住iPhone5的秒杀。至于电饭锅，让它自生自灭吧！
所以我可能会把 90台tair都用于iPhone等5W个重点热门商品，10台用于剩下的95W其他商 品。

（以上所有数字纯属YY）

第三个例子：
大家都吐槽12306的排队，那么问题来了——如果你的代码真的写的很好了，机器真的不够用怎么办？

只能排队啊。。。
「双十一」对于各银行的科技部都有怎样的考验？历年都有哪些趣事发生？  这里可以看看银行的同学们是多么的头疼。

银行啊！大型机啊！都搞不定啊！

所以如何优雅的“降级”，是阿里这几年技术成长的一个重点。想做优雅的排队？对不起，首先你要异步化，否则就只能暴力的把用户拦在外面；想异步化？对不起，你是支付宝，你是金融系统，在异步链路下依然要保证强一致性（告诉用户购买成功、钱却等了1分钟才扣这种现象要尽全力避免——经  @曾祥能  同学的提醒已修改）。
就算做到这些了，还要一个把 并发编程思想发挥到极致的queue中间件 ，不仅能有条不紊的削峰填谷、蓄洪限流，还要能随时接收参数调整， 实时动态并发的改变阀门阈值 （什么概念？一点点的差错、1ms的差错，就会导致海量的订单没有按预期流动）

即使这些都已经做的很努力了~还是要不停的改进！能不降级就不降啊、能不限流就别限啊——看评论里同学们的吐槽就知道了，技术上还是有很多不足的。

先就说这三个例子。 虽然没有正面回答题主的问题，但是已经很明显的看到，现在的“监控”，已经 不仅仅是cpu、load、磁盘、端口、网络这些运维同学的事情了。不仅要做到T+0的实时BI、实况转播、ROOT-CAUSE，还要做到对所有决策的实时反馈、准备应急降级预案、事先规划资源分配 ……

试想第一个例子，大促开场 高峰期要关闭部分后台的复杂查询功能 （甚至是“前台”的次要业务）， 小二和客服的某些服务就会暂停 ，用户投诉就会上升，就要启动事先准备好的缓和对策， 等到压力稳定，要立刻恢复被降级的服务，小二和客服立刻得到通知尽快去解决拖延已久的问题、安抚生气的用户 。

补充：（关于降级）我们老家有句话叫“有多少米做多大粑”。客人来的多了，食材不够，这就是现状，是前提，改变不了。在这种情况下还能准备好一顿开心的晚餐，把客人的总体损失降到最低，也是个技术活儿。就连纳斯达克在大公司上市之前也要执行“预演”，避免不必要的交易行为把证券系统搞挂，这也是一种降级。

补充：（提到了银行就再补充一个喜闻乐见的例子）小银行顶不住了怎么办？收银台引导啊、让用户用扛得住的银行卡啊！ 银行都挺不住怎么办？充值送红包啊，让用户多用支付宝余额啊！银行的量还降下不来怎么办？多送点红包啊！300不行送500啊！运营找财务拨钱来发红包啊！决策小组亲自审批啊！ 营销规则要立刻发布更新啊！这一切要在几分钟内完成啊！就酱紫……

想要把整个双十一玩转，需要PD、运营、中间件、业务系统、决策小组、客服等N多个部门一起合作。因为在这么大的数据量面前，技术上纠结的程度已经具体到电饭锅了。

所以亲历双十一是什么感觉？
就是你看到作战室（超大会议室）里十几个大屏幕上翻滚的各种业务指标、系统数据，各种红红绿绿的报表曲线提醒着每一秒钟的业务健康情况、决策执行情况、降级损害程度……
然后决策小组的一帮最高指挥官通过这些数据做出各种决策，有些闲庭信步、有些壮士断腕。
运维人员和系统owner以最高效的方式执行决策并跟踪反馈决策效果。
DBA、中间件的同学盯着自己的DB、系统在强大的压力下随时准备申请执行预案 （还能撑一点！加油啊儿子！我靠不行扛不住了、首架我要执行Plan B！……）
运营和客服的同学更不用说了，已经忙翻天了，她们可是要根据决策小组的决策不停变换工作策略 ！


至于我？ 那些屏幕上的数字还在动，是准的，够用，我才能安心的过来写知乎啊~

————————————————————————
看了评论里的吐槽都指向收藏夹啊？
暂时得到的反馈是收藏夹大促未做降级，肯定还是量太大没有稳住
可惜的是这一块的业务监控做的很弱（之前都重点覆盖购物车等业务了……），目前没有什么有用的指标，大促之后我得到原因再过来反馈。

——————————————————————————
另外很多热爱coding的同学都在寻求技术答案， 我知识面有限，难以全部回答准确， qcon上支付宝架构师胡喜的支付宝弹性计算架构应该能够帮助同行们了解一下支付宝技术上的努力，淘宝的就更多了，很多早就开源的优秀解决方案。技术问题我就不一一解答了 ，可以私信留言，我去帮你翻翻资料尽量回复。

————————————————————————————
评论好多…… 我知道有很多朋友觉得阿里这种“人为创造春运”的行为不好，明明可以把交易分摊到更久的时间段里慢慢买的，为何要人为的创造这样一个“节日”来折腾员工、折腾用户、折腾快递小哥。 这个问题好大，我只是一个码农我只能回答一个码农的观点：
大家觉得春运不好， 本质还是运力不足、经济发展不平衡，这些才是痛点的源头啊 。可是互联网、电子商务、IT技术，这些可以不痛啊。我听过这样一句话：

在很多科技领域，我们赶超欧美日本等发达国家还有很长的路要走，人家比我们提早了几百年。 但是计算机，我们的起步只落后几十年，尤其是软件，落后的更短，而且软件的资源成本、硬成本较低，它的关键是人才 。

支付宝从最初的一个小工具，到赶超VISA、支付能力甩它几条街，我们并没有消耗浪费很多的社会资源，我们一年又一年的性能优化项目反而是在降低资源消耗。 这个“人造节日”，锻炼出了一批又一批的高素质软件人才，无论他们去向哪里，都会成为编程好手、架构栋梁，促进整个IT业的发展，改变我们依赖洋大人、天天学SSH、天天捧着Google的论文尊为圣经的现状 。

起码对程序猿，这是好事儿，不是吗

从银行清算的角度来说，双十一是最不招人喜欢的庆祝光棍节的方式。

触类旁通的举例，春运之前的抢票 + 春节期间的公共交通，以及长假期间的各大名胜景点，比如京郊最近的红叶疯了。

通过支付宝购物分成两个阶段，一是同银行内部划转，二是跨行头寸清算。阿里巴巴在各家银行会开立支付宝专用帐户，首先所有的同银行买方卖方的交易总量汇总到一起，进出这个帐户（收付款双方均在同一家银行，比如说工商银行，开有银行帐户）。然后会在阿里巴巴公司的名义下，进行同企业跨行轧差清算，完成收付款相关方跨行开户的问题。

其中同银行内部清算部分，考虑到双十一的交易量，对于任何一家银行来说哪怕是国有四大行都是让人头痛不已的事情。以2013年双十一交易量为参考，2013年双十一成交额350.19亿元，支付宝成功支付1.88亿笔。考虑到收款操作都是在收货后完成，所以只需计算这1.88亿笔的交易。双十一开始后8小时42分钟，成交121亿，粗略的等比计算一下大约等于从凌晨零点到早上八点期间发生了6496万笔在线交易，即为每分钟13.53万笔交易。手头没有国有银行日常的交易量数据，不过可以肯定的一点就是这种每分钟10万以上的交易量毫无疑问是让现有银行系统吃不消的（据阿里巴巴“无线支付达到 4518 万笔，最高每分钟支付 79 万笔” -____-!!）。从双十一开始成气候以来，每年11月11号上班银行同行之间最感兴趣的就是今天早上哪家最先崩溃，who的系统死扛到了最后。不负责任的据说，2013年的光棍节，只有宇宙第一大行的系统笑到了最后全须全尾的功成身退。

然后问题就来了，银行要不要扩充系统去为这种一年一次的，发生概率为0.27%(1/365)的事情掏腰包搞升级？同样的问题就是，铁道部有没有必要扩充系统到轻松应付春运的水平？各大景区要不要跑马圈地到足够装下黄金周的所有游客？然后，在一年的绝大多数时间让扩充之后的资源闲置落灰折旧玩？我个人当然更希望上述各路神仙们可以把银子花在更好的客户体验方面(ONLY IF THEY CAN...)。

曾经有人提出要通过云计算解决这种峰值数据处理的问题，不过，银行铁路这种涉及国计民生的机构又有谁敢把性命攸关的数据资料交给别人呢……

翻一翻这几年google research的论文，基本上摘要里都要写上一句“经过xxx我们在xxx领域相对Map/Reduce 实现了xxx倍的性能提升” ~

个人理解是世界上没有万能的银弹，Map/Reduce只是一种编程模型，hadoop只是某个领域（比如离线批处理）不错的工具。而在很多其他的领域，都可以通过深度定制实现更好的性能，比如用percolator做增量索引构建、比如用dremel做列状存储全量检索、比如用Spark做交互式、迭代式任务……

http://www.zhihu.com/question/24280664/answer/27287313

术业有专攻，全面发展会导致全面平庸~ 
所以我感觉大牛们都是在找一个平衡——

不能太万能、太通用，会导致众口难调、达不到极致
不能太定制、太专用，会导致重复返工、难灵活扩展

最后附一个以前翻译的percolator论文
Percolator:Large-scale Incremental Processing Using Distributed Transactions and Notifications
文章末尾的批注也许可以参考一下

昨天我边盯着一个 MapReduce job 边听 Google I/O, 听到 Urs 说我们都不用 MapReduce 了好桑心，虽然 Google 内部系统通常只有 deprecated 和 experimental 两种状态，但真不带拿 MapReduce 这么玩儿的不是。

官方 blog[1] 有个简单解释，相关论文其实早就出来了。

Today at Google I/O, we are demonstrating Google Cloud Dataflow for the first time. Cloud Dataflow is a fully managed service for creating data pipelines that ingest, transform and analyze data in both batch and streaming modes. Cloud Dataflow is a successor to MapReduce, and is based on our internal technologies like Flume andMillWheel.

我感觉题主链接的新闻重点抓错了，MapReduce 这套分布式计算框架实现的 主要局限在于 1. 用 MapReduce 写复杂的分析 pipeline 太麻烦；2. 它怎么改进都还是一个基于 batch mode 的框架。

MapReduce 的计算模型特别简单，只要分析任务稍微复杂一点，你就会发现一趟 MapReduce 是没法把事情做完了，你就得 设计多个互相依赖的 MapReduce 任务 ，这就是所谓 pipeline.在数据流复杂的分析任务中，设计好的 pipeline 达到最高运行效率很困难，至于给 pipeline 调错就真是让人想死。这时就需要用到 Flume[2] 了 —— 演示中的代码其实就是运用 Flume 框架的 Java 代码。Flume 提供了一个抽象层次更高的 API ，然后一个 planner 把 Flume 程序转换成若干个 MapReduce 任务去跑。Google 还有很多这种基于 MapReduce 的封装， 有一个叫 Tenzing[3] 的项目，是把复杂的 SQL 查询转换（编译）成 MapReduce , 还有 Sawzall[4] 这样的直接基于 MapReduce 模型的专用语言。所以没错，裸奔 MapReduce API 的时候确实少了，但数据中心里每天仍有无数的 MapReduce job 甚至在工程师自己都不知道的情况下，默默地低调地跑着 —— 当然这个 MapReduce 经过多年改进，估计 2003 年出论文时的代码现在已经一行不剩了。如果哪天所有人都不裸奔 MapReduce API 了（总有我这样的顽固分子），Urs 要偷偷把 MapReduce 换成什么别的我们可能还真都不知道。

另外插播一句 Flume 的思路没有多独特，它的编程模型跟微软的 LINQ 很相象，DryadLINQ[5] 的计划算法也跟 Flume 异曲同工。它们所依赖的理论基础可就老了去了。

MillWheel[6] 则是解决流计算的问题了。

我觉得必须在概念上把 MapReduce 计算模型，和 Google 内部基于这套计算模型做出的分布式计算框架实现分开。 MapReduce 这个计算模型其实很古老，是函数式程序设计里的一个基本思路，它的名字就源于 LISP 类函数式语言里的 map 和 reduce 操作。Google MapReduce 论文的主要贡献是在于它让这个非常常用的计算模型跑在了一大堆会随时崩溃的 PC 上，而不在计算模型本身。

把 MapReduce 看成基本的函数式编程模型而不是具体实现，理解 Flume 和 MillWheel 会简单很多， Flume 做的工作其实就是一个编译器，把一个复杂的分析程序编译成一堆基本的 MapReduce 执行单元 。至于 MillWheel 的所谓流计算 则跟函数式编程里的懒惰求值大有渊源，比如计算

(map (fn [x] (* x 2)) (map (fn [x] (+ x 1)) data-list))

最笨的做法就是先把 data-list 每项加 1，输出一个列表作为每项乘 2 的 map 任务的输入，然后再输出另一个列表，这就是传统 MapReduce 实现干的事情。Clojure 利用 LazySeq 实现了对 map 的懒惰求值，可以做到「要一个算一个」：当要取上述结果的第一项时，它才去取 data-list 中的第一项，作加 1 和乘 2 操作然后输出，如此类推，就不是做完一个 map 再做另一个 map 了。MillWheel 做的则是方向正好反过来的「来一个算一个」，data-list 里来一个输入就输出一个结果，每一步都不需要等上一步全部完成（数据流往往是无限的，没有「全部完成」的概念）。例如计算：

(reduce + 0 (map (fn [x] (* x 2)) data-stream))

（注意这不是一个典型的 MapReduce，虽然里面有 map 和 reduce） 在 MillWheel 里，就可以随着 data-stream 数据的涌入，实时显示当前的数据总和，而不是到 data-stream 结束时才输出一个结果，而且这样 x * 2 的中间结果也压根用不着存储下来 。

可以看到，具体怎么实现上述运算，是个具体实现的底层优化的问题，在概念上计算模型还是基本的 map 和 reduce，就好比同一条 SQL 查询语句可用于不同的执行引擎 —— 在 I/O 上工程师也演示了一段分析代码是怎么可以不加修改同时适应 batch 模式和流模式的。作为常用计算模型的 MapReduce 并没有什么被淘汰的可能。

再补充一句，MapReduce 当然不是唯一可用的计算模型， MillWheel 可以很方便的实现其他计算模型，Google 还有基于图的计算框架 Pregel [7] 等。另外其实自从 有了 Dremel[8], 很多分析任务都可以直接用交互式查询来完成，写分析 pipeline 的时候也少了很多 。

当然，也说不定google又整出来一个耳目一新的技术，然后又再次养活了大批的程序员～～想当年， 谷歌的三篇论文给我们提供了多少工作机会呀 ～～
1.  http:// googlecloudplatform.blogspot.com /2014/06/reimagining-developer-productivity-and-data-analytics-in-the-cloud-news-from-google-io.html
2.  http:// pages.cs.wisc.edu/~akel la/CS838/F12/838-CloudPapers/FlumeJava.pdf
3.  Tenzing A SQL Implementation On The MapReduce Framework
4.  Google Research Publication: Sawzall
5.  DryadLINQ - Microsoft Research
6.  MillWheel: Fault-Tolerant Stream Processing at Internet Scale
7.  http:// googleresearch.blogspot.com /2009/06/large-scale-graph-computing-at-google.html
8.  Dremel: Interactive Analysis of Web-Scale Datasets