Hi there 👋

三小时的将睡未睡后，于早上六点抵达成田机场，向机场工作人员求助未果，与售票机搏斗良久，才在八点多坐上了驶离机场的电车。虽到东京才过两小时，机场整洁小巧的建筑结构、售票机叮叮当当地吐出的繁多面额的硬币、站台呈现的低饱和度工业风美术风格，已足够形成对东京的初步印象。候机厅充斥着旅客却不见一丝交谈声与手机声，人们目不斜视地专注于自己地事情，不缓不急地在自己地轨道上行动，避免冒犯到他人，甚至坐扶梯也一定是间距一人地靠左站立。 转而在上午 10.30 在酒店附近寄存好行李，将于浅草桥站前往新宿站。春初的东京不算寒冷但也谈不上天气适宜，露天的站台上方是金属支立起的点点锈迹的顶棚，随之边沿流下的不止雨水，还弥漫着雨水的气息伴着丝丝冷意。除了点点雨声再无其它声响，几乎彻夜未眠的我不感到疲惫，感受着此刻的宁静，直到电车入站的音乐响起。 午饭是在新宿站附近解决的，是一家名叫 “こめらく ニッポンのお茶漬け日和” 的茶泡饭店。这是一家无法预定只能 walk in 的普通小店，短暂地排队和观察让我确信这是一家受本地人亲睐的店，愉快地进入其中。 我点的是 “真鯛のごま和え茶漬け”，壶内盛着泡饭的茶，前方摆放着可自行添加的鱼干和海苔。十分清淡几乎没油，但比较咸口，齁咸的那种，量比较小，吃完后不知为何心想，果然日本的味道就该是这样啊。对我来说属于是喜欢但不会天天吃的味道，还是中国菜吃的上头，而且这个量确实很难填饱中国人的胃袋，也没什么蔬菜，请至少保持四分之一的蔬菜呀。 下午先去了 bic camera 拿下 Nikon 24-120mm f4 镜头，这是很早就看好的，ZF 才买没几天，只有挂机的 40mm f2，整个行程一开始就想好了第一天要来东京，第一站要先来新宿拿下镜头方便经历完整的旅行见闻。但购买的过程有个小插曲，我在小红书看到看到 bic camera 有 7% 的优惠券，但销售和我说只有 5% 的，我亮出小红书上的优惠券后才和说确实有 7%，可能是忘了吧。最终以 6300rmb 拿下这枚镜头。 随后在 “喫茶室ルノアール 新宿ハルク横店” 小歇，这是一家咖啡厅，充斥着聊天的日本人，这里的热闹与外面的冷寂是两个世界，原来日本人也会这么大声说话啊，我暗自感慨到。 直到晚饭前，都穿梭于新宿的各个店间。 综合百货 伊势丹 堂吉柯德 BIC camera 相机店 北村相機店，高端中古器材（徕卡、哈苏、禄来） 柠檬社 中古カメラBOX Map Camera 友都八喜 动漫玩具 KEN BOX，模型小车玩具 书店 / 二手店 紀伊國屋書店 新宿本店 纪伊国屋洋书店 bookoff 其他 新宿Beams 雨后夜游新宿，夜景下的霓光灯与倒影交错，人们熙熙攘攘却互不相扰的氛围，就这样漫步在异国的街道，也没有什么目的。走呀走，仿佛在体验别人的人生，又仿佛成为一个刚降临在世间的人，对平日习以为常的事物产生新奇的感受，对平日不曾经历的事物感到陌生的新奇。剥离了熟知的环境，外在对内心的影响在此刻降到最低，成为大人后第一次找回了孩童时的自由自在无拘无束，和探索世界的新奇与喜悦。 拿到 24-120mm 的第一次拍摄，是在 “新都心歩道橋”。作为摄影新手不懂得夜间降低曝光，于是愉快地过曝了，努力用后期修正了。不少人一同在这儿，看来是很有名的机位呢。这桥有点摇摇晃晃地感觉，十分担心会塌下去。。。 预定地烧鸟居酒屋 “Yakitori Ruike”，平日不吃内脏地我却迷上了师傅做的几乎全生地生肝烤串，另外清酒和冰淇淋的搭配很有趣，用翻译器告诉师傅很喜欢他的料理，被郑重地鞠躬了，当时不知所措不知道该怎么回应呢，但真的是很有趣地经历，谢谢你们。...

