系统设计与实践
系统设计介绍
短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