系統(tǒng)設計與實踐
系統(tǒng)設計介紹
短URL設計
設計一個系統(tǒng)把用戶提供的URL轉(zhuǎn)換為短的URL，訪問的時候要跳回到原始的URL，在系統(tǒng)設計的面試里，如何評價一個系統(tǒng)設計，一分到四分
第一級：
設計一個數(shù)據(jù)庫來映射關(guān)系，從短URL到原始的URL。
有哪些不好的地方？
從原始的URL返回一個5位的編碼，不是五位的用0補充。
能不能擴充，返回的ID為什么都是0到9？
在Cache里面搜索，Read/Write rate LRU和LFU
第二級：
Key-Value DB
MySQL is slow
Key-Value模型做了很多簡化，提升了性能，是MySQL的10倍以上
有沒有其他辦法產(chǎn)生呢？
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：一致性，在分布式當中，某一個節(jié)點還沒有同步完成，從A和B中讀出來有誤差
第四級：
從chunk中分到一個cluster，id generator（zookeeper）
怎么避免URL被重復地訪問和爬蟲(有些網(wǎng)站不想要被爬取)，可以在內(nèi)部把字符串打亂
怎么限制單一用戶RPS，strategy?
流量控制
怎么實現(xiàn)重定向的思路？
速率限制：可以用memcache,key是IP，Username/Email, UserId(logged in)
Reak key in memcache: key+timestamp(inminute)
Value:counter
Expiration:/m,/h,/d
Memcache內(nèi)存
Redis內(nèi)存+磁盤，定時從內(nèi)存flush
Nosqul database
Sql database
Ratelimit
使用cache帶上過期銷毀信息，一個小時后銷毀，但算法會出錯
系統(tǒng)設計七劍客：
同步
網(wǎng)絡
數(shù)據(jù)庫
分布式
性能
估算
面向?qū)ο?/p>
案例-社交網(wǎng)絡信息流
日志統(tǒng)計
網(wǎng)絡爬蟲
電商產(chǎn)品頁面
concurrency
thread vs. process
consumer and producer
blockingqueue
tracking:
synchronized, asynchronized
操作系統(tǒng)里面程序運行的系統(tǒng)單位，一個程序至少有一個進程，一個進程至少有一個線程，進程的劃分比較小，一個進程有獨立的內(nèi)存單位，但多個線程可以共享內(nèi)存，每一個獨立的線程有入口，序列和程序的出口，操作系統(tǒng)會用進程的調(diào)度管理來分配，進程是數(shù)據(jù)集合上的活動，是系統(tǒng)實現(xiàn)調(diào)度的單位
生產(chǎn)者和消費者：
有限的緩沖問題，多線程同步問題的案例，主要描述了兩個共享緩沖區(qū)的線程，一個叫consumer,一個叫producer，生產(chǎn)者生產(chǎn)一定數(shù)據(jù)到緩沖區(qū)，消費者負責消費，生產(chǎn)者不會在緩沖區(qū)滿的時候加入，消費者不會在空的時候的消費
blockingqueue
給定了一個queue的結(jié)構(gòu)，普通的queue先入先出，但空的時候要等待，滿的時候不能push，queue的基本操作，有move和add，有maxSize,，如果有兩個同時去操作的話，有保護，在函數(shù)起始位置有l(wèi)ock,末尾有unlock.當queue是空的時候，que就一直在等待，
tracking相關(guān)的，記錄一個事件是不是被記錄下來，
兩種做法一種是同步的，一種是異步的，當你去訪問一個服務的時候是一個get請求，異步的方式，放入緩沖區(qū)，做一種積累，log aggregator，每隔一段時間去刷新到磁盤上面，好處是一方面降低系統(tǒng)復雜度，另一方面可以加一些實時的分析系統(tǒng)。
網(wǎng)絡結(jié)構(gòu)
OSI
Application layer
Presentation layer
Session layer
Transport layer
Networklayer
Data link layer
Physical layer
在頭部會加一些mate data
應用層有HTTP協(xié)議，1.1
傳輸層：TCP,UDP
網(wǎng)絡層IP
TCP是一個可靠的穩(wěn)定的鏈接，UDP不太可靠，到物理層會通過路由傳輸?shù)搅硗庖慌_機子上去，然后會一層層往上解壓
Visit URL
當你輸入一個URL后發(fā)生了哪些事情
先要鏈接到遠端的服務器，然后發(fā)送請求到服務器，尋址和建立鏈接，首先你要做一個尋址，如果瀏覽器中存在URL的IP，就直接訪問，否則要訪問DNS，尋址加上域名找到IP，域名是一個分層的結(jié)果，頂級域名，DNS會返回服務器的地址，第三步就是瀏覽器會建立三次握手建立TCP的鏈接，網(wǎng)頁服務默認端口是80端口，第四部是瀏覽器和服務器的會話，接受數(shù)據(jù)，第五步是瀏覽器解析數(shù)據(jù)并渲染展示網(wǎng)頁，瀏覽器關(guān)閉的時候會終止對話并把鏈接關(guān)閉。
數(shù)據(jù)庫Database
relational DB vs. Key value store
sharding vs. clustering
以前關(guān)聯(lián)是主流，結(jié)構(gòu)化和數(shù)據(jù)模型，交易的安全性要求非常高
KV store在很多社交網(wǎng)站，發(fā)了很多信息是對象的存儲，是一個靜態(tài)的過程，不需要做很多關(guān)聯(lián)。
分片和集群的比較，一臺數(shù)據(jù)庫的容量有限，單個表的承受在一千萬左右，超過一千萬實現(xiàn)的性能比較差，需要拿到更大的數(shù)據(jù)量需要拆表，垂直拆和水平拆，取摸然后分配到不同的機器上面去，第二種是clustering,是一個自動管理的東西，會自動維護，有協(xié)調(diào)者，知道哪個服務器的復雜量的高低，每次先訪問協(xié)調(diào)者，然后返回一個服務器地址。
聽起來很好，加一臺數(shù)據(jù)庫會告訴你，在真正的工業(yè)中sharding更多一點，算法設計不好的話本來負荷就很高，給更多的壓力，一旦發(fā)現(xiàn)問題的話sharding能做問題的定位和處理，在做tinyURL的時候也用到了數(shù)據(jù)庫的結(jié)構(gòu)，怎么拿到code,url, created_at,要加一個索引。
分布式
怎么規(guī)模化tinyurl，一個是對于前段的服務可以用load balancer,給前端服務做均衡，當某一臺機器做了一個轉(zhuǎn)移之后還能做
第二個是把服務器sharding化。
第三步提高性能，每一層都可以加一些cache,相當于把讀的請求給緩存住，大大減輕服務器的壓力。
然后對寫的流量也要給做一個平衡化。
原來只能寫到集中一臺的對象，現(xiàn)在能寫到某一個服務器上的數(shù)據(jù)庫。
如何做一個tracking可以在本地做一個緩沖，異步刷新到message queue上去。
Performance性能
Numbers evetyone should know
訪問效率，cache 0.5ns
硬盤千萬納秒級
閃存，壽命比磁盤小一些，比較適合做隨機，磁盤適合做順序
Estimation
全世界范圍內(nèi)有多少調(diào)音師
tinyURL總的存儲大小
URL長度10-1000字符
設計模式
MVC，網(wǎng)絡系統(tǒng)中，后端數(shù)據(jù)叫模型層，前段叫View,中間叫Controller
Singleton只有一個實例，能使用一些方式來初始化這個實例
Factory
Iterator
Decorator
Fa?ade
案例
news feeds
stats server
web crawler
amazon product page
