人人网UGC海量存储系统Nuclear介绍

2024-01-25 08:32
文章标签 介绍 海量 存储系统 人人 ugc nuclear

本文主要是介绍人人网UGC海量存储系统Nuclear介绍，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

转kuqin网上一篇介绍人人网实现海量存储的文章，人人网构建了自己的存储系统Nuclear，先简单列列感想。

 

又一个使用java构建的分布式的key-value存储系统，在设计思想上严重受到GFS的影响。

在存在中心管理节点的情况下，怀疑其提到的“无限扩展性”，夸张了；
不过通过一致性hash算法来确定key对应的value会落到哪个存储节点上，使得中心节点对存储节点的信息知晓最少，集群规模可以大大扩展；

在添加、删除节点时，通过分区管理模块迁移数据来踢除“脏数据”；确保数据正确性。

感慨构建在java之上的分布式存储系统越来越多了... ...

               人人网UGC海量存储系统Nuclear介绍

书曰：工欲善其事，必先利其器。人人网作为国内第一大SNS网站，欲存海量UGC数据，必有海量存储系统。Nuclear存储系统在高性能、高可靠、可扩展的海量数据存储 需求下横空出世，待小的给列位看官慢慢道来。

缘由篇

看过《人人网使用的开源软件列表 》一文的看官一定知道人人网的关系型数据库使用的是MySQL，Key-Value存储使用的是Tokyo Cabinet ， 话说战斗在第一线的UGC Team的兄弟们发现，MySQL虽然已经被我们用上了散库、散表大法，但是每次数据达到服务器负载临界值时，必然得经过一番迁移数据的剧痛；使用TC也 会存在这个问题，且TC只在某些特定的应用场景起作用。于是乎，我们开始需找能满足高性能、高可靠、可扩展等特性，同时能符合UGC应用场景的存储系统， 下表列出我们的考察对象及需求。

Snap2

TC在使用过程中发现单独使用TC会在某些时间点出现性能瓶颈；Voldemort 目前的版本对扩展性支持不好；且Voldemort和Casscandra 作为一个正在快速开发中的系统，我们尚未有勇气把它引入到生产环境中。追溯到Amazon的Dynamo 系统，我们决定在其思想上开发自己的存储系统，Nuclear就是在这样的背景下诞生的。言归正传，给各位道来功能篇及应用篇。

功能篇

高可扩展

一个Nuclear集群支持1到n(n<264 )个节点(Node)的规模，每台服务器(Server)支持部署多个节点。当集群资源达到瓶颈时，可以通过增加新的节点来扩展。增加新节点的过程，系统服务无需停止，无需人工干预迁移数据。Nuclear理论上可以无限Scale-Out 。

高可靠

单个节点的crash永远对系统的运行造成影响，不存在单点风险。数据的写入参考Dynamo 的W+R>N理论，简释之，例如设置系统每一份数据都存储在3个节点上(N=3)，那么读的话必须成功读到两个节点上的数据才认为读成功 (R=2)，写的话必须成功写到两个节点上才认为写成功( W=2)。系统永远可写入(Hinted HandOff)。

高性能

在Xeon E5405 CPU的服务器上，单节点每秒最高2.5w req/s。整个集群的性能取决于一致性级别、N、W、R数及底层存储引擎的选择。例举我们的一个测试数据：
节点数量：4 Node (Server配置： Xeon E5405，16G memory，千兆网卡)
存储引擎：Mysql5.0.45
参数：N=3 W=2 R=2
压力：100 Client Write Request
测试结果：单个Node 15862 req/s，从Client看平均单次请求耗时5ms(见图)， 99.51% 请求耗时 < 50ms

nnn1

存储

Nuclear本身的数据存储是基于Key-Value形式的，value的形式可以是富数据模型，也可以是List；如果底层的存储引擎是关系型的，那么Nuclear还提供弱结构化的查询功能。下面是Nuclear目前及计划中支持的存储引擎。

fff1
*Cassandra我们只使用其底层的存储引擎

应用篇

Nuclear组件介绍

普通节点(Node)
 普通节点的职责是接收并处理来自Client的请求，管理该节点上的存储引擎。

中心节点(Seed)
 中心节点维护着整个Nuclear集群的拓扑关系(membership)，它熟知每一个节点负责的数据区域。它定时对所有节点进行健康检测，因此熟知每一个节点当前的状态及负责的数据区域。

客户端(Nuclear Client)
 提供简单有效的CRUD API。详情如下：
Get
@param key<String>
@param dataID<Long>
@param consistencyLevel
@return ByteString

List
@param key<String>
@param Condition<?>
@param consistencyLevel
@return List<ByteString>

Put
@param key<String>
@param dataID<Long>
@param value<ByteString>
@param consistencyLevel

Replace
同 Put
 dataID可选

Delete
@param key<String>
@param dataID<Long>
@param consistencyLevel

NextDataID
@reutrn dataID<Long>

参数详解：
@param dataID<Long> dataID
每一条数据在Nuclear集群中的唯一标示，由系统提供。使用DataID而不是Key作为数据的唯一标示的目的是为了满足Key->List的需求。

