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

曾经写过一些系统设计方面的思考(比如 这个这个),但是最近准备面试,又接触了更多系统设计方面的问题。这里我想简单记录一些典型系统设计问题的思路。通过学习常见的系统,在心中形成一些问题解决的套路,以在思考和分析新问题的时候提供一些既定思路。很抱歉时间关系写得很简略,主要是提示一些思路和方向。

设计 Tweeter
两种常见模型的 trade off:

  • Pull on demand: merge x timelines
  • Push on change: async, read once to get them

缓存的设计,cache through

设计 Web crawl[……] 阅读全文

工作流系统的设计

workflow

几年前曾经写过一点点对于 缓存框架设计 的体会,这大半年和工作流系统打交道颇为丰富,因此想总结一点关于工作流系统的设计。

首先,明确工作流(workflow)系统的定义。 维基百科 上有极其简单的介绍。我记得以前在文章里面说过,作为大公司里面的小 team,为了做一些有趣的东西,从而更好的招人,通常有几个众人皆知的突破口:比如一个更符合业务需求的 storage,再比如一个自定义的工作流系统。在 Amazon 内部,我接触过好多个 workflow,而且大多以 Amazon SWF 为原型(当时学习的时候还写了一点体会,link 1link 2),于是宏观上看,60% 的东西是一样的,大同小异;但是也有很多重

[……]阅读全文

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

最近工作中一直和 SWF(Amazon 的 Simple Work Flow)打交道,在一个基于 SWF 的工作流框架上面开发和修 bug。SWF 的 activity 超时时间是 5 分钟,在 activity task 开始执行以后,activity worker 需要 主动发送心跳请求 告知 service 端:“我还活着,我还在干活”,如果出现超过 5 分钟(可以 配置)没有心跳,SWF 的 service 端就认为,你已经挂了,我需要把这个 activity 安排到别的 activity worker 上来执行了。借用 AWS 官网 的一张图:

heartbeat

每台机器上有若干个 activity task 在被执行。可以看到,在 activity 任务启动起来以后

[……]阅读全文

三次性能优化经历

performance

最近在做一些性能优化工作,回想起工作这些年来,参与过的三次集中性能优化,每次都得折腾少则一个月,多则半年。这些内容既是不同视角、不同思路的比较,也是挺有趣的工作经历。

Portal 的性能优化

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

Portal 的性能优化需要从前端和后端两个角度去思考问题,先考虑客户端和服务端之间的交互模型,然后再在客户端和服务端单独考虑分而治之。这个其实和设计的思路是一样的,交互问题需要首先考虑,定义好交互的报文形式(比如某 JSON 的具体形式)以后,包括用户触发什么行为引

[……]阅读全文

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

作为系统设计学习的一部分,不久前在梳理面试中典型的系统设计问题,发现大部分都可谓有套路可寻。我把思路梳理了一下,简单整理到下面这张图表里面:

System Design Layers

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

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

[……]阅读全文

读写模型整理笔记

读模型

1、主键读

最常见的读模型,说是主键,其实也包括其它索引键,或者联合主键。

常见实现:hash,时间复杂度可以接近 O(1);B 树或变种:时间复杂度接近 O(log(n))。

关于 B 树和变种:

B 树(B-树):本质上是二叉查找树的升级版,变成了平衡的 N 叉查找树,这个 N 的范围根据磁盘一次读取的块大小来调整,这样复杂度 log n 的底数就从 2 变成一个更大的数,减少了树的高度。除此以外,还有一些额外的优化,比如为了插入和删除的性能考虑,通常准备一些预留的空间,只要在当前块或者邻近块中找到空间写入,就避免了开销巨大的所有记录向后偏移的操作。

B 树的阶:

  1. 一棵 m 阶的 B 树最多有 m 棵子树;
  2. 根节点至少有

[……]阅读全文

系统设计典型问题的思考

CAP 系统设计方面的问题问题是非常考验经验和思维过程的,而且和常见的算法问题、语言基础问题不同,涉及的面很广,还没有比较一致的判别标准。但无论如何,还是可以归纳一些常见的思路和典型问题的线索。

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

  • use cases,通常问题只需要 2~3 个 use cases 需要考虑,其他的部分会晚些考虑,或者不考虑。这样就可以简化问题。
  • 用户数量(用户可以是下游系统或者人)、数据数量,澄清这个事实无疑非常重要,对系统设计的决策有重大意义。
  • 请求模型,

