Category: 系统设计
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 个汉字, 你数一下对不对. …
在系统设计面试中，可用性百分比是软件工程师应该熟悉的基本知识。 在系统可靠性领域（System Availability），99.9% 或 99.99% 之类的可用性百分比是关键的基准。但是这些数字究竟意味着什么？它们又如何转化为实际停机时间（Downtime）？以下介绍了如何计算与不同可用性水平相关的停机时间，并使用示例来说明 99.9%、99.99% 和其他可用性目标所带来的预期。 什么是可用性百分比？ 可用性百分比表示系统在给定时间段（通常是一年、一月或一天）内预计正常运行的时间比例。例如，99.9% 的可用性意味着系统在指定期间内可以停机 0.1% 的时间。 可用性百分比和停机时间 以下是根据不同时间段的可用性百分比计算停机时间的方法： 确定总时间周期：选择参考周期： 年：365 天，或 31,536,000 秒（365 天 × 24 小时 × 60 分钟 × 60 …
在 Facebook/Meta 的软件工程师（包括站点可靠性工程师SRE和企业工程师EE）的面试中，产品设计/Product Design和系统设计/System Design起着比较相当重要的作用。 一般来说，编程面试（Coding Interviews)和行为规范面试（Behavior，考查是否和公司的文化价值观一致）是最基本的要求，而设计能力（系统设计或者产品设计）才是决定给你Offer的级别。 产品设计面试：Product Design Interview 目标：评估您创建以用户为中心的产品的能力，这些产品可以有效解决实际问题。 重点：您如何考虑用户需求、确定功能的优先级以及制定符合业务目标的解决方案。 典型问题 “您将如何设计一个允许用户管理其隐私设置的功能？” “为 Facebook 上的新用户设计入门体验。” 评估的技能 了解用户角色和痛点。 打造直观且可扩展的用户体验。 平衡用户需求与业务目标。 分析不同产品特性之间的权衡。 关键方法：CIRCLES 等框架（考虑用户、想象场景、需求、削减和确定优先级、列出解决方案、评估权衡、总结）。 系统设计面试：System Design Interview 目标：评估您构建可扩展、可靠且性能卓越的复杂的分布式系统的能力。 重点：如何设计技术后端和基础设施以支持高流量和强大的应用程序性能。 …
许多大型科技公司（如 FANG：Facebook/Meta、Apple、Netflix、Google）以及微软等，在发出工作邀请之前，通常会进行多轮面试。这些面试通常包括编程/Coding、系统设计/System Design和行为评估/Behaviour，以考察文化契合度。 我提供 45 分钟的模拟面试，帮助您准备编码和系统设计环节。作为曾在亚马逊（AWS，S3 Object Lambda）担任面试官的我，将通过真实的练习环节为您提供指导。在编码模拟面试中，您将解决一到两个编程问题；而在系统设计模拟面试中，您需要在白板上设计一个可扩展的产品。 此外，我还提供 45 分钟的聊天时间，可以讨论任何话题，包括职业发展和建议。 我目前定价 60 英镑一小时，会员价是 55 英镑，毕竟时间就是金钱。而这也大概和我的时薪差不多。 如果您有兴趣，请点击此处。 PS：我发现 Buy Me a Coffee 这个创业点子很好，赞赏+集成了网上商店，很是方便，界面也很友好，感兴趣的可以通过这个链接来创建一个专属于你的页面，在为用户创作内容的同时也能很快捷的收到赞赏！ 英文：45 Minute Mock Interview (Coding, System …
视频观看地址 同步到以下地址，还有微信视频号和小红书。 油管：Youtube B站：Bilibili 西瓜：Xigua 新挖一个坑，教媳妇系统设计，第1课讲的是数据分片/切片，也就是把数据按怎么样的方式存放到不同的服务器上。 随着数字化时代的快速发展，数据无疑成为了企业最宝贵的资源之一。然而，数据的快速增长也带来了存储和处理的挑战。在这个背景下，“数据分片（Data Sharding）”成为了解决大规模数据管理问题的关键技术之一。本文将深入探讨数据分片的不同类型和实现方法，并着重讨论水平分片和垂直分片的具体策略。 水平分片 (Horizontal Sharding) 水平分片是指将一个大表中的行分割成较小的片（Shards），每个片在物理上可以分布在不同的数据库服务器上。这种方法的主要优点是能够提高查询性能和可扩展性，因为操作可以在多个服务器上并行处理。水平分片可以根据不同的分片策略来实现，常见的有： 基于键的分片 (Key-based Sharding)：在这种策略中，数据根据分片键的值被分配到不同的片。分片键通常是数据表中的一个或多个字段，通过散列函数，可以将行均匀地分布到多个片中。这种方法的一个挑战是选择合适的散列函数，以避免数据热点问题。 基于范围的分片 (Range-based Sharding)：此方法按照指定范围将数据分配到不同的片中。例如，客户记录可以根据姓氏的字母顺序或客户ID的范围进行分片。虽然这种方法可以很容易地实现和理解，但如果数据分布不均，可能会导致某些片过大，影响系统性能。 基于字典的分片 (Dictionary-based Sharding)：在这种策略中，维护一个查找表或字典，指明哪些行属于哪个片。这种方法在数据分布不容易预测或经常变化的情况下特别有用，因为字典可以动态更新。但是，管理和更新字典可能会增加额外的复杂性和开销。 垂直分片 (Vertical Sharding) 垂直分片涉及将一个数据库表中的列分割开来，不同的列（通常是功能相关的列组）存储在不同的数据库或服务器上。这样不仅可以减少每次查询需要扫描的数据量，还能根据应用的需求优化数据的存储。垂直分片的主要挑战在于跨多个数据库或服务器的事务一致性和数据整合。 总结 数据分片是一种强大的技术，可以帮助企业有效管理大规模数据集。选择合适的分片策略需要综合考虑数据的特性、应用的需求以及系统的架构。通过合理的设计和实现，数据分片不仅能够提升系统的性能和可扩展性，还能确保数据管理的灵活性和高效性。在未来的数据驱动世界中，掌握和应用数据分片技术将变得越来越重要。 数据分片 (Data …
我在STEEM区块链上部署了ChatGPT机器人：系统设计: Steem区块链ChatGPT机器人，这个系统设计同时还跑了其它类型的机器人，原理就有一个读进程监听链上的操作，发现是相关的操作就把数据写到数据库中，然后由相关机器人的进程(比如ChatGPT)把数据再取出来，进行处理，然后再相应的写到数据库中的另一个表中。这里的数据库就类似中消息中间件 Message Queue，用来解耦不同的组件。 单点故障 Single Point of Failure，指得是系统中的一些零件如果损坏不能用了，整个系统也就变得不能用了。这里的读取进程就是单点故障，因为如果该进程崩溃了，再重新启用的时候也无法回溯过去区块链上的信息，这个进程实时监听链上的操作，如果错过了就是错过了。而这个系统设计其它的零件则没有这个问题，毕竟是处理数据库中的数据，进程崩溃会被自动重启，然后继续处理数据库中未被处理完的数据。 解决这个问题也不难，只要在不同的服务器上多跑几个读进程即可。不过这里需要保证数据库表里有唯一的限制，这样多台服务器在同时往同一数据库表格写数据的话只会有一条成功，而其它则会失败。 下面SQL给表格加个唯一的限制： alter table blockchain add unique key (block, ...); 英文：Avoid Single Point of Failures by Introducing Multiple Master Backup …
前几天, 把ChatGPT整合到了STEEM区块链上, 但最初的设计存在缺陷. 我发现其它机器人命令(!bing, !thumbup, !price, !info) 同样也有问题, 所以就借此机会重新设计重构了一下代码和结构. 这个DApps (ChatGPT机器人) 是使用JS (Node)编写的, 并由pm2管理器托管运行在一台云服务器上(VPS Server). STEEM区块链ChatGPT DApps设计缺陷 原先的设计: 进程(Blockchain)监听STEEM区块链上所有的帖子, 把满足条件的评论(含有 !ask 命令)的操作入数据库. 进程(ask) 或其他命令从MySQL中获取相应的记录, 并立即处理它们, 然后在同一进程中同步地发布到STEEM区块链. 这里会有一个问题, 确实来说, 大量并发会有问题. …