@param consistencyLevel
一致性级别，Nuclear系统提供一致性级别选择如下：

  • DISCARD 请求发送至Node后即可，无需认为是否成功(List,Get不支持此级别)
  • MIN 至少成功请求一个Node
  • QUORUM 严格按照N+W>R理论
  • DISCARDQUORUM 按照N+W>R理论，但允许Hinted HandOff
  • ALL成功请求的节点数必须是N@param value<ByteString>
    Nuclear系统存储的数据使用Google的protocol buffers 协议，因此存入和取出的数据都是google的 ByteString 类型

    @param Condition
    结构化数据的条件查询参数，目前仅支持MySQL引擎下按DataID检索、排序及分页

    Code Example:
    dddd

    系统部署图
    vvvv

    图释：每一个节点都会和其它的节点建立联系，但来自Client的请求只会落在普通节点上。

    集群管理

    Nuclear提供对节点的增、删、替换操作，面对使用者非常简单，只需要知晓仅有的几个命令即可。
    增加 ： sh node.sh new A
     node.sh是node启动的脚本；new标示当前节点为新增；A标示新增的节点去分担现有的A节点的负载。

    删除 :  delete node A
    进入Nuclear管理后台，执行该命令

    替换 ： sh node.sh replace A

    后台管理 : sh manage.sh nodeip nodeport
    目前提供如下功能点：

  • QPS查看
  • Node接收请求总数
  • Node处理请求耗时数据
  • 节点信息查看
  • 集群拓扑信息查看
  • 动态更改节点工作线程数

    原理篇

    Nuclear系统构建于java之上，NIO组件使用Netty ，数据序列化使用google的Protocol Buffers ，Spring当然是用了的。下图是Nuclear系统内部的一个预览：

    Nuclear Overview

    嗯……其实这张图对各位看官意义不大，只是罗列出了Nuclear中的各个组件及简单的层次关系。下面着重分析分区、节点增减、路由的原理。

    分区

    前 文讲到，我们是一个分布式的Key-Value存储系统，那么key对应的数据分布在什么节点上，需要遵守一定的规则。熟悉Memecached Client的同学一定清楚一致性Hash的应用，没错，Hash Ring就是我们的不二选择。在Nuclear中，数据分布在0~264 的Hash Ring上，Nuclear集群初始化的时候，根据节点数均分整个Hash Ring。如下图所示：

    Snap3

     

    在N=3时，A,B,C三个节点的配置就是系统需要的最少节点了。Nuclear中，顺时针的开始值和结束值确定一个分区管理的数据范围，同时规定分区的范围左开右闭。因此，如上图，我们记录A,B,C分别管理的分区范围是：
    A {[c,a],[b, c],[a,b]}
    B {[a,b],[c,a],[b,c]}
    C {[b,c],[a,b],[c,a]}
    可以看出，A处理管理自己的分区数据外，还会把自己管理的数据顺时针往前复制到2     (N-1) 个节点中。

    节点变更

    Nuclear 增加节点时需要制定目标节点的名称，即增加的节点是用来分担目标节点的负载的。这点不同于Dynamo的分区策略，节点增加的时候会均衡的从现有的节点窃 取分区，Nuclear中增加的节点只会影响到邻近的三个节点。加入我们在上面的例子中增加一个新节点N后分区图如下所示：

    Snap2

    记录N,A,B,C管理的分区如下：
    N {[c,n],[b,c],[a,b]}
    A {[n,a],[c,n],[b,c]}
    B {[a,b],[n,a],[c,n]}
     C {[b,c],[a,b],[n,a]}
    Nuclear的分区管理模块将自动的计算出需要同步到N上的数据:
    A [a,b] => N
    B [b,c] => N
    C [c,n] => N
    各位看官不难明白，其实就是把A,B,C不再需要的数据挪给新的节点了。删、替换节点原理大同小异，不再冗述。

    路由

    Nuclear 提供服务器端路由策略，Client的请求随机落在Node节点上，由接收到请求的节点处理后续的逻辑。相对于Client端路由来说，优点是 Client无需知道Nuclear集群元数据，易于维护；缺点是会造成一定程度的延时，不过我们的测试结果显示延时在可接受范围之内。

    两个设计上的Tips贡献给大家:
    1. 万事皆异步
    我们在编码的过程中走了一些弯路，同步的操作在高并发的情况下带来的性能下降是非常恐怖的，于是乎，Nuclear系统中任何的高并发操作都消除了Block。no waiting, no delay。

    2. 根据系统负载控制后台线程的资源占用
    Nuclear系统中有不少的后台线程默默无闻的做着各种辛苦的工作，但是它们同样会占用系统资源，我们的解决方案是根据系统负载动态调整线程的运行和停止，并达到平衡。

    展望篇

    Nuclear中计划在不远的将来(不远有多远?)实现如下功能：

    1. Eventually Consistent 最终的一致性问题，在保重数据完整性上至关重要。
    2. Async Store 异步数据库存储，各位可以参考：adbcj , async-mysql-connector
    3. Read Cache
    4. Balance Monitor 建立集群的负载监控体系，在新节点加入的时候可以自动去平衡负载最高的节点。

    全文完^_^，谢谢各位的捧场，同时有任何好的建议欢迎提出！

    参考资料：

    1. Amazon’s Dynamo
      http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
    2. Cassandra
      http://incubator.apache.org/cassandra/
    3. Voldemort
      http://project-voldemort.com/
  • 转载地址：http://www.kuqin.com/system-analysis/20100205/79192.html

