d********f
发帖数: 43471 | 1 【 以下文字转载自 Programming 讨论区 】
发信人: wwzz (一辈子当码工), 信区: Programming
标 题: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
发信站: BBS 未名空间站 (Tue Feb 24 10:41:41 2015, 美东)
微信产品经理和架构师们是靠什么扛住了10亿个红包？
2015-02-21新朋友请加产品中国
微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
是相当地有学习的价值,分享给大家。
400倍的挑战
今年微信红包方式与去年用户与用户之间互发红包相比，摇红包的方式对业务量来说是
一个极大的爆发，光是除夕10：30送出的一波红包就达到了1.2亿个，已经是2014年除
夕夜峰值的400倍之巨（2014年峰值每分钟被拆开红包数量仅2.5W个）！
进入抢红包环节，后台数据瞬间飙升
发10亿红包，难在哪里？
微信团队总结下来有三大难点：
快——如何保证用户快速摇到红包？
准——如何保证摇到的红包能成功拆开？
稳——如何保证拆开的红包能分享出去？
大量用户在同一时间摇红包，瞬间产生每秒千万级的请求，这个量级的请求如果不加以
疏导处理直接到达后台，必定会导致后端服务过载甚至崩溃。上文中除夕当天后台监控
数据曲线便能说明一切——在前台重重的分流减压下，后台服务器负载仍然瞬间飙升十
倍以上。
三大应对策略齐上阵
对于以上三个难点，微信后台开发团队主要通过三大应对策略应对：有损服务，柔性可
用，大系统小做
有损服务-追求高可用和快速响应。
什么是有损服务？有损服务是通过精心拆分产品流程，选择性牺牲一部分数据一致性和
完整性从而保证核心功能绝大多数运行。这是腾讯在PC时代积累下来的一种特色运营策
略——在资源一定的前提下，互联网条件千变万化的场景中，量力而为，满足用户的核
心需求。
微信红包的核心点是摇，拆，分享红包，整个系统设计时必须尽最大可能保证这三个步
骤一气呵成，任何关联系统出现异常的时候马上进行系统降级，防止引起系统雪崩。
系统降级可以分为两个方面，一是把核心功能进行分拆和简化，通过辅助轻量化的服务
实现，确保最短关键路径的可行，比方说在接入层置入摇红包逻辑，将每秒千万级请求
转化为每秒万级的红包请求，再传到红包服务的后端逻辑，降低雪崩的可能性。
点评：有损服务就是让重要的事情先做，重要的人物先行。这在现实中也很常见，军人
买票优先，领导视察封路，让领导车先行，我等小民等待也是这个路子。
同时后端采用异步分拆，接收到用户请求时仅进行合法性验证，验证完成后直接告知成
功，后续业务逻辑进入异步队列进行处理，减少了用户的等待时间，也极大降低了峰值
雪崩的概率。
耗时最长的入账操作，直接跳过，异步处理
另外一方面是采取过载保护措施：
微信红包的过载保护在客户端已提前预埋了策略，在连接失败或超时情况下会有相应提
示，减少用户重复请求次数。接入层面也会进行自我保护，针对频繁发出请求的客户端
限制响应速度，并对系统负载划分出若干等级，达到不同阈值时引导客户端使用不同限
速速率；在异常情况出现时，采取减少红包数，异步限流降低拆/分享红包的速率等措
施减轻服务器端压力；与此同时，微信红包还有全程压测流程，对整个业务链接进行自
动提前评估，防止过载。
点评：在前端挡住对后端流量的进入，比如出现通信失败时，当前这个用户，对后台已
经不会有什么压力了。
这画面你可能没见过，它其实早已在手机待命
在有损服务思想的重重保护下，第一波的摇红包体验活动中，微信红包几乎满分通过考
验，其中过载保护的作用相当明显，在客户端、接入层层减压、过滤，最终仅把十万级
压力传递到后台。
柔性可用-细化场景把握核心需求。
柔性可用是在有损服务价值观支持下的方法，重点在于实际上会结合用户使用场景，根
据资源消耗，调整产品策略，设计几个级别不同的用户体验场景，保证尽可能成功返回
关键数据，并正常接受请求，绝不轻易倒下。
柔性服务更具有产品的思维性质，意义在于深刻理解产品每一个场景的核心价值，把握
用户在每一个场景中的核心需求，设计不同层次的满足核心诉求的办法，对柔性服务在
微信红包中的实践，红包团队也有相应的措施，主要可以分为几大类。
1、系统容灾：面对大规模的请求量，系统容灾必不可少，容灾一般可分为逻辑层容灾
和数据层容灾，这次微信后台开发团队在容灾布置中采用30%切换的逻辑层方案，即核
心服务都能做到最多1/3服务器出问题的情况下自动容灾切换以保证服务质量，提高预
警级别换取系统的可用性。
2、资源隔离：顾名思义就是把资源进行隔离减少服务支路间的影响，从逻辑入手，在
资源逻辑中，当A服务同时分派任务给BC服务时，设定单个最大分配上限值，避免任意
一个支路出问题影响整个服务链条，这样即使部分服务出现问题也不会影响到整个服务
的崩塌。
3、快速拒绝：当服务过载时尽早拒绝请求，由服务调用方换机重试避免单一服务器重
试过载，快速拒绝和有损服务中的及早拒绝是一个概念的方法，从过程的源头将问题解
决，成本越低，影响越小，前端保护后端的方式来解决问题。
点评：这里面需要指出一点的是，客户端跟Web 系统不同，做这种操作的前提，是提前
预计到关键路径，在客户端的版本更新中，将相关的指令和策略埋入，当接受数据获取
异常时，在客户端自动就降低请求频率，比如一次请求失败，用户肯定想二次再刷，但
是可能实际上没有向后端请求，而是直接返回，请客户稍安勿躁，如果不提前埋入，到
有问题时才处理是来不及的。
4、支付分组：从支付环节入手，将所有红包分为50个组，放在50个单独的set上互不影
响，单组set出问题最多只影响1/50用户，保证多数人服务不受干扰。分组set化也是柔
性可用的一个重要技术手段，这一思维非常类似于现实生活中的集装箱思维——通过标
准化，规模化的箱体设计，应对复杂多样的货物，使每个流通环节既独立又不失灵活。
5、流量预加载：从客户端入手，将语音图片等极消耗流量的资源提前让客户端自动下
载预置好，提前将流量洪峰疏导，并在活动当天CDN将准备数百G带宽应对，这块也与过
载保护中的快慢分离是相通的，将耗流量的服务提前加载避免高峰期间的冲突。
点评：这是提前准备，从各个路径上，把缓存用到彻底。
大系统小做-保证进程的功能单一
大系统小做应该来说，是一种意识，他的核心思想是将功能复杂较大的系统，化大为小
，减少模块耦合，降低关联性，用多个独立的模块来实现整体系统的功能，大系统小做
采用的是化繁为简，分而治之，便于开发和迅速实现。
微信红包如此庞大的后台系统，模块也相当之多，而这次的模块微信开发后台团队采用
了系统高度模块化的方式，分成一个个高度自制的小系统，形成高内聚低耦合的格局，
每个模块之间不会过分依赖对方，这样的好处是不会因为任何一个模块而影响全部服务
，避免牵一发动全身的风险，实现真正的灰度服务。
点评：降低耦合，增加问题处理时的难度和平时的可维护性。
海量服务能力决定成败
从2014的滴滴打车，到2015的微信红包，腾讯用一个个案例，去证明自身在海量服务方
面的实力。事实上，真正支撑起微信红包顺畅运营的幕后英雄，正是腾讯内部一个叫做
“海量之道2.0”的技术体系。有损服务，柔性服务，大系统小做三大手段也是脱胎于
此体系中。移动互联网大战硝烟味愈浓，BAT都在为争夺支付入口使出浑身解数，在业
务从起步到小跑再到腾飞的过程中，巨头背后的海量服务能力将对其最终成败有着来越
发深远的影响。
总结：优才网一直坚持一个观点，尽管是在移动互联网时代，但是客户端应用开发本身
，并不是体验的决胜之处，真正对团队挑战的地方，还在于后端，无论是承压能力，还
是安全性等方面，如果这些地方过不了关，整个应用的基础是不扎实的，我们也认为，
技术能力是应用的骨架，如果技术能力，或者说后端能力不强，应用在长到一定程度也
会支撑不下去。当然可喜的是，现在有了很多云服务，从Iaas 腾讯云、阿里云，到
Paas SAE，另外还有专业的存储云服务，比如七牛，甚至对于代码级服务质量监控 APM
厂商也出现了，国内做得最好的是 OneAPM， 这些服务一定程度上能降低团队的技术
要求，以及在平时，能发现自己服务中所存在的问题。进行及早准备。
来源: 腾讯大讲堂
产品中国 ：pmtooo
加入我们
1、产品中国资深俱乐部：273121797（业内大咖，腾讯PM、京东PM、淘宝PM正等你加入
）入群格式：公司名称-昵称
2、商务合作QQ：24815601422 投稿：[email protected]
/* */
转载自公众号: 腾讯大讲堂
Pageview 4473584 Report |
k***a
发帖数: 1199 | 2 威信红包不是甭过吗，还吹牛。。。。没一点技术含量
APM
/* */
【在 d********f 的大作中提到】
: 【 以下文字转载自 Programming 讨论区 】
: 发信人: wwzz (一辈子当码工), 信区: Programming
: 标 题: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 发信站: BBS 未名空间站 (Tue Feb 24 10:41:41 2015, 美东)
: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 2015-02-21新朋友请加产品中国
: 微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
: 我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
: 公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
: 是相当地有学习的价值,分享给大家。
|
d****o
发帖数: 32610 | 3 反正我毛都没摇出来
【在 d********f 的大作中提到】
: 【 以下文字转载自 Programming 讨论区 】
: 发信人: wwzz (一辈子当码工), 信区: Programming
: 标 题: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 发信站: BBS 未名空间站 (Tue Feb 24 10:41:41 2015, 美东)
: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 2015-02-21新朋友请加产品中国
: 微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
: 我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
: 公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
: 是相当地有学习的价值,分享给大家。
|
c*****t
发帖数: 10738 | |
l*****o
发帖数: 19235 | 5 他们不会把前端所有数据都送回去了吧？随便加个过滤，把前戏都留在终端，摇十分钟
送一个请求回去，服务器跟玩似的。。。 |
z*********n
发帖数: 94654 | 6 你们一个个的吹吧
这流量的确很大，腾讯的确很牛。天朝的网站流量都很大，所以天朝的网站后台的确够
牛B
我表示非常钦佩
【在 l*****o 的大作中提到】
: 他们不会把前端所有数据都送回去了吧？随便加个过滤，把前戏都留在终端，摇十分钟
: 送一个请求回去，服务器跟玩似的。。。
|
a****e
发帖数: 9589 | 7 太长了，根本没看。
国人就是喜欢把简单的问题复杂化，以体现他们的专业和逼格。
其实就一句话，透明计算，一切皆有可能。
【在 d********f 的大作中提到】
: 【 以下文字转载自 Programming 讨论区 】
: 发信人: wwzz (一辈子当码工), 信区: Programming
: 标 题: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 发信站: BBS 未名空间站 (Tue Feb 24 10:41:41 2015, 美东)
: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 2015-02-21新朋友请加产品中国
: 微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
: 我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
: 公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
: 是相当地有学习的价值,分享给大家。
|
z*********n
发帖数: 94654 | 8 这个就没意思了，大流量不是简单问题
他们搞得也不算太复杂化
google更喜欢show off
这篇文章至少说的还比较简单，就是流量大，简单化处理，降低客户重试啥的
其实背后就是大量的硬件投入
【在 a****e 的大作中提到】
: 太长了，根本没看。
: 国人就是喜欢把简单的问题复杂化，以体现他们的专业和逼格。
: 其实就一句话，透明计算，一切皆有可能。
|
x****o
发帖数: 21566 | 9 接入层置入摇红包逻辑
这个接入层是个啥东东？
【在 z*********n 的大作中提到】
: 这个就没意思了，大流量不是简单问题
: 他们搞得也不算太复杂化
: google更喜欢show off
: 这篇文章至少说的还比较简单，就是流量大，简单化处理，降低客户重试啥的
: 其实背后就是大量的硬件投入
|
H*****i
发帖数: 1867 | 10 手机app里内置吧
【在 x****o 的大作中提到】
: 接入层置入摇红包逻辑
: 这个接入层是个啥东东？
|
|
|
z*********n
发帖数: 94654 | 11 我觉得主要说的就是先让你摇到了再说，然后真的转账慢慢批处理
不过光摇到没摇到这一点流量也够大，要瞬间做决定，也挺有挑战的，毕竟你不能一个
红包发给两个人啊
【在 x****o 的大作中提到】
: 接入层置入摇红包逻辑
: 这个接入层是个啥东东？
|
x****o
发帖数: 21566 | |
d****o
发帖数: 32610 | 13 红包又不带序列号
不要求唯一
这个比车票简单多了
只需要监控大概发了多少
然后估计个时间掐断
而且流量太高调整概率就行
最后发超了一点装作没这回事就行
【在 z*********n 的大作中提到】
: 我觉得主要说的就是先让你摇到了再说，然后真的转账慢慢批处理
: 不过光摇到没摇到这一点流量也够大，要瞬间做决定，也挺有挑战的，毕竟你不能一个
: 红包发给两个人啊
|
z*********n
发帖数: 94654 | 14 不过就算转账不实时进行，后台进行，这么庞大得处理量，腾讯肯定也得有个巨大的服
务器群组批处理这些转账，还尽是几分几分的
下了血本了。如果不能转换成用户开始用他们当付款方式，就是白忙乎啊，呵呵
【在 x****o 的大作中提到】
: 奥
|
z*********n
发帖数: 94654 | 15 你这是胡说八道，红包是跟真钱联系的
到最后老胡发了10块钱，结果我领了10块，你领了10块，反正老胡银行卡只扣10块
腾讯给补？
又不是伪币，是真钱
【在 d****o 的大作中提到】
: 红包又不带序列号
: 不要求唯一
: 这个比车票简单多了
: 只需要监控大概发了多少
: 然后估计个时间掐断
: 而且流量太高调整概率就行
: 最后发超了一点装作没这回事就行
|
K******S
发帖数: 10109 | 16 my niece got RMB 6688 but the fine print says the money only stays in her
account for several days and will be taken back. However, she can keep the
interest accumulated in those 3-5 days.
【在 d********f 的大作中提到】
: 【 以下文字转载自 Programming 讨论区 】
: 发信人: wwzz (一辈子当码工), 信区: Programming
: 标 题: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 发信站: BBS 未名空间站 (Tue Feb 24 10:41:41 2015, 美东)
: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 2015-02-21新朋友请加产品中国
: 微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
: 我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
: 公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
: 是相当地有学习的价值,分享给大家。
|
d****o
发帖数: 32610 | 17 老张发了个红包给老胡，
老张钱包减少4.19元，
老胡钱包增加4.19元，
这个跟老张给老胡发了条微信，
老张发信记录多一条，
老胡收信记录多一条，
有什么本质区别吗？
反正包子都在腾讯服务器里
【在 z*********n 的大作中提到】
: 不过就算转账不实时进行，后台进行，这么庞大得处理量，腾讯肯定也得有个巨大的服
: 务器群组批处理这些转账，还尽是几分几分的
: 下了血本了。如果不能转换成用户开始用他们当付款方式，就是白忙乎啊，呵呵
|
d****o
发帖数: 32610 | 18 摇红包说的是官方发，用户摇
不是互相发的那个
再说又不是直接连银行
都在微信钱包里
你给老胡的微信不会被博导看到
为啥红包会被多拿？
【在 z*********n 的大作中提到】
: 你这是胡说八道，红包是跟真钱联系的
: 到最后老胡发了10块钱，结果我领了10块，你领了10块，反正老胡银行卡只扣10块
: 腾讯给补？
: 又不是伪币，是真钱
|
z*********n
发帖数: 94654 | 19 你如何确定老张钱包减少4.19同事老胡钱包增加4.19？
只在手机上逻辑显然不行，二者需要协调
你协调10个交易简单，协调几亿个试试
短信的区别，短信发出去对方收到没有什么ACCOUNTING得要求
你发出去，你的短信也没消失
伪币的话也无所谓，反正是伪币
微信红包是真钱，必须完全对应
【在 d****o 的大作中提到】
: 老张发了个红包给老胡，
: 老张钱包减少4.19元，
: 老胡钱包增加4.19元，
: 这个跟老张给老胡发了条微信，
: 老张发信记录多一条，
: 老胡收信记录多一条，
: 有什么本质区别吗？
: 反正包子都在腾讯服务器里
|
d****o
发帖数: 32610 | 20 你的钱是从微信钱包发出去的
微信钱包也在腾讯服务器里
【在 z*********n 的大作中提到】
: 你如何确定老张钱包减少4.19同事老胡钱包增加4.19？
: 只在手机上逻辑显然不行，二者需要协调
: 你协调10个交易简单，协调几亿个试试
: 短信的区别，短信发出去对方收到没有什么ACCOUNTING得要求
: 你发出去，你的短信也没消失
: 伪币的话也无所谓，反正是伪币
: 微信红包是真钱，必须完全对应
|
|
|
z*********n
发帖数: 94654 | 21 没那么简单啦，比如十个红包，我领了一个，你领了一个，这个必须汇报回去，才能保
证服务器知道是发了俩不是发了1个，然后还得服务器再反馈回来你才能知道你来晚一
步没了。不可能逻辑都在前台，只要涉及逻辑在后台的，这么大的数据量都不是闹着玩的
【在 d****o 的大作中提到】
: 摇红包说的是官方发，用户摇
: 不是互相发的那个
: 再说又不是直接连银行
: 都在微信钱包里
: 你给老胡的微信不会被博导看到
: 为啥红包会被多拿？
|
z*********n
发帖数: 94654 | 22 正因为在服务器里才导致复杂啊
如果都在你手机前台逻辑就简单了
【在 d****o 的大作中提到】
: 你的钱是从微信钱包发出去的
: 微信钱包也在腾讯服务器里
|
d********f
发帖数: 43471 | 23 你这个根本无解，程序员基本做不了太多事情，数据库作transaction占了整个event相
应时间的99%,除了提高硬件水平，其他都是扯犊子。现在这些轮子都是你们网站马宫骗
钱用的
玩的
【在 z*********n 的大作中提到】
: 没那么简单啦，比如十个红包，我领了一个，你领了一个，这个必须汇报回去，才能保
: 证服务器知道是发了俩不是发了1个，然后还得服务器再反馈回来你才能知道你来晚一
: 步没了。不可能逻辑都在前台，只要涉及逻辑在后台的，这么大的数据量都不是闹着玩的
|
z*********n
发帖数: 94654 | 24 程序员用处不大，当然程序员经常来个不关闭打开的socket拉，不垃圾处理啦的导致对
硬件的要求增加100倍，硬件商最爱半路出家只会写程序的程序员了。
解决方式的确就是硬件。据说腾讯去年买服务器的投资是好几个亿。
到了数据库，已经过了我说的保证一致等等那些逻辑了
【在 d********f 的大作中提到】
: 你这个根本无解，程序员基本做不了太多事情，数据库作transaction占了整个event相
: 应时间的99%,除了提高硬件水平，其他都是扯犊子。现在这些轮子都是你们网站马宫骗
: 钱用的
:
: 玩的
|
d****o
发帖数: 32610 | 25 你这又是在说第三种红包了
之前最开始说的是官方发，用户摇的摇红包
这个是我说的不带序列号的那种
只需要监控发放速度预测发光的时间
最后降低概率就可以
然后是用户之间定点发的普通红包
这个是一对一发
跟普通微信数据量没区别
现在你说的这个是拼手气红包
一个用户发，群里几个人抢
这个东西确实有你说的问题
但也是体验上来说最糟糕的
各种延迟，卡
经常刚看到点进去发现人家一分钟前就抢完了
这个可能就是腾讯说的“有损服务”
玩的
【在 z*********n 的大作中提到】
: 没那么简单啦，比如十个红包，我领了一个，你领了一个，这个必须汇报回去，才能保
: 证服务器知道是发了俩不是发了1个，然后还得服务器再反馈回来你才能知道你来晚一
: 步没了。不可能逻辑都在前台，只要涉及逻辑在后台的，这么大的数据量都不是闹着玩的
|
z*********n
发帖数: 94654 | 26 不管哪种都是需要后台服务的
只要后台需要服务，哪怕后天只是做个1+1 = 2然后返回个2，流量上去都是很大很大的
挑战
每个流量都是一个服务请求。腾讯的这个流量，足够摧毁全世界99%的网站了。你别不
信，所谓的一个TERM DDOS攻击，就是发动很多机器同时提出请求，都不管请求内容是
啥，就一个syn request，就足够摧毁好多网站了
全中国人民一起提出有效请求，能应付得了，服务器付出是非常大的
【在 d****o 的大作中提到】
: 你这又是在说第三种红包了
: 之前最开始说的是官方发，用户摇的摇红包
: 这个是我说的不带序列号的那种
: 只需要监控发放速度预测发光的时间
: 最后降低概率就可以
: 然后是用户之间定点发的普通红包
: 这个是一对一发
: 跟普通微信数据量没区别
: 现在你说的这个是拼手气红包
: 一个用户发，群里几个人抢
|
d****o
发帖数: 32610 | 27 数据量大是当然的
但这10亿红包跟peer比也不算啥
拜年群发短信瞬发服务请求可能都比这个多
【在 z*********n 的大作中提到】
: 不管哪种都是需要后台服务的
: 只要后台需要服务，哪怕后天只是做个1+1 = 2然后返回个2，流量上去都是很大很大的
: 挑战
: 每个流量都是一个服务请求。腾讯的这个流量，足够摧毁全世界99%的网站了。你别不
: 信，所谓的一个TERM DDOS攻击，就是发动很多机器同时提出请求，都不管请求内容是
: 啥，就一个syn request，就足够摧毁好多网站了
: 全中国人民一起提出有效请求，能应付得了，服务器付出是非常大的
|
z*********n
发帖数: 94654 | 28 手机短信是piggy back cell tower的hello message回去的，根本没有额外负荷，不是
网络请求
且手机短信你发出去别人五分钟后收到也无所谓啊
另，说腾讯应付流量牛没说电信不牛啊
在中国做大的网站都很牛的
当然如果你说的是微信拜年短信，更说明腾讯应付流量很牛啊
【在 d****o 的大作中提到】
: 数据量大是当然的
: 但这10亿红包跟peer比也不算啥
: 拜年群发短信瞬发服务请求可能都比这个多
|
d********f
发帖数: 43471 | 29 短信很容易，都是放到queue里慢慢处理，延时几天都可以
【在 d****o 的大作中提到】
: 数据量大是当然的
: 但这10亿红包跟peer比也不算啥
: 拜年群发短信瞬发服务请求可能都比这个多
|
d****o
发帖数: 32610 | 30 是 腾讯本来就牛
我是说这个红包没啥特别的
跟车票之类的服务难度没法比
【在 z*********n 的大作中提到】
: 手机短信是piggy back cell tower的hello message回去的，根本没有额外负荷，不是
: 网络请求
: 且手机短信你发出去别人五分钟后收到也无所谓啊
: 另，说腾讯应付流量牛没说电信不牛啊
: 在中国做大的网站都很牛的
: 当然如果你说的是微信拜年短信，更说明腾讯应付流量很牛啊
|
|
|
T*U
发帖数: 22634 | 31 这难度比买票差多了吧。
【在 d********f 的大作中提到】
: 短信很容易，都是放到queue里慢慢处理，延时几天都可以
|
z*********n
发帖数: 94654 | 32 个人见过的实例，某美国较著名网站，因为天朝一个普通大流量网站错将DNS指向，立
刻瘫痪。神马buzz word的各种设计，毫无抵抗之力，瘫痪，lol。那次见识过那个事件
之后，就对天朝大流量网站的后台佩服得很。
后来跟相关人士聊天，问过，回答都是，买硬件呗。国内很多网站硬件投资很大的，呵
呵，感觉比美国这边大
美国好多公司的钱都让各层高工资的人搞了，投资个硬件就和美国国会吵架似的，
budget很难通过
【在 d****o 的大作中提到】
: 是 腾讯本来就牛
: 我是说这个红包没啥特别的
: 跟车票之类的服务难度没法比
|
r*g
发帖数: 3159 | 33 可能不考虑公平。没有先来后到的要求。请求接受一大批，随机发10个。简单多了。
玩的
【在 z*********n 的大作中提到】
: 没那么简单啦，比如十个红包，我领了一个，你领了一个，这个必须汇报回去，才能保
: 证服务器知道是发了俩不是发了1个，然后还得服务器再反馈回来你才能知道你来晚一
: 步没了。不可能逻辑都在前台，只要涉及逻辑在后台的，这么大的数据量都不是闹着玩的
|
t***e
发帖数: 3601 | 34 They could add logic to client to randomly fail a percentage of the requests
. E.g.
10 requests only got to server once.
Problem solved. |
R***a
发帖数: 41892 | 35 估计有损服务就是这个意思。
requests
【在 t***e 的大作中提到】
: They could add logic to client to randomly fail a percentage of the requests
: . E.g.
: 10 requests only got to server once.
: Problem solved.
|
T*U
发帖数: 22634 | 36 服务器发出去10个包，每包随机数量的钱后，就不管了，逻辑在服务器干嘛。
玩的
【在 z*********n 的大作中提到】
: 没那么简单啦，比如十个红包，我领了一个，你领了一个，这个必须汇报回去，才能保
: 证服务器知道是发了俩不是发了1个，然后还得服务器再反馈回来你才能知道你来晚一
: 步没了。不可能逻辑都在前台，只要涉及逻辑在后台的，这么大的数据量都不是闹着玩的
|
R***a
发帖数: 41892 | 37 同时有100个请求进来分这个10个包，服务器怎么能不管？
【在 T*U 的大作中提到】
: 服务器发出去10个包，每包随机数量的钱后，就不管了，逻辑在服务器干嘛。
:
: 玩的
|
z*********n
发帖数: 94654 | 38 跟微信合作的伙伴提供了1000的奖金，结果微信给发出去一亿，咋办？当然赖账是可以
的，也就是，演砸了，不认账啦
【在 R***a 的大作中提到】
: 同时有100个请求进来分这个10个包，服务器怎么能不管？
|
R***a
发帖数: 41892 | 39 这个容易，在独立的服务器上估算一下目前摇中比例，
然后微信后台每小时一个请求更新一下摇中比例，
直接客户端按照这个比例拒掉请求就成了
【在 z*********n 的大作中提到】
: 跟微信合作的伙伴提供了1000的奖金，结果微信给发出去一亿，咋办？当然赖账是可以
: 的，也就是，演砸了，不认账啦
|
z*********n
发帖数: 94654 | 40 比例对了，总摇的数量咋办啊
你咋知道客户是摇了1000万下还是一亿下啊
【在 R***a 的大作中提到】
: 这个容易，在独立的服务器上估算一下目前摇中比例，
: 然后微信后台每小时一个请求更新一下摇中比例，
: 直接客户端按照这个比例拒掉请求就成了
|
|
|
R***a
发帖数: 41892 | 41 这文章里说了，摇了一下没摇到，再摇就直接返回false就行了。
【在 z*********n 的大作中提到】
: 比例对了，总摇的数量咋办啊
: 你咋知道客户是摇了1000万下还是一亿下啊
|
a9
发帖数: 21638 | 42 没人说腾讯不牛。
就像这个新年红包，假设有1000个红包，在数据库里有1000条纪录。
有1000000个人抢，这1000000个客户端先将其中1/10直接不往服务器发。这就变成了
100000
服务器再根据请求量决定1/10或1/100或1/1000发送到数据库。这个中间层其实堆机器
很容易堆出来了。这样数据库就只剩下1000条需要处理了。1秒内处理完一点问题都没
有。
这相当于1秒处理了1百万个红包。听上去很牛逼吧？
【在 z*********n 的大作中提到】
: 比例对了，总摇的数量咋办啊
: 你咋知道客户是摇了1000万下还是一亿下啊
|
z*********n
发帖数: 94654 | 43 谁返回false手机客户端？还是服务器？要是服务器返回，光处理这个也够流量大的
【在 R***a 的大作中提到】
: 这文章里说了，摇了一下没摇到，再摇就直接返回false就行了。
|
a9
发帖数: 21638 | 44 客户端
【在 z*********n 的大作中提到】
: 谁返回false手机客户端？还是服务器？要是服务器返回，光处理这个也够流量大的
|
R***a
发帖数: 41892 | 45 当然是客户端返回了啊。
【在 z*********n 的大作中提到】
: 谁返回false手机客户端？还是服务器？要是服务器返回，光处理这个也够流量大的
|
z*********n
发帖数: 94654 | 46 但是过年那几天每个群里都狂发红包
那个就真的得走服务器了，那个是真流量
【在 R***a 的大作中提到】
: 当然是客户端返回了啊。
|
R***a
发帖数: 41892 | 47 比较大的群可以用类似算法，就是可以估算你现在抢，多大几率可以抢到。
这个估算甚至可以直接在客户端做，就是根据红包已经存在的时间，群的大小，
当前活跃用户的大小，就可以出来个差不多。
【在 z*********n 的大作中提到】
: 但是过年那几天每个群里都狂发红包
: 那个就真的得走服务器了，那个是真流量
|
z*********n
发帖数: 94654 | 48 这个跟实际观察不符
个人发的红包都是按顺序发出去得
发红包的人可以看到谁领走了，很多红包都是两秒钟抢光
然后后来的人就说已经抢光了
不会发生没抢光结果你发现你领不到的情况
因为每一笔都记录了
【在 R***a 的大作中提到】
: 比较大的群可以用类似算法，就是可以估算你现在抢，多大几率可以抢到。
: 这个估算甚至可以直接在客户端做，就是根据红包已经存在的时间，群的大小，
: 当前活跃用户的大小，就可以出来个差不多。
|
s******d
发帖数: 9806 | 49 这个说法我不赞成。国内网站的构架还都比较原始，包括BAT。距离G和F还是有相当的
差距的。当然了，不是说构架原始就解决不了大流量的问题。
【在 z*********n 的大作中提到】
: 你们一个个的吹吧
: 这流量的确很大，腾讯的确很牛。天朝的网站流量都很大，所以天朝的网站后台的确够
: 牛B
: 我表示非常钦佩
|
R***a
发帖数: 41892 | 50 两秒钟抢光就是两秒钟之后100%客户端拒绝请求就成了？
这两秒钟内发生的事情A比B其实早按半秒，但是B拿到红包，A没拿到，
难道作为最终用户你能看得出来？
【在 z*********n 的大作中提到】
: 这个跟实际观察不符
: 个人发的红包都是按顺序发出去得
: 发红包的人可以看到谁领走了，很多红包都是两秒钟抢光
: 然后后来的人就说已经抢光了
: 不会发生没抢光结果你发现你领不到的情况
: 因为每一笔都记录了
|
|
|
s******d
发帖数: 9806 | 51 有区别。短信大多是点对点的。这个红包是点对多点。短信对时效要求不高，这个红包
对时效要求高多了。
【在 d****o 的大作中提到】
: 老张发了个红包给老胡，
: 老张钱包减少4.19元，
: 老胡钱包增加4.19元，
: 这个跟老张给老胡发了条微信，
: 老张发信记录多一条，
: 老胡收信记录多一条，
: 有什么本质区别吗？
: 反正包子都在腾讯服务器里
|
z*********n
发帖数: 94654 | 52 你提前这么做了，结果正好一分钟没人领红包，经常发生啊，咋整
明明红包还在，你第十秒抢说没了？
【在 R***a 的大作中提到】
: 两秒钟抢光就是两秒钟之后100%客户端拒绝请求就成了？
: 这两秒钟内发生的事情A比B其实早按半秒，但是B拿到红包，A没拿到，
: 难道作为最终用户你能看得出来？
|
R***a
发帖数: 41892 | 53 所以我说大群可以啊，大群怎么可能发生中间一分钟没人领红包的事情？
中间有一秒来钟没人领红包是看不出来的。别人打字说领到没领到都得十几秒
【在 z*********n 的大作中提到】
: 你提前这么做了，结果正好一分钟没人领红包，经常发生啊，咋整
: 明明红包还在，你第十秒抢说没了？
|
z*********n
发帖数: 94654 | 54 你说的这个逻辑太离谱了，比如国内申根半夜大家都睡了，有人发了一个红包，这个时
候咋办？
据我观察，个人红包没有采用你说的逻辑，是真实发送的
大群有多大？最大的是不是99人啊
如果99人，大家都在睡觉的可能性很高啊
我们高中43人的群有时候一个小时才能领完一个随机包群
也就过年那天经常秒光
【在 R***a 的大作中提到】
: 所以我说大群可以啊，大群怎么可能发生中间一分钟没人领红包的事情？
: 中间有一秒来钟没人领红包是看不出来的。别人打字说领到没领到都得十几秒
|
R***a
发帖数: 41892 | 55 大家都睡的时间段算小群啊。
小群领红包跟短信没区别，不要求时效性啊。
【在 z*********n 的大作中提到】
: 你说的这个逻辑太离谱了，比如国内申根半夜大家都睡了，有人发了一个红包，这个时
: 候咋办？
: 据我观察，个人红包没有采用你说的逻辑，是真实发送的
: 大群有多大？最大的是不是99人啊
: 如果99人，大家都在睡觉的可能性很高啊
: 我们高中43人的群有时候一个小时才能领完一个随机包群
: 也就过年那天经常秒光
|
z*********n
发帖数: 94654 | 56 任何群不会大到摇红包那个规模的
100个人的群经常没人在看手机概率很高啊
且你说的逻辑太复杂了
还得考虑哪天大家都在熬夜，哪天一般没人熬夜
且，红包在你点领取后，是肯定有时效性的，他会当场诚实地告诉你领到多少，领到没
有，并列出本红包别人抢的情况
不是说发给你了你就领到了，那天拆都行
当然最后真的转账是背后的，但至少这个红包如何分配是实时的
【在 R***a 的大作中提到】
: 大家都睡的时间段算小群啊。
: 小群领红包跟短信没区别，不要求时效性啊。
|
a****e
发帖数: 9589 | 57 放在客户端就简单多了。没参加这个活动，不知道是否要登记参加这个活动。
首先，放个cookie 在客户端，校验是否已经摇过。手机app 没做过，用cookie 做比方
其次，概率计算。如果活动要登记，在登记是安个客户端小script, 按照概率来产生
中奖就可以了，这样会滤掉很大一部分的traffic。如果不需要登记，就用透明计算，
在手机基站的switch 加过滤层，或者过时的map reduce 就能搞定。然后将中奖的有关
数据传入各分布服务器上，最后汇总。
这样也没必要与数据库关联，做个counter ，然后用csv 存下中奖的微信Id 即可。数
据库操作可以过了元宵节再做也不迟
【在 a9 的大作中提到】
: 没人说腾讯不牛。
: 就像这个新年红包，假设有1000个红包，在数据库里有1000条纪录。
: 有1000000个人抢，这1000000个客户端先将其中1/10直接不往服务器发。这就变成了
: 100000
: 服务器再根据请求量决定1/10或1/100或1/1000发送到数据库。这个中间层其实堆机器
: 很容易堆出来了。这样数据库就只剩下1000条需要处理了。1秒内处理完一点问题都没
: 有。
: 这相当于1秒处理了1百万个红包。听上去很牛逼吧？
|
R***a
发帖数: 41892 | 58 这逻辑不复杂啊，只考虑发红包的时间段是不是密集时间段就成了，
因为人不会定点一起起床开手机的。
红包发光以后，后来的人看到红包的时候就可以直接告诉客户端，这个红包没了，
虽然用户人类自己不点红包不知道。
非高峰时间就算一秒一个请求（差不多10秒红包就空了），每个请求throttle一下，
一秒才给你处理完，这样用户没啥不适的，也可以诚实告诉你领到多少，前面都有谁领，
这跟短信区别不大啊。
对服务器负担大是10个红包有10000个同时请求，这个需要同步锁定逻辑。
10000个红包分别10000个请求的压力就小多了。
【在 z*********n 的大作中提到】
: 任何群不会大到摇红包那个规模的
: 100个人的群经常没人在看手机概率很高啊
: 且你说的逻辑太复杂了
: 还得考虑哪天大家都在熬夜，哪天一般没人熬夜
: 且，红包在你点领取后，是肯定有时效性的，他会当场诚实地告诉你领到多少，领到没
: 有，并列出本红包别人抢的情况
: 不是说发给你了你就领到了，那天拆都行
: 当然最后真的转账是背后的，但至少这个红包如何分配是实时的
|