[……]阅读全文

程序的库设计

think 最近在 Stack Exchange 上面看到一个帖子,是问程序库设计的指导原则的,“What guidelines should I follow while designing a library?”,有趣的是,很多人都在谈论面向设计,各路 API 设计,还有程序语言设计,唯独搜索“程序库设计”,无论中文还是英文,Google 还是百度都找不到太多内容。但是我想,没有程序员会否认库设计的重要性吧,我想在这里结合这个帖子谈谈我的想法。

在这个帖子里面,votes 最高的回答,提到了这样几类 tips,我在下面简要叙述一下,其中基础的部分包括:

  • Pin Map,明确你期望库主要用来做什么,但不要把它定得

[……]阅读全文

实际技术选型的考虑因素

tech

最近在工作中我需要把数据从公共的 Data Warehouse(数据仓库)导出来,放到属于我们 team 自己账号的云端存储资源中去,然后再在我们的应用中查询这样的资源。需要导出数据是因为直接从 Data Warehouse 查询数据是一个缓慢而且异步的过程,而我们的应用数据查询需要实时性。现在要解决这个问题有一些 AWS 的服务可供我们可以选择,基本上分成了两大类:

第一类是存储和内容分发(Storage & Content Delivery):

  • CloudFront:CloudFront 是用于内容分发给不同地区用户的,它在全球设有数个“edge”,作为临近网络访问数据的入口。就如同大网站建立

[……]阅读全文

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

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

再做系统设计的时候,我们常常会这样说:“一般

[……]阅读全文

用户积分功能的设计

image 有一个 SNS 应用,用户在使用的过程中积累积分,例如登陆+3 点,个人空间每次浏览+1 点,结交每个朋友+5 点等等。同时,很重要的一点是,用户需要看到自己的积分累计有多少,能够根据积分划分用户等级,在自己的空间展示积分。

在用户量比较大的情况下(例如超过三千万),这是一个比较典型的读写都很频繁的问题,而且写入的次数可能和读取的次数差别不大(大多数 SNS 应用中,读次数远超写次数的场景居多,例如用户的状态信息,更新一次以后有成千上万的访问)。

这实际是一个简单,但是典型的功能。试想,给文章投票(例如“顶”一下),给微博统计访问次数,给媒体打分……这些都是非常类似的功能。对于这样问题的思考和设计,考虑到

[……]阅读全文

MVC 框架的映射和解耦

mvc 最近在写一个业务上用到的框架,回想起接触过的一些 MVC 框架,尤其是主要贡献在后端表现层上的那些,它们之间有太多的相似,在不断解耦的过程中,层数和模块数也越来越多,需要不断引入层与层之间的映射逻辑将不同层次之间关联起来,我们不妨来查看一下这个过程,能否寻找一些 MVC 框架的共性和启示。

MVC 1 到 MVC 2 模型的进化

这个话题有点老。MVC 1 在桌面程序中应用较多,业务逻辑当然放在 Model 里面,Controller 负责将用户的请求数据传递到 Model 去,之后就放手不管了,让 View 通过观察者模式不断获知 Model 的最新变化(可以是 Model 变化后通知 View,也可以是 View 自己来获取)。这

[……]阅读全文

DAO 的演进

1 这个思考源于最近项目中对 DAO 的使用和讨论。数据访问对象,在贫血模型下,要怎样去设计,框架需要完成什么,后续的开发人员需要关注什么,设计的时候到底需要把握怎样的粒度?

最早做项目的时候,是老老实实给每个必要的模型增加 DAO 接口和实现类的:

public interface IUserDAO{
    public long add(User user);
    public void delete(User user);
    public int count(String condition);
    ... ...
}
public class UserDAOImp

[……]阅读全文

网站性能优化的三重境界

hold

这篇文章是关于网站性能优化体验的,性能优化是一个复杂的话题,牵涉的东西非常多,我只是按照我的理解列出了性能优化整个过程中需要考虑的种种因素。点到为止,包含的内容以浅显的介绍为主,如果你有见解能告知我那再好不过了。无论如何,希望阅读它的你有所收获。

 