你好，Blog。

简介 虽然红包雨复杂度低，但是是 C 端典型（或者说少有）的大流量写业务场景，且需要保障资金安全，根据业务形态和宣传资源，QPS 可达数万至数千万不等，可借由方案的推敲和设计一窥 C 端大流量核心场景系统设计的原则，和互联网后端工程师的核心能力模型 —— 大流量高并发下的系统设计和稳定性与容灾保障。 本文不会涉及具体的方案设计，只能泛泛而谈，希望能给读者一些启发。 需求概述 活动期内，每天定时领取红包。 业务价值 通过玩法将用户导量到入口和出口的场景。 比如免登录态参与玩法引导用户注册。比如玩完红包雨后跳转到春节活动主会场引导用户玩其他玩法。比如在聊天玩红包雨提升群聊活跃度。 流量预估 峰值流量取决于入口流量和玩法漏斗转化率，进而取决于： 宣传入口：如春晚口播、全局弹窗、feed 流强插、挂件等，其中最有效的是春晚口播和全局弹窗 用户数量：一般按高峰活跃用户数量估计，如有往年数据可以直接以 DAU 比例计算，如果定向圈人则需考虑圈人比例 是否打散：打散是削峰的关键，需要除以打散时长，一般推崇向前打散 玩法转化：如有往年数据可直接参考，如无则需依赖产品估算各级漏斗转化率给口径 流量预估会进行多次，一般是需求评审后 RD 会拍个粗估的峰值去做技术方案，开发期间 RD 和产品经过多轮讨论才能给出细化的预估，最终会通过演练场次算出精确的流量预估。此外对于红包雨这种玩法，在初期是无法确定真实的流量范围的，是否有春晚口播、是否使用全局弹窗，这些都不是前期能定下来的，所以初期技术方案设计上得按高估计。 不过如果产品往年做过类似玩法，可以参考往年数据进行粗估。 如有春晚口播，初期流量预估可以直接按该玩法普通导流方式的流量乘以十倍。 技术方案 技术挑战 大流量与高并发 应对挑战： 开始时会瞬间涌入大量用户 配置下发、玩法产生大量请求，对机房带宽产生压力 与秒杀不同，红包雨需要尽量保证用户能领取到奖励，大量请求能走完领奖的完整流程 解决方案： 入口打散 减少网络交互，接口简单 限流 提前建连保活 稳定性与容灾 应对挑战： 高并发下的玩法体验，保证服务稳定性 故障时的快速止损，恢复玩法体验 解决方案： 简化玩法，链路尽可能短，强依赖尽可能少 合理的重试、超时、限流配置 热备异构存储，设计合理的存储一致性维护方案 资金安全保障 应对挑战： 预算充足时正常发放，预算不足时发放兜底 每个用户的奖励需由策略算出，不能提前拆红包 保证各种情况下，不超发 解决方案： 合理设计预算控制模块抗超高流量的预算检查和扣除 梳理各种异常情况的兜底表现 幂等入账 对账、熔断、一致性校验 决策分歧点 附加需求 不展开 边缘机房 or 核心机房 机房分为核心机房和边缘机房，流量一般由边缘机房流向核心机房，边缘机房的特点是离用户更近，带宽承载能力更强，基础设施建设相对不完善。 选择流量终结在边缘机房的原因可能是： 极高稳定性和延迟要求 不希望超高流量打到核心机房影响核心业务 边缘机房到核心机房的带宽建设不足，可能无法承载超高流量 物理机 or 容器 在极端性能敏感或极致服务设计的情况下可以使用物理机，物理机的好处是：...