豆瓣的基础架构

　　本文凭据InfoQ中文站对豆瓣洪强宁（@hongqn）的相同交流整理而成。洪强宁先容了豆瓣的架构和组件，并分享了豆瓣基础平台部的一些团队履历。文中截图来自洪强宁在2002年CTO俱乐部中的分享。

　　架构

　　豆瓣整个基础架构可以大略的分为在线和离线两大块。在线的部门和大部门网站类似：前面用LVS做HA，用Nginx做反向署理，形成负载平衡的一层；应用层主要是做运算，将运算效果返回给前面的用户，DAE平台是这两年建起来的，现在大部门豆瓣的应用基本都跑在DAE上面了；应用后面的基础服务也跟其他网站差不多，MySQL、memcached、redis、beanstalkd，纷歧样的是NoSQL的选择——BeansDB，这是我们在几年前开源的KV数据库，也是海内比力早开源的KV数据库。

　　BeansDB项目可以说是一个简化版的AWS DynamoDB，该项目在2008年汇海，2009年开源，第?版使?tokyo cabinet作为存储引擎，2010年使?bitcask存储花样重写了存储引擎，性能更好。BeansDB对key做哈希运算找到节点来实现漫衍和冗余， 一个写操作会写好几个节点，而现在的设置是写三份读一份。BeansDB主要的特点是支持海量KV数据库——相比Redis这种支持几十个G到几百个G的内存KV数据库，BeansDB可以支持到上百T的数据。另外BeansDB最大的利益就是运维很简朴，性能、可用性、扩容都很好，也实现了最终一致性。

　　BeansDB中心的Proxy是用Go语言写的，也是一个开源的组件。整体来说BeansDB的设计结构比力简朴，相比Redis那种有多种value类型的方式，BeansDB的value比力简朴一些。

　　在豆瓣内部建设了两个差别的BeansDB集群，一个是doubandb，一个是doubanfs，划分针对差别的场景。doubandb主要存储小型文本数据，如影评、用户小我私家先容、帖子内容等，这样的利益是可以大大降低我们对MySQL的性能依赖，算是给MySQL减负；doubanfs主要存放图片和音频等中型数据。

　　DAE可以说是基于许多以前积累的、旧的组件做起来的。我们做的这种对内的PaaS，相比对外的PaaS而言做了许多简化，尤其是宁静方面如应用距离离、权限治理方面，我们都不用像公有云那样花大量精神去做，以是事情量实在还好。DAE现在在企图开源，固然它现在只支持Python应用。以后我们也许会让DAE支持Go语言。

　　上面是在线的部门，对高可用性和低时延有较概略求。离线部门则包罗数据挖掘、数据剖析等，手艺组件划分是海量漫衍式文件系统MooseFS，这个文件系统的结构类似HDFS，用C语言编写，其利益在于FUSE模块实现的比力好，用文件系统就可以直接举行操作，而不需要专门的下令，可以支持的数据量也很大。另外就是自己开发的漫衍式盘算平台DPark。

　　DPark顾名思义是Spark的Python实现，不外现在已经跟Spark越来越纷歧样了。和Hadoop 相比，Spark可以使用内存做为缓存加速漫衍式盘算，DPark继续了这个优点，这对于大规模数据的迭代盘算很是有用。在软件开发豆瓣的应用场景下，由于我们的离线盘算许多是推荐算法盘算，这种盘算涉及大量的迭代算法，若是每次盘算的效果都入磁盘再在下一轮盘算加载，那性能是很差的，以是DPark能够大幅提升性能。另外，由于DPark的编写使用了函数式语言的特点，以是可以写的很是简练：

　　到现在（2014年3月），DPark的集群规模和处置惩罚数据量已经比去年多了一倍左右，一天要处置惩罚60~100TB左右的数据。

　　团队

　　当前，我所卖力的豆瓣平台部一共包罗四个部门：焦点系统，这块也是由我直接领导的，共6名工程师；DAE，现在是彭宇卖力，共4名工程师；DBA两人；SA两人。

　　平台部卖力的项目大多是跟营业无关的工具，贴近应用层的主要在产物线团队做，这个分工跟豆瓣工程团队的生长历史有关。早期豆瓣工程师还不多的时间，就已经分为两种倾向，一种是偏营业的，就是去做用户能看得见的工具；另一种是支持性的，运行在营业层下面、不被用户所感知的工具。下面这一层就衍酿成了平台部门。

 1/2    1 2 下一页 尾页