A Code

I just noticed that this question is quite old. Nevertheless, I consider the following aspects to be worth adding: Use MongoDB if you don't know yet how you're going to query your data. MongoDB is suited for Hackathons, startups or every time you don't know how you'll query the data you inserted. MongoDB does not make any assumptions on your underlying schema. While MongoDB is schemaless and non-relational, this does not mean that there is no schema at all. It simply means that your schema needs to be defined in your app (e.g. using Mongoose). Besides that, MongoDB is great for prototyping or trying things out. Its performance is not that great and can't be compared to Redis. Use Redis in order to speed up your existing application. Redis can be easily integrated as a  LRU cache . It is very uncommon to use Redis as a standalone database system (some people prefer referring to it as a "key-value"-store). Websites like Craigslist use  Redis nex...

https://www.youtube.com/watch?v=H9J5vl_Huio  reddit CEO talking scaling https://www.youtube.com/watch?v=Y6Ev8GIlbxc Distributed Systems in One Lesson by Tim Berglund https://www.youtube.com/watch?v=BhosKsE8up8&t=4525s Zookeeper：分布式系统入门到实战 https://www.youtube.com/watch?v=hyJZP-rgooc Apache Kafka Tutorial | What is Apache Kafka? | Kafka Tutorial for Beginners |  Edureka https://www.1point3acres.com/bbs/thread-160526-1-1.html

https://www.jiuzhang.com/qa/630/ 写的非常好 订票网站一直都是世界难题。12306应该比这个还恐怖。 不要被 500k QPS吓到。500k也好，5k也好，500也好，分析的方法和思路都是一样的。 这个题的关键首先是给出一个可行解（无论任何系统设计题的关键都是如此），一个核心要实现的功能是，票的预留与回收。在设计可行解的时候，可以先将500k qps抛之脑后。假设现在只有10个用户来买票。优化的事情，放到Evolve的那一步。 按照我们的 4S 分析法来： Scenario 设计些啥，设计得多牛？ 设计些啥 用户提交订票请求 客户端等待订票 预留票，用户完成支付 票过期，回收票 限制一场演唱会的票数。 设计得多牛？ 500k QPS，面试官已经给出 响应时间 ——是在用户点击的一瞬间就要完成预定么？不是，可以让用户等个几分钟。也就是说，500K的请求，可以在若干分钟内完成就好了。因此所谓的 500k QPS，并不是Average QPS，只是说峰值是 500k QPS。而你要做的事情并不是在1秒之内完成500k的预定，而是把确认你收到了购票申请就好了。 Service 服务 ReservationService —— 用户提交一个预定请求，查询自己的预定状态 TicketService —— 系统帮一个预定完成预定，生成具体的票 Storage 数据如何存储与访问 ReservationService  —— 用户提交了一个订票申请之后，把一条预定的数据写到数据库里。所以需要一个Reservation的table。大概包含的columns有： id(primary_key) created_at(timestamp) concert_id(foreign key) user_id(foreign key) tickets_count(int) status(int) 简单的说就是谁在什么时刻预定了哪个演唱会，预定了几张，当前预定状态是什么（等待，成功，失败）。 2.  TicketService  —— 系统从数据库中按照顺序 选出预定 ，完成预定，预定成功的，生成对应的Ticket。表结构如下： id (primary ...

不对。这个问题的解决流程是这样的： 首先你需要一个 log 的service，把用户的搜索信息记录下来，比如： {"apple": 1, "google": 2, "baidu": 3} 这个时候key是用户搜索的完整单词，value 是搜索次数。 然后用一个 离线 脚本，将这个结果整理为 Trie。这个时候我们称之为 Trie' 吧。在 Trie' 中，每个 TrieNode 上也只存储到此节点为一整个单词的被搜索的次数。 接着你需要再用一个离线脚本去统计，每个 Prefix 下面的 Top 10的结果是什么。http://www.lintcode.com/en/problem/trie-service/ 这个题目就是为了让大家理解怎么完成这个部分。完成这个操作之后的 Trie 我们称之为 Trie'' ，也就是此时，TrieNode 上不仅仅存储了该 Prefix 被搜索的次数，还存储了以该 Prefix 开头的 Top 10 的单词。举个例子： { "a": ["ab", "ac", "ad" ...] -- "ab": ["abc", "abe" ..] -- "ac": ["aca", "acd" ..] "b": ... ... } 也就是说，这个时候的 Trie''，在给定某个 prefix的时候，就能够直接在 O(Len(prefix)) 的时间复杂度内找到 Top K，而不需要遍历整个 Trie 去搜寻。 然后此时我们发现内存不够了，要开始 sharding了，我们可能会把 "a" 和 “ab” 分在不同的机器上，但是 a的那个小的top 10 的list，也就是["ab", "ac", "ad" .. ] 会跟着 a走，也就是虽然 ab ac ad 作为key的那个prefix，不和a在同一台...

