同志，

stupid 发表于 2015-3-13 11:27
- ]6 c. M" o3 ?' X! m! g0 Z你猜！
. i3 b) ^# N# B% c2 |5 ^
+ k  P, f; _4 s4 Z  K" r  S8 q这是一个可以亮瞎无数人双眼的PAM4眼图。

或者你这是低波特率？？??

buzheng821 发表于 2015-3-8 00:45
最后那PAM4信号时哪台机器产生的？

你猜！
' \6 T, z8 |! C
这是一个可以亮瞎无数人双眼的PAM4眼图。
% v% q. E+ n2 E% e: A# d( y

最后那PAM4信号时哪台机器产生的？

最后那PAM4信号时哪天机器产生的？

摇红包砸了不少电视

8 E7 h6 R& u  T: Z' A: j) W

编者按：

     微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还是相当地有学习的价值 ，优才网作为培养全栈工程师和未来架师的团队，转载并加以注释，分享给大家。

400倍的挑战
9 F# D, |5 R0 ^4 D

今年微信红包方式与去年用户与用户之间互发红包相比，摇红包的方式对业务量来说是一个极大的爆发，光是除夕10：30送出的一波红包就达到了1.2亿个，已经是2014年除夕夜峰值的400倍之巨（2014年峰值每分钟被拆开红包数量仅2.5W个）！

进入抢红包环节，后台数据瞬间飙升

: Y) H) ?) @% x2 }+ j/ D0 h$ x

发10亿红包，难在哪里？

微信团队总结下来有三大难点：

' C, d/ l* M: m( W* ?/ I

快——如何保证用户快速摇到红包？

准——如何保证摇到的红包能成功拆开？

稳——如何保证拆开的红包能分享出去？

# ]7 ?% l& Q' e5 ]& {, E  ]. P

大量用户在同一时间摇红包，瞬间产生每秒千万级的请求，这个量级的请求如果不加以疏导处理直接到达后台，必定会导致后端服务过载甚至崩溃。上文中除夕当天后台监控数据曲线便能说明一切——在前台重重的分流减压下，后台服务器负载仍然瞬间飙升十倍以上。

; s/ ~/ i% |2 y5 |, D5 Z
3 {: S3 g& w, B' a+ |) X& G2 O

三大应对策略齐上阵

对于以上三个难点，微信后台开发团队主要通过三大应对策略应对：有损服务，柔性可用，大系统小做

• 有损服务-追求高可用和快速响应。
  
  

什么是有损服务？有损服务是通过精心拆分产品流程，选择性牺牲一部分数据一致性和完整性从而保证核心功能绝大多数运行。这是腾讯在PC时代积累下来的一种特色运营策略——在资源一定的前提下，互联网条件千变万化的场景中，量力而为，满足用户的核心需求。

- j/ m8 t9 V0 `: R9 ^$ e+ ]

微信红包的核心点是摇，拆，分享红包，整个系统设计时必须尽最大可能保证这三个步骤一气呵成，任何关联系统出现异常的时候马上进行系统降级，防止引起系统雪崩。

系统降级可以分为两个方面，一是把核心功能进行分拆和简化，通过辅助轻量化的服务实现，确保最短关键路径的可行，比方说在接入层置入摇红包逻辑，将每秒千万级请求转化为每秒万级的红包请求，再传到红包服务的后端逻辑，降低雪崩的可能性。

% G" I1 w9 w6 S) `4 b

点评：有损服务就是让重要的事情先做，重要的人物先行。这在现实中也很常见，军人买票优先，领导视察封路，让领导车先行，我等小民等待也是这个路子。

同时后端采用异步分拆，接收到用户请求时仅进行合法性验证，验证完成后直接告知成功，后续业务逻辑进入异步队列进行处理，减少了用户的等待时间，也极大降低了峰值雪崩的概率。

' Q9 ]( M- _# x8 y* u耗时最长的入账操作，直接跳过，异步处理

, Z: P: R. u8 S+ G; l; K# Y5 }

另外一方面是采取过载保护措施：

微信红包的过载保护在客户端已提前预埋了策略，在连接失败或超时情况下会有相应提示，减少用户重复请求次数。接入层面也会进行自我保护，针对频繁发出请求的客户端限制响应速度，并对系统负载划分出若干等级，达到不同阈值时引导客户端使用不同限速速率；在异常情况出现时，采取减少红包数，异步限流降低拆/分享红包的速率等措施减轻服务器端压力；与此同时，微信红包还有全程压测流程，对整个业务链接进行自动提前评估，防止过载。
& ]6 H1 J+ z/ q$ q- X

' z; V+ u' F8 ?+ y7 d

点评：在前端挡住对后端流量的进入，比如出现通信失败时，当前这个用户，对后台已经不会有什么压力了。

7 C1 P( Y8 G1 l+ ]7 l

