系统Design 的一个 github 链接，备忘
https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md
1、设计一个 url 转短链接的问题：
1，如果平时没有思考过这个问题，最直观的就是考虑 hash(url) = code, 然后 对 code 进行 base16/32/62/64 的编码，
然后取前8位；
比如对于任意多个 url，我们取md5， 有128bit， 16byte字符，然后用某种base编码算法，再取前8位；
那么我们一定会遇到 hash 冲突的问题， 这个时候我们的出发点就是怎么去解决hash冲突；
这是非常符合我们思维的正向思维方式，从工作的流程触发，我们生成 短链接，存储对应关系，出现冲突就解决冲突；
========== 如何解决冲突===========
把已有的存入数据库，然后 插入的时候，看有不有冲突，有冲突就再次生成；
瓶颈问题，如果数据量很大，检测冲突的问题会有严重性能消耗， 这个时候，需要考虑使用 bloomfilter等工具，来快速判断存在性问题；
另外一个大的问题是并发， 同时10万并发，存在性判断的准确性会有更多bad case；
总体来看，上述问题都是一个无法100%精确，并且随着系统数据量，并发扩张，问题会越来越多的设计；
=============== 另外一种思维：
对于经验丰富的工程师，可能会把这个问题转化成，分布式唯一 ID 生成的问题；
如果我们有一个分布式唯一ID 生成器，那么问题就很好解决，对于每一个url，给他生成一个 ID即可；
几种常见的唯一ID 生成器；
- UUID；字符太长，不连续； 查询和插入数据库性能都会有问题
- snowFlaker， 多机器的唯一ID 生成算法， DCID+workID+ timeer
- redis，利用单台incr 原子操作；对于高并发，可以10台一起，每台负责10分之一，这种分片的方式，大幅度提高并发能力；
- mysql， 也可以利用10台，分片生成ID；
使用生成器的模式：
- 不用考虑hash的冲突的问题
- 可以方便的scale，对应的数据和并发，都可以通过横向scale分区来处理
- 生成数字化的ID，可以很方便的编码成短链，连续性也好，查找和插入的性能不会有太大的问题
总之，把问题转化为我们熟悉的领域，很多问题就迎刃而解了，这就是优秀的设计思路带来的好处；
通用的 feed 系统设计考虑
Feed 系统的设计：
离不开的 pull/push 模式讲解：
https://segmentfault.com/a/1190000019640171?utm_source=sf-similar-article
Tips
- push 写扩散； 空间换时间，自己写到每个用户的inbox 队列；每次只需要查询自己的inbox队列；非常快；写入性能要求很高；不太适合有大V的场景；
- pull 模式， 用户微博，直接放在自己的outbox中，粉丝自己去取，需要很高性能的读；如果每个用户都去遍历自己的 粉丝列表读数据，读并发瞬间放大很多；
同时，需要用户记录每次拉取的offset，以便不去拉取相同的内容； - 总得来说，push模式比pull模式要简单；但是不适合大V场景， 所以可以采用混合模式， 把大V 挑选出来，然后，对它们的消息做pull模式；那么 读和写的请求，就会有一个
平衡，需要做相应的数据分析，来确定到底 多少粉丝 才算大V；
队列的选择：
- 何种模式实现消息队列；每个用户的inbox和 outBox，目前貌似都用 redis-list 的数据结构来做；每个用户userId 作为key，box 里面只有ID；
用户来到ID 之后再去查询具体内容，具体内容数据库做好分区提高性能； - 目前新浪微博的缓存貌似在 T级别，缓存高可用，缓存击穿等问题，都需要设计；
- 目前只把活跃的用户的信息放到缓存中
怎么处理瞬时流量爆炸的问题？ 比如 明星离婚，读写的流量都会瞬时放大很多比如（100倍）；
能够做到 event-sense的动态扩容吗？
https://www.jianshu.com/p/0d5a98ba8a20?utm_source=oschina-app
我们看看微博的缓存架构， 在DB上做的事情，在缓存上再做一次， 缓存的缓存，L1， 缓存也要做HA；
烧钱
需要补一下高并发高性能系统设计；
比如： 单个组件极限的 读写性能；
使用的存储，查询，写入的极限；需要有量化的指标；
爬虫的设计
分布式的爬虫很难设计，high level 的component 也比较多；
- url 模块； 种子节点，然后不断的bfs 爬取，更新 list 列表， 去重，bloomfilter的设计
- 优先级模块， url list 的优先级算法，比如pagerank，基于 种子节点 扩散的深度排序； 如果取top K；
在topk 里面，如何做到 不同host 的均匀分布； 比如 使用双队列，一个做topk，一个做 IP balance；
排序的话，设计大表的排序，可以外排，可以spark 大数据平台等； - 代理模块，IP 池子的管理，调度算法；
- 内容解析模块，索引建立等
- 用户搜索匹配模块，语法树，分词， ranking 匹配；结果 format等；
分布式定时器redis
https://www.jianshu.com/p/eb4e3363275e
https://mp.weixin.qq.com/s/DGgbzPTYw8pDtyRcBGtr3A
限流系统的设计
- java jvm 设计；hashmap
- 基于redis 的滑动窗口
- 漏斗模式
- guava 的令牌桶
https://blog.csdn.net/qq_34528297/article/details/107987048
网友评论