binling的专栏

Elastic Search 的分布式特点(和MongoDB对比）回顾一下mongoDB的分布式： replica set：若干mongod组成，只有一个master可写，自动选举 。 sharding: 若干mongos 作为前端router，每个shard对应一个replica set，还有一个replica set作为sharding metatadata的存储（config s

1 给一棵树，查询任意两个结点是否有祖先关系，1）只查一次lca，如果返回值是给定的两个结点之一，有祖先关系，否则无祖先关系。2）任意多次查询DFS 序，做dfs，记录每个结点进入和离开的时间（不必是真的时间戳，一个整数就好）time = 0def dfs(v): l[v] = ++time for child in G[v]: dfs(child) r[v] =

问题：给定一个词典，包括一些词和其出现的频率。实现type ahead功能，要求用户每键入一个字符，下拉框显示以当前输入为前缀的前10个最热门的词解法1:用不带data的Trie，实时查询法框架就是Triie的 startWithPrefix 查询，不同的是并不是返回遍历得到的所有词，而是像经典求top k那样，用一个大小为k的最小堆过滤。解法2: 用 带data的 T

从一个分布式系统面临的一般问题：1 Multicast 问题centralspan tree basedgossip2 membership 维护问题

已知一个消息流会不断地吐出整数1~N，但不一定按照顺序吐出。如果上次打印的数为i，那么当i+1出现时,请打印i+1及其之后接收过的并且连续的所有数,直到1~N全部接收并打印完，请设计这种接收并打印的结构。消息流吐出 2,一种结构接收而不打印 2,因为 1 还没出现。消息流吐出 1,一种结构接收 1,并且打印:1,2。class TCPReceiver {priva

1 堆文件类似数据库的堆表，内存管理中的堆，记录是无序存储的，要访问一个记录需要知道其地址（位移），mds的masterBin就是这种文件，自己维护metadata(pointer table)2散列文件记录按照key散列到块， hash(key) % n，n是总块数。然后存入块里，如果块满了，就插入到溢出桶（拉链法）缺点，只能根据key来取一条记录（bookmark查询）

索引的本质是关联、link，key -> 记录地址（ row locator等）或者字段 -> 主Id 的一个映射正排索引：id -> (col1, col2, col3), docId - > { wordId }倒排索引：col -> id， wordId -> docId为什么需要倒排索引？关系是这样的：用col 通过倒排索引得到Id, 进而用Id通过正排得到整体，也就是得到

几个Object: logical array, paged index files, data filesLogical Array: 1) head index: next array index to append2) tail index: start index of the array, typically 0, if not wrapped这两个是logica

程序就是一些互相引用的内存快，互相发消息。每个内存块就是一个状态机，状态的迁移规则是定制好的一些消息（方法）。构造函数用来初始化状态。一个内存块的方法除了改变自身状态，也有可能向引用的别内存快发消息，引起别的内存块发生状态转移。重点不在过程化的code，而在对象的状态，code只是定制好的对象状态转移的规则，重在掌握状态怎么转移。程序运行就是对象状态转移，一切都是状态，结果

Persistent Queue的实现方式：1）Berkeley DB，一个基于文件的高效的key-value store。需要一个从key-value 存取系统到 FIFO存取系统的转换。维护一个自增的Long型的key，队头就是最小的key，队尾就是最大的key。2）paged file。队列由一系列文件或者块组成，只有第一个块和最后一个块是hot的，需要map到memory里

之前的solution是POSIX based filesystem： 一些NAS(Network attached storage) 设备mount 到NFS上主要问题：per file metadata 导致过多的disk operation because of metadata lookup。读取一个文件一般至少3个步骤1）一次或者多次disk operation 访问到dir

The Architecture and Design of a Publish & Subscribe Messaging System Tailored for Big Data Collecting and AnalyticsMAR 27TH, 2013 | COMMENTSOverviewWith the advent of big data era, we a

indexer 主要包含：html parser，word generator， url id generator，inverted index（keyword->[docId]，docs table（url, id, refCount)word generator的职责是输入一个text文本，返回一个word iterable。具体参数有，最小word长度，exclude list，