% g3 v4 K/ P. ?' D& q! \

这画面你可能没见过，它其实早已在手机待命

在有损服务思想的重重保护下，第一波的摇红包体验活动中，微信红包几乎满分通过考验，其中过载保护的作用相当明显，在客户端、接入层层减压、过滤，最终仅把十万级压力传递到后台。

• 柔性可用-细化场景把握核心需求。
  
  0 k  ]7 ^4 `3 J  J. Y9 Z/ j

柔性可用是在有损服务价值观支持下的方法，重点在于实际上会结合用户使用场景，根据资源消耗，调整产品策略，设计几个级别不同的用户体验场景，保证尽可能成功返回关键数据，并正常接受请求，绝不轻易倒下。

6 q) j4 P) I1 q) w: s6 b( P6 V

柔性服务更具有产品的思维性质，意义在于深刻理解产品每一个场景的核心价值，把握用户在每一个场景中的核心需求，设计不同层次的满足核心诉求的办法，对柔性服务在微信红包中的实践，红包团队也有相应的措施，主要可以分为几大类。

; h3 R4 z# c( C- T$ f- _% y

1、系统容灾：面对大规模的请求量，系统容灾必不可少，容灾一般可分为逻辑层容灾和数据层容灾，这次微信后台开发团队在容灾布置中采用30%切换的逻辑层方案，即核心服务都能做到最多1/3服务器出问题的情况下自动容灾切换以保证服务质量，提高预警级别换取系统的可用性。

2、资源隔离：顾名思义就是把资源进行隔离减少服务支路间的影响，从逻辑入手，在资源逻辑中，当A服务同时分派任务给BC服务时，设定单个最大分配上限值，避免任意一个支路出问题影响整个服务链条，这样即使部分服务出现问题也不会影响到整个服务的崩塌。

3、快速拒绝：当服务过载时尽早拒绝请求，由服务调用方换机重试避免单一服务器重试过载，快速拒绝和有损服务中的及早拒绝是一个概念的方法，从过程的源头将问题解决，成本越低，影响越小，前端保护后端的方式来解决问题。

点评：这里面需要指出一点的是，客户端跟Web 系统不同，做这种操作的前提，是提前预计到关键路径，在客户端的版本更新中，将相关的指令和策略埋入，当接受数据获取异常时，在客户端自动就降低请求频率，比如一次请求失败，用户肯定想二次再刷，但是可能实际上没有向后端请求，而是直接返回，请客户稍安勿躁，如果不提前埋入，到有问题时才处理是来不及的。

4、支付分组：从支付环节入手，将所有红包分为50个组，放在50个单独的set上互不影响，单组set出问题最多只影响1/50用户，保证多数人服务不受干扰。分组set化也是柔性可用的一个重要技术手段，这一思维非常类似于现实生活中的集装箱思维——通过标准化，规模化的箱体设计，应对复杂多样的货物，使每个流通环节既独立又不失灵活。

. `; k% z5 `6 [( ?# B* o

5、流量预加载：从客户端入手，将语音图片等极消耗流量的资源提前让客户端自动下载预置好，提前将流量洪峰疏导，并在活动当天CDN将准备数百G带宽应对，这块也与过载保护中的快慢分离是相通的，将耗流量的服务提前加载避免高峰期间的冲突。

点评：这是提前准备，从各个路径上，把缓存用到彻底。

• 大系统小做-保证进程的功能单一         。
  
  

大系统小做应该来说，是一种意识，他的核心思想是将功能复杂较大的系统，化大为小，减少模块耦合，降低关联性，用多个独立的模块来实现整体系统的功能，大系统小做采用的是化繁为简，分而治之，便于开发和迅速实现。

微信红包如此庞大的后台系统，模块也相当之多，而这次的模块微信开发后台团队采用了系统高度模块化的方式，分成一个个高度自制的小系统，形成高内聚低耦合的格局，每个模块之间不会过分依赖对方，这样的好处是不会因为任何一个模块而影响全部服务，避免牵一发动全身的风险，实现真正的灰度服务。

点评：降低耦合，增加问题处理时的难度和平时的可维护性。

海量服务能力决定成败

从2014的滴滴打车，到2015的微信红包，腾讯用一个个案例，去证明自身在海量服务方面的实力。事实上，真正支撑起微信红包顺畅运营的幕后英雄，正是腾讯内部一个叫做“海量之道2.0”的技术体系。有损服务，柔性服务，大系统小做三大手段也是脱胎于此体系中。移动互联网大战硝烟味愈浓，BAT都在为争夺支付入口使出浑身解数，在业务从起步到小跑再到腾飞的过程中，巨头背后的海量服务能力将对其最终成败有着来越发深远的影响。

  Q- N4 y4 {) F) M

+ p/ a/ k9 `" G9 {