nebula

Kubernetes 是什么 Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效，Kubernetes 提供了应用部署，规划，更新，维护的一种机制。<br />Kubernetes 在设计结构上定义了一系列的构建模块，其目的是为了提供一个可以 部署、维护和扩展应用程序的机制 ，组成 Kubernetes 的组件设计概念为 松耦合 和 可扩展 的，这样可以使之满足多种不同的工作负载。可扩展性在很大程度上由 Kubernetes API 提供，此 API 主要被作为扩展的内部组件以及 Kubernetes 上运行的容器来使用。 Kubernetes 主要由以下几个核心组件组成： etcd 保存了整个集群的状态 apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制 controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等 scheduler 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上 kubelet 负责维护容器的生命周期，同时也负责 Volume和网络的管理 Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI） kube-proxy 负责为 Service 提供

应用 AddressSanitizer 发现程序内存错误 作为 C/ C++ 工程师，在开发过程中会遇到各类问题，最常见便是 内存使用问题 ，比如， 越界 ， 泄漏 。过去常用的工具是 Valgrind，但使用 Valgrind 最大问题是它会极大地降低程序运行的速度，初步估计会降低 10 倍运行速度。而 Google 开发的 AddressSanitizer 这个工具很好地解决了 Valgrind 带来性能损失问题，它非常快，只拖慢程序 2 倍速度。 AddressSanitizer 概述 AddressSanitizer 是一个基于编译器的测试工具，可在运行时检测 C/C++ 代码中的多种内存错误。严格上来说，AddressSanitizer 是一个编译器插件，它分为两个模块，一个是编译器的 instrumentation 模块，一个是用来替换 malloc/free 的动态库。 Instrumentation 主要是针对在 llvm 编译器级别对访问内存的操作（store，load，alloc等），将它们进行处理。动态库主要提供一些运行时的复杂的功能（比如 poison/unpoison shadow memory）以及将 malloc/free 等系统调用函数 hook 住。 AddressSanitizer 基本使用 根据 AddressSanitizer Wiki

在文章 《Nebula 架构剖析系列（一）图数据库的存储设计》 中，我们提过分布式图存储的管理由 Meta Service 来统一调度，它记录了所有 partition 的分布情况，以及当前机器的状态。当 DBA 增减机器时，只需要通过 console 输入相应的指令，Meta Service 便能够生成整个 Balance 计划并执行。而之所以没有采用完全自动 Balance 的方式，主要是为了减少数据搬迁对于线上服务的影响，Balance 的时机由用户自己控制。 在本文中我们将着重讲解在存储层如何实现数据和服务的负载平衡。 简单回顾一下， Nebula Graph 的服务可分为 graph，storage，meta。本文主要描述对于存储层（storage）的数据和服务的 balance。这些都是通过 Balance 命令来实现的：Balance 命令有两种，一种需要迁移数据，命令为 BALANCE DATA ；另一种不需要迁移数据，只改变 partition 的 raft-leader 分布（负载均衡），命令为 BALANCE LEADER 。 本文目录 Balance 机制浅析 集群数据迁移 Step 1：准备工作 Step 1.1 查看现有集群状态 Step 1.2 创建图空间 Step 2 加入新实例 Step 3 迁移数据 Step 4 假如要中途停止 balance

分布式技术的发展，深刻地改变了我们编程的模式和思考软件的模式。值 2019 岁末，PingCAP 联合 InfoQ 共同策划出品“分布式系统前沿技术 ”专题， 邀请众多技术团队共同参与，一起探索这个古老领域的新生机。本文出自 UCloud 后台研发工程师邓瑾。 为了应对 IO 性能要求很高的数据分析、AI 训练、高性能站点等场景，UFS 团队又推出了一款基于 NVMe SSD 介质的性能型 UFS，以满足高 IO 场景下业务对共享存储的需求。性能型 UFS 的 4K 随机写的延迟能保持在 10ms 以下，4K 随机读延迟在 5ms 以下。 性能的提升不仅仅是因为存储介质的升级，更有架构层面的改进，本文将从协议、索引、存储设计等几方面来详细介绍性能型 UFS 升级改造的技术细节。 协议改进 此前容量型 UFS 设计时支持的协议为 NFSv3，其设计理念是接口无状态，故障恢复的逻辑简单。此外 NFSv3 在 Linux 和 Windows 上被广泛支持，更易于跨平台使用。但是 NFSv3 的设计缺点导致的高延迟在高 IO 场景下是不可接受的，所以在性能型 UFS 中，我们选择仅支持性能更好、设计更先进的 NFSv4 协议。 NFSv4 与 NFSv3 相比，更先进的特性包括：支持有状态的 lock 语义、多协议间的 compound 机制等。特别是 compound 机制，可以让多次

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ​ 在本篇文章中主要介绍图数据库 Nebula Graph 在 Jepsen 这块的实践。 Jepsen 简介 Jepsen 是一款用于系统测试的开源软件库，致力于提高分布式数据库、队列、共识系统等的安全性。作者 Kyle Kingsbury 使用函数式编程语言 Clojure 编写了这款测试框架，并对多个著名的分布式系统和数据库进行了一致性测试。目前 Jepsen 仍在 GitHub 保持活跃，能否通过 Jepsen 的测试已经成为各个分布式数据库对自身检验的一个标杆。 Jepsen 的测试流程 Jepsen 测试推荐使用 Docker 搭建集群。默认情况下由 6 个 container 组成，其中一个是控制节点（control node），另外 5 个是数据库的节点（默认为 n1-n5）。控制节点在测试程序开始后会启用多个 worker 进程，并发地通过 SSH 登入数据库节点进行读写操作。 测试开始后，控制节点会创建一组进程，进程包含了待测试分布式系统的客户端。另一个 Generator 进程产生每个客户端执行的操作，并将操作应用于待测试的分布式系统。每个操作的开始和结束以及操作结果记录在历史记录中。同时，一个特殊进程 Nemesis 将故障引入系统。 测试结束后，Checker 分析历史记录是否正确

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 摘要 Maven 中央仓库并不支持直接上传 jar 包，因此需要将 jar 包发布到一些指定的第三方 Maven 仓库，比如：Sonatype OSSRH 仓库，然后该仓库再将 jar 包同步到 Maven ，本文详细记录整个发布、同步过程。 注册一个 Sonatype 用户 进入地址： https://issues.sonatype.org/secure/Signup!default.jspa 注册 Sonatype 用户，Sonatype 通过 JIRA（JIRA 是 Atlassian 公司出品的项目与事务跟踪工具）来管理 OSSRH 仓库。<br /> 创建一个发布构件的 issue 提交「构件发布申请」的第一步是在 JIRA Dashborad 上创建一个 issue。如下所示，点击 Create 按钮： 会弹出一个对话框让你填写 issue 的详细信息，这里最重要的就是 Group Id，一般会带上域名，千万别弄错了，这关系到以后发布其它的构件。我们这里是 com.vesoft 。 Sonatype 有域名验证，验证方式: 往你的 DNS 中添加 JIRA 编号记录 重定向到你的 Github 主页 如果你没有域名，可参考这个链接： http://central.sonatype.org/pages