一涉及到persistent， 哪怕只是最基本的需求，很多人都会依赖数据库，或是其他现成的库或工具。确实，对于文件，大部分人很少直接打交道，或者只是诸如整体反序列化/序列化、按行读取、append new line等有限的操作。一个persistent store最基本的问题是如何组织数据，也就是access method, 大致有：1）队列（定长记录 or 不定长记录): kaf

Cluster  and Replicate和mysql 类似，全局级的replicate 配置（cassandra 是每个key space可以独立配置） ，一个master，多个secondary，写只能在master上一致性：写操作返回可以配置为1）全部副本写成功（complete），2）多数（majority），3）只是primary写成功，4）仅仅是成功交给primary（f

1 调度算法Capacity based， DRF(dominant recourse fairness)，label based等多态化，插件化，可以多种策略一起工作，对应于不同Job （优先级，job特性，service or batch job)2 容错，HA调度器一般处在一个中心位置，存在SPF问题。可以采用类似HDFS，JobTracker的HA方案1）act

依赖于连续存储的数据结构（具体的，就是依赖array）都有一个resizing问题。对于vector，一般的策略就是满的时候double and copy，降到1/4时候 half 。Hashtable也可以这么做，均摊的复杂度模型是一样的。比如load factor （number of entry / hash table size) 大于5的时候触发 resize，创建一个double

1最基本的，一个数据流（文件），求top k biggest. solution：维护大小为K的最小堆，和堆顶比，大于堆顶的加入堆，如果size  超过K，移除堆顶。2一般的是Top K frequent，需要先统计每个数据的个数（频率）。主要看全部unique的数据size（乘上计数值size）是否可以装进内存，可以的话，直接symbol table计数，然后再维护key为频率，

设计一般流程：黑盒：1用例分析白盒：2 识别类：分析阶段只identify 问题领域的类，设计阶段可能添加软件世界特有的类，或者    3 识别类之间的关系（关联，泛华，聚合，组合，依赖）    4）画顺序图，结合用例图，完善类图类图是结构设计，顺序图是动态交互设计设计还有一个重要部分是：控制驱动设计，识别主动对象。系统可以看作是一堆对象，对象可以接受消息提供服务，但是一般

普通heap支持的操作和queue, stack一样，就是push, pop，只是pop出的是最小值，具体点就是add, delMinhashheap支持一般HashMap的功能，同时维护最小值，和LinkedHashMap是对等的，后者是HashMap加上维护先后关系，hashHeap其实叫HeapedHashMap更科学。LinkedHashMap -> LRUHeapedHash

Two Phase CommitMVCCPaxosTPC对应于传统数据库上的local cluster的一致性，分布式事务，每个节点上的local事务可以是不同的亦可以是相同的（replica）MVCC的思想是抓住Transaction的本质：server state从一个一致性state迁移到另一个一致性state，也就是Transaction是工作在一个snap

先OO分析、建模，再研究具体问题。这里面涉及的对象：1）线程2）锁关系：占有：线程——锁 的一对多关系：一个线程可以占有多个锁，一个锁只能被一个线程占有等待：线程——锁 的多对多关系：一个线程可以等待多个锁，一个锁可以被多个线程等待间接等待关系 线程——线程 的多对多关系，一个线程A等待的锁被另一个线程B拥有，则线程A对线程B有等待关系输入模型：线程列表，锁列表

一个OutputStream不断append文件，一个InputStream读同一个文件，读的速度比写快。当Reader 赶上Writer的时候会EOF，但不存在data corruption问题，不需要用户同步。理论上也应该是这样：文件是按块存取的1）如果读写不在一个块，挨不着2）在一个块，变成了一个内存块的顺序读和顺序写的问题，也不需要同步内存块顺序读和顺序写的scen

1）首先垂直切分，按业务模块把一些紧密联系的表分在一起（按表切分)，形成一个抽象的vertical partition2）水平切分。垂直切分之后的单个vertical partition（甚至其中单个表）仍然可能太大，一个server放不下，进一步按行切分，这时候需要选择一个聚合根作为记录的horizontal partiotion的标志，一般是userId，对于Forum模块，forumId

搜索要弄清2个基本问题：1）要搜索出什么类型的entity？2）entity的哪个方面／维度和关键词发生关联的？一般来说可以有多个角度link到entity，一个entity支持多个索引，可以从不同的column检索对于 web search，这两个问题都很简单，1）只有一种entity，就是网页，2）关键词和网页也只有一种关联关系，就是包含关系对于linkedin

