云时代架构读后感（五）

朴灿烈づ我的快乐病毒、 2022-01-08 00:07 243阅读 0赞

豆瓣的基础架构

原文地址：https://mp.weixin.qq.com/s?\_\_biz=MzA5NDI5MTgwMg==&mid=200664136&idx=1&sn=3e1949d70fd4ab1d5229492fc7d52f36&scene=21\#wechat\_redirect

本次阅读的为豆瓣的基础架构，豆瓣整个基础架构可以粗略的分为在线和离线两大块。

在负载均衡层，使用的方法为，前边用LVS和HA，反向代理使用Nginx。

应用层即为计算层，通过运算，将结果返回给前面的用户。

在服务层使用的为MySQL、memcached、redis、beanstalkd，不一样的是NoSQL的选择——BeansDB，这是我们在几年前开源的KV数据库，也是国内比较早开源的KV数据库。

基础服务层在初始阶段使用的是tokyo cabinet作为存储引擎，之后使用的为bitcask存储格式重写了存储引擎，性能更好。而通过BeansDB可以对键做运算，通过哈希运算实现分布和冗余。相比Redis这种支持几十个G到几百个G的 内存KV数据库，BeansDB可以支持到上百T的数据。另外BeansDB最大的好处就是运维很简单，性能、可用性、扩容都很好，也实现了最终一致性。

在线的部分，对高可用性和低时延有较大要求。离线部分则包括数据挖掘、数据分析等，技术组件分别是海量分布式文件系统MooseFS。另外就是自己开发的分布式计算平台DPark。

DPark顾名思义是Spark的Python实现，不过现在已经跟Spark越来越不一样了。和 Hadoop 相比，Spark可以使用内存做为缓存加速分布式计算，DPark继承了这个优点，这对于大规模数据的迭代计算非常有用。在豆瓣的应用场景下，因为我们的 离线计算很多是推荐算法计算，这种计算涉及大量的迭代算法，如果每次计算的结果都入磁盘再在下一轮计算加载，那性能是很差的，所以DPark能够大幅提升 性能。另外，因为DPark的编写使用了函数式语言的特点，所以可以写的非常简洁。

对于新技术的引入上，豆瓣整体是比较偏激进的，我们鼓励大家去看看新的技术。当然我们也不会看到新的就上，这里面有一些限制：一个是比较重要 的服务如果要上新的技术，一定要有成功案例，且成功案例有跟我们量级差不多的规模，这样可以降低风险；另一个是对于引入的新技术一定要吃透——大部分引入 的技术肯定是要做二次开发的，所以拿进来的技术你必须保证能完全理解它的代码结构，出了问题能修，能去掉自己无法掌控的东西。

转载于:https://www.cnblogs.com/wys-373/p/10715263.html