Tag: 系统设计

Fan-out / fan-in 指的是一种并发模式：将工作拆分为多个单元并行执行，然后在所有任务完成后进行同步。虽然它经常在无服务器（serverless）函数的语境中被提及，但这一概念并不局限于无服务器架构。 更广义地说，fan-out / fan-in 是一种通用的并发模式，适用于任何可以将任务分解为相互独立部分的场景，例如线程、进程、Actor、微服务，甚至分布式作业，并在之后将结果汇聚起来。其核心思想是在执行阶段将工作并行展开（fan-out），在收敛阶段对各个分支的输出进行协调和聚合（fan-in），而不依赖于具体的执行模型或底层基础设施。 在实际工程中，fan-out / fan-in 模式常用于提升系统吞吐量和资源利用率，尤其适合 I/O 密集型或可并行计算的场景。通过将一个复杂任务拆分为多个相互独立的子任务并同时执行，可以显著缩短整体处理时间；而在 fan-in 阶段，对各个子任务的结果进行统一汇总、排序或合并，则有助于保持业务逻辑的完整性与一致性。不过，这种模式也需要注意并发控制、错误处理以及超时与重试机制，否则容易在高并发场景下引入资源争用、级联失败或结果不一致等问题。因此，在设计和实现 fan-out / fan-in 架构时，应结合具体场景权衡并发度、系统复杂度与稳定性。 英文：System Design: Fan-out/Fan-in Concurrency Pattern 本文一共 452 个汉字, 你数一下对不对. …

我儿子也说我不够Senior： 去年9月，我第三次面试伦敦谷歌，目标是一个SRE（站点可靠性工程师）职位，抱着试试看的心态参加了面试。第一轮面试的最后两分钟，回答了一个关于如何将算法应用于分布式系统（如何优化算法）的follow-up问题，表现得不太好，因此没能通过那一轮。 不过严格来说也不算被拒绝。等了三周后，他们告诉我最终选择了另一位候选人，虽然我的表现不是最出色的，但应该达到了最低门槛，所以并未直接拒掉我，而是建议我等待伦敦的其他职位空缺再申请。 这一等就到了12月。这位谷歌的美女猎头联系了我，很快安排了隔一周的两轮算法与编码面试。新年后还有两轮：一轮系统设计，一轮文化匹配（也就是行为测试）。 这是我第二次进入谷歌的终面（Final Rounds），也就是 Onsite Interviews。 谷歌终面：接近L5却被给L4，大饼画得响 面试结束后的第二周，我发了邮件询问结果，但没收到任何回复。又过了一周，还是毫无消息。我一度以为自己被拒绝了，甚至怀疑是不是发挥太差，谷歌连拒信都懒得发给我。 上周（面试后的第6周），突然就接到猎头的邮件，她说： I hope you’re keeping well! Apologies for my delay I’ve been unexpectedly out the office. Your feedback isn’t …

软件工程师都应该去面面顶级科技公司，不同公司的难度和录取率差异巨大。以下是对 Google、Microsoft、Meta、Amazon、Apple、TikTok（字节跳动）、Netflix 和 Jane Street 录取难度的分析，以及估算的 Offer 接受率。 大厂的福利较好，有份大厂的经历/经验在找下一份工作的时候会比较加分，毕竟大厂是Proven Record。 一般来说，微软/Microsoft是软件公司，但是微软也有Azure云。微软的挣钱项目比较多，不像谷歌苹果还有NetFlix比较单一。 公司 Offer 接受率 难度等级（1-10） 关键因素 平均薪资（总包） Google ~0.2% – 0.5%（1/200 – 1/500） 9.5 算法、系统设计、高文化门槛 $300K+（L4，美国） Microsoft ~1% – …