这篇关于人人网UGC海量存储系统Nuclear介绍的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/642678。

相关文章

性能测试介绍

性能测试介绍

性能测试是一种测试方法，旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试，可以确定系统是否能够满足预期的性能要求，找出性能瓶颈和潜在的问题，并进行优化和调整。 发现性能瓶颈：性能测试可以帮助发现系统的性能瓶颈，即系统在高负载或高并发情况下可能出现的问题
阅读更多...
水位雨量在线监测系统概述及应用介绍

水位雨量在线监测系统概述及应用介绍

在当今社会，随着科技的飞速发展，各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中，水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术，其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成，形成了一个完整的闭环系统。 数据采集单元：这是系统的“眼睛”，
阅读更多...
Hadoop数据压缩使用介绍

Hadoop数据压缩使用介绍

一、压缩原则 （1）运算密集型的Job，少用压缩 （2）IO密集型的Job，多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1）为了支持多种压缩/解压缩算法，Hadoop引入了编码/解码器 2）要在Hadoop中启用压缩，可以配置如下参数
阅读更多...
图神经网络模型介绍（1）

图神经网络模型介绍（1）

我们将图神经网络分为基于谱域的模型和基于空域的模型，并按照发展顺序详解每个类别中的重要模型。 1.1基于谱域的图神经网络         谱域上的图卷积在图学习迈向深度学习的发展历程中起到了关键的作用。本节主要介绍三个具有代表性的谱域图神经网络：谱图卷积网络、切比雪夫网络和图卷积网络。 （1）谱图卷积网络 卷积定理：函数卷积的傅里叶变换是函数傅里叶变换的乘积，即F{f*g}
阅读更多...
C++——stack、queue的实现及deque的介绍

C++——stack、queue的实现及deque的介绍

目录 1.stack与queue的实现 1.1stack的实现  1.2 queue的实现 2.重温vector、list、stack、queue的介绍 2.1 STL标准库中stack和queue的底层结构  3.deque的简单介绍 3.1为什么选择deque作为stack和queue的底层默认容器  3.2 STL中对stack与queue的模拟实现 ①stack模拟实现
阅读更多...
Mysql BLOB类型介绍

Mysql BLOB类型介绍

BLOB类型的字段用于存储二进制数据 在MySQL中，BLOB类型，包括：TinyBlob、Blob、MediumBlob、LongBlob，这几个类型之间的唯一区别是在存储的大小不同。 TinyBlob 最大 255 Blob 最大 65K MediumBlob 最大 16M LongBlob 最大 4G
阅读更多...
FreeRTOS-基本介绍和移植STM32

FreeRTOS-基本介绍和移植STM32

FreeRTOS-基本介绍和STM32移植 一、裸机开发和操作系统开发介绍二、任务调度和任务状态介绍2.1 任务调度2.1.1 抢占式调度2.1.2 时间片调度 2.2 任务状态 三、FreeRTOS源码和移植STM323.1 FreeRTOS源码3.2 FreeRTOS移植STM323.2.1 代码移植3.2.2 时钟中断配置 一、裸机开发和操作系统开发介绍 裸机：前后台系
阅读更多...
nginx介绍及常用功能

nginx介绍及常用功能

什么是nginx nginx跟Apache一样，是一个web服务器（网站服务器），通过HTTP协议提供各种网络服务。 Apache：重量级的，不支持高并发的服务器。在Apache上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源，导致HTTP请求的平均响应速度降低。这些都决定了Apache不可能成为高性能WEB服务器  nginx：
阅读更多...
多路转接之select(fd_set介绍,参数详细介绍),实现非阻塞式网络通信

多路转接之select(fd_set介绍,参数详细介绍),实现非阻塞式网络通信

目录 多路转接之select 引入 介绍 fd_set 函数原型 nfds readfds / writefds / exceptfds readfds  总结  fd_set操作接口  timeout timevalue 结构体 传入值 返回值 代码 注意点 -- 调用函数 select的参数填充  获取新连接 注意点 -- 通信时的调用函数 添加新fd到
阅读更多...
火语言RPA流程组件介绍--浏览网页

火语言RPA流程组件介绍--浏览网页

🚩【组件功能】：浏览器打开指定网址或本地html文件 配置预览 配置说明 网址URL 支持T或# 默认FLOW输入项 输入需要打开的网址URL 超时时间 支持T或# 打开网页超时时间 执行后后等待时间(ms) 支持T或# 当前组件执行完成后继续等待的时间 UserAgent 支持T或# User Agent中文名为用户代理，简称 UA，它是一个特殊字符串头，使得服务器
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2