分布式架构

突发奇想，对于数据库，想到了一些有意思的事情和功能，算是对未来数据库发展的一种畅想吧，期待未来有实力的公司或是科研机构能真正实现。 一：分布式操作系统---永动机型操作系统 聊数据库，先要说说操作系统，毕竟数据库要安装部署在操作系统上。 目前应用服务常见的硬故障分为电源、CPU、硬盘、内存、网络等，这些都是常见的、不可抗拒的故障。非分布式操作系统下，各个服务器资源不能最大化的得到合理利用，即使是现在的K8S容器时代，也是这样。目前在应用服务层面，存在读写性能、CPU、内存、网络等瓶颈，但在分布式操作系统下的数据库将突破这些瓶颈，将实现永动机型的应用，永不宕机，资源足够的情况下，各种资源自动弹性伸缩，性能永远没有瓶颈，整体的资源也得到合理的利用，应用服务不再关心硬件问题。 目前实现了文件存储的分布式(如ceph等文件系统),但是还没有实现CPU、内存、网络的分布式，即使只实现文件系统的分布式，也带来了数据库的巨大变革，代表Aurora、PolarDB等，实现存储与计算分离，在硬件上，基本上不用在关注硬盘故障的问题，安全、性能和弹性扩展能力得到极大提升。 如果最主要的CPU、硬盘、内存、网络全部实现了真正的分布式，不再区分单机CPU、硬盘、内存、网络，所有的资源都在一个大池子中，所有分布式集群中的CPU和内存等资源是集群共有的、可以共享的，既可以限定使用服务资源使用

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一个集群如果出现了负载不均衡问题，那么负载最大的机器往往将成为影响系统整体表现的瓶颈和短板。为了避免这种情况的发生，需要动态负载均衡机制，以达到实时的最大化资源利用率，从而提升系统整体的吞吐。 OceanBase架构介绍 OceanBase是一个具有 自治功能 的分布式存储系统，由 中心节点RootServer、静态数据节点ChunkServer、动态数据节点UpdateServer以及数据合并节点MergeServer四个Server构成 ，如下图所示。 Tablet：分片数据，最基本的存储单元，一般会存储多份，一个Table由多个tablet构成； RootServer：负责集群机器的管理、Tablet定位、数据负载均衡、Schema等元数据管理等。 UpdateServer：负责存储动态更新数据，存储介质为内存和SSD，对外提供写服务； ChunkServer：负责存储静态Tablet数据，存储介质为普通磁盘或者SSD。 MergeServer：负责对查询中涉及多个Tablet数据进行合并，对外提供读服务； 在一个集群中，Tablet的多个副本分别存储在不同的ChunkServer，每个ChunkServer负责一部分Tablet分片数据，MergeServer和ChunkServer一般会一起部署。

GFS分布式文件系统集群 GlusterFS概述 GlusterFS简介 开源的分布式文件系统 由存储服务器，客户端以及NFS/Samba存储网关组成 无元数据服务器 RDMA:负责数据传输 GlusterFS的特点 扩展性和高性能 高可用性 全局统一的命名空间 弹性卷管理 基于标准协议 GlusterFS术语 Brick ： 存储节点 Volume ： 卷 FUSE ： 内核模块，用户端的交互模块 VFS ： 虚拟端口 Glusterd ： 服务 模块化堆栈架构 模块化、堆栈式的架构 通过对模块的组合，实现负责的功能 GlusterFS工作模式 Application：客户端或应用程序通过GlusterFSync的挂载点访问数据 VFS：linux系统内核通过VFS API收到请求并处理 FUSE ： VFS 将数据递交给FUSE内核文件系统，fuse 文件系统则是将数据通过/dev/fuse设备文件递交给了GlusterFS client端 GlusterFS Client ; 通过网络将数据传递至远端的GlusterFS Server，并且写入到服务器存储设备上 GlusterFS工作原理 GlusterFS工作流程 弹性HASH算法 通过HASH算法得到一个32位的整数 划分为N个连续的子空间，每个空间对应一个Brick 弹性HASH算法的优点

一 什么是 ZooKeeper ZooKeeper 的由来 下面这段内容摘自《从Paxos到Zookeeper 》第四章第一节的某段内容，推荐大家阅读以下： Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以， 雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。 关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家RaghuRamakrishnan开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起， 雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好要用来进行分布式环境的协调一一于是，Zookeeper的名字也就由此诞生了。 1.1 ZooKeeper 概览 ZooKeeper 是一个开源的分布式协调服务，ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache

HDFS概述及设计目标 什么是HDFS： 是Hadoop实现的一个分布式文件系统（Hadoop Distributed File System），简称HDFS 源自于Google的GFS论文 论文发表于2003年，HDFS是GFS的克隆版 HDFS的设计目标： 非常巨大的分布式文件系统 运行在普通廉价的硬件上 易扩展、为用户×××能不错的文件存储服务，也就是容错性 HDFS官方文档地址如下： https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html HDFS架构 HDFS是主/从式的架构。一个HDFS集群会有一个NameNode（简称NN），也就是命名节点，该节点作为主服务器存在（master server）。NameNode用于管理文件系统的命名空间以及调节客户访问文件。此外，还会有多个DataNode（简称DN），也就是数据节点，数据节点作为从节点存在（slave server）。通常每一个集群中的DataNode，都会被NameNode所管理，DataNode用于存储数据。 HDFS公开了文件系统名称空间，允许用户将数据存储在文件中，就好比我们平时使用操作系统中的文件系统一样，用户无需关心底层是如何存储数据的。而在底层，一个文件会被分成一个或多个数据块