在系统设计面试中，可用性百分比是软件工程师应该熟悉的基本知识。 在系统可靠性领域（System Availability），99.9% 或 99.99% 之类的可用性百分比是关键的基准。但是这些数字究竟意味着什么？它们又如何转化为实际停机时间（Downtime）？以下介绍了如何计算与不同可用性水平相关的停机时间，并使用示例来说明 99.9%、99.99% 和其他可用性目标所带来的预期。 什么是可用性百分比？ 可用性百分比表示系统在给定时间段（通常是一年、一月或一天）内预计正常运行的时间比例。例如，99.9% 的可用性意味着系统在指定期间内可以停机 0.1% 的时间。 可用性百分比和停机时间 以下是根据不同时间段的可用性百分比计算停机时间的方法： 确定总时间周期：选择参考周期： 年：365 天，或 31,536,000 秒（365 天 × 24 小时 × 60 分钟 × 60 …

Google（谷歌）是全球知名的互联网巨头之一，几年前被认为是养老终级大厂，福利优厚，压力相对较小。在英国伦敦，Google设有一个主要从事开发和研究的办公室。 第一次面试 2016年 我在2016年首次面试Google。第一轮是电话面试，由一位在瑞士的工程师主导，通过电话交流并在Google Doc上同步编写代码。由于当时技术水平有限，我用C++完成了那道消息打印的题目，核心是使用队列和哈希表来解决问题，写得很磕磕巴巴。 当时对软件工程师的级别没有特别概念，推测自己面的是SWE L4/L5的级别，因为当时也就工作了5年多。 我查了一下邮件，2013年11月份的时候谷歌猎头联系我问我要不要试试？我说我当时没拿到英国永居，不想冒险，虽然他说到谷歌可以办工签，我当时还是没有选择去面试，现在想起来实在不可思议，后来2014年/2015年的时候同一个猎头还每隔6个月就check-in一次，最后面是在2016年4月份的时候才开始第一次的。 我要是当时聪明一些，努力刷题一些，搞不好当时进谷歌，现在也工作将近十年了，拿着谷歌股票到现在，也不至于现在混个高不成低不就的。 第二次面试 2020年 第二次面试是2020年11月份，第零轮其实应该算是Google的猎头问的一些选择题，比如C++里的哈希表/map如果访问一个不存在的键会发生什么？Google的软件工程师包括SRE站点可靠工程师在面试的时候都可以选两种路径，一个是数据结构和算法（编程），另一个是运维/DevOps偏LINUX知识的。我都选前者，毕竟这个我感觉只要短期刷题就好了，相反后者需要多年工作实战的积累。 通过了猎头的小测试，我进入了第一轮，是道编程题，但是并不是那种力扣上可以见到的，这一轮45分钟，给得是一个比较有意思的游戏，比如迷宫生成算法。面试的时候需要你主导整个过程，包括澄清问题，构思，写代码，分析复杂度等等，每一步都需要你Think Aloud。虽然这一轮我犯了些错误，但是给得反馈总题还不错，面试官说他觉得我应该进入下一轮。 到了终面，安排在了同一天，上午2轮，下午3轮，我记得3轮编程/Coding，一轮系统设计，一轮Culture Fit/Behavior/行为模式。除了系统设计是1小时，其它的4轮都是45分钟，谷歌的Coding面试45分钟都是解决1题即可，题目并不是力扣上的，题目范围/scope较大，偏难。一般来说coding完还会有一些Follow-up的问题，比如怎么优化算法。这个和Meta/Facebook的Coding面试不同，Meta百分百喜欢出力扣上原题，40分钟内需要解决2题力扣原题（留5分钟问问题），这个可以通过力扣按公司归类最近3/6个月的试题准备即可。 系统设计我记得是设计一个类似AWS S3的文件存储，也不知道是不是看我当时在AWS S3工作。很可惜，最后面这一轮不过关，当时我面的是L5（Senior），软件工程师级别越往上走，对系统设计的能力则要求越高（设计可扩展/分布式/高性能的系统 ）。 Unfortunately Google doesn’t disclose specific feedback per interview session …

