├── .gitignore ├── LANGS.md ├── LICENSE ├── README.md ├── book.json ├── cn ├── README.md ├── SUMMARY.md ├── api-rate-limiting.md ├── appendix │ ├── raft.md │ └── skip-list.md ├── bigdata │ ├── README.md │ ├── cardinality-estimation.md │ ├── data-stream-sampling.md │ ├── frequency-estimation.md │ ├── heavy-hitters.md │ ├── membership-query.md │ └── range-query.md ├── crawler.md ├── distributed-id-generator.md ├── filesystem-cache.md ├── hashmap.md ├── key-value-store.md ├── load-balancer.md ├── method.md ├── news-feed.md ├── pagerank.md ├── search-engine.md ├── task-scheduler.md ├── tinyurl.md └── top-k-frequent-ip-in-one-hour.md └── images ├── array-of-count-min-sketch.png ├── count-min-sketch.jpg └── leveldb ├── architecture.png ├── log.png ├── manifest.png └── sstable.png /.gitignore: -------------------------------------------------------------------------------- 1 | # Node rules: 2 | ## Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 3 | .grunt 4 | 5 | ## Dependency directory 6 | ## Commenting this out is preferred by some people, see 7 | ## https://docs.npmjs.com/misc/faq#should-i-check-my-node_modules-folder-into-git 8 | node_modules 9 | 10 | # Book build output 11 | _book 12 | 13 | # eBook build output 14 | *.epub 15 | *.mobi 16 | *.pdf 17 | 18 | # Mac OS junk files 19 | .DS_Store 20 | -------------------------------------------------------------------------------- /LANGS.md: -------------------------------------------------------------------------------- 1 | * [简体中文](cn/) 2 | 3 | 8 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | CC0 1.0 Universal 2 | 3 | Statement of Purpose 4 | 5 | The laws of most jurisdictions throughout the world automatically confer 6 | exclusive Copyright and Related Rights (defined below) upon the creator and 7 | subsequent owner(s) (each and all, an "owner") of an original work of 8 | authorship and/or a database (each, a "Work"). 9 | 10 | Certain owners wish to permanently relinquish those rights to a Work for the 11 | purpose of contributing to a commons of creative, cultural and scientific 12 | works ("Commons") that the public can reliably and without fear of later 13 | claims of infringement build upon, modify, incorporate in other works, reuse 14 | and redistribute as freely as possible in any form whatsoever and for any 15 | purposes, including without limitation commercial purposes. These owners may 16 | contribute to the Commons to promote the ideal of a free culture and the 17 | further production of creative, cultural and scientific works, or to gain 18 | reputation or greater distribution for their Work in part through the use and 19 | efforts of others. 20 | 21 | For these and/or other purposes and motivations, and without any expectation 22 | of additional consideration or compensation, the person associating CC0 with a 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work 25 | and publicly distribute the Work under its terms, with knowledge of his or her 26 | Copyright and Related Rights in the Work and the meaning and intended legal 27 | effect of CC0 on those rights. 28 | 29 | 1. Copyright and Related Rights. A Work made available under CC0 may be 30 | protected by copyright and related or neighboring rights ("Copyright and 31 | Related Rights"). Copyright and Related Rights include, but are not limited 32 | to, the following: 33 | 34 | i. the right to reproduce, adapt, distribute, perform, display, communicate, 35 | and translate a Work; 36 | 37 | ii. moral rights retained by the original author(s) and/or performer(s); 38 | 39 | iii. publicity and privacy rights pertaining to a person's image or likeness 40 | depicted in a Work; 41 | 42 | iv. rights protecting against unfair competition in regards to a Work, 43 | subject to the limitations in paragraph 4(a), below; 44 | 45 | v. rights protecting the extraction, dissemination, use and reuse of data in 46 | a Work; 47 | 48 | vi. database rights (such as those arising under Directive 96/9/EC of the 49 | European Parliament and of the Council of 11 March 1996 on the legal 50 | protection of databases, and under any national implementation thereof, 51 | including any amended or successor version of such directive); and 52 | 53 | vii. other similar, equivalent or corresponding rights throughout the world 54 | based on applicable law or treaty, and any national implementations thereof. 55 | 56 | 2. Waiver. To the greatest extent permitted by, but not in contravention of, 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright 59 | and Related Rights and associated claims and causes of action, whether now 60 | known or unknown (including existing as well as future claims and causes of 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum 62 | duration provided by applicable law or treaty (including future time 63 | extensions), (iii) in any current or future medium and for any number of 64 | copies, and (iv) for any purpose whatsoever, including without limitation 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes 66 | the Waiver for the benefit of each member of the public at large and to the 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver 68 | shall not be subject to revocation, rescission, cancellation, termination, or 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work 70 | by the public as contemplated by Affirmer's express Statement of Purpose. 71 | 72 | 3. Public License Fallback. Should any part of the Waiver for any reason be 73 | judged legally invalid or ineffective under applicable law, then the Waiver 74 | shall be preserved to the maximum extent permitted taking into account 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver 76 | is so judged Affirmer hereby grants to each affected person a royalty-free, 77 | non transferable, non sublicensable, non exclusive, irrevocable and 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration 80 | provided by applicable law or treaty (including future time extensions), (iii) 81 | in any current or future medium and for any number of copies, and (iv) for any 82 | purpose whatsoever, including without limitation commercial, advertising or 83 | promotional purposes (the "License"). The License shall be deemed effective as 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the 85 | License for any reason be judged legally invalid or ineffective under 86 | applicable law, such partial invalidity or ineffectiveness shall not 87 | invalidate the remainder of the License, and in such case Affirmer hereby 88 | affirms that he or she will not (i) exercise any of his or her remaining 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims 90 | and causes of action with respect to the Work, in either case contrary to 91 | Affirmer's express Statement of Purpose. 92 | 93 | 4. Limitations and Disclaimers. 94 | 95 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 96 | surrendered, licensed or otherwise affected by this document. 97 | 98 | b. Affirmer offers the Work as-is and makes no representations or warranties 99 | of any kind concerning the Work, express, implied, statutory or otherwise, 100 | including without limitation warranties of title, merchantability, fitness 101 | for a particular purpose, non infringement, or the absence of latent or 102 | other defects, accuracy, or the present or absence of errors, whether or not 103 | discoverable, all to the greatest extent permissible under applicable law. 104 | 105 | c. Affirmer disclaims responsibility for clearing rights of other persons 106 | that may apply to the Work or any use thereof, including without limitation 107 | any person's Copyright and Related Rights in the Work. Further, Affirmer 108 | disclaims responsibility for obtaining any necessary consents, permissions 109 | or other rights required for any use of the Work. 110 | 111 | d. Affirmer understands and acknowledges that Creative Commons is not a 112 | party to this document and has no duty or obligation with respect to this 113 | CC0 or use of the Work. 114 | 115 | For more information, please see 116 | 117 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 系统设计面试题精选 2 | 3 | 本书精选了一些经典的系统设计题，也是各大公司常考的，进行详细深入的讲解，帮助读者举一反三，各个击破。 4 | 5 | 6 | # 在线阅读 7 | 8 | 9 | 10 | 11 | # Community 12 | 13 | Github: 14 | 15 | 微博： [@灵魂机器](http://weibo.com/soulmachine) 16 | 17 | 18 | ## License 19 | Book License: [CC BY-SA 3.0 License](http://creativecommons.org/licenses/by-sa/3.0/) 20 | -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "gitbook": "3.x.x", 3 | "title": "系统设计", 4 | "description": "系统设计面试题精选", 5 | "plugins": ["katex", "github", "codesnippet", "image-captions", "disqus"], 6 | "pluginsConfig": { 7 | "disqus": { 8 | "shortName": "system-design" 9 | }, 10 | "github": { 11 | "url": "https://www.github.com/soulmachine/system-design" 12 | } 13 | } 14 | } 15 | -------------------------------------------------------------------------------- /cn/README.md: -------------------------------------------------------------------------------- 1 | # 系统设计面试题精选 2 | 3 | 本书精选了一些经典的系统设计题，也是各大公司常考的，进行详细深入的讲解，帮助读者举一反三，各个击破。 4 | 5 | 6 | ### 在线阅读 7 | 8 | 9 | 10 | 11 | {% include "./SUMMARY.md" %} 12 | 13 | 14 | ### Community 15 | 16 | Github: 17 | 18 | 微博： [@灵魂机器](http://weibo.com/soulmachine) 19 | 20 | 21 | ### License 22 | Book License: [CC BY-SA 3.0 License](http://creativecommons.org/licenses/by-sa/3.0/) 23 | -------------------------------------------------------------------------------- /cn/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # 内容目录 2 | 3 | * [分布式ID生成器](distributed-id-generator.md) 4 | * [短网址系统(TinyURL)](tinyurl.md) 5 | * [信息流(News Feed)](news-feed.md) 6 | * [定时任务调度器](task-scheduler.md) 7 | * [API限速](api-rate-limiting.md) 8 | * [线程安全的HashMap](hashmap.md) 9 | * [最近一个小时内访问频率最高的10个IP](top-k-frequent-ip-in-one-hour.md) 10 | * [负载均衡](load-balancer.md) 11 | * [Key-Value存储引擎](key-value-store.md) 12 | * [网络爬虫](crawler.md) 13 | * [PageRank](pagerank.md) 14 | * [搜索引擎](search-engine.md) 15 | * [大数据](bigdata/README.md) 16 | * [数据流采样](bigdata/data-stream-sampling.md) 17 | * [基数估计](bigdata/cardinality-estimation.md) 18 | * [频率估计](bigdata/frequency-estimation.md) 19 | * [Top K 频繁项](bigdata/heavy-hitters.md) 20 | * [范围查询](bigdata/range-query.md) 21 | * [成员查询](bigdata/membership-query.md) 22 | * 附录 23 | * [跳表(Skip List)](appendix/skip-list.md) 24 | * [Raft](appendix/raft.md) 25 | -------------------------------------------------------------------------------- /cn/api-rate-limiting.md: -------------------------------------------------------------------------------- 1 | 给定一个公共API，限制每个用户每秒只能调用1000次，如何实现？ 2 | 3 | 这个一个经典的API限速问题(API rate limiting)。 4 | 5 | 6 | ### 参考资料 7 | 8 | * [Google Interview API rate limiting - CareerCup](https://www.careercup.com/question?id=5147519440912384) 9 | -------------------------------------------------------------------------------- /cn/appendix/raft.md: -------------------------------------------------------------------------------- 1 | Raft协议的原始论文非常完整，不仅有理论还有各种细节伪代码，不像Paxos论文，有些细节没有涉及到，导致后来人是实现时有不同的理解。因此Raft不仅在教学方面更加容易理解，在工程实现方面也是更加容易实现。 2 | 3 | 4 | ### 参考资料 5 | 6 | * [In Search of an Understandable Consensus Algorithm(Extended Version)](https://raft.github.io/raft.pdf) 7 | * [The Raft Consensus Algorithm](https://raft.github.io/) 8 | * [Designing for Understandability: The Raft Consensus Algorithm - YouTube](https://www.youtube.com/watch?v=vYp4LYbnnW8) 9 | * [分布式一致性算法：raft 算法（raft 论文翻译）](http://linbingdong.com/2017/02/19/%E5%88%86%E5%B8%83%E5%BC%8F%E4%B8%80%E8%87%B4%E6%80%A7%E7%AE%97%E6%B3%95%EF%BC%9ARaft%20%E7%AE%97%E6%B3%95%EF%BC%88Raft%20%E8%AE%BA%E6%96%87%E7%BF%BB%E8%AF%91%EF%BC%89/?spm=5176.100239.blogcont71302.14.0bBQaI) 10 | * [etcd - Github](https://github.com/coreos/etcd) 11 | * [Raft一致性算法论文的中文翻译 - Github](https://github.com/maemual/raft-zh_cn) 12 | * [raft算法与paxos算法相比有什么优势，使用场景有什么差异？ - 知乎](https://www.zhihu.com/question/36648084) 13 | * [The Log: What every software engineer should know about real-time data's unifying abstraction](https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying) 14 | -------------------------------------------------------------------------------- /cn/appendix/skip-list.md: -------------------------------------------------------------------------------- 1 | 跳表 2 | 3 | 4 | ### 参考资料 5 | 6 | * [SkipList 跳表 - ITeye技术网站](http://kenby.iteye.com/blog/1187303) 7 | * [Skip List - Wikipedia](https://en.wikipedia.org/wiki/Skip_list) 8 | -------------------------------------------------------------------------------- /cn/bigdata/README.md: -------------------------------------------------------------------------------- 1 | # 大数据 2 | 3 | 本章主要讲一些大数据相关的经典系统设计题。 4 | -------------------------------------------------------------------------------- /cn/bigdata/cardinality-estimation.md: -------------------------------------------------------------------------------- 1 | 如何计算数据流中不同元素的个数？例如，独立访客(Unique Visitor，简称UV)统计。这个问题称为基数估计(Cardinality Estimation)，也是一个很经典的题目。 2 | 3 | 4 | ### 方案1: HashSet 5 | 6 | 首先最容易想到的办法是用HashSet，每来一个元素，就往里面塞，HashSet的大小就所求答案。但是在大数据的场景下，HashSet在单机内存中存不下。 7 | 8 | 9 | ### 方案2: bitmap 10 | 11 | HashSet耗内存主要是由于存储了元素的真实值，可不可以不存储元素本身呢？bitmap就是这样一个方案，假设已经知道不同元素的个数的上限，即基数的最大值，设为N，则开一个长度为N的bit数组，地位跟HashSet一样。每个元素与bit数组的某一位一一对应，该位为1，表示此元素在集合中，为0表示不在集合中。那么bitmap中1的个数就是所求答案。 12 | 13 | 这个方案的缺点是，bitmap的长度与实际的基数无关，而是与基数的上限有关。假如要计算上限为1亿的基数，则需要12.5MB的bitmap，十个网站就需要125M。关键在于，这个内存使用与集合元素数量无关，即使一个网站仅仅有一个1UV，也要为其分配12.5MB内存。该算法的空间复杂度是$$O(N_{max})$$。 14 | 15 | 16 | 实际上目前还没有发现在大数据场景中准确计算基数的高效算法，因此在不追求绝对准确的情况下，使用近似算法算是一个不错的解决方案。 17 | 18 | 19 | ### 方案3: Linear Counting 20 | 21 | Linear Counting的基本思路是： 22 | 23 | * 选择一个哈希函数h，其结果服从均匀分布 24 | * 开一个长度为m的bitmap，均初始化为0(m设为多大后面有讨论) 25 | * 数据流每来一个元素，计算其哈希值并对m取模，然后将该位置为1 26 | * 查询时，设bitmap中还有u个bit为0，则不同元素的总数近似为 $$-m\log\dfrac{u}{m}$$ 27 | 28 | 在使用Linear Counting算法时，主要需要考虑的是bitmap长度`m`。m主要由两个因素决定，基数大小以及容许的误差。假设基数大约为n，允许的误差为ϵ，则m需要满足如下约束， 29 | 30 | $$m > \dfrac{\epsilon^t-t-1}{(\epsilon t)^2}$$, 其中 $$t=\dfrac{n}{m}$$ 31 | 32 | 精度越高，需要的m越大。 33 | 34 | Linear Counting 与方案1中的bitmap很类似，只是改善了bitmap的内存占用，但并没有完全解决，例如一个网站只有一个UV，依然要为其分配m位的bitmap。该算法的空间复杂度与方案2一样，依然是$$O(N_{max})$$。 35 | 36 | 37 | ### 方案4: LogLog Counting 38 | 39 | LogLog Counting的算法流程： 40 | 41 | 1. 均匀随机化。选取一个哈希函数h应用于所有元素，然后对哈希后的值进行基数估计。哈希函数h必须满足如下条件， 42 | 43 | 1. 哈希碰撞可以忽略不计。哈希函数h要尽可能的减少冲突 44 | 1. h的结果是均匀分布的。也就是说无论原始数据的分布如何，其哈希后的结果几乎服从均匀分布（完全服从均匀分布是不可能的，D. Knuth已经证明不可能通过一个哈希函数将一组不服从均匀分布的数据映射为绝对均匀分布，但是很多哈希函数可以生成几乎服从均匀分布的结果，这里我们忽略这种理论上的差异，认为哈希结果就是服从均匀分布）。 45 | 1. 哈希后的结果是固定长度的 46 | 47 | 1. 对于元素计算出哈希值，由于每个哈希值是等长的，令长度为L 48 | 1. 对每个哈希值，从高到低找到第一个1出现的位置，取这个位置的最大值，设为p，则基数约等于$$2^p$$ 49 | 50 | 如果直接使用上面的单一估计量进行基数估计会由于偶然性而存在较大误差。因此，LLC采用了分桶平均的思想来降低误差。具体来说，就是将哈希空间平均分成m份，每份称之为一个桶（bucket）。对于每一个元素，其哈希值的前k比特作为桶编号，其中$$2^k=m$$，而后L-k个比特作为真正用于基数估计的比特串。桶编号相同的元素被分配到同一个桶，在进行基数估计时，首先计算每个桶内最大的第一个1的位置，设为`p[i]`，然后对这m个值取平均后再进行估计，即基数的估计值为$$2^{\frac{1}{m}\Sigma_{i=0}^{m-1} p[i]}$$。这相当于做多次实验然后去平均值，可以有效降低因偶然因素带来的误差。 51 | 52 | LogLog Counting 的空间复杂度仅有$$O(\log_2(\log_2(N_{max})))$$，内存占用极少，这是它的优点。不过LLC也有自己的缺点，当基数不是很大的时候，误差比较大。 53 | 54 | 关于该算法的数学证明，请阅读原始论文和参考资料里的链接，这里不再赘述。 55 | 56 | 57 | ### 方案5: HyperLogLog Counting 58 | 59 | HyperLogLog Counting（以下简称HLLC）的基本思想是在LLC的基础上做改进， 60 | 61 | * 第1个改进是使用调和平均数替代几何平均数，调和平均数可以有效抵抗离群值的扰。注意LLC是对各个桶取算术平均数，而算术平均数最终被应用到2的指数上，所以总体来看LLC取的是几何平均数。由于几何平均数对于离群值（例如0）特别敏感，因此当存在离群值时，LLC的偏差就会很大，这也从另一个角度解释了为什么基数n不太大时LLC的效果不太好。这是因为n较小时，可能存在较多空桶，这些特殊的离群值干扰了几何平均数的稳定性。使用调和平均数后，估计公式变为 $$\hat{n}=\frac{\alpha_mm^2}{\Sigma_{i=0}^{m-1} p[i]}$$，其中$$\alpha_m=(m\int_0^{\infty}(log_2(\frac{2+u}{1+u}))^mdu)^{-1}$$ 62 | * 第2个改进是加入了分段偏差修正。具体来说，设e为基数的估计值， 63 | 64 | * 当 $$e \leq \frac{5}{2}m$$时，使用 Linear Counting 65 | * 当 $$\frac{5}{2}m\frac{1}{30}2^{32}$$时，修改估计公式为$$\hat{n}=-2^{32}\log(1-e/2^{32})$$ 67 | 68 | 关于分段偏差修正的效果分析也可以在原论文中找到。 69 | 70 | 71 | ### 参考资料 72 | 73 | * [解读Cardinality Estimation算法（第一部分：基本概念）](http://blog.codinglabs.org/articles/algorithms-for-cardinality-estimation-part-i.html) 74 | * [解读Cardinality Estimation算法（第二部分：Linear Counting）](http://blog.codinglabs.org/articles/algorithms-for-cardinality-estimation-part-ii.html) 75 | * [解读Cardinality Estimation算法（第三部分：LogLog Counting）](http://blog.codinglabs.org/articles/algorithms-for-cardinality-estimation-part-iii.html) 76 | * [解读Cardinality Estimation算法（第四部分：HyperLogLog Counting及Adaptive Counting）](http://blog.codinglabs.org/articles/algorithms-for-cardinality-estimation-part-iv.html) 77 | -------------------------------------------------------------------------------- /cn/bigdata/data-stream-sampling.md: -------------------------------------------------------------------------------- 1 | 有一个无限的整数数据流，如何从中随机地抽取k个整数出来？ 2 | 3 | 这是一个经典的数据流采样问题，我们一步一步来分析。 4 | 5 | ### 当k=1时 6 | 7 | 我们先考虑最简单的情况，k=1，即只需要随机抽取一个样本出来。抽样方法如下： 8 | 9 | 1. 当第一个整数到达时，保存该整数 10 | 1. 当第2个整数到达时，以1/2的概率使用该整数替换第1个整数，以1/2的概率丢弃改整数 11 | 1. 当第i个整数到达时，以$$\dfrac{1}{i}$$的概率使用第i个整数替换被选中的整数，以$$1-\dfrac{1}{i}$$的概率丢弃第i个整数 12 | 13 | 假设数据流目前已经流出共n个整数，这个方法能保证每个元素被选中的概率是$$\dfrac{1}{n}$$吗？用数学归纳法，证明如下： 14 | 15 | 1. 当n=1时，由于是第1个数，被选中的概率是100%，命题成立 16 | 1. 假设当n=m(m>=1)时，命题成立，即前m个数，每一个被选中的概率是 $$\dfrac{1}{m}$$ 17 | 1. 当n=m+1时，第m+1个数被选中的概率是 $$\dfrac{1}{m+1}$$, 前m个数被选中的概率是$$\dfrac{1}{m} \cdot (1-\dfrac{1}{m+1})=\dfrac{1}{m+1}$$，命题依然成立 18 | 19 | 由1，2，3知n>=1时命题成立，证毕。 20 | 21 | 22 | ### 当k>1时 23 | 24 | 当 k > 1，需要随机采样多个样本时，方法跟上面很类似， 25 | 26 | 1. 前k个整数到达时，全部保留，即被选中的概率是 100%， 27 | 1. 第i个整数到达时，以$$k/i$$的概率替换k个数中的某一个，以$$1-\dfrac{k}{i}$$的概率丢弃，保留k个数不变 28 | 29 | 假设数据流目前已经流出共N个整数，这个方法能保证每个元素被选中的概率是$$\dfrac{k}{N}$$吗？用数学归纳法，证明如下： 30 | 31 | 1. 当n=m(m<=k)时，被选中的概率是100%，命题成立 32 | 1. 假设当n=m(m>k)时，命题成立，即前m个数，每一个被选中的概率是 $$\dfrac{1}{m}$$ 33 | 1. 当n=m+1时，第m+1个数被选中的概率是 $$\dfrac{k}{m+1}$$, 前m个数被选中的概率是$$\dfrac{1}{m} \cdot [\dfrac{k}{m+1} \cdot (1-\dfrac{1}{k})+1-\dfrac{k}{m+1}]=\dfrac{1}{m+1}$$，命题依然成立 34 | 35 | 由1，2，3知n>=1时命题成立，证毕。 36 | 37 | 38 | ### 参考资料 39 | 40 | * [浅谈流处理算法 (1) – 蓄水池采样](https://rosona.github.io/post/20151223/) 41 | * [Google Interview Question: Given a stream of integers of... | Glassdoor](https://www.glassdoor.com/Interview/Given-a-stream-of-integers-of-unknown-possibly-large-length-how-would-you-pick-one-at-random-Now-prove-its-random-QTN_36764.htm) -------------------------------------------------------------------------------- /cn/bigdata/frequency-estimation.md: -------------------------------------------------------------------------------- 1 | 如何计算数据流中任意元素的频率？ 2 | 3 | 这个问题也是大数据场景下的一个经典问题，称为频率估计(Frequency Estimation)问题。 4 | 5 | 6 | ### 方案1: HashMap 7 | 8 | 用一个HashMap记录每个元素的出现次数，每来一个元素，就把相应的计数器增1。这个方法在大数据的场景下不可行，因为元素太多，单机内存无法存下这个巨大的HashMap。 9 | 10 | 11 | ### 方案2: 数据分片 + HashMap 12 | 13 | 既然单机内存存不下所有元素，一个很自然的改进就是使用多台机器。假设有8台机器，每台机器都有一个HashMap，第1台机器只处理`hash(elem)%8==0`的元素，第2台机器只处理`hash(elem)%8==1`的元素，以此类推。查询的时候，先计算这个元素在哪台机器上，然后去那台机器上的HashMap里取出计数器。 14 | 15 | 方案2能够scale, 但是依旧是把所有元素都存了下来，代价比较高。 16 | 17 | 如果允许近似计算，那么有很多高效的近似算法，单机就可以处理海量的数据。下面讲几个经典的近似算法。 18 | 19 | 20 | ### 方案3: Count-Min Sketch 21 | 22 | Count-Min Sketch 算法流程： 23 | 24 | 1. 选定d个hash函数，开一个 dxm 的二维整数数组作为哈希表 25 | 1. 对于每个元素，分别使用d个hash函数计算相应的哈希值，并对m取余，然后在对应的位置上增1，二维数组中的每个整数称为sketch 26 | 1. 要查询某个元素的频率时，只需要取出d个sketch, 返回最小的那一个（其实d个sketch都是该元素的近似频率，返回任意一个都可以，该算法选择最小的那个） 27 | 28 | ![](../../images/count-min-sketch.jpg) 29 | 30 | 这个方法的思路和 Bloom Filter 比较类似，都是用多个hash函数来降低冲突。 31 | 32 | * 空间复杂度`O(dm)`。Count-Min Sketch 需要开一个 `dxm` 大小的二位数组，所以空间复杂度是`O(dm)` 33 | * 时间复杂度`O(n)`。Count-Min Sketch 只需要一遍扫描，所以时间复杂度是`O(n)` 34 | 35 | Count-Min Sketch算法的优点是省内存，缺点是对于出现次数比较少的元素，准确性很差，因为二维数组相比于原始数据来说还是太小，hash冲突比较严重，导致结果偏差比较大。 36 | 37 | 38 | ### 方案4: Count-Mean-Min Sketch 39 | 40 | Count-Min Sketch算法对于低频的元素，结果不太准确，主要是因为hash冲突比较严重，产生了噪音，例如当m=20时，有1000个数hash到这个20桶，平均每个桶会收到50个数，这50个数的频率重叠在一块了。Count-Mean-Min Sketch 算法做了如下改进： 41 | 42 | * 来了一个查询，按照 Count-Min Sketch的正常流程，取出它的d个sketch 43 | * 对于每个hash函数，估算出一个噪音，噪音等于该行所有整数(除了被查询的这个元素)的平均值 44 | * 用该行的sketch 减去该行的噪音，作为真正的sketch 45 | * 返回d个sketch的中位数 46 | 47 | ```java 48 | class CountMeanMinSketch { 49 | // initialization and addition procedures as in CountMinSketch 50 | // n is total number of added elements 51 | long estimateFrequency(value) { 52 | long e[] = new long[d] 53 | for(i = 0; i < d; i++) { 54 | sketchCounter = estimators[i][ hash(value, i) ] 55 | noiseEstimation = (n - sketchCounter) / (m - 1) 56 | e[i] = sketchCounter – noiseEstimator 57 | } 58 | return median(e) 59 | } 60 | } 61 | ``` 62 | 63 | Count-Mean-Min Sketch算法能够显著的改善在长尾数据上的精确度。 64 | 65 | 66 | ### 参考资料 67 | 68 | * [数据流处理—摘要的艺术](http://chuansong.me/n/2035207) 69 | * [大数据处理中基于概率的数据结构 - fxjwind - 博客园](http://www.cnblogs.com/fxjwind/p/3289221.html) 70 | * [Probabilistic Data Structures for Web Analytics and Data Mining](https://dirtysalt.github.io/probabilistic-data-structures-for-web-analytics-and-data-mining.html) 71 | -------------------------------------------------------------------------------- /cn/bigdata/heavy-hitters.md: -------------------------------------------------------------------------------- 1 | 寻找数据流中出现最频繁的k个元素(find top k frequent items in a data stream)。这个问题也称为 Heavy Hitters. 2 | 3 | 这题也是从实践中提炼而来的，例如搜索引擎的热搜榜，找出访问网站次数最多的前10个IP地址，等等。 4 | 5 | 6 | ### 方案1: HashMap + Heap 7 | 8 | 用一个 `HashMap`，存放所有元素出现的次数，用一个小根堆，容量为k，存放目前出现过的最频繁的k个元素， 9 | 10 | 1. 每次从数据流来一个元素，如果在HashMap里已存在，则把对应的计数器增1，如果不存在，则插入，计数器初始化为1 11 | 1. 在堆里查找该元素，如果找到，把堆里的计数器也增1，并调整堆；如果没有找到，把这个元素的次数跟堆顶元素比较，如果大于堆丁元素的出现次数，则把堆丁元素替换为该元素，并调整堆 12 | 13 | * 空间复杂度`O(n)`。HashMap需要存放下所有元素，需要`O(n)`的空间，堆需要存放k个元素，需要`O(k)`的空间，跟`O(n)`相比可以忽略不急，总的时间复杂度是`O(n)` 14 | * 时间复杂度`O(n)`。每次来一个新元素，需要在HashMap里查找一下，需要`O(1)`的时间；然后要在堆里查找一下，`O(k)`的时间，有可能需要调堆，又需要`O(logk)`的时间，总的时间复杂度是`O(n(k+logk))`，k是常量，所以可以看做是O(n)。 15 | 16 | 如果元素数量巨大，单机内存存不下，怎么办？ 有两个办法，见方案2和3。 17 | 18 | 19 | ### 方案2: 多机HashMap + Heap 20 | 21 | * 可以把数据进行分片。假设有8台机器，第1台机器只处理`hash(elem)%8==0`的元素，第2台机器只处理`hash(elem)%8==1`的元素，以此类推。 22 | * 每台机器都有一个HashMap和一个 Heap, 各自独立计算出 top k 的元素 23 | * 把每台机器的Heap，通过网络汇总到一台机器上，将多个Heap合并成一个Heap，就可以计算出总的 top k 个元素了 24 | 25 | 26 | ### 方案3: Count-Min Sketch + Heap 27 | 28 | 既然方案1中的HashMap太大，内存装不小，那么可以用[Count-Min Sketch算法](frequency-estimation.md)代替HashMap， 29 | 30 | * 在数据流不断流入的过程中，维护一个标准的Count-Min Sketch 二维数组 31 | * 维护一个小根堆，容量为k 32 | * 每次来一个新元素， 33 | * 将相应的sketch增1 34 | * 在堆中查找该元素，如果找到，把堆里的计数器也增1，并调整堆；如果没有找到，把这个元素的sketch作为钙元素的频率的近似值，跟堆顶元素比较，如果大于堆丁元素的频率，则把堆丁元素替换为该元素，并调整堆 35 | 36 | 这个方法的时间复杂度和空间复杂度如下： 37 | 38 | * 空间复杂度`O(dm)`。m是二维数组的列数，d是二维数组的行数，堆需要`O(k)`的空间，不过k通常很小，堆的空间可以忽略不计 39 | * 时间复杂度`O(nlogk)`。每次来一个新元素，需要在二维数组里查找一下，需要`O(1)`的时间；然后要在堆里查找一下，`O(logk)`的时间，有可能需要调堆，又需要`O(logk)`的时间，总的时间复杂度是`O(nlogk)`。 40 | 41 | 42 | ### 方案4: Lossy Counting 43 | 44 | Lossy Couting 算法流程： 45 | 46 | 1. 建立一个HashMap，用于存放每个元素的出现次数 47 | 1. 建立一个窗口（窗口的大小由错误率决定，后面具体讨论） 48 | 1. 等待数据流不断流进这个窗口，直到窗口满了，开始统计每个元素出现的频率，统计结束后，每个元素的频率减1，然后将出现次数为0的元素从HashMap中删除 49 | 1. 返回第2步，不断循环 50 | 51 | Lossy Counting 背后朴素的思想是，出现频率高的元素，不太可能减一后变成0，如果某个元素在某个窗口内降到了0，说明它不太可能是高频元素，可以不再跟踪它的计数器了。随着处理的窗口越来越多，HashMap也会不断增长，同时HashMap里的低频元素会被清理出去，这样内存占用会保持在一个很低的水平。 52 | 53 | 很显然，Lossy Counting 算法是个近似算法，但它的错误率是可以在数学上证明它的边界的。假设要求错误率不大于ε，那么窗口大小为1/ε，对于长度为N的流，有N／（1/ε）＝εN 个窗口，由于每个窗口结束时减一了，那么频率最多被少计数了窗口个数εN。 54 | 55 | 该算法只需要一遍扫描，所以时间复杂度是`O(n)`。 56 | 57 | 该算法的内存占用，主要在于那个HashMap, Gurmeet Singh Manku 在他的论文里，证明了HashMap里最多有 `1/ε log (εN)`个元素，所以空间复杂度是`O(1/ε log (εN))`。 58 | 59 | 60 | ### 方案5: SpaceSaving 61 | 62 | TODO, 原始论文 "Efficient Computation of Frequent and Top-k Elements in Data Streams" 63 | 64 | 65 | ### 参考资料 66 | 67 | 1. [An improved data stream summary:the count-min sketch and its applications](http://vaffanculo.twiki.di.uniroma1.it/pub/Ing_algo/WebHome/p14_Cormode_JAl_05.pdf) by Graham Cormode 68 | 1. [Approximate Frequency Counts over Data Streams](http://delab.csd.auth.gr/courses/c_dm_pms/afc.pdf) by Gurmeet Singh Manku 69 | 1. A.Metwally, D.Agrawal, A.El Abbadi. Efficient Computation of Frequent and Top-k Elements in Data Streams. In Proceeding of the 10th International Conference on Database Theory(ICDT), pp 398-412,2005. 70 | 1. Massimo Cafaro, et al. “A parallel space saving algorithm for frequent items and the Hurwitz zeta distribution”. Proceeding arXiv: 1401.0702v12 [cs.DS] 19 Setp 2015. 71 | 1. [Efficient Computation of Frequent and Top-k Elements in Data Streams](http://www.cse.ust.hk/~raywong/comp5331/References/EfficientComputationOfFrequentAndTop-kElementsInDataStreams.pdf) by Ahmed Metwally 72 | 1. [Finding Frequent Items in Data Streams ](http://dmac.rutgers.edu/Workshops/WGUnifyingTheory/Slides/cormode.pdf) 73 | * [实时大数据流上的频率统计：Lossy Counting Algorithm - 待字闺中](http://www.wdiandi.com/p/b3779f.shtml) 74 | * [What is Lossy Counting? - Stack Overflow](http://stackoverflow.com/a/8033083/381712) 75 | -------------------------------------------------------------------------------- /cn/bigdata/membership-query.md: -------------------------------------------------------------------------------- 1 | 给定一个无限的数据流和一个有限集合，如何判断数据流中的元素是否在这个集合中？ 2 | 3 | 在实践中，我们经常需要判断一个元素是否在一个集合中，例如垃圾邮件过滤，爬虫的网址去重，等等。这题也是一道很经典的题目，称为成员查询(Membership Query)。 4 | 5 | 答案: Bloom Filter 6 | -------------------------------------------------------------------------------- /cn/bigdata/range-query.md: -------------------------------------------------------------------------------- 1 | 给定一个无限的整数数据流，如何查询在某个范围内的元素出现的总次数？例如数据库常常需要SELECT count(v) WHERE v >= l AND v < u。这个经典的问题称为范围查询(Range Query)。 2 | 3 | 4 | ### 方案1: Array of Count-Min Sketches 5 | 6 | 有一个简单方法，既然[Count-Min Sketch](https://soulmachine.gitbooks.io/system-design/content/cn/bigdata/frequency-estimation.html)可以计算每个元素的频率，那么我们把指定范围内所有元素的sketch加起来，不就是这个范围内元素出现的总数了吗？要注意，由于每个sketch都是近似值，多个近似值相加，误差会被放大，所以这个方法不可行。 7 | 8 | 解决的办法就是使用多个“分辨率”不同的Count-Min Sketch。第1个sketch每个格子存放单个元素的频率，第2个sketch每个格子存放2个元素的频率（做法很简答，把该元素的哈希值的最低位bit去掉，即右移一位，等价于除以2，再继续后续流程），第3个sketch每个格子存放4个元素的频率（哈希值右移2位即可），以此类推，最后一个sketch有2个格子，每个格子存放一半元素的频率总数，即第1个格子存放最高bit为0的元素的总次数，第2个格子存放最高bit为1的元素的总次数。Sketch的个数约等于`log(不同元素的总数)`。 9 | 10 | * 插入元素时，算法伪代码如下， 11 | 12 | def insert(x): 13 | for i in range(1, d+1): 14 | M1[i][h[i](x)] += 1 15 | M2[i][h[i](x)/2] += 1 16 | M3[i][h[i](x)/4] += 1 17 | M4[i][h[i](x)/8] += 1 18 | # ... 19 | 20 | * 查询范围[l, u)时，从粗粒度到细粒度，找到多个区间，能够不重不漏完整覆盖区间[l, u)，将这些sketch的值加起来，就是该范围内的元素总数。举个例子，给定某个范围，如下图所示，最粗粒度的那个sketch里找不到一个格子，就往细粒度找，最后找到第1个sketch的2个格子，第2个sketch的1个格子和第3个sketch的1个格子，共4个格子，能够不重不漏的覆盖整个范围，把4个红线部分的值加起来就是所求结果 21 | 22 | ![](../../images/array-of-count-min-sketch.png) 23 | 24 | 25 | ### 参考资料 26 | 27 | * [大数据处理中基于概率的数据结构 - fxjwind - 博客园](http://www.cnblogs.com/fxjwind/p/3289221.html) 28 | * [Probabilistic Data Structures for Web Analytics and Data Mining](https://dirtysalt.github.io/probabilistic-data-structures-for-web-analytics-and-data-mining.html) 29 | -------------------------------------------------------------------------------- /cn/crawler.md: -------------------------------------------------------------------------------- 1 | 请设计一个网络爬虫。 2 | 3 | 并发下载，网址去重，IP被禁等等 4 | -------------------------------------------------------------------------------- /cn/distributed-id-generator.md: -------------------------------------------------------------------------------- 1 | 如何设计一个分布式ID生成器(Distributed ID Generator)，并保证ID按时间粗略有序？ 2 | 3 | 4 | ### 应用场景(Scenario) 5 | 6 | 现实中很多业务都有**生成唯一ID**的需求，例如： 7 | 8 | * 用户ID 9 | * 微博ID 10 | * 聊天消息ID 11 | * 帖子ID 12 | * 订单ID 13 | 14 | 15 | ### 需求(Needs) 16 | 17 | 这个ID往往会作为数据库主键，所以需要保证**全局唯一**。数据库会在这个字段上建立聚集索引(Clustered Index，参考 MySQL InnoDB)，即该字段会影响各条数据再物理存储上的顺序。 18 | 19 | ID还要尽可能**短**，节省内存，让数据库索引效率更高。基本上64位整数能够满足绝大多数的场景，但是如果能做到比64位更短那就更好了。需要根据具体业务进行分析，预估出ID的最大值，这个最大值通常比64位整数的上限小很多，于是我们可以用更少的bit表示这个ID。 20 | 21 | 查询的时候，往往有分页或者**排序**的需求，所以需要给每条数据添加一个时间字段，并在其上建立普通索引(Secondary Index)。但是普通索引的访问效率比聚集索引慢，如果能够让ID**按照时间粗略有序**，则可以省去这个时间字段。为什么不是按照时间精确有序呢？因为按照时间精确有序是做不到的，除非用一个单机算法，在分布式场景下做到精确有序性能一般很差。 22 | 23 | 这就引出了ID生成的三大核心需求： 24 | 25 | * 全局唯一(unique) 26 | * 按照时间粗略有序(sortable by time) 27 | * 尽可能短 28 | 29 | 30 | 下面介绍一些常用的生成ID的方法。 31 | 32 | 33 | ### UUID 34 | 35 | 用过MongoDB的人会知道，MongoDB会自动给每一条数据赋予一个唯一的[ObjectId](https://docs.mongodb.com/manual/reference/method/ObjectId/),保证不会重复，这是怎么做到的呢？实际上它用的是一种UUID算法，生成的ObjectId占12个字节，由以下几个部分组成， 36 | 37 | * 4个字节表示的Unix timestamp, 38 | * 3个字节表示的机器的ID 39 | * 2个字节表示的进程ID 40 | * 3个字节表示的计数器 41 | 42 | [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier)是一类算法的统称，具体有不同的实现。UUID的有点是每台机器可以独立产生ID，理论上保证不会重复，所以天然是分布式的，缺点是生成的ID太长，不仅占用内存，而且索引查询效率低。 43 | 44 | 45 | ### 多台MySQL服务器 46 | 47 | 既然MySQL可以产生自增ID，那么用多台MySQL服务器，能否组成一个高性能的分布式发号器呢？ 显然可以。 48 | 49 | 假设用8台MySQL服务器协同工作，第一台MySQL初始值是1，每次自增8，第二台MySQL初始值是2，每次自增8，依次类推。前面用一个 round-robin load balancer 挡着，每来一个请求，由 round-robin balancer 随机地将请求发给8台MySQL中的任意一个，然后返回一个ID。 50 | 51 | [Flickr就是这么做的](http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/)，仅仅使用了两台MySQL服务器。可见这个方法虽然简单无脑，但是性能足够好。不过要注意，在MySQL中，不需要把所有ID都存下来，每台机器只需要存一个MAX_ID就可以了。这需要用到MySQL的一个[REPLACE INTO](http://dev.mysql.com/doc/refman/5.0/en/replace.html)特性。 52 | 53 | 这个方法跟单台数据库比，缺点是**ID是不是严格递增的**，只是粗略递增的。不过这个问题不大，我们的目标是粗略有序，不需要严格递增。 54 | 55 | 56 | ### Twitter Snowflake 57 | 58 | 比如 Twitter 有个成熟的开源项目，就是专门生成ID的，[Twitter Snowflake](https://github.com/twitter/snowflake) 。Snowflake的核心算法如下： 59 | 60 | ![](http://121.40.136.3/wp-content/uploads/2015/04/snowflake-64bit.jpg) 61 | 62 | 最高位不用，永远为0，其余三组bit占位均可浮动，看具体的业务需求而定。默认情况下41bit的时间戳可以支持该算法使用到2082年，10bit的工作机器id可以支持1023台机器，序列号支持1毫秒产生4095个自增序列id。 63 | 64 | [Instagram用了类似的方案](https://engineering.instagram.com/sharding-ids-at-instagram-1cf5a71e5a5c)，41位表示时间戳，13位表示shard Id(一个shard Id对应一台PostgreSQL机器),最低10位表示自增ID，怎么样，跟Snowflake的设计非常类似吧。这个方案用一个PostgreSQL集群代替了Twitter Snowflake 集群，优点是利用了现成的PostgreSQL，容易懂，维护方便。 65 | 66 | 有的面试官会问，如何让ID可以粗略的按照时间排序？上面的这种格式的ID，含有时间戳，且在高位，恰好满足要求。如果面试官又问，如何保证ID严格有序呢？在分布式这个场景下，是做不到的，要想高性能，只能做到粗略有序，无法保证严格有序。 67 | 68 | 69 | ### 参考资料 70 | 71 | * [Sharding & IDs at Instagram](https://engineering.instagram.com/sharding-ids-at-instagram-1cf5a71e5a5c) 72 | * [Ticket Servers: Distributed Unique Primary Keys on the Cheap](http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/) 73 | * [Twitter Snowflake](https://github.com/twitter/snowflake) 74 | * [细聊分布式ID生成方法 - 沈剑](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=403837240&idx=1&sn=ae9f2bf0cc5b0f68f9a2213485313127&scene=21) 75 | * [服务化框架－分布式Unique ID的生成方法一览 - 江南白衣](http://calvin1978.blogcn.com/articles/uuid.html) 76 | * [生成全局唯一ID的3个思路，来自一个资深架构师的总结](https://mp.weixin.qq.com/s?__biz=MzI4MTY5NTk4Ng==&mid=2247489561&idx=1&sn=7396f373af4efa62ba4dbecc6d7f83b3&source=41) 77 | -------------------------------------------------------------------------------- /cn/filesystem-cache.md: -------------------------------------------------------------------------------- 1 | 如何设计一个文件系统缓存？ 2 | 3 | 在 Linux 操作系统中，当应用程序需要读取文件中的数据时，操作系统先分配一些内存，将数据从磁盘读入到这些内存中，然后再将数据传给应用程序；当需要往文件中写数据时，操作系统先分配内存接收用户数据，然后再将数据从内存写到磁盘上。文件 Cache 管理指的就是对这些由操作系统分配，并用来存储文件数据的内存的管理。 4 | 5 | 6 | ## 短网址的长度 7 | 8 | ## 参考资料 9 | 10 | * [Linux 内核的文件 Cache 管理机制介绍-IBM](https://www.ibm.com/developerworks/cn/linux/l-cache/) 11 | * [Ticket Servers: Distributed Unique Primary Keys on the Cheap](http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/) 12 | * [Twitter Snowflake](https://github.com/twitter/snowflake) 13 | * [短 URL 系统是怎么设计的？](https://www.zhihu.com/question/29270034) 14 | -------------------------------------------------------------------------------- /cn/hashmap.md: -------------------------------------------------------------------------------- 1 | 请设计一个线程安全的HashMap。 2 | 3 | 先回顾一下普通的哈希表(HashMap)是怎么写出来的，再讨论如何做到线程安全。HashMap的核心在于如何解决哈希冲突，主流思路有两种， 4 | 5 | * 开地址法(Open addressing). 即所有元素在一个一维数组里，遇到冲突则按照一定规则向后跳，假设元素x原本在位置`hash(x)%m`（m表示数组长度），那么第i次冲突时位置变为`Hi = [hash(x) + di] % m`，其中`di`表示第i次冲突时人为加上去的偏移量。偏移量`di`一般有如下3种计算方法， 6 | 7 | 1. 线性探测法(Linear Probing)。非常简单，发现位子已经被占了，则向后移动1位，即$$d_i = i$$, i=1,2,3,... 8 | 9 | 该算法最大的优点在于计算速度快，对CPU高速缓存友好；其缺点也非常明显，假设3个元素x1，x2，x3的哈希值都相同，记为p, x1先来，查看位置p，是空，则x1被映射到位置p，x2后到达，查看位置p，发生第一次冲突，向后探测一下，即p+1，该位置为空，于是x2映射到p+1, 同理，计算x3的位置需要探测位置p, p+1, p+2，也就是说对于发生冲突的所有元素，在探测过程中会扎堆，导致效率低下，这种现象被称为clustering。 10 | 11 | 1. 二次探测法(Quadratic Probing)。$$d_i=ai^2+bi+c$$, 其中a,b,c为系数，$$d_i$$是i的二次函数，所以称为二次探测法。该算法的性能介于线性探测和双哈希之间。 12 | 1. 双哈希法(Double Hashing)。偏移量di由另一个哈希函数计算而来，设为`hash2(x)`，则`di=(hash2(x) % (m-1) + 1) * i` 13 | 14 | * 拉链法(Chaining)。开一个定长数组，每个格子指向一个桶(Bucket, 可以用单链表或双向链表表示)，对每个元素计算出哈希并取模，找到对应的桶，并插入该桶。发生冲突的元素会处于同一个桶中。 15 | 16 | JDK7和JDK8里`java.util.HashMap`采取了拉链法。 17 | 18 | 如何将基于拉链法的HashMap改造为线程安全的呢？有以下几个思路， 19 | 20 | * 将所有public方法都加上synchronized. 相当于设置了一把全局锁，所有操作都需要先获取锁，`java.util.HashTable`就是这么做的，性能很低 21 | * 由于每个桶在逻辑上是相互独立的，将每个桶都加一把锁，如果两个线程各自访问不同的桶，就不需要争抢同一把锁了。这个方案的并发性比单个全局锁的性能要好，不过锁的个数太多，也有很大的开销。 22 | * 锁分离(Lock Stripping)技术。第2个方法把锁的压力分散到了多个桶，理论上是可行的的，但是假设有1万个桶，就要新建1万个`ReentrantLock`实例，开销很大。可以将所有的桶均匀的划分为16个部分，每一部分成为一个段(Segment)，每个段上有一把锁，这样锁的数量就降低到了16个。JDK 7里的`java.util.concurrent.ConcurrentHashMap`就是这个思路。 23 | * 在JDK8里，ConcurrentHashMap的实现又有了很大变化，它在锁分离的基础上，大量利用了了CAS指令。并且底层存储有一个小优化，当链表长度太长（默认超过8）时，链表就转换为红黑树。链表太长时，增删查改的效率比较低，改为红黑树可以提高性能。JDK8里的ConcurrentHashMap有6000多行代码，JDK7才1500多行。 24 | 25 | 26 | ### 方案1: JDK7版本，锁分离 27 | 28 | TODO 29 | 30 | 31 | ### 方案2: JDK8版本，锁分离+CAS+红黑树 32 | 33 | TODO 34 | 35 | 36 | ### 参考资料 37 | 38 | * [ConcurrentHashMap.java - JDK8](http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/util/concurrent/ConcurrentHashMap.java) 39 | * [ConcurrentHashMap.java - JDK7](http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/java/util/concurrent/ConcurrentHashMap.java) 40 | * [Java 8系列之重新认识HashMap - 美团点评技术团队](http://tech.meituan.com/java-hashmap.html) 41 | * [JDK1.8源码分析之HashMap（一） - 博客园](http://www.cnblogs.com/leesf456/p/5242233.html) 42 | * [ConcurrentHashMap - 博客园](http://www.cnblogs.com/yydcdut/p/3959815.html) 43 | * [探索jdk8之ConcurrentHashMap 的实现机制 - 博客园](http://www.cnblogs.com/huaizuo/p/5413069.html) 44 | * [《Java源码分析》：ConcurrentHashMap JDK1.8 - CSDN](http://blog.csdn.net/u010412719/article/details/52145145) 45 | * [ConcurrentHashMap源码解读(put/transfer/get)-jdk8](https://bentang.me/tech/2016/12/01/jdk8-concurrenthashmap-1/) 46 | * [ConcurrentHashMap源码分析（JDK8版本）](http://blog.csdn.net/u010723709/article/details/48007881) 47 | * [ConcurrentHashMap源码分析--Java8](http://note.youdao.com/share/?id=dde7a10b98aee57676408bc475ab0680&type=note/) 48 | * [聊聊并发（四）——深入分析ConcurrentHashMap - InfoQ](http://www.infoq.com/cn/articles/ConcurrentHashMap) 49 | * [探索 ConcurrentHashMap 高并发性的实现机制 - IBM](https://www.ibm.com/developerworks/cn/java/java-lo-concurrenthashmap/) 50 | * [ConcurrentHashMap源码解析 - Github](https://github.com/BingLau7/blog/issues/14) 51 | * [并发与并行的区别？ - 知乎](https://www.zhihu.com/question/33515481/answer/105348019) 52 | * [深入理解Java内存模型（一） - 基础](http://www.infoq.com/cn/articles/java-memory-model-1) 53 | * [深入理解Java内存模型（二） - 重排序](http://www.infoq.com/cn/articles/java-memory-model-2) 54 | * [深入理解Java内存模型（三） - 顺序一致性](http://www.infoq.com/cn/articles/java-memory-model-3) 55 | * [深入理解Java内存模型（四） - volatile](http://www.infoq.com/cn/articles/java-memory-model-4) 56 | * [深入理解Java内存模型（五） - 锁](http://www.infoq.com/cn/articles/java-memory-model-5) 57 | * [深入理解Java内存模型（六） - final](http://www.infoq.com/cn/articles/java-memory-model-6) 58 | * [深入理解Java内存模型（七） - 总结](http://www.infoq.com/cn/articles/java-memory-model-7) 59 | * [一种简单又高效的True Lock-free HashMap c++实现](https://zhuanlan.zhihu.com/p/348414580) 60 | -------------------------------------------------------------------------------- /cn/key-value-store.md: -------------------------------------------------------------------------------- 1 | 请设计一个Key-Value存储引擎(Design a key-value store)。 2 | 3 | 这是一道频繁出现的题目，个人认为也是一道很好的题目，这题纵深非常深，内行的人可以讲的非常深。 4 | 5 | 首先讲两个术语，**数据库**和**存储引擎**。数据库往往是一个比较丰富完整的系统, 提供了SQL查询语言，事务和水平扩展等支持。然而存储引擎则是小而精, 纯粹专注于单机的读/写/存储。一般来说, 数据库底层往往会使用某种存储引擎。 6 | 7 | 目前开源的KV存储引擎中，RocksDB是流行的一个，MongoDB和MySQL底层可以切换成RocksDB， TiDB底层直接使用了RocksDB。大多数分布式数据库的底层不约而同的都选择了RocksDB。 8 | 9 | RocksDB最初是从LevelDB进化而来的，我们先从简单一点的LevelDB入手，借鉴它的设计思路。 10 | 11 | 12 | ## LevelDB整体结构 13 | 14 | 有一个反直觉的事情是，**内存随机写甚至比硬盘的顺序读还要慢**，磁盘随机写就更慢了，说明我们要避免随机写，最好设计成顺序写。因此好的KV存储引擎，都在尽量避免更新操作，把更新和删除操作转化为顺序写操作。LevelDB采用了一种SSTable的数据结构来达到这个目的。 15 | 16 | SSTable(Sorted String Table)就是一组按照key排序好的 key-value对, key和value都是字节数组。SSTable既可以在内存中，也可以在硬盘中。SSTable底层使用LSM Tree(Log-Structured Merge Tree)来存放有序的key-value对。 17 | 18 | LevelDB整体由如下几个组成部分， 19 | 20 | 1. MemTable。即内存中的SSTable，新数据会写入到这里，然后批量写入磁盘，以此提高写的吞吐量。 21 | 1. Log文件。写MemTable前会写Log文件，即用WAL(Write Ahead Log)方式记录日志，如果机器突然掉电，内存中的MemTable丢失了，还可以通过日志恢复数据。WAL日志是很多传统数据库例如MySQL采用的技术，详细解释可以参考[数据库如何用 WAL 保证事务一致性？ - 知乎专栏](https://zhuanlan.zhihu.com/p/24900322)。 22 | 1. Immutable MemTable。内存中的MemTable达到指定的大小后，将不再接收新数据，同时会有新的MemTable产生，新数据写入到这个新的MemTable里，Immutable MemTable随后会写入硬盘，变成一个SST文件。 23 | 1. `SSTable`文件。即硬盘上的SSTable，文件尾部追加了一块索引，记录key->offset，提高随机读的效率。SST文件为Level 0到Level N多层，每一层包含多个SST文件；单个SST文件容量随层次增加成倍增长；Level0的SST文件由Immutable MemTable直接Dump产生，其他Level的SST文件由其上一层的文件和本层文件归并产生。 24 | 1. Manifest文件。 Manifest文件中记录SST文件在不同Level的分布，单个SST文件的最大最小key，以及其他一些LevelDB需要的元信息。 25 | 1. Current文件。从上面的介绍可以看出，LevelDB启动时的首要任务就是找到当前的Manifest，而Manifest可能有多个。Current文件简单的记录了当前Manifest的文件名。 26 | 27 | ![](../images/leveldb/architecture.png) 28 | 29 | LevelDB的一些核心逻辑如下， 30 | 31 | 1. 首先SST文件尾部的索引要放在内存中，这样读索引就不需要一次磁盘IO了 32 | 1. 所有读要先查看`MemTable`，如果没有再查看内存中的索引 33 | 1. 所有写操作只能写到`MemTable`, 因为SST文件不可修改 34 | 1. 定期把`Immutable MemTable`写入硬盘，成为`SSTable`文件，同时新建一个`MemTable`会继续接收新来的写操作 35 | 1. 定期对`SSTable`文件进行合并 36 | 1. 由于硬盘上的`SSTable`文件是不可修改的，那怎么更新和删除数据呢？对于更新操作，追加一个新的key-value对到文件尾部，由于读`SSTable`文件是从前向后读的，所以新数据会最先被读到；对于删除操作，追加“墓碑”值(tombstone)，表示删除该key，在定期合并`SSTable`文件时丢弃这些key, 即可删除这些key。 37 | 38 | 39 | ## Manifest文件 40 | 41 | Manifest文件记录各个SSTable各个文件的管理信息，比如该SST文件处于哪个Level，文件名称叫啥，最小key和最大key各自是多少，如下图所示， 42 | 43 | ![](../images/leveldb/manifest.png) 44 | 45 | 46 | ## Log文件 47 | 48 | Log文件主要作用是系统发生故障时，能够保证不会丢失数据。因为在数据写入内存中的MemTable之前，会先写入Log文件，这样即使系统发生故障，MemTable中的数据没有来得及Dump到磁盘，LevelDB也可以根据log文件恢复内存中的MemTable，不会造成系统丢失数据。这个方式就叫做 WAL(Write Ahead Log)，很多传统数据库例如MySQL也使用了WAL技术来记录日志。 49 | 50 | 每个Log文件由多个block组成，每个block大小为32K，读取和写入以block为基本单位。下图所示的Log文件包含3个Block， 51 | 52 | ![](../images/leveldb/log.png) 53 | 54 | 55 | ### SSTable 56 | 57 | ![](../images/leveldb/sstable.png) 58 | 59 | 60 | ## MemTable 61 | 62 | MemTable 是内存中的数据结构，存储的内容跟硬盘上的SSTable一样，只是格式不一样。Immutable MemTable的内存结构和Memtable是完全一样的，区别仅仅在于它是只读的，而MemTable则是允许写入和读取的。当MemTable写入的数据占用内存到达指定大小，则自动转换为Immutable Memtable，等待Dump到磁盘中，系统会自动生成一个新的MemTable供写操作写入新数据，理解了MemTable，那么Immutable MemTable自然不在话下。 63 | 64 | MemTable里的数据是按照key有序的，因此当插入新数据时，需要把这个key-value对插入到合适的位置上，以保持key有序性。MemTable底层的核心数据结构是一个跳表(Skip List)。跳表是红黑树的一种替代数据结构，具有更高的写入速度，而且实现起来更加简单，请参考[跳表(Skip List)](appendix/skip-list.md)。 65 | 66 | 67 | 前面我们介绍了LevelDB的一些内存数据结构和文件，这里开始介绍一些动态操作，例如读取，写入，更新和删除数据，分层合并，错误恢复等操作。 68 | 69 | 70 | ## 添加、更新和删除数据 71 | 72 | LevelDB写入新数据时，具体分为两个步骤： 73 | 74 | 1. 将这个操作顺序追加到log文件末尾。尽管这是一个磁盘操作，但是文件的顺序写入效率还是跟高的，所以不会降低写入的速度 75 | 1. 如果log文件写入成功，那么将这条key-value记录插入到内存中MemTable。 76 | 77 | LevelDB更新一条记录时，并不会本地修改SST文件，而是会作为一条新数据写入MemTable，随后会写入SST文件，在SST文件合并过程中，新数据会处于文件尾部，而读取操作是从文件尾部倒着开始读的，所以新值一定会最先被读到。 78 | 79 | LevelDB删除一条记录时，也不会修改SST文件，而是用一个特殊值(墓碑值，tombstone)作为value，将这个key-value对追加到SST文件尾部，在SST文件合并过程中，这种值的key都会被忽略掉。 80 | 81 | 核心思想就是把写操作转换为顺序追加，从而提高了写的效率。 82 | 83 | 84 | ## 读取数据 85 | 86 | 读操作使用了如下几个手段进行优化： 87 | 88 | * MemTable + SkipList 89 | * Binary Search(通过 manifest 文件) 90 | * 页缓存 91 | * bloom filter 92 | * 周期性分层合并 93 | 94 | 95 | ## 分层合并(Leveled Compaction) 96 | 97 | 98 | ### 参考资料 99 | 100 | * [SSTable and Log Structured Storage: LevelDB - igvita.com](https://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/) 101 | * [数据分析与处理之二（Leveldb 实现原理） - Haippy - 博客园](http://www.cnblogs.com/haippy/archive/2011/12/04/2276064.html) 102 | * [Log Structured Merge Trees(LSM) 原理 - OPEN 开发经验库](http://www.open-open.com/lib/view/open1424916275249.html) 103 | * [从朴素解释出发解释leveldb的设计 | ggaaooppeenngg](https://ggaaooppeenngg.github.io/zh-CN/2017/03/31/%E4%BB%8E%E6%9C%B4%E7%B4%A0%E8%A7%A3%E9%87%8A%E5%87%BA%E5%8F%91%E8%A7%A3%E9%87%8Aleveldb%E7%9A%84%E8%AE%BE%E8%AE%A1/index.html) 104 | * [LSM 算法的原理是什么？ - 知乎](https://www.zhihu.com/question/19887265) 105 | * [数据库如何用 WAL 保证事务一致性？ - 知乎专栏](https://zhuanlan.zhihu.com/p/24900322) 106 | * [LevelDB系列概述 - 360基础架构组](http://chuansong.me/n/1509342851514) 107 | * [存储引擎技术架构与内幕 (leveldb-1) - GitHub](https://github.com/abbshr/abbshr.github.io/issues/58) 108 | * [leveldb中的SSTable (3)](http://bean-li.github.io/leveldb-sstable-bloom-filter/) 109 | -------------------------------------------------------------------------------- /cn/load-balancer.md: -------------------------------------------------------------------------------- 1 | 请设计一个load balancer。 2 | -------------------------------------------------------------------------------- /cn/method.md: -------------------------------------------------------------------------------- 1 | 2 | ## 系统设计考察的是什么？ 3 | 4 | 系统设计这个面试环节，首先当然是考察候选人的对**系统(System)**底层的了解，然后考察的是候选人的**架构(Architect)**能力，在各种工具和方案中组合出最合适的。最后，大部分系统设计题是开放型的题目，这时候**沟通(Communication)**很重要，要多问面试官，理解题意，给出一个能自圆其说的结论。 5 | 6 | 7 | ## 设计容量 8 | 9 | 搭建一个服务，跟建造一个房子一样，是有开发成本的。不同容量的系统，需要的人月数完全不一样，成本差别巨大。拿到一个题目，首先要问面试者，希望抗住多少流量，多大的QPS或者多少在线用户等。 10 | 11 | 12 | 13 | 这个题目我一直在考虑要不要写，因为有一天也许我们彼此会坐在一方小桌的两端，聊聊系统设计，而我这么做有泄题兜底之嫌。不过，考虑到不是所有的读者都会来 TubiTV 这座小庙面试，而这个方面的确是很多朋友的弱项，我就略说几句。 14 | 15 | 请听题：一个使用 rail（或者 django，或者 express，...）和 MySQL 做的 API 系统，最近流量从 6,000 RPM 激增至 20,000 RPM，整个系统的压力骤升，现在需要在应用层设计一套缓存方案来降低整个系统的负荷。要求是：缓存方案不能在 web 层（包括 proxy）做，也不能使用 framework 自带的，或者第三方的缓存模块。 16 | 17 | 大部分的面试者一看，这问题简单啊，使用 redis（或者 memcached），加在应用服务器和数据库服务器之间，读取数据的时候如果没有命中缓存，则读取数据库并写入缓存，下次再读相同的数据时就能命中缓存，大大减轻数据库的压力了。 18 | 19 | 这回答对么？不好说。也许对，也许不对。但你要这么快抢答的话基本上就会被面试官毙了。 20 | 21 | 系统设计的面试重在讨论和交流，厘清一切限制条件，然后在这些限制条件下面找到一个比较合理的解决方案。它不是编程题或者算法题，弄清楚题目的要求就可以写开始答案的。 22 | 23 | 好的面试者应该主动发问，来尽量找全限制条件，而不是直接假设。拿上述回答来说，面试者还没开始认真分析问题所在，就想当然认为压力在数据库一侧（是的，流量激增之后 90% 的可能性都是数据库先扛不住压力，但这是假设，不能化作前提），从可能错误的前提出发，必然会得出一个很可能错误的解决方案。 24 | 25 | 所以比较对路的思考过程是： 26 | 27 | 现有系统的架构是什么样子？ 28 | 29 | 作为一个已有系统的优化项目，不了解现有系统的架构，历史（演变的过程和演变的原因，当然，在面试中这个可以省去）而立刻上手设计都是在耍流氓。 30 | 31 | web 服务器，应用服务器，数据库服务器等之间的关系以及数量？ 32 | 33 | 现在有没有使用类似于 redis / memcached 的缓存服务器？如果有，它们用来处理什么任务？（如果有人问道这个，会有大大的加分） 34 | 35 | 目前哪个部分在系统中压力最大？ 36 | 37 | 这个问题非常重要，你得需要先知道问题在哪再考虑优化。如果问题出在应用服务器，那么，可能需要做页面级的缓存；如果问题出在数据库服务器上，可以做数据级或者页面级的缓存。 38 | 39 | 我们希望达到一个什么样的 capacity？ 40 | 41 | 很多有多年一线工作经验的面试者在这样一个系统设计中竟然不去考虑究竟需要一个什么样的 capacity，就进入到具体的解决方案，这样是不妥的。capacity 因问题而异，在这例子中，起码要考虑 1) 缓存系统每秒的处理能力 2) 缓存系统的容量。对于一个 20k PRM 的请求数量，缓存系统应该能承受 50k，100k，甚至 200k PRM 的请求。至于容量，应该考虑假设所有不同的请求都被缓存（worst case），需要多大的容量，在限定的软硬件条件下，是否能达到这个容量，达不到的话，什么样的上限比较合理。 42 | 43 | 有了这样一个目标后，你还需要对你要使用的工具有个谱。有一个面试者说用 redis 做缓存，因为 redis 很快。「很快」是个很虚的概念，我于是问这个面试者你觉得 redis 对于 1k 大小的value，在 commodity hardware 上做 GET 操作每秒钟的 QPS 是多少？对此，面试者一点概念也没有，我让他猜，他竟然给了个 3-5k QPS 的估值。我自己印象中 redis benchmark GET 操作大概是 100k 这个数量级，当然，每次返回 1k 大小的数据会拖累这个结果，但绝不会差出来两个数量级。 44 | 45 | 有了设计容量的概念后，我们需要知道要缓存数据的大小，这其中，median size，average size，max size 都需要了解一下，起码知道是什么量级。返回 2k 大小的数据和 200k 大小的数据的处理方式可能是完全不同的，假设你的缓存系统的容量是 1M，2k 数据大小的缓存直接占用的内存是 2G，而 200k 则是 200G，后者显然不能使用内存来做缓存，只能用文件系统缓存。 46 | 47 | 讲到文件系统，多说两句。用文件系统做缓存则需要注意 unix 的目录实际上是一个记录文件名和 inode 对应关系的 map（你可以 ls -ai1 . 查看）。单个目录下的文件越多，这个 map 越大，需要的读取次数就越多（一般系统调用会每次读 32k 或者类似的量级），所以当一个目录下的文件特别多时，访问效率会急剧下降。这是为什么常见的文件缓存系统都是用两级甚至多级目录，1M 个文件，一级目录使用两个字母或数字，可以有 (26 + 10) 平方个二级目录，也就是 1296 个目录，每个目录名两个字节，加上 inode 和其他一些消耗， 10-20 字节完全够用，一次读取就能获得所有二级目录，而二级目录平均是 772 个文件，一次读取也能完成，总共两次读取，找到缓存文件，而如果把 1M 个文件放在一个目录下，如果每个记录 32 字节，需要 1000 次读取。这种分级缓存的思路在很多系统中都能见到，比如 TLB（不过多级 TLB 主要是为了节省内存）。 48 | 49 | 设计是否有优化的地方？ 50 | 51 | 如今，内存，硬盘已经非常便宜，很多时候我们做系统设计，已经不需要一个比特或者一个字节地去扣细节，但这并不意味着更好的，更省内存，更快运行的方案就没有价值。我曾在一个面试中和面试者讨论一个系统设计的优化，那个面试者对我「逼」着他优化算法很不理解，他认为 computation 这么便宜，钱不是问题，多加几台机器并行运算就可以了。这是一种错误的做事态度。 52 | 53 | 永远不要忘了设计应该是面向未来的，如果通过更换更好的算法，能节省数十倍的内存（bitmap vs hashmap），或者数十倍的运算（bloom filter pre-filter vs raw computation），那么你省下的不仅仅是当下的资源（或者金钱），还有未来的时间 —— 因为，当你的应用有10倍的流量时，你还能够应对自如。 54 | 55 | 此外，优化可能会从量变转化为质变。一个 analytics 应用如果每五分钟才能完成一次分析，一小时仅能进行 12 次分析；如果将其优化成 30 秒完成，一个小时就可能完成 120 次，用户可以更快地掌握趋势。 56 | 57 | 一个认为资源不是问题，钱不是问题的设计者，只能是一个平庸的设计者。 58 | 59 | 每个认真的程序员应该这样看待自己：In me the tiger sniffs the rose. 60 | 61 | https://zhuanlan.zhihu.com/p/20578447 62 | -------------------------------------------------------------------------------- /cn/news-feed.md: -------------------------------------------------------------------------------- 1 | 请设计一个信息流(news feed)。例如Facebook用户首页的信息流，微博用户的信息流，等等。 2 | -------------------------------------------------------------------------------- /cn/pagerank.md: -------------------------------------------------------------------------------- 1 | 请实现PageRank算法(Implement PageRank)。 2 | 3 | 注意要分布式。 4 | -------------------------------------------------------------------------------- /cn/search-engine.md: -------------------------------------------------------------------------------- 1 | 请实现一个搜索引擎(Design a search engine)。 2 | 3 | 下载系统， 索引系统，分析系统，查询系统。 4 | 5 | 6 | ### 参考资料 7 | 8 | * [Google Interview Question: How to design a search engin... | Glassdoor](https://www.glassdoor.com/Interview/-How-to-design-a-search-engine-If-each-document-contains-a-set-of-keywords-and-is-associated-with-a-numeric-attribute-ho-QTN_9026.htm) 9 | -------------------------------------------------------------------------------- /cn/task-scheduler.md: -------------------------------------------------------------------------------- 1 | 请实现一个定时任务调度器，有很多任务，每个任务都有一个时间戳，任务会在该时间点开始执行。 2 | 3 | 定时执行任务是一个很常见的需求，例如Uber打车48小时后自动好评，淘宝购物15天后默认好评，等等。 4 | 5 | 6 | ### 方案1: PriorityBlockingQueue + Polling 7 | 8 | 我们很快可以想到第一个办法： 9 | 10 | * 用一个`java.util.concurrent.PriorityBlockingQueue`来作为优先队列。因为我们需要一个优先队列，又需要线程安全，用`PriorityBlockingQueue`再合适不过了。你也可以手工实现一个自己的`PriorityBlockingQueue`，用`java.util.PriorityQueue` + `ReentrantLock`，用一把锁把这个队列保护起来，就是线程安全的啦 11 | * 对于生产者，可以用一个`while(true)`，造一些随机任务塞进去 12 | * 对于消费者，起一个线程，在 `while(true)`里每隔几秒检查一下队列，如果有任务，则取出来执行。 13 | 14 | 这个方案的确可行，总结起来就是**轮询(polling)**。轮询通常有个很大的缺点，就是时间间隔不好设置，间隔太长，任务无法及时处理，间隔太短，会很耗CPU。 15 | 16 | 17 | ### 方案2: PriorityBlockingQueue + 时间差 18 | 19 | 可以把方案1改进一下，`while(true)`里的逻辑变成： 20 | 21 | * 偷看一下堆顶的元素，但并不取出来，如果该任务过期了，则取出来 22 | * 如果没过期，则计算一下时间差，然后 sleep()该时间差 23 | 24 | 不再是 sleep() 一个固定间隔了，消除了轮询的缺点。 25 | 26 | **稍等！这个方案其实有个致命的缺陷**，导致它比 `PiorityBlockingQueue + Polling` 更加不可用，这个缺点是什么呢？。。。假设当前堆顶的任务在100秒后执行，消费者线程peek()偷看到了后，开始sleep 100秒，这时候一个新的任务插了进来，该任务在10秒后应该执行，但是由于消费者线程要睡眠100秒，这个新任务无法及时处理。 27 | 28 | 29 | ### 方案3: DelayQueue 30 | 31 | 方案2虽然已经不错了，但是还可以优化一下，Java里有一个[DelayQueue](http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/util/concurrent/DelayQueue.java)，完全符合题目的要求。DelayQueue 设计得非常巧妙，可以看做是一个特化版的`PriorityBlockingQueue`，它把**计算时间差并让消费者等待该时间差**的功能集成进了队列，消费者不需要关心时间差的事情了，直接在`while(true)`里不断`take()`就行了。 32 | 33 | DelayQueue的实现原理见下面的代码。 34 | 35 | ```java 36 | import java.util.PriorityQueue; 37 | import java.util.concurrent.Delayed; 38 | import java.util.concurrent.locks.Condition; 39 | import java.util.concurrent.locks.ReentrantLock; 40 | 41 | import static java.util.concurrent.TimeUnit.NANOSECONDS; 42 | 43 | public class DelayQueue { 44 | private final transient ReentrantLock lock = new ReentrantLock(); 45 | private final PriorityQueue q = new PriorityQueue(); 46 | private final Condition available = lock.newCondition(); 47 | private Thread leader = null; 48 | 49 | public DelayQueue() {} 50 | 51 | /** 52 | * Inserts the specified element into this delay queue. 53 | * 54 | * @param e the element to add 55 | * @return {@code true} 56 | * @throws NullPointerException if the specified element is null 57 | */ 58 | public boolean put(E e) { 59 | final ReentrantLock lock = this.lock; 60 | lock.lock(); 61 | try { 62 | q.offer(e); 63 | if (q.peek() == e) { 64 | leader = null; 65 | available.signal(); 66 | } 67 | return true; 68 | } finally { 69 | lock.unlock(); 70 | } 71 | } 72 | 73 | /** 74 | * Retrieves and removes the head of this queue, waiting if necessary 75 | * until an element with an expired delay is available on this queue. 76 | * 77 | * @return the head of this queue 78 | * @throws InterruptedException {@inheritDoc} 79 | */ 80 | public E take() throws InterruptedException { 81 | final ReentrantLock lock = this.lock; 82 | lock.lockInterruptibly(); 83 | try { 84 | for (;;) { 85 | E first = q.peek(); 86 | if (first == null) 87 | available.await(); 88 | else { 89 | long delay = first.getDelay(NANOSECONDS); 90 | if (delay <= 0) 91 | return q.poll(); 92 | first = null; // don't retain ref while waiting 93 | if (leader != null) 94 | available.await(); 95 | else { 96 | Thread thisThread = Thread.currentThread(); 97 | leader = thisThread; 98 | try { 99 | available.awaitNanos(delay); 100 | } finally { 101 | if (leader == thisThread) 102 | leader = null; 103 | } 104 | } 105 | } 106 | } 107 | } finally { 108 | if (leader == null && q.peek() != null) 109 | available.signal(); 110 | lock.unlock(); 111 | } 112 | } 113 | } 114 | ``` 115 | 116 | 这个代码中有几个要点要注意一下。 117 | 118 | **1. put()方法** 119 | 120 | ```java 121 | if (q.peek() == e) { 122 | leader = null; 123 | available.signal(); 124 | } 125 | ``` 126 | 127 | 如果第一个元素等于刚刚插入进去的元素，说明刚才队列是空的。现在队列里有了一个任务，那么就**应该唤醒所有在等待的消费者线程，避免了方案2的缺点**。将`leader`重置为null，这些消费者之间互相竞争，自然有一个会被选为leader。 128 | 129 | 130 | **2. 线程leader的作用** 131 | 132 | `leader`这个成员有啥作用？DelayQueue的设计其实是一个Leader/Follower模式，`leader`就是指向Leader线程的。该模式可以减少不必要的等待时间，当一个线程是Leader时，它只需要一个时间差；其他Follower线程则无限等待。比如头节点任务还有5秒就要开始了，那么Leader线程会sleep 5秒，不需要傻傻地等待固定时间间隔。 133 | 134 | 想象一下有个多个消费者线程用take方法去取任务,内部先加锁,然后每个线程都去peek头节点。如果leader不为空说明已经有线程在取了，让当前消费者无限等待。 135 | 136 | ```java 137 | if (leader != null) 138 | available.await(); 139 | ``` 140 | 141 | 如果为空说明没有其他消费者去取任务,设置leader为当前消费者，并让改消费者等待指定的时间， 142 | 143 | ```java 144 | else { 145 | Thread thisThread = Thread.currentThread(); 146 | leader = thisThread; 147 | try { 148 | available.awaitNanos(delay); 149 | } finally { 150 | if (leader == thisThread) 151 | leader = null; 152 | } 153 | } 154 | ``` 155 | 156 | 下次循环会走如下分支，取到任务结束， 157 | 158 | ```java 159 | if (delay <= 0) 160 | return q.poll(); 161 | ``` 162 | 163 | **3. take()方法中为什么释放first** 164 | 165 | ```java 166 | first = null; // don't retain ref while waiting 167 | ``` 168 | 169 | 我们可以看到 Doug Lea 后面写的注释，那么这行代码有什么用呢？ 170 | 171 | 如果删除这行代码，会发生什么呢？假设现在有3个消费者线程， 172 | 173 | * 线程A进来获取first,然后进入 else 的 else ,设置了leader为当前线程A，并让A等待一段时间 174 | * 线程B进来获取first, 进入else的阻塞操作,然后无限期等待，这时线程B是持有first引用的 175 | * 线程A等待指定时间后被唤醒，获取对象成功，出队，这个对象理应被GC回收，但是它还被线程B持有着，GC链可达，所以不能回收这个first 176 | * 只要线程B无限期的睡眠，那么这个本该被回收的对象就不能被GC销毁掉，那么就会造成内存泄露 177 | 178 | 179 | #### Task对象 180 | 181 | ```java 182 | import java.util.concurrent.Delayed; 183 | import java.util.concurrent.TimeUnit; 184 | 185 | public class Task implements Delayed { 186 | private String name; 187 | private long startTime; // milliseconds 188 | 189 | public Task(String name, long delay) { 190 | this.name = name; 191 | this.startTime = System.currentTimeMillis() + delay; 192 | } 193 | 194 | @Override 195 | public long getDelay(TimeUnit unit) { 196 | long diff = startTime - System.currentTimeMillis(); 197 | return unit.convert(diff, TimeUnit.MILLISECONDS); 198 | } 199 | 200 | @Override 201 | public int compareTo(Delayed o) { 202 | return (int)(this.startTime - ((Task) o).startTime); 203 | } 204 | 205 | @Override 206 | public String toString() { 207 | return "task " + name + " at " + startTime; 208 | } 209 | } 210 | ``` 211 | 212 | JDK中有一个接口`java.util.concurrent.Delayed`，可以用于表示具有过期时间的元素，刚好可以拿来表示任务这个概念。 213 | 214 | 215 | #### 生产者 216 | 217 | ```java 218 | import java.util.Random; 219 | import java.util.UUID; 220 | 221 | public class TaskProducer implements Runnable { 222 | private final Random random = new Random(); 223 | private DelayQueue q; 224 | 225 | public TaskProducer(DelayQueue q) { 226 | this.q = q; 227 | } 228 | 229 | @Override 230 | public void run() { 231 | while (true) { 232 | try { 233 | int delay = random.nextInt(10000); 234 | Task task = new Task(UUID.randomUUID().toString(), delay); 235 | System.out.println("Put " + task); 236 | q.put(task); 237 | Thread.sleep(3000); 238 | } catch (InterruptedException e) { 239 | e.printStackTrace(); 240 | } 241 | } 242 | } 243 | } 244 | ``` 245 | 246 | 生产者很简单，就是一个死循环，不断地产生一些是时间随机的任务。 247 | 248 | 249 | #### 消费者 250 | 251 | ```java 252 | public class TaskConsumer implements Runnable { 253 | private DelayQueue q; 254 | 255 | public TaskConsumer(DelayQueue q) { 256 | this.q = q; 257 | } 258 | 259 | @Override 260 | public void run() { 261 | while (true) { 262 | try { 263 | Task task = q.take(); 264 | System.out.println("Take " + task); 265 | } catch (InterruptedException e) { 266 | e.printStackTrace(); 267 | } 268 | } 269 | } 270 | } 271 | ``` 272 | 273 | 当 DelayQueue 里没有任务时，`TaskConsumer`会无限等待，直到被唤醒，因此它不会消耗CPU。 274 | 275 | 276 | #### 定时任务调度器 277 | 278 | ```java 279 | public class TaskScheduler { 280 | public static void main(String[] args) { 281 | DelayQueue queue = new DelayQueue<>(); 282 | new Thread(new TaskProducer(queue), "Producer Thread").start(); 283 | new Thread(new TaskConsumer(queue), "Consumer Thread").start(); 284 | } 285 | } 286 | ``` 287 | 288 | DelayQueue这个方案，每个消费者线程只需要等待所需要的时间差，因此响应速度更快。它内部用了一个优先队列，所以插入和删除的时间复杂度都是$$\log n$$。 289 | 290 | JDK里还有一个[ScheduledThreadPoolExecutor](http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java)，原理跟DelayQueue类似，封装的更完善，平时工作中可以用它，不过面试中，还是拿DelayQueue来讲吧，它封装得比较薄，容易讲清楚原理。 291 | 292 | 293 | ### 方案4: 时间轮(HashedWheelTimer) 294 | 295 | 时间轮(HashedWheelTimer)其实很简单，就是一个循环队列，如下图所示， 296 | 297 | ![](http://upload-images.jianshu.io/upload_images/584578-044ce81079679c1c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) 298 | 299 | 上图是一个长度为8的循环队列，假设该时间轮精度为秒，即每秒走一格，像手表那样，走完一圈就是8秒。每个格子指向一个任务集合，时间轮无限循环，每转到一个格子，就扫描该格子下面的所有任务，把时间到期的任务取出来执行。 300 | 301 | 举个例子，假设指针当前正指向格子0，来了一个任务需要4秒后执行，那么这个任务就会放在格子4下面，如果来了一个任务需要20秒后执行怎么？由于这个循环队列转一圈只需要8秒，这个任务需要多转2圈，所以这个任务的位置虽然依旧在格子4(20%8+0=4)下面，不过需要多转2圈后才执行。因此每个任务需要有一个字段记录需圈数，每转一圈就减1，减到0则立刻取出来执行。 302 | 303 | 怎么实现时间轮呢？Netty中已经有了一个时间轮的实现, [HashedWheelTimer.java](https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/HashedWheelTimer.java)，可以参考它的源代码。 304 | 305 | 时间轮的优点是性能高，插入和删除的时间复杂度都是O(1)。Linux 内核中的定时器采用的就是这个方案。 306 | 307 | **Follow up: 如何设计一个分布式的定时任务调度器呢？** 308 | 答: Redis ZSet, RabbitMQ等 309 | 310 | 311 | ### 参考资料 312 | 313 | * [java.util.concurrent.DelayQueue](http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/util/concurrent/DelayQueue.java) 314 | * [HashedWheelTimer.java - Github](https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/HashedWheelTimer.java) 315 | * [delayQueue原理理解之源码解析 - 简书](http://www.jianshu.com/p/e0bcc9eae0ae) 316 | * [细说延时任务的处理 - 简书](http://www.jianshu.com/p/7beebbc61229) 317 | * [延迟任务的实现总结 - nick hao - 博客园](http://www.cnblogs.com/haoxinyue/p/6663720.html) 318 | * [定时器（Timer）的实现](http://novoland.github.io/%E5%B9%B6%E5%8F%91/2014/07/26/%E5%AE%9A%E6%97%B6%E5%99%A8%EF%BC%88Timer%EF%BC%89%E7%9A%84%E5%AE%9E%E7%8E%B0.html) 319 | * [java.util.concurrent.DelayQueue Example](https://examples.javacodegeeks.com/core-java/util/concurrent/delayqueue/java-util-concurrent-delayqueue-example/) 320 | * [HashedWheelTimer 原理 - ZimZz - 博客园](http://www.cnblogs.com/zemliu/p/3928285.html) 321 | * [Hash算法系列-具体算法（HashedWheelTimer） - CSDN](http://blog.csdn.net/yq76034150/article/details/6783398) 322 | * [java Disruptor工作原理，谁能用一个比喻形容下? - 知乎](https://www.zhihu.com/question/23235063) 323 | * [1分钟实现“延迟消息”功能 - 58沈剑](http://chuansong.me/n/1673795846413) 324 | * [Linux 下定时器的实现方式分析 - IBM](https://www.ibm.com/developerworks/cn/linux/l-cn-timers/) 325 | * [1分钟了解Leader-Follower线程模型 - 58沈剑](http://chuansong.me/n/1591963946624) 326 | -------------------------------------------------------------------------------- /cn/tinyurl.md: -------------------------------------------------------------------------------- 1 | 如何设计一个短网址服务(TinyURL)？ 2 | 3 | 4 | ### 使用场景(Scenario) 5 | 6 | 微博和Twitter都有140字数的限制，如果分享一个长网址，很容易就超出限制，发布出去。短网址服务可以把一个长网址变成短网址，方便在社交网络上传播。 7 | 8 | 9 | ### 需求(Needs) 10 | 11 | 很显然，要尽可能的**短**。长度设计为多少才合适呢？ 12 | 13 | 14 | ### 短网址的长度 15 | 16 | 当前互联网上的网页总数大概是 45亿(参考 )，45亿超过了 $$2^{32}=4294967296$$，但远远小于64位整数的上限值，那么用一个64位整数足够了。 17 | 18 | 微博的短网址服务用的是长度为7的字符串，这个字符串可以看做是62进制的数，那么最大能表示$${62}^7=3521614606208$$个网址，远远大于45亿。所以**长度为7就足够了**。 19 | 20 | 一个64位整数如何转化为字符串呢？，假设我们只是用大小写字母加数字，那么可以看做是62进制数，$$log_{62} {(2^{64}-1)}=10.7$$，即字符串最长11就足够了。 21 | 22 | 实际生产中，还可以再短一点，比如新浪微博采用的长度就是7，因为 $$62^7=3521614606208$$，这个量级远远超过互联网上的URL总数了，绝对够用了。 23 | 24 | 现代的web服务器（例如Apache, Nginx）大部分都区分URL里的大小写了，所以用大小写字母来区分不同的URL是没问题的。 25 | 26 | 因此，**正确答案：长度不超过7的字符串，由大小写字母加数字共62个字母组成** 27 | 28 | 29 | ### 一对一还是一对多映射？ 30 | 31 | 一个长网址，对应一个短网址，还是可以对应多个短网址？ 这也是个重大选择问题 32 | 33 | 34 | 35 | 一般而言，一个长网址，在不同的地点，不同的用户等情况下，生成的短网址应该不一样，这样，在后端数据库中，可以更好的进行数据分析。如果一个长网址与一个短网址一一对应，那么在数据库中，仅有一行数据，无法区分不同的来源，就无法做数据分析了。 36 | 37 | 以这个7位长度的短网址作为唯一ID，这个ID下可以挂各种信息，比如生成该网址的用户名，所在网站，HTTP头部的 User Agent等信息，收集了这些信息，才有可能在后面做大数据分析，挖掘数据的价值。短网址服务商的一大盈利来源就是这些数据。 38 | 39 | 40 | **正确答案：一对多** 41 | 42 | 43 | ### 如何计算短网址 44 | 45 | 现在我们设定了短网址是一个长度为7的字符串，如何计算得到这个短网址呢？ 46 | 47 | 最容易想到的办法是哈希，先hash得到一个64位整数，将它转化为62进制整，截取低7位即可。但是哈希算法会有冲突，如何处理冲突呢，又是一个麻烦。这个方法只是转移了矛盾，没有解决矛盾，抛弃。 48 | 49 | **正确答案：[分布式发号器(Distributed ID Generator)](distributed-id-generator.md)** 50 | 51 | 52 | ### 如何存储 53 | 54 | 如果存储短网址和长网址的对应关系？以短网址为 primary key, 长网址为value, 可以用传统的关系数据库存起来，例如MySQL, PostgreSQL，也可以用任意一个分布式KV数据库，例如Redis, LevelDB。 55 | 56 | 如果你手痒想要手工设计这个存储，那就是另一个话题了，你需要完整地造一个KV存储引擎轮子。当前流行的KV存储引擎有LevelDB何RockDB，去读它们的源码吧 :D 57 | 58 | 59 | ### 301还是302重定向 60 | 61 | 这也是一个有意思的问题。这个问题主要是考察你对301和302的理解，以及浏览器缓存机制的理解。 62 | 63 | 301是永久重定向，302是临时重定向。短地址一经生成就不会变化，所以用301是符合http语义的。但是如果用了301， Google，百度等搜索引擎，搜索的时候会直接展示真实地址，那我们就无法统计到短地址被点击的次数了，也无法收集用户的Cookie, User Agent 等信息，这些信息可以用来做很多有意思的大数据分析，也是短网址服务商的主要盈利来源。 64 | 65 | 所以，**正确答案是302重定向**。 66 | 67 | 可以抓包看看新浪微博的短网址是怎么做的，使用 Chrome 浏览器，访问这个URL ，是我事先发微博自动生成的短网址。来抓包看看返回的结果是啥， 68 | 69 | ![](http://cn.soulmachine.me/images/tinyurl-302.png) 70 | 71 | 可见新浪微博用的就是302临时重定向。 72 | 73 | 74 | ### 预防攻击 75 | 76 | 如果一些别有用心的黑客，短时间内向TinyURL服务器发送大量的请求，会迅速耗光ID，怎么办呢？ 77 | 78 | 首先，限制IP的单日请求总数，超过阈值则直接拒绝服务。 79 | 80 | 光限制IP的请求数还不够，因为黑客一般手里有上百万台肉鸡的，IP地址大大的有，所以光限制IP作用不大。 81 | 82 | 可以用一台Redis作为缓存服务器，存储的不是 ID->长网址，而是 长网址->ID，仅存储一天以内的数据，用LRU机制进行淘汰。这样，如果黑客大量发同一个长网址过来，直接从缓存服务器里返回短网址即可，他就无法耗光我们的ID了。 83 | 84 | 85 | ### 参考资料 86 | 87 | * [Sharding & IDs at Instagram](https://engineering.instagram.com/sharding-ids-at-instagram-1cf5a71e5a5c) 88 | * [Ticket Servers: Distributed Unique Primary Keys on the Cheap](http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/) 89 | * [Twitter Snowflake](https://github.com/twitter/snowflake) 90 | * [短 URL 系统是怎么设计的？](https://www.zhihu.com/question/29270034) 91 | -------------------------------------------------------------------------------- /cn/top-k-frequent-ip-in-one-hour.md: -------------------------------------------------------------------------------- 1 | 实时输出最近一个小时内访问频率最高的10个IP，要求： 2 | 3 | * 实时输出 4 | * 从当前时间向前数的1个小时 5 | * QPS可能会达到10W/s 6 | 7 | 8 | 这道题乍一看很像[Top K 频繁项](bigdata/heavy-hitters.md)，是不是需要 Lossy Count 或 Count-Min Sketch 之类的算法呢？ 9 | 10 | 其实杀鸡焉用牛刀，这道题用不着上述算法，请听我仔细分析。 11 | 12 | 1. QPS是 10万/秒，即一秒内最高有 10万个请求，那么一个小时内就有 100000*3600=360000000≈$$2^{28.4}$$，向上取整，大概是 $$2^{29}$$个请求，也不是很大。我们在内存中建立3600个`HashMap`，放在一个数组里，每秒对应一个HashMap，IP地址为key, 出现次数作为value。这样，一个小时内最多有$$2^{29}$$个pair，每个pair占8字节，总内存大概是 $$2^{29} \times 8=2^{32}$$字节，即4GB，单机完全可以存下。 13 | 2. 同时还要新建一个固定大小为10的小根堆，用于存放当前出现次数最大的10个IP。堆顶是10个IP里频率最小的IP。 14 | 3. 每次来一个请求，就把该秒对应的HashMap里对应的IP计数器增1，并查询该IP是否已经在堆中存在， 15 | 16 | * 如果不存在，则把该IP在3600个HashMap的计数器加起来，与堆顶IP的出现次数进行比较，如果大于堆顶元素，则替换掉堆顶元素，如果小于，则什么也不做 17 | * 如果已经存在，则把堆中该IP的计数器也增1，并调整堆 18 | 19 | 4. 需要有一个后台常驻线程，每过一秒，把最旧的那个HashMap销毁，并为当前这一秒新建一个HashMap，这样维持一个一小时的窗口。 20 | 5. 每次查询top 10的IP地址时，把堆里10个IP地址返回来即可。 21 | 22 | 以上就是该方案的全部内容。 23 | 24 | 有的人问，可不可以用"IP + 时间"作为key, 把所有pair放在单个HashMap里？如果把所有数据放在一个HashMap里，有两个巨大的缺点， 25 | 26 | * 第4步里，怎么淘汰掉一个小时前的pair呢？这时候后台线程只能每隔一秒，全量扫描这个HashMap里的所有pair,把过期数据删除，这是线性时间复杂度，很慢。 27 | * 这时候HashMap里的key存放的是"IP + 时间"组合成的字符串，占用内存远远大于一个int。而前面的方案，不用存真正的时间，只需要开一个3600长度的数组来表示一个小时时间窗口。 28 | -------------------------------------------------------------------------------- /images/array-of-count-min-sketch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soulmachine/system-design/f807036b54e3253774851aeaa649a2bf81c136d0/images/array-of-count-min-sketch.png -------------------------------------------------------------------------------- /images/count-min-sketch.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soulmachine/system-design/f807036b54e3253774851aeaa649a2bf81c136d0/images/count-min-sketch.jpg -------------------------------------------------------------------------------- /images/leveldb/architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soulmachine/system-design/f807036b54e3253774851aeaa649a2bf81c136d0/images/leveldb/architecture.png -------------------------------------------------------------------------------- /images/leveldb/log.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soulmachine/system-design/f807036b54e3253774851aeaa649a2bf81c136d0/images/leveldb/log.png -------------------------------------------------------------------------------- /images/leveldb/manifest.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soulmachine/system-design/f807036b54e3253774851aeaa649a2bf81c136d0/images/leveldb/manifest.png -------------------------------------------------------------------------------- /images/leveldb/sstable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soulmachine/system-design/f807036b54e3253774851aeaa649a2bf81c136d0/images/leveldb/sstable.png --------------------------------------------------------------------------------