当今世界，互联网、大数据应用迅猛发展，物联网、人工智能、云计算 技术日新月异，随之而来的是各种企业和个人应用持续不断地产生亿级甚至是百亿级的海量小文件。这些小文件的元数据管理、存储性能以及访问效率等问题因而成为学术界和工业界公认的难题。 例如，国内目前最大的电商网站淘宝存储的商品图片超过 200 亿张，这些文件的平均大小仅为 15KB 左右，国外著名的社交网站Facebook 存储的图片总量更是超过了600亿张；在线视频播放服务中，每个视频会被切片服务器分割成 1MB 左右的分片文件，一部动画电影所包含的图片文件可能会超过 500 万张，平均大小为15KB；一些在线阅读图书每页内容均会被扫描成大约几十KB的图片文件…… 在非结构化数据和新应用快速增加的情况下，对象存储更能满足企业的业务需求。为此，杉岩数据推出了强大的对象存储产品，解决企业对海量图片、视频等非结构数据存储需求，以便更好的挖掘非结构化数据的价值。 端到端的Scale-Out扩展，实现大数据积累 分布式对象存储总容量可达到数百PB级规模，单个名字空间也可以扩展到整个硬件存储总空间容量，不需要割裂成多个隔离空间，并且在文件数量上会有更大的扩展，文件数量可达百亿级，是真正的端到端Scale-Out快速扩展。它可以满足业务系统整个生命周期的存储容量需求，无需挂载目录和调整业务系统，让IT人员更加关注业务价值本身。

这一章简单搭建一个分布式服务： 1、Dubbo简介： Dubbo 是一个分布式服务框架，是阿里巴巴开源项目。 Dubbo 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，Dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有Dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。 dubbo流程图如下： 节点角色说明： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 调用关系说明： 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 2、Zookeeper注册中心： 官方推荐使用

作者知乎id：一路走好 本人目前做图的底层存储引擎“分片和副本分布式可扩展”相关的研究，来满足业务的快速增长。 本文内容大量来自被我阅读的文章。感谢王建奎博士~~ 华为 先来说说最神秘的华为吧，华为的图数据库构建在多模数据库中，由高斯实验室负责原型研发，图数据库的 headcount 由任总钦点，图数据库在华为重要性可想而知，但是由于华为保密要求严格，凡事都不让对外说。技术领先，设计方案简单高效。其他朋友不方便多跟我说，不过团队从现在到前后会新增 至少 20 个 headcount，任总有要求，非招人不可大有可为呀。如果有想去上海工作的朋友，欢迎联系我，我帮你联系我的朋友。 费马科技 洪春涛学长在北京BDTC2017中国大数据技术大会上深入分析了当时图数据库和图计算领域的难点、现状以及费马在2个领域的优化和产品能力。我当时真的对那几个优化数字感到震惊费马的性能真的非常好，团队也非常专业。京东金融是他们的一个客户案例（详细可查看：https://fma-ai.cn/case）。 费马科技是一个专注图数据库和图计算的创业公司，主打：快如闪电的高性能图数据存储及分析平台。 LightGraph 是费马科技自主研发的图数据库产品。其主要特点是单机大数据量，高吞吐率，以及灵活的 API，同时支持高效的在线事务处理（OLTP）和在线分析处理（OLAP）。LightGraph支持 TB

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、需求缘起 几乎所有的业务系统，都有生成一个记录标识的需求，例如： （1）消息标识：message-id （2）订单标识：order-id （3）帖子标识：tiezi-id 这个记录标识往往就是数据库中的唯一主键，数据库上会建立聚集索引（cluster index），即在物理存储上以这个字段排序。 这个记录标识上的查询，往往又有分页或者排序的业务需求，例如： （1）拉取最新的一页消息：selectmessage-id/ order by time/ limit 100 （2）拉取最新的一页订单：selectorder-id/ order by time/ limit 100 （3）拉取最新的一页帖子：selecttiezi-id/ order by time/ limit 100 所以往往要有一个time字段，并且在time字段上建立普通索引（non-cluster index）。 我们都知道普通索引存储的是实际记录的指针，其访问效率会比聚集索引慢，如果记录标识在生成时能够基本按照时间有序，则可以省去这个time字段的索引查询： select message-id/ (order by message-id)/limit 100 再次强调，能这么做的前提是，message-id的生成基本是趋势时间递增的。

1、引言 关于“负载均衡”的解释，百度词条里：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个操作单元上进行执行，共同完成工作任务。 负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 负载均衡有两方面的含义： 1）首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间； 2）其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 简单来说就是： 1）其一是将大量的并发处理转发给后端多个节点处理，减少工作响应时间； 2）其二是将单个繁重的工作转发给后端多个节点处理，处理完再返回给负载均衡中心，再返回给用户。 目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。 总之，它的目的就通过调度集群，达到最佳化资源使用，最大化吞吐率，最小化响应时间，避免单点过载的问题。 内容概述：本文将从负载均衡技术的分类、技术原理、常见实现算法、常用方案等入手，为您详细讲解负载均衡技术的方方面面。这其中，四层和七层负载均衡技术最为常用，它们也是本文介绍的重点。 内容点评