GeekBand C++ Week12 Notes

2016-08-02  本文已影响0人  古来征战几人回

系统设计与实践

系统设计介绍

短URL设计

设计一个系统把用户提供的URL转换为短的URL,访问的时候要跳回到原始的URL,在系统设计的面试里,如何评价一个系统设计,一分到四分

第一级:

设计一个数据库来映射关系,从短URL到原始的URL。

有哪些不好的地方?

从原始的URL返回一个5位的编码,不是五位的用0补充。

能不能扩充,返回的ID为什么都是0到9?

在Cache里面搜索,Read/Write rate LRU和LFU

第二级:

Key-Value DB

MySQL is slow

Key-Value模型做了很多简化,提升了性能,是MySQL的10倍以上

有没有其他办法产生呢?

URL->md5(128bits)

Base64->6bits

Truncate(md5(URL), 5)

第三级:

考虑到扩展性和可靠性

Multiple Servers(Memcache/DB)

Sharding: hash(URL) % N = Server ID

Standby

Reliability

Replica(cross region, master slave)

Recovery(master: checkpoints, slave:recreate)

Consistency:一致性,在分布式当中,某一个节点还没有同步完成,从A和B中读出来有误差

第四级:

从chunk中分到一个cluster,id generator(zookeeper)

怎么避免URL被重复地访问和爬虫(有些网站不想要被爬取),可以在内部把字符串打乱

怎么限制单一用户RPS,strategy?

流量控制

怎么实现重定向的思路?

速率限制:可以用memcache,key是IP,Username/Email, UserId(logged in)

Reak key in memcache: key+timestamp(inminute)

Value:counter

Expiration:/m,/h,/d

Memcache内存

Redis内存+磁盘,定时从内存flush

Nosqul database

Sql database

Ratelimit

使用cache带上过期销毁信息,一个小时后销毁,但算法会出错

系统设计七剑客:

同步

网络

数据库

分布式

性能

估算

面向对象

案例-社交网络信息流

日志统计

网络爬虫

电商产品页面

concurrency

thread vs. process

consumer and producer

blockingqueue

tracking:

synchronized, asynchronized

操作系统里面程序运行的系统单位,一个程序至少有一个进程,一个进程至少有一个线程,进程的划分比较小,一个进程有独立的内存单位,但多个线程可以共享内存,每一个独立的线程有入口,序列和程序的出口,操作系统会用进程的调度管理来分配,进程是数据集合上的活动,是系统实现调度的单位

生产者和消费者:

有限的缓冲问题,多线程同步问题的案例,主要描述了两个共享缓冲区的线程,一个叫consumer,一个叫producer,生产者生产一定数据到缓冲区,消费者负责消费,生产者不会在缓冲区满的时候加入,消费者不会在空的时候的消费

blockingqueue

给定了一个queue的结构,普通的queue先入先出,但空的时候要等待,满的时候不能push,queue的基本操作,有move和add,有maxSize,,如果有两个同时去操作的话,有保护,在函数起始位置有lock,末尾有unlock.当queue是空的时候,que就一直在等待,

tracking相关的,记录一个事件是不是被记录下来,

两种做法一种是同步的,一种是异步的,当你去访问一个服务的时候是一个get请求,异步的方式,放入缓冲区,做一种积累,log aggregator,每隔一段时间去刷新到磁盘上面,好处是一方面降低系统复杂度,另一方面可以加一些实时的分析系统。

网络结构

OSI

Application layer

Presentation layer

Session layer

Transport layer

Networklayer

Data link layer

Physical layer

在头部会加一些mate data

应用层有HTTP协议,1.1

传输层:TCP,UDP

网络层IP

TCP是一个可靠的稳定的链接,UDP不太可靠,到物理层会通过路由传输到另外一台机子上去,然后会一层层往上解压

Visit URL

当你输入一个URL后发生了哪些事情

先要链接到远端的服务器,然后发送请求到服务器,寻址和建立链接,首先你要做一个寻址,如果浏览器中存在URL的IP,就直接访问,否则要访问DNS,寻址加上域名找到IP,域名是一个分层的结果,顶级域名,DNS会返回服务器的地址,第三步就是浏览器会建立三次握手建立TCP的链接,网页服务默认端口是80端口,第四部是浏览器和服务器的会话,接受数据,第五步是浏览器解析数据并渲染展示网页,浏览器关闭的时候会终止对话并把链接关闭。

数据库Database

relational DB vs. Key value store

sharding vs. clustering

以前关联是主流,结构化和数据模型,交易的安全性要求非常高

KV store在很多社交网站,发了很多信息是对象的存储,是一个静态的过程,不需要做很多关联。

分片和集群的比较,一台数据库的容量有限,单个表的承受在一千万左右,超过一千万实现的性能比较差,需要拿到更大的数据量需要拆表,垂直拆和水平拆,取摸然后分配到不同的机器上面去,第二种是clustering,是一个自动管理的东西,会自动维护,有协调者,知道哪个服务器的复杂量的高低,每次先访问协调者,然后返回一个服务器地址。

听起来很好,加一台数据库会告诉你,在真正的工业中sharding更多一点,算法设计不好的话本来负荷就很高,给更多的压力,一旦发现问题的话sharding能做问题的定位和处理,在做tinyURL的时候也用到了数据库的结构,怎么拿到code,url, created_at,要加一个索引。

分布式

怎么规模化tinyurl,一个是对于前段的服务可以用load balancer,给前端服务做均衡,当某一台机器做了一个转移之后还能做

第二个是把服务器sharding化。

第三步提高性能,每一层都可以加一些cache,相当于把读的请求给缓存住,大大减轻服务器的压力。

然后对写的流量也要给做一个平衡化。

原来只能写到集中一台的对象,现在能写到某一个服务器上的数据库。

如何做一个tracking可以在本地做一个缓冲,异步刷新到message queue上去。

Performance性能

Numbers evetyone should know

访问效率,cache 0.5ns

硬盘千万纳秒级

闪存,寿命比磁盘小一些,比较适合做随机,磁盘适合做顺序

Estimation

全世界范围内有多少调音师

tinyURL总的存储大小

URL长度10-1000字符

设计模式

MVC,网络系统中,后端数据叫模型层,前段叫View,中间叫Controller

Singleton只有一个实例,能使用一些方式来初始化这个实例

Factory

Iterator

Decorator

Façade

案例

news feeds

stats server

web crawler

amazon product page

上一篇下一篇

猜你喜欢

热点阅读