最新 | 最热门 | 最高评价

+0  常见分布式应用系统设计图解(十三):短网址系统

Tag: System and Architecture | 图解笔记 | 应用系统 | 短网址 | 系统设计
四火 发于 2020年12月29日 07:46 | 点击: 560 | 展开摘要
短网址系统可能是最常见的分布式系统设计问题之一了,本身从业务需求上说,读远多过写,而且数据结构确定且简单,数据量小,还易于使用缓存,因此本身难度在分布式系统的问题里面算是比较低的。另外,这个系统本身 “分布式” 的特性也比较弱,而且从组件图的角度来说,没有多少是 “可画的” ,因此之前也就没有介绍它。不过后来我改变想法了,我觉得还是可以总结总结,特别是可以把一些相关的特殊需求考虑进去。

短网址服务就像是 bit.ly 这样的,给一个长长的 URL,它给你吐出一个较短的 UR

查看全文: http://www.udpwork.com/item/17816.html

+0  常见分布式应用系统设计图解(十二):证券交易系统

Tag: System and Architecture | 交易系统 | 图解笔记 | 应用系统 | 系统设计 | 股票
四火 发于 2020年12月27日 02:09 | 点击: 653 | 展开摘要
这篇讲的是证券交易系统,这类系统包含的内容很多,但是我们还是把目光放在核心的交易部分,比如说股票交易。在某个可交易时间,如果卖家 A 要以至少 y 的价格卖掉股票 x,卖家 B 愿以至多 y 的价格买入股票 x,那么这个交易就可以发生。

虽说是交易系统,但是它和任何一个支付平台的交易系统有着显著的不同,它的核心是一个竞价匹配的机制,而非货币支付的机制,简单地说,这个机制包含了这样四个步骤:

挂单(可以是买单,也可以是卖单)
匹配(或者叫做撮合)
成交
清算

从非功能的角

查看全文: http://www.udpwork.com/item/17817.html

+0  常见分布式基础设施系统设计图解(七):分布式实时流处理系统

Tag: System and Architecture | streaming | 图解笔记 | 基础设施 | 实时 | 系统设计
四火 发于 2020年11月20日 07:11 | 点击: 522 | 展开摘要
今天这篇是关于实时流处理(real-time stream processing)的,这一类的系统这几年比较多了,但相对而言并没有之前提到的几类基础设施系统常见。为什么说这类系统如今更为常见呢?因为一般说来,或者说曾经有一个普遍的认知,就是 throughput 和 latency 难以兼得的事实:

同步系统适用于响应实时性要求高的请求,处理实时性要求高的数据,速度快,处理过程中关注的数据粒度小,吞吐量也相对受限;
异步系统适用于响应实时性要求低的请求,处理实时性要求低的数

查看全文: http://www.udpwork.com/item/17818.html

+0  常见分布式应用系统设计图解(十一):数据监控系统

Tag: System and Architecture | 图解笔记 | 应用系统 | 监控系统 | 系统设计
四火 发于 2020年11月18日 05:37 | 点击: 443 | 展开摘要
这篇是讲数据监控系统的,常见的包括 Datadog 和 Prometheus 等等。一个比较完整的数据监控系统要包括数据采集和数据展示两个部分。在此基础上,还可以具备告警和其它数据处理的功能。

对于监控的数据, 通常包括两类,一类是操作系统层面的数据,比如 CPU、内存、IO 等等;还有一类是应用相关的数据,这些数据就具备明确的业务意义了。

大体上,图中虚线表示控制流,而实现表示实际的统计数据流向。
用户通过 Web UI 来查看数据、定义规则,这些元信息存储在图中上方的

查看全文: http://www.udpwork.com/item/17819.html

+0  常见分布式应用系统设计图解(十):电商秒杀系统

Tag: System and Architecture | 图解笔记 | 应用系统 | 电商 | 秒杀 | 系统设计
四火 发于 2020年11月17日 03:11 | 点击: 455 | 展开摘要
这篇是关于电商平台秒杀系统的。

首先,我觉得 “秒杀” 是一个中国色彩浓重的词,这样的概念在西方电商系统中也有,但只有在中国,本来业务量就已经如此之巨大了,还将其如此发扬开来。因此顶尖的秒杀高并发场景,还真是基本上只有在中国的电商平台系统中,才能见得到。

其次,我觉得对于系统设计的学习,电商秒杀系统这样的极致,即便再精彩,还是应当放在第二位的。扎扎实实地把常规的高并发系统设计做好,才是最重要的。因为无论秒杀系统使用怎样的特殊技巧和手段,高并发分布式系统才是一个秒杀系统工作

查看全文: http://www.udpwork.com/item/17820.html

+0  常见分布式应用系统设计图解(九):协同编辑系统