在 Facebook/Meta 的软件工程师（包括站点可靠性工程师SRE和企业工程师EE）的面试中，产品设计/Product Design和系统设计/System Design起着比较相当重要的作用。 一般来说，编程面试（Coding Interviews)和行为规范面试（Behavior，考查是否和公司的文化价值观一致）是最基本的要求，而设计能力（系统设计或者产品设计）才是决定给你Offer的级别。 产品设计面试：Product Design Interview 目标：评估您创建以用户为中心的产品的能力，这些产品可以有效解决实际问题。 重点：您如何考虑用户需求、确定功能的优先级以及制定符合业务目标的解决方案。 典型问题 “您将如何设计一个允许用户管理其隐私设置的功能？” “为 Facebook 上的新用户设计入门体验。” 评估的技能 了解用户角色和痛点。 打造直观且可扩展的用户体验。 平衡用户需求与业务目标。 分析不同产品特性之间的权衡。 关键方法：CIRCLES 等框架（考虑用户、想象场景、需求、削减和确定优先级、列出解决方案、评估权衡、总结）。 系统设计面试：System Design Interview 目标：评估您构建可扩展、可靠且性能卓越的复杂的分布式系统的能力。 重点：如何设计技术后端和基础设施以支持高流量和强大的应用程序性能。 …

视频观看地址 同步到以下地址，还有微信视频号和小红书。 油管：Youtube B站：Bilibili 西瓜：Xigua 新挖一个坑，教媳妇系统设计，第1课讲的是数据分片/切片，也就是把数据按怎么样的方式存放到不同的服务器上。 随着数字化时代的快速发展，数据无疑成为了企业最宝贵的资源之一。然而，数据的快速增长也带来了存储和处理的挑战。在这个背景下，“数据分片（Data Sharding）”成为了解决大规模数据管理问题的关键技术之一。本文将深入探讨数据分片的不同类型和实现方法，并着重讨论水平分片和垂直分片的具体策略。 水平分片 (Horizontal Sharding) 水平分片是指将一个大表中的行分割成较小的片（Shards），每个片在物理上可以分布在不同的数据库服务器上。这种方法的主要优点是能够提高查询性能和可扩展性，因为操作可以在多个服务器上并行处理。水平分片可以根据不同的分片策略来实现，常见的有： 基于键的分片 (Key-based Sharding)：在这种策略中，数据根据分片键的值被分配到不同的片。分片键通常是数据表中的一个或多个字段，通过散列函数，可以将行均匀地分布到多个片中。这种方法的一个挑战是选择合适的散列函数，以避免数据热点问题。 基于范围的分片 (Range-based Sharding)：此方法按照指定范围将数据分配到不同的片中。例如，客户记录可以根据姓氏的字母顺序或客户ID的范围进行分片。虽然这种方法可以很容易地实现和理解，但如果数据分布不均，可能会导致某些片过大，影响系统性能。 基于字典的分片 (Dictionary-based Sharding)：在这种策略中，维护一个查找表或字典，指明哪些行属于哪个片。这种方法在数据分布不容易预测或经常变化的情况下特别有用，因为字典可以动态更新。但是，管理和更新字典可能会增加额外的复杂性和开销。 垂直分片 (Vertical Sharding) 垂直分片涉及将一个数据库表中的列分割开来，不同的列（通常是功能相关的列组）存储在不同的数据库或服务器上。这样不仅可以减少每次查询需要扫描的数据量，还能根据应用的需求优化数据的存储。垂直分片的主要挑战在于跨多个数据库或服务器的事务一致性和数据整合。 总结 数据分片是一种强大的技术，可以帮助企业有效管理大规模数据集。选择合适的分片策略需要综合考虑数据的特性、应用的需求以及系统的架构。通过合理的设计和实现，数据分片不仅能够提升系统的性能和可扩展性，还能确保数据管理的灵活性和高效性。在未来的数据驱动世界中，掌握和应用数据分片技术将变得越来越重要。 数据分片 (Data …