我觉得考点有： 排序算法，你得会按照ID排序 如何存储，好友之间的关系如何存下来， <friend1, friend2> 存下来以后数据如何查询，怎么query你的数据 如何quyer 2 度，3度的数据，类似于sql的join 如何加速你的查询 这里你可以用sql的设计 和 nosql的key-value的存储两方面作答，我们的系统有讲一个差不多的 好友系统。 https://www.jiuzhang.com/qa/4361/ Linkedin - Get Second/Third Friends https://engineering.linkedin.com/real-time-distributed-graph/using-set-cover-algorithm-optimize-query-latency-large-scale-distributed Overview of Query Routing LinkedIn's distributed  graph  system consists of three major subcomponents: GraphDB : a partitioned and replicated graph  database . Network Cache Service (NCS) : a distributed cache that  stores  a member's network and serves queries requiring second degree knowledge. API layer : the  access point  for front-ends. A key challenge in a distributed graph system is that, when the graph is partitioned across a  cluster of  machines , multiple remote calls must occur during g...

32. Minimum Window Substring 30. Insert Interval 417. Valid Number 86. Binary Search Tree Iterator 1360. Symmetric Tree 934. Unlock Problem 932. Friends Within Three Jumps 1488. Longest Sequence 933. Tuple Multiply 650. Find Leaves of Binary Tree 645. Find the Celebrity(https://blog.csdn.net/magicbean2/article/details/74729767) 649. Binary Tree Upside Down *836. Partition to K Equal Sum Subsets //优化，注意从大到小排序后的剪枝处理 （Partition Equal Subset Sum）//DP解法，背包问题 can I win 面经 1132. Valid Triangle Number 528. Flatten Nested List Iterator(stack的神奇使用) //queue也可以用 474. Lowest Common Ancestor II (parent节点) max stack private : list < int > v; map < int , vector<list< int >::iterator>> m; All in O(1) private : struct Bucket { int val; unordered_set< string > keys; }; list <Bucket> buckets; unordered_map < string , list<Bucket>::iterator> m; 366 find leaves of binary tree insert...

https://github.com/checkcheckzz/system-design-interview#intro 很好的全面资料 https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#nosql http://www.learn4master.com/interview-questions/system-design/system-design%E9%9D%A2%E8%AF%95 好的资料 SQL vs. NoSQL  Structured Query Language Not only SQL  SQL vs NoSQL 是否需要支持 Transaction（事务）？NoSQL不支持Transaction 是否需要丰富的 SQL Query？NoSQL的SQL Query不是太丰富, 也有一些NoSQL的数据库提供简单的SQL Query支持 是否想偷懒？ 大多数 Web Framework 与 SQL 数据库兼容得很好 用SQL比用NoSQL少写很多代码 是否需要Sequential ID？ SQL 为你提供了 auto-increment 的 Sequential ID。也就是1,2,3,4,5 … NoSQL的ID并不是 Sequential 的 对QPS的要求有多高？ NoSQL 的性能更高 对Scalability的要求有多高？ SQL 需要码农自己写代码来 Scale 还记得Db那节课中怎么做 Sharding，Replica 的么？NoSQL 这些都帮你做了 SQL优点:  1, 事务处理 保持数据的一致性；（是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit) ） 2，由于以标准化为前提，数据更新的开销很小（相同的字段基本上只有一处）； 3，可以进行Join等复杂查询。 缺点： 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难; 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，...