最新 | 最热门 | 最高评价

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

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

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

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

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

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

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

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

从非功能的角

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tag: System and Architecture | MapReduce | 图解笔记 | 基础设施 | 系统设计
四火 发于 2020年11月03日 02:17 | 点击: 356 | 展开摘要
其实对于 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 | 点击: 2247 | 展开摘要
曾经写过一些系统设计方面的思考(比如这个和这个),但是最近准备面试,又接触了更多系统设计方面的问题。这里我想简单记录一些典型系统设计问题的思路。通过学习常见的系统,在心中形成一些问题解决的套路,以在思考和分析新问题的时候提供一些既定思路。很抱歉时间关系写得很简略,主要是提示一些思路和方向。

设计Tweeter

两种常见模型的trade off:

Pull on demand: merge x timelines

Push on change: async, read

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

+0  工作流系统的设计

Tag: Recommended | System Design & Architecture | SWF | 工作流 | 设计
四火 发于 2016年08月19日 15:28 | 点击: 2729 | 展开摘要
几年前曾经写过一点点对于缓存框架设计的体会,这大半年和工作流系统打交道颇为丰富,因此想总结一点关于工作流系统的设计。

首先,明确工作流(workflow)系统的定义。维基百科上有极其简单的介绍。我记得以前在文章里面说过,作为大公司里面的小team,为了做一些有趣的东西,从而更好的招人,通常有几个众人皆知的突破口:比如一个更符合业务需求的storage,再比如一个自定义的工作流系统。在Amazon内部,我接触过好多个workflow,而且大多以Amazon SWF为原型(当时

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

+0  一种工作流心跳机制的设计

Tag: System Design & Architecture | EMR | SWF | 工作流 | 心跳
四火 发于 2016年04月28日 13:38 | 点击: 1665 | 展开摘要
最近工作中一直和SWF(Amazon的Simple Work Flow)打交道,在一个基于SWF的工作流框架上面开发和修bug。SWF的activity超时时间是5分钟,在activity task开始执行以后,activity worker需要主动发送心跳请求告知service端:“我还活着,我还在干活”,如果出现超过5分钟(可以配置)没有心跳,SWF的service端就认为,你已经挂了,我需要把这个activity安排到别的activity worker上来执行了。借用A

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

+0  Druid中国用户组第一次线下技术交流资料分享

Tag: 大数据 | Architecture | Big Data | Druid
Guancheng (G.C.) 发于 2016年03月29日 16:29 | 点击: 2673 | 展开摘要
Druid(http://www.druid.io)作为一个开源的大数据OLAP分析引擎,得到了越来越多的关注。在Druid co-founder Fangjin Yang的支持下,阿里,OneAPM,Hulu,小米,蚂蜂窝,滴滴,携程等公司的同学共同成立了Druid China User Group的微信群,并决定与2016年2月20日下午举办第一次线下技术交流,欢迎对大数据分析,Druid,OLAP引擎等话题感兴趣的同学参加。

PPT下载链接:http://pan.ba

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

+0  三次性能优化经历

Tag: System Design & Architecture | Portal | Service | Spark | 性能优化
四火 发于 2016年02月16日 14:22 | 点击: 2170 | 展开摘要
最近在做一些性能优化工作,回想起工作这些年来,参与过的三次集中性能优化,每次都得折腾少则一个月,多则半年。这些内容既是不同视角、不同思路的比较,也是挺有趣的工作经历。

Portal的性能优化

这已经是大概五年前了,搞了接近半年的Portal性能优化,后来某些内容总结在这篇文章里面。既然是Portal,性能优化上就有它的特点。比如说:

Portal的性能优化需要从前端和后端两个角度去思考问题,先考虑客户端和服务端之间的交互模型,然后再在客户端和服务端单独考虑分而治之。这个

查看全文: http://www.udpwork.com/item/15213.html
|<<<1234>>>| 一共4页, 40条记录