理论上应该先黑盒用例，分析需要求，系统边界的输入输出，再白盒类图。 但是对于现实世界模拟的OO，个人感觉先emulate现实世界，初步识别类和类之间的关系，再用用例和顺序图丰富、修正类图。识别类，最主要的原则是封装，数据和数据的操作封装成一个类：轿厢 box：封装轿厢的状态：位置、方向、静止还是运动，capacity,  pickup列表，目的地列表楼building：用户请求电梯的媒

基本需求：系统按时导入数据的新版本，然后复制到分节点版本化的好处：1）安全。如果最新版本corrupt了，可以回滚到上一个版本。2）读写互不影响，类似copy on write，导入新版本数据的过程中，系统可以使用旧数据从分布式系统的角度，系统由一个ingest Process 和多个sync Process 组成，分布在不同的机器。sync Process 和 i

什么是分布式系统，就是系统由多台机器组成，每台机器上有不同的role，mediaroom就是典型的分布式系统。具体化一下，多台机器其实就是多process，不要觉得机器上有很多程序，在系统设计领域，说一台机器实质上就是说一个process。只不过是不同机器上的process，和同一台机器上的多进程相比，不能用OS系统调用或者本地磁盘的机制进行同步或者数据共享。process是什么就是一

Job是关于整个数据和面向整个集群的概念，task一般是处理数据的子集，并且和集群中的具体一台机器相联系。Vod deploy系统的架构cluster job 相当于job， vserver job相当于task，VodController 相当于JobTracker，VServer Com+相当于 taskTracker输入首先是一个cluster job 的 priorit

pop哪一个元素，决定了queue, stack, priority_queue的不同。新加一个random_queue，等概率的从集合里取出一个元素pop1）先用rand(int l, int r)得到一个随机位置，2）和top交换3）top--思路：连续存储一般只有在边界add/remove才是O(1)的，否则会涉及shift。这里有个前提，就是要保持其余元素的

索引的本质就是一个symbol tablekey是关键字， value就是docId,或者row locator的一个集合docId 之后是存储系统，接收一个docId, 返回对应的doc或记录，一般就是一个堆一样的东西。索引的概念和任何数据结构无关，起的就是个关联作用（key -> {docId})， 就是一个具体的symbol table的应用（value 是doc

一些基本术语feed, status, 动态，微博，follow subscribeinbox outbox聚合：把你关注的人的最新动态；或者关注的内容类别（体育、娱乐等）的最新内容呈现到你的home page上feed的type：上传照片，留言，comment，like等两种基本模式push：feed产生的时候，push分发到follower的inbox，fo

Use Case:1 Shortening 2 Redirection3 Automatic Link expiration4 Manual removalArchitecture: Service based：（web service形式)major issueshort URL generation 方案 : 常见形式就是大小为6的字母和数字组成的字

naive的做法是，定时轮询，一个单独线程检查

新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第

一般排序是数据取出来之后，

基本就是靠log, 或者说undo log经典的转帐问题，需要A的账户减去金额，B的账户增加金额，如果A减去了金额，而B账户增加金额的时候掉电，怎么办？方案：在执行transaction之前save 事务要涉及的数据，transaction结束后要log 成功结束标志End Transaction。系统恢复的时候如果发现某个事务没有log End Transaction，说明这个事

Service本质就是一个驻留Process，驻留Prcess至少有一个驻留线程，这个线程处在waiting的状态（相对于Runable)，控制流停在某个点上，受外部事件驱动，或者是自己的timer驱动。Windows Service是一个exe，要有Main方法，Main方法要把一个继承了ServiceBase、实现了OnStart(), OnStop()等生命周期回调方法的Servic

producer library linked to all kinds of services which generate logsbroker processes consumer library linked to consumer applicationzookeeper hold global informationMessage是有key的，map到topic的一个p

Goal：即满足一致性又尽量提高吞吐量Sequential equivalence checking: 两个事务的所有conflicting operation pair的相对顺序都是一样的悲观并发控制：用锁实现 Sequential equivalence锁的理解，2个作用1）基本数据完整性，防止同时修改导致的坏数据，2）操作完整性、事务完整性，复合状态的完整性，比如