Tag: System and Architecture | Google | 协作编辑 | 图解笔记 | 应用系统 | 系统设计
四火 发于 2020年11月13日 01:14 | 点击: 398 | 展开摘要
这里讲的 “协同编辑”,指的是 “Collaborative Editing”,多个人同时一起编辑同一个文件,比如说 Google Docs,国内的有有道云协作、石墨文档之类的。这样的系统倒不如我们前面提到的那些应用系统那么 “火”,但是,依然具备相当的典型性。

第一印象,这样的一个系统,我们可以简单做出如下归类:

这是一个文件编辑系统,这是最最基础的一个功能性需求,它就好像是 Windows 下的记事本,只不过它是在线的。
这是一个分布式系统,客户端/浏览器可以在不同的

查看全文: http://www.udpwork.com/item/17821.html

+0  常见分布式基础设施系统设计图解(六):分布式 MR 系统

Tag: System and Architecture | MapReduce | 图解笔记 | 基础设施 | 系统设计
四火 发于 2020年11月03日 02:17 | 点击: 428 | 展开摘要
其实对于 MR(Map Reduce)系统来说,可能更重要的是分治和分步处理的思想,因为现在的基于 MR 的数据处理框架或者平台,在实现上数据处理往往已经和最经典的对于 MR 的理解(最早应该是来自 Google 的那篇论文)有了不少区别。当然,我还是按照之前的做法,把一个典型的 MR 系统简单图示画出来了,这个图相对比较简单。

还是老规矩,虚线表示控制流,实线表示数据流。
上半部分用户向 Master 这个 job 管理节点提交一个 job 的请求,这个请求被拆解为若干个

查看全文: http://www.udpwork.com/item/17822.html

+0  几个系统设计问题的解决思路

Tag: System Design & Architecture | 系统设计
四火 发于 2017年10月31日 10:22 | 点击: 2295 | 展开摘要
曾经写过一些系统设计方面的思考(比如这个和这个),但是最近准备面试,又接触了更多系统设计方面的问题。这里我想简单记录一些典型系统设计问题的思路。通过学习常见的系统,在心中形成一些问题解决的套路,以在思考和分析新问题的时候提供一些既定思路。很抱歉时间关系写得很简略,主要是提示一些思路和方向。

设计Tweeter

两种常见模型的trade off:

Pull on demand: merge x timelines

Push on change: async, read

查看全文: http://www.udpwork.com/item/16482.html

+0  系统设计的典型分层和涉及的知识点

Tag: System Design | 分层 | 系统设计 | 面试
四火 发于 2015年08月10日 03:56 | 点击: 1790 | 展开摘要
作为系统设计学习的一部分,不久前在梳理面试中典型的系统设计问题,发现大部分都可谓有套路可寻。我把思路梳理了一下,简单整理到下面这张图表里面:

对于其中的内容,稍微补充几句:

系统设计需要经验的积累,但也确确实实有章可循。问的问题考察的类型很集中,比如同步、异步,消息push和pull,根据实际问题设计存储的数据结构,对于scalability、availability的认识等等。最喜欢被问到的问题,我在《系统设计典型问题的思考》这里列了几个。

pull on deman

查看全文: http://www.udpwork.com/item/14473.html

+0  系统设计典型问题的思考

Tag: System Design | 典型问题 | 系统设计
四火 发于 2015年03月15日 15:34 | 点击: 2483 | 展开摘要
系统设计方面的问题问题是非常考验经验和思维过程的,而且和常见的算法问题、语言基础问题不同,涉及的面很广,还没有比较一致的判别标准。但无论如何,还是可以归纳一些常见的思路和典型问题的线索。

首先,反复沟通和澄清系统需求。只有把需求澄清清楚了,才可以开始思考并落到纸面上。但是需求的沟通应该是持续和循序渐进的,问题很难从一开始就思考全面。最重要的条目包括:

use cases,通常问题只需要2~3个use cases需要考虑,其他的部分会晚些考虑,或者不考虑。这样就可以简化问题

查看全文: http://www.udpwork.com/item/13993.html

+0  留心那些潜在的系统设计问题

Tag: Architecture | Recommended | 系统设计 | 评审 | 问题
四火 发于 2013年09月19日 23:21 | 点击: 1643 | 展开摘要
文章系本人原创,转载请保持完整性并注明出自《四火的唠叨》

在系统设计阶段考虑全面很难,有许多人倾向于把整个设计分成若干阶段,在迭代中完成整个设计,这本身是非常好的,但是,就如同“先做出来,以后再优化”这样的经典谎言一样,本身并无错,只是许多程序员都不习惯于真正的迭代设计和迭代优化。举例来说,有一个日益复杂的类,每个人都修改一点点,一直到最后都没有人愿意去做重构,大家的心态都是一样的:“我只修改了一点点,为什么要我去动那么大的刀,于我没有任何好处”。我不在这里谈论这一问题的解

查看全文: http://www.udpwork.com/item/11018.html
|<<<1>>>| 一共1页, 11条记录