binling的专栏

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

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

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

Data Model：1）structure  2) constraints 3) operationhierarchy/Treelike(give me my children)， table， graph， stream（give me next n bytes)数据库 key ideaphysical data independence : interface with

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

首先是数据的partition,  share nothing parallel architecture,  执行task的machine独立，各自处理自己的partition,不需要通信暴露给用户的控制点只有2个 map function 和 reduce function，但是整个流程包含更多的步骤，（其他的步骤是infrastructure做的）load: 文件写到 hdfs 就完

几个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

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

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

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

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

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

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

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

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

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

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

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

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

http://blog.youkuaiyun.com/bluishglc/article/details/6161475本文着重介绍sharding的基本思想和理论上的切分策略，关于更加细致的实施策略和参考事例请参考我的另一篇博文：数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 一、基本思想      Sharding的基本思想就要把一个数据库

随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机

最近见几个朋友都在说人人网新鲜事排序的问题，恰巧对这方面也较感兴趣，于是打算顺便把手头收集到的资料梳理学习一下。由于本人也只是新手，很多内容仅仅是参阅资料后的个人猜测与纸上谈兵故难免存有错误与纰漏，感谢大家指正。一、 什么是feed“Feed，本意是“饲料、饲养、（新闻的）广播等”，RSS订阅的过程中会用到的“Feed”，便是在这个意义上进行引申，表示这是用来接收该信息来源更新

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

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

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

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

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

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

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

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

经典的想法就是一个Trie的 keysWithPrefix 问题。更高级的，进一步考察，keysWithPrefix需要做prefix下的inOrder遍历，但是每当用户type下一个字符，那个提示列表瞬间就显示出来了，不像是遍历很大一棵树，除非保证这棵trie不是很大，比如只是到了一定popular程度的词才才放进来，这是一个办法。还有一个思路，就是倒排索引的思想，用户输入的所有

搜索引擎4大系统1下载系统三个data Ingest service，定时到3个库拿数据，基于时间戳的增量2分析系统基于XLST/XPATH，可定制，输入是feed entry， 输出是3个方向1）entry整体存档，作为原始文档，data fragment service2）用xlst 对 entry进行数据抽取、转换，变成result item3）用xl

update一行的时候的时候不是in-place的修改，而是产生一个行的新版本，在新行上修改，最后有点类似copy on write array，在提交的时候切换到新版本。好处是不影响现有数据的读取，一致性好。概括为：准备数据 + 原子commit 切换版本，和无锁数据结构实现的思路很像，先准备好数据，最后往结构上挂的那一下用CAS原子性保证。MVCC是把一个复杂事务的原子性问题转化到comm

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

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