系统设计典型问题的思考

标签: Architecture 典型问题 系统设计 | 发表时间:2015-03-15 15:34 | 作者:四火
出处:http://www.raychase.net

系统设计典型问题的思考 最近我老婆在找工作,于是我也一起学习了一些系统设计的知识,这里总结典型的思路和题目。

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

其次,尝试抽象一个简单的模型,从简单模型开始,思考不同的场景和约束,逐步完善。落实到代码上的时候,接口定义大于一切。考虑最基础的组件和架构划分,比如:

  • 存储层。是否需要持久化存储?选择文件、关系数据库,还是NoSQL数据库?
  • 如果选择关系数据库,是否需要sharding或partition?参考Quora: What’s the difference between sharding and partition?
  • 如果选择NoSQL数据库,CAP中分别牺牲和优先保证哪一个?参考: Visual Guide to NoSQL System。扩容的策略(比如一致性hash)?
  • 存储是否需要分层(比如冷层——文件、暖层——关系型数据库、热层——缓存,不同成本的存储介质,用以应付不同的数据访问频率)?
  • 集群。所有节点对等还是中心节点主备?请求负载分担的策略?如何增减节点?如何判定节点健康状况?是否需要会话?会话如何同步?Scale up和Scale out的区别,参考Wikipedia: Scalability
  • 消息模型。生产者和消费者的速率?无法应付时是否需要缓冲队列?消息流量控制?速率控制的精细度?
  • 缓存系统。缓存的分层?分布式部署还是集中式缓存服务?使用什么缓存淘汰算法(比如LRU)?参考: In-Process Caching vs. Distributed Caching
  • 再次,不断讨论和完善,每一个讨论迭代都要得出一个实际的结论,避免持续停留在过高抽象层面。这里涉及的部分可以很多,包括可扩展性、数据规模、吞吐量、可维护性、实时性、数据一致性等等。

    这些点说起来容易做起来难,通过反复阅读和思考一些常见的系统设计场景,其实我们还是可以从中总结出若干规律来。

    下面列出几个非常常见和典型的系统设计问题的思路:

    1、怎样设计一个微博/Twitter系统(news feed系统)

    • 思考读写模型,latency上看明显是读的要求明显高于写的模式。
    • 转发和回复,拷贝原微博文字还是存储转发/回复树形关系?分析利弊。另外,这里涉及到产品设计,参见: Twitter Vs. Weibo: 8 Things Twitter Can Learn From The Latter
    • 区分两种典型场景:push on change和pull on demand,两种方式利弊明显。参考: Why Are Facebook, Digg, And Twitter So Hard To Scale?
    • 存储分级。这里CAP中A最为重要,往往C可以被牺牲,达到最终一致性。
    • 缓存设计,分层的数据流动?如何识别热门?
    • 删除微博功能的设计。

    2、怎样设计一个短网址映射系统(tiny url系统)

    • 思考读写模型,明显是读优先级高于写的服务,但是通常不需要修改。读写服务分离,在写服务崩溃时保证读服务健康运行。
    • 链接缩短使用的加密和映射的方式中,算法如何选择?短链接可以接受那些字符?此处可以估算特定的规则下长度为n的短链接最多可能表示多少种实际链接。
    • 如果使用统一的短链接序列分配机制,如何分布式设计这个分配逻辑?它不能够成为瓶颈。例如,一种常见的思路是让关系数据库的自增长索引给出唯一id,但是如果不使用关系数据库,在分布式系统中如何产生唯一序列号且避免冲突?参考: 如何在高并发分布式系统中生成全局唯一Id
    • 是否需要保留原始链接最后部分?如http://abc.def.com/p/124/article/12306.html压缩成http://short.url/asdfasdf/12306.html,以增加可读性。
    • 由于协议部分可以预见或者需要支持的数量很少(比如就支持http和https),是否可以考虑把协议部分略去,以枚举方式和短链接正文放在一起?
    • 由于属于web服务,考虑判定URL合法性,考虑怎样控制请求流量和应对恶意访问。

    还有一些系统设计典型和经典问题,想到的先列在下面,等后续有时间总结了再补充到上面去:

    • 搜索引擎设计(包括网页爬虫)
    • 邮件系统设计(例如GMail)
    • 聊天系统

    无论如何,对于这些问题的解决,思考是最有趣的环节。这些东西貌似可以直接拿来学习的材料比较少,而且也不像算法那样丁是丁卯是卯的,评判的标准模糊得很。

    文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

    分享到:

    相关 [系统 设计 典型] 推荐:

    系统设计典型问题的思考

    - - 四火的唠叨
    最近我老婆在找工作,于是我也一起学习了一些系统设计的知识,这里总结典型的思路和题目. 首先,反复沟通和澄清系统需求. 只有把需求澄清清楚了,才可以开始思考并落到纸面上. 但是需求的沟通应该是持续和循序渐进的,问题很难从一开始就思考全面. 其次,尝试抽象一个简单的模型,从简单模型开始,思考不同的场景和约束,逐步完善.

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

    - - 四火的唠叨
    作为系统设计学习的一部分,不久前在梳理面试中典型的系统设计问题,发现大部分都可谓有套路可寻. 我把思路梳理了一下,简单整理到下面这张图表里面:. 对于其中的内容,稍微补充几句:. 系统设计需要经验的积累,但也确确实实有章可循. 问的问题考察的类型很集中,比如同步、异步,消息push和pull,根据实际问题设计存储的数据结构,对于scalability、availability的认识等等.

    评价系统设计篇

    - - 互联网 - ITeye博客
    评论系统大家都见得非常多了,大到京东、淘宝、亚马逊,小到个人网站、博客都有评论系统,小型网站采用传统PHP+Mysql方式就能很快将系统搭建起来,同时采用单库单表方式就能轻松解决数据存储、数据查询等问题,但是对于上述中大型网站而言,已经远远不能支撑系统正常运行了. 接下来将从系统架构、数据存储、高性能服务等方面来揭示京东的评价系统在面对海量数据、海量请求的情况是如何处理的.

    网页扁平化设计的五个最典型的特征

    - - 飞鱼的声纳
    如今设计界最炙手可热的明星大概就是扁平化设计了吧,关于它的讨论至今都没有冷却的迹象. 诸多设计师分成了泾渭分明的两个阵营,一边努力把扁平化做到极致,一面对其不屑一顾. 我是个骑墙派,不支持也不反对,在我看来,优秀的设计的定义就是好用,只要能设计出优秀的产品,我可以采用任何方式,扁平化也是其中之一. 但是必须意识到,没有哪种风格是包打天下的,不能强行将一种风格应用到不该用的地方.

    思考系统API设计的问题

    - edware_love - C++博客-首页原创精华区
    最近正好在思考系统API设计中考量的一些问题,. 我现在的理解是这样的,假设有巨大的真实内存. windows首先将高2G的内存自己占了,用作各种内核对象. 这2G内存共享给每个进程,但进程不能直接访问,只能通过windows给定的函数访问. : 然后每个进程都给他2G内存,进程如果创建自己的对象就放到自己那2G内存里面,如果要建立内核对象就放到共享的那高2G里面去.

    系统设计中的简单法则

    - - 酷勤网-挖经验 [expanded by feedex.net]
    最近,包云岗在自己的 博客中总结了系统设计中的基本法则——简单之美,列举了不少经典观点和案例. 他首先总结了麻省理工方法(MIT Approach)和新泽西方法(New Jersey Approach)的异同:. 简单性:两种方法都强调设计必须简单,这既是对实现的要求,也是对接口的要求. 但是,MIT方法认为接口的简单要比实现的简单更加重要,而NJ方法认为实现的简单要比接口的简单更加重要.

    财务系统设计的思考

    - - 行业应用 - ITeye博客
    说到财务系统的设计,就不由得联想到了目前很流行的一个职业“互联网产品经理”,他们的设计着眼于用户体验,创造出新的功能,改善着上亿网民的生活,比如扫一扫,摇一摇等. 财务系统不同于互联网的产品,它的复杂性对于没有深入了解它的人来说,是不太能想象出来的. 互联网的功能开发,讲究的是时效,从一个点子,到产品发布可能只用一周的时间,然后如果市场冷淡,可能第三周就下线了.

    12306订票系统设计关键点

    - - 互联网旁观者
    12306全国火车票网上售票网站的情况大家都见到了,如果让你来设计该订票网站,你会如何设计才能应对如此大规模以及高并发的情况呢. 以下是百度前技术总监邵辉给出的设计:. 列车在线订票系统的业务逻辑比较简单,不用多说. 可能的瓶颈有两个,一个是车次和剩余票量的查询,一个是下单. 在设计软件架构之前,需要先研究产品需求、软硬件条件、网络环境以及关联系统的接口,但这些资料无从获得,所以只能做几点分析和假设,做为设计的前提条件.

    网购秒杀系统架构设计

    - - 企业架构 - ITeye博客
    秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必须会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪. 用户在秒杀开始前,通过不停刷新浏览器页面以保证不会错过秒杀,这些请求如果按照一般的网站应用架构,访问应用服务器、连接数据库,会对应用服务器和数据库服务器造成极大的负载压力.

    秒杀系统设计的知识点

    - - 互联网 - ITeye博客
    A, 高并发,cache,锁机制 . B, 基于缓存架构redis,Memcached的先进先出队列. C, 稍微大一点的秒杀,肯定是分布式的集群的,并发来自于多个节点的JVM,synchronized所有在JVM上加锁是不行了. F, 如何防止用户来刷, 黑名单. G, 利用memcached的带原子性特性的操作做并发控制. .