我眼中的网站性能问题都反映了一个网站的“Availability”(中文叫做可用性,但是这个翻译也不足够达意),以往我的认识是,这个网站如果全部或者部分不可用,那是功能问题,但是如果响应慢、负载差,这才是性能问题;可是后来我逐渐意识到,性能问题涵盖的范围更广,我还没法给出一个准确定义,但是 许多非业务逻辑

[……]阅读全文

大型互联网应用的技术选型和决策,10 条成功与失败的记录

internet 作为以老版本为模子重做的解耦版本,这个大型互联网应用产品是从 2009 年中开始落地的。而我本人也是该版本的主创人员之一,到今日,团队已经发展到开发测试人数百人的大型互联网产品团队的规模,发布、割接和上线了许许多多个商用版本。

 

对架构的审视,对选型和设计的反思,不仅仅要在产品初创时期,更要在产品发展的整个过程中进行,团队做同类型产品的能力就是这样在不断总结和自我批评中成熟的。以下为个人观点,难免不对许多人的胃口,不过还是希望这些文字有足够到让人思考的价值。无论如何,对于这样一款产品,从如今的视角来解读它的历史故事,更别有一番风味。

 

—————–

[……]阅读全文

设计缓存框架需要关注的要素

1 最近关注了一些缓存框架的特性和实现,包括 OSCache、JCS、Ehcache、Memcached 等等,公司的两个缓存框架,以及一个标准 JSR 107(JCache),发现一些诸多类同的方面。如果你不够熟悉以上,不妨先看看这两篇文章:OSCache框架源码解析 》和《Ehcache详细解读 》,再看下面的内容也许会有更多想法 。之后再思考,如果要自己去实现一套缓存框架,需要考虑哪些东西?

1、为哪些数据做缓存?

  1. 模型对象,这在业务逻辑层面最常见。
  2. 数据库查询结果集。
  3. 页面缓存、页面片段缓存。
  4. 运算结果集,尤其对于幂等性服务。
  5. 外部接口查询结果。

 

2、缓存框架的核心:

&nb

[……]阅读全文

你会怎样设计铁道部购票网站?

1 最近铁道部购票已经成为了热点话题,毛病多得一塌糊涂,如果让你来设计铁道部购票网站,你会怎么做?

 

这样的网站属于实时性要求较高、并发性要求非常高、容量要求一般的类型,以下是我简单的想法:

 

1、部署是基于 CDN 的,对于车票查询的环节来说,这是没有问题的。

 

2、数据库表设计上面,应当有一张车次表,每行代表一趟车,至少有这样的字段:还剩多少张,已被锁定多少张。

 

3、每次发生订票操作时,先去查询当前是否有余票,有的话锁定一张等待用户操作,如果半小时内无法完成,锁定票放回。

 

4、查询部分,集群中放置分布式缓存,存放数据的静态页面,但由

[……]阅读全文

Flash Scope

项目中遇到了一个潜在的问题,大致就是说,在一个流程的两个或某几个环节中,需要短暂地存储一部分对象(如果不存储,就需要在这几个环节中多次调用同一个外部接口,这被认为是不够合理的实现)。

而这部分对象的存储:

(1)如果用 request,太小,毕竟一次提交以后就丢失了,如果需要往后传递,可能需要借助一些页面参数传值等丑陋或是不易控制的方法;

(2)如果用 session,太大,我不需要在整个用户会话生命周期内使用,而且如果同个用户并行地操作两个流程,期间会互相影响到。

其实在 Rails/Grails 里面就已经包含了一个机制,它将对象短暂地放置在 session 中,request-response 连续的

[……]阅读全文

说说 JavaEye 网站架构

image 偶然看到了 Robbin 的一则胶片 《JavaEye 网站架构解密》,说到了一些 JavaEye 的一些实现,那就来看看有哪些有意思的东西。

我正在参与做的一个项目,在某某地方上线,需要几十块单板集群;在某某地方上线,又需要怎样的一个集群组网。咋听起来兴许觉得能有怎样的业务逻辑处理和怎样的用户量呢?可是 JavaEye 让我很吃惊,我先前只知道与 CSDN 比起来,JavaEye 确实是一个小规模一些的网站,专业一些的网站,可是服务器呢?只有两台!

这是那台 Web Server:

• AMD Opteron 2.4GHz 单核 * 2 颗
• 8G 内存
• 146G S

[……]阅读全文

back to top