ZooKeeper

引导 dubbo的服务的注册与发现，需要通过第三方注册中心来协助完成，目前dubbo支持的注册中心包括 zookeeper,consul,etcd3,eureka,nacas,redis,sofa。这些注册中心的不同支持在之后的篇章进行分享。 基础铺垫 在铺垫一些基础内容之前，根据如果下几个问题来进行回答，或许能更好的阐明dubbo的实现服务的注册和发现的实现过程。 1、dubbo是在什么时机与注册中心建立连接。 2、dubbo服务注册和导出的时机在什么时候。 3、dubbo服务的订阅时机是在什么时候。 4、dubbo服务的上下线是如何通知订阅者的。 5、dubbo是如何把这些各种第三方注册中心进行整合的。 为了回答上面的五个问题，我们一起去从dubbo的源码探寻答案，这些问题和服务的注册有关，那么首先我们需要的就是去dubbo-registry这个源码模块去查询。 基础数据结构 1、dubbo 还是通过SPI技术，根据参数URL来动态选择不同的注册中心。 @SPI("dubbo") public interface RegistryFactory { @Adaptive({"protocol"}) Registry getRegistry(URL url); } RegistryFactory 就是产生一个注册中心的工程，它有个自适应的方法getRegistry

作者 | 潘天颖，Github ID @pantianying，开源爱好者，就职于涂鸦智能 dubbo 是一个基于 Java 开发的高性能的轻量级 RPC 框架，dubbo 提供了丰富的服务治理功能和优秀的扩展能力。而 dubbo-go 在 java 与 golang 之间提供统一的服务化能力与标准，是涂鸦智能目前最需要解决的主要问题。本文分为实践和快速接入两部分，分享在涂鸦智能的 dubbo-go 实战经验，意在帮助用户快速接入 dubbo-go RPC 框架，希望能让大家少走些弯路。另外，文中的测试代码基于 dubbo-go版本 v1.4.0。 dubbo-go 网关实践 dubbo-go 在涂鸦智能的使用情况如上图，接下来会为大家详细介绍落地细节，希望这些在生产环境中总结的经验能够帮助到大家。 1. 背景 在涂鸦智能，dubbo-go 已经作为了 golang 服务与原有 dubbo 集群打通的首选 RPC 框架。其中比较有代表性的 open-gateway 网关系统（下文统一称 gateway，开源版本见 https://github.com/dubbogo/dubbo-go-proxy ）。该 gateway 动态加载内部 dubbo 接口信息，以HTTP API 的形式对外暴露。该网关意在解决上一代网关的以下痛点。 通过页面配置 dubbo 接口开放规则，步骤繁琐

consul、eureka、nacos对比 配置中心 eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 注册中心 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代

前言 不知不觉，2020年已经过去一半了，最近突然反应过来自己也看了不少文献资料了，就想着把看过的文献和觉得比较好的书籍做一个总结，基本都是大数据分布式领域的，回顾自己学识的同时，也给想从事或这个领域的小伙伴一些参考 😃。最后顺便把接下来要看的东西列个列表，也会将自己学习的心得和经验分享出来，有需要的童鞋可以参考参考。 另外有些文献看完我会进行整理和输出，这部分链接我一并附在文献的介绍后面，后面看的书或是文献也会保持这种习惯，如果觉得有兴趣欢迎各位大佬交流，顺便也可以点波关注~~ 论文总结 MapReduce 《MapReduce Simplified Data Processing on Large Clusters》 从现在的眼光来看，Mapreduce可以说可圈可点。但在那个年代，这个思想可以说是相当先进的。不得不说Google一直引领技术潮流，包括近几年流行的k8s也是Google主导。 这篇文章主要介绍了Mapreduce的流程还有一些细节方面的介绍，如果已经有使用过Mapreduce编程的小伙伴应该看一遍就能懂。另外，看完如果想加以巩固的话，推荐做MIT6.824的Lab1，用go实现一个Mapreduce。至于什么是Mit6.824，百度一下就知道喔。我以前也有写过一篇介绍MR，有兴趣的童鞋不妨看看： 从分治算法到 Hadoop MapReduce 。 地址：

本文源码： GitHub·点这里 || GitEE·点这里 一、分布式事务简介 1、转账经典案例 跨地区和机构的转账的业务在实际生活中非常常见，基础流程如下： 账户01通过一系列服务和支付的流程，把钱转入账户02，在这一过程中，如果账户01出现出账成功，但是账户02没有入账，这就导致数据不一致，违反了基本的事务原则。基于数据归属在不同服务和不同的数据库中，这种情况下的事务出错被称为分布式事务问题。 2、基本概念 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 如上的转账案例，看似只有一次的转账操，实际上由不同的服务不同数据库的多个细节操作组成，这些无感知的细节操作分布在不同服务上，甚至属于不同的地区和应用，如何保证这些操作全部成功或者全部失败，即保证不同数据库间的数据一致性，这就是分布式事务需要解决的核心问题。 3、分布式事务特点 基于如下电商业务场景，基本分布式的架构思路： 数据库基于业务特点，进行分库分表； 数据库拆分，随之就是业务的服务化(SOA)； 基于电商业务进行拆分，会出现常见的：订单，用户，库存，物流等一系列的服务，管理不同的业务数据库，在实际的下单支付应用场景下，需要同时操作用户，订单，库存等多个服务，就必须保证数据一致性，下单支付成功，库存必须就需要用到分布式事务。 二、CAP基础理论 1、基础简介

文章目录 hbase（上） 1、HBase的基本介绍 2、hbase与hadoop的关系 3、RDBMS与HBase对比 4、HBase的简要特征 5、hbase的架构 6、HBase的集群环境搭建 第一步：下载对应的HBase的安装包 第二步：压缩包上传并解压 第三步：修改配置文件 第四步：安装包分发到其他机器 第五步：三台机器创建软连接 第六步：三台机器添加HBASE_HOME的环境变量 第七步：HBase集群启动 第八步：页面访问 7、HBase常用基本shell操作 1.进入HBase客户端命令操作界面 2.查看帮助命令 3.查看当前数据库中有哪些表 4.创建一张表 5.添加数据操作 6.查询数据操作 第一种查询方式：get rowkey 通过rowkey直接获取数据 效率最高 1.通过rowkey进行查询 2.查看rowkey下面的某个列族的信息 3.查看rowkey指定列族指定字段的值 4.查看rowkey指定多个列族的信息 5.指定rowkey与列值查询 6.指定rowkey与列值模糊查询 第二种查询方式：scan tableName startRowkey endRowKey 根据rowkey的范围值进行查询、rowkey是按照字典顺序进行排列 7.rowkey的范围值查询 第三种查询方式 scan tableName 全表扫描 8.查询所有数据 9.列族查询 10

一直以来都想写一点关于kafka consumer的东西，特别是关于新版consumer的中文资料很少。最近Kafka社区邮件组已经在讨论是否应该正式使用新版本consumer替换老版本，笔者也觉得时机成熟了，于是写下这篇文章讨论并总结一下新版本consumer的些许设计理念，希望能把consumer这点事说清楚，从而对广大使用者有所帮助。 在开始之前，我想花一点时间先来明确一些概念和术语，这会极大地方便我们下面的讨论。另外请原谅这文章有点长，毕竟要讨论的东西很多，虽然已然删除了很多太过细节的东西。 一、 误区澄清与概念明确 1 Kafka的版本 很多人在Kafka中国社区(替群主做个宣传，QQ号：162272557)提问时的开头经常是这样的：“我使用的kafka版本是2.10/2.11, 现在碰到一个奇怪的问题。。。。” 无意冒犯，但这里的2.10/2.11不是kafka的版本，而是编译kafka的Scala版本。Kafka的server端代码是由Scala语言编写的，目前Scala主流的3个版本分别是2.10、2.11和2.12。实际上Kafka现在每个PULL request都已经自动增加了这三个版本的检查。下图是我的一个PULL request，可以看到这个fix会同时使用3个scala版本做编译检查： 目前广泛使用kafka的版本应该是这三个大版本：0.8.x， 0.9

最强面试题推荐： 2020Java面试题及答案，命中率高达90% 1.Dubbo是什么？ Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring 框架无缝集成。 RPC 指的是远程调用协议，也就是说两个服务器交互数据。 2.Dubbo的由来？ 互联网的快速发展，Web应用程序的规模不断扩大，一般会经历如下四个发展阶段。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起即可。 垂直应用架构 当访问量逐渐增大，单一应用按照有业务线拆成多个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。 3.Dubbo的主要应用场景？ 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制

文章目录 一、hbase安装前必备步骤 1.hadoop集群搭建 2.zookeeper安装步骤（hbase 依赖于zookeeper） 二、hbase安装步骤 1.将hbase拖入opt文件夹中 2.解压安装包并删除安装包 3.修改配置文件 4.hbase 环境变量配置并进行source 5.修改 regionservers 6.将整个hbase文件夹和profile文件传输到另外两台虚拟机上 三、启动 1.先启动hadoop(仅需要在主节点上启动就可以了) 2.三台虚拟机都启动zookeeper 3.启动hbase(仅需要在主节点上启动就可以了) 4.网址连接(http://192.168.238.111:60010/master-status) hbase百度网盘地址 ： hbase-1.2.0-cdh5.14.2.tar.gz 一、hbase安装前必备步骤 1.hadoop集群搭建 具体步骤请参考： linux-配置hadoop集群（配置文件及环境配置） 2.zookeeper安装步骤（hbase 依赖于zookeeper） 具体步骤请参考： hadoop集群环境下zookeeper的安装的详细步骤 二、hbase安装步骤 1.将hbase拖入opt文件夹中 2.解压安装包并删除安装包 #解压 tar -zxf hbase-1.2.0-cdh5.14.2.tar.gz

HBase作为一个分布式存储的数据库，它是如何保证可用性的呢？对于分布式系统的CAP问题，它是如何权衡的呢？ 最重要的是，我们在生产实践中，又应该如何保证HBase服务的高可用呢？ 下面我们来仔细分析一下。 什么是分布式系统的CAP？ CAP是指一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。 Consistency 一致性 一致性指更新操作成功并返回客户端完成后，分布式系统中所有节点在同一时间的数据完全一致。 从客户端的角度来看，一致性主要指的是并发访问时获取的数据一致。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 对于数据库来说，如果要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。 Availability 可用性 可用性指服务一直可用，整个系统是可以正常响应的。一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。我们经常说的3个9，4个9的SLA，就是对于可用性的量化表述。 Partition Tolerance分区容错性 分区容错性指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 而CAP定理证明