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

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

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

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

缓存的设计,cache through

设计Web crawler
分布式queue,用来存放不断更新的需要爬虫完成的任务,典型的N个生产者+M个消费者的模型
key value storage,用来存储已经完成的网页,爬下来的数据放在S3上
Quota的使用:用来避免对某一个网站分配过多的资源

设计Type Ahead
核心在于避免从磁盘中实时查询,所有查询必须最快命中内存中的数据结构,并且查询的效率必须是O(1)的
采用Trie树,并且每个节点都要有指向结果集的链接
这样的数据结构的生成和更新必须在一开始就初始化完成

设计邮件系统
核心在于存储层schema的设计,user id作为range key,email id作为primary key,邮件的时间列索引化,以便查询某人最近的邮件
读写分离,收取邮件和发送邮件的服务分开

设计图片上传和访问系统
核心在于CDN的使用,要把静态资源的读取推送到离用户近的节点去。
处理在用户上传图片后,CDN数据还没有最新数据的情况(数据不一致的问题)

设计图像转换服务
典型异步系统的设计:

  • 一个分布式queue存放异步任务,
  • 另一个key-value storage存放任务状态,用来供另外的系统查询任务状态

两个API设计:上传图像后返回上传成功和任务ID;查询当前任务状态
另外可以考虑Lambda这种serverless的方式

设计分布式文件系统
核心在于怎么存放文件的meta data和实际的data从而分担读写压力,怎么处理文件的更新和删除
比如master上存放粗略的meta data,知道文件的分片在哪个slave服务器上,slave上存放分片具体信息,client读写仅仅通过master定位到slave,余下的工作不通过master完成,以避免master成为瓶颈
chunk和checksum的设计和使用

设计Tiny URL服务
schema的设计,需要解决两个问题:short URL -> long URL(最多被使用)和 long URL -> short URL
short URL的生成,几种方法在分布式系统中生成唯一ID
读基于缓存的优化

设计流量限制系统

  • 思路1:Cache TTL on bucket level
  • 思路2:Leaky Bucket / Token Bucket

设计Metrics系统
Ring Buffer,根据不同的统计粒度,设定不同的bucket size
根据不同的统计粒度,建立不同的表来持久化和供未来查询
读写模型:写多读少,汇总增量数据后再更新的优化

设计打车系统
核心在于司机和乘客怎样更新地理位置信息,系统怎样存储地理位置信息,已经怎样为乘客寻找最近的司机(geo hash)
读写模型:写多读少,怎样优化系统来应付这种状况,一致性的牺牲

设计即时聊天系统
引入Channel Service,socket push的使用
存储:解耦成消息表和会话表,使得用户可以单独设定每个会话的属性引入Channel Service
用户在线状态的维护:heartbeat

设计联机日志服务
持久化问题,日志client和日志service,减少单点故障造成的日志丢失
尽可能不影响现有业务应用,线程必须独立
引入队列,对于大量日志写入的缓冲
在网络不可用时,日志客户端可以写入本地文件,网络恢复后可以上传本地文件

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

分享到:

发表评论

电子邮件地址不会被公开。

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Preview on Feedage: