ZooKeeper

最近的项目还是用的老的kafka版本（0.8），用spark 接数据的时候，如果spark 程序意外重启，重启时间内的kafka数据会丢失。我们需要实现最少消费一次，数据重复没有关系。但不能允许丢失数据。 在 Spark Streaming 中消费 Kafka 数据的时候，有两种方式分别是 1）基于 Receiver-based 的 createStream 方法和 2）Direct Approach (No Receivers) 方式的 createDirectStream 方法， 在生产上我们首先用第一种方式，发现性能有很多损耗，而且也不稳定，所以我们后来使用的是第2种方式。我们把kafka 的offset 保存在zookeeper中，实际测试发现zookeeper保存offset效率还不错，下面是具体代码修改记录, 供参考： val topics = Set[String](kafkaInputTopic) val kafkaParams = Map[String, String]( "metadata.broker.list" -> destBrokerHost, "serializer.class" -> "kafka.serializer.StringEncoder", "group.id" -> kafkaGroup) var offsetRanges = Array

前言 在做实时数仓时，数据量往往比较大的，如果使用Canal来监听MySQL的状态当Canal 是单节服务时，服务器挂掉是就会造成数据丢失，这时Canal恰好可以配置HA这样就能解决单点问题，但是依赖于zookeeper,那我们就来配置一下Canal的HA。 一、Canal HA模式配置 1.1 服务器端HA模式配置 canal是支持HA的，其实现机制也是依赖zookeeper来实现的，用到的特性有watcher和EPHEMERAL节点(和session生命周期绑定)，与HDFS的HA类似。 canal的ha分为两部分，canal server和canal client分别有对应的ha实现 canal server: 为了减少对mysql dump的请求， 不同 server上的instance(不同server上的相同instance)要求同一时间只能有一个处于running，其他的处于standby状态(standby是instance的状态)。 canal client : 为了保证有序性，一份instance同一时间只能由一个canal client进行get/ack/rollback操作，否则客户端接收无法保证有序。 1.2 环境准备 Canal：node01,node02 zookeeper： node01,node02,node03 MySQL: node01 1.3

一、什么是CAP？ CAP示意图 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。 二、取舍策略 取舍策略图 CAP三个特性只能满足其中两个，那么取舍的策略就共有三种： CA without P： 如果不要求P（不允许分区），则C（强一致性）和A

分布式理论（一） CAP 理论 一． CAP 理论前言 CAP 原则又称为 CAP 理论，主要思想是在任何一个分布式系统中都无法同时满足 CAP 。 C （ Consistency ）：表示一致性，所有的节点同一时间看到的是相同的数据。 A （ Avaliablity ）：表示可用性，不管是否成功，确保一个请求都能接收到响应。 P （ Partion Tolerance ）：分区容错性，系统任意分区后，在网络故障时，仍能操作。 如上所述，正如 Gilbert 认为， 一致性 其实就是关系型数据库所讲的 ACID ，一个用户请求要么是成功，要么是失败的，不能有处于一个中间状态；一旦一个事务完成，将来所有事务都必须基于这个完成后的状态；未完成的事务不会互相影响；一旦一个事务完成，就是持戒的。 可用性 其实就是对于一个系统而言，所有的请求都应该 “成功”并且收到“响应”。 分区容错性 其实就是指分布式系统的容错性，一个节点出现了故障，不影响整个集群的正常使用。 二． CAP 理论介绍 如图，在一个网络中， N1 和 N2 即分布式系统中的两个节点，他们都共享数据块 V ，其中有一个值是为 V0 。 l 在满足一致性的时候， A 中的 V0 应该和 B 中的 V0 保持一致的，即 V0=V0 l 在满足可用性的时候，无论请求访问 A 或者是 B 都应该得到响应。 l 在满足分区可用性的时候

但作为面试者，想进入BAT并成长为一名高级Java工程师却没那么容易。 虽然面试者具备了一定的工作年限要求，也长期使用Java语言进行开发，但面试时，面对刨根问底的提问，经常感觉get不到面试官的点，自己回答的也是马马虎虎，甚至无法完整描述自己开发过的系统或者使用过的技术， 因此也就很难得到满意的面试结果。 过完年就是金三银四，2021不会比2020好过，过一年有很多小伙伴在面试中屡屡碰壁，不是基本功不扎实就是遇到一些平时没怎么接触过问题还失败告终。 今天在这特地整理了一份阿里，美团，京东，拼多多，蚂蚁金服等大厂Java岗面试必备清单！ 注意： 由于篇幅原因，在这只展示了目录和内容截图， 有需要这份大厂Java后端面试清单的（以及更多学习资料），可以免费分享给大家一起学习，转发后转发后添加小编vx：mxzFAFAFA即可免费获取！！！ JVM专题 作为Java从业者，在找工作的时候，一定会被问及关于 JVM 相关的知识。 JVM 知识的掌握程度，在很多面试官眼里是候选人技术深度的一个重要评判标准。 如果连JVM都回答不好，大厂一面基本也就凉凉！ 在这里我们将详细地整理常见的 JVM 面试题目，并给出标准答案， 提供给大家学习参考。 内容展示 Java并发/多线程专题 从事 Java开发的小伙伴们会发现 Java 多线程和并发无论是工作或者是面试都绕不开的话题

事情是这样的，我今天早上醒来手机上收到了来自腾讯云的通知，说我服务器中木马，于是我来到腾讯云控制台查看了一下，发现了5个病毒文件。 我的第一反应便是中挖矿病毒了，于是我顺便查看了一下服务器监控情况。果不其然，CPU直接跑满了。 于是我赶紧登陆了服务器， top 一下了解一下具体情况。 原来是这个名为kswapd0的程序登陆了我创建的zookeeper用户在疯狂的跑着我服务器的CPU。 于是我便上网搜了一下kswapd0，经过查证，这玩意是一个perl脚本，通过SSH爆破攻击目标系统，同时传播基于Perl的Shellbot和门罗币挖矿木马。 结果我便想到了，我本来用来玩转zookeeper而创建的zookeeper用户，账号密码都是zookeeper，而zookeeper客户端开启默认端口2181我也未进行修改。 我尝试登陆zookeeper用户，结果发现密码竟然不正确。好家伙，竟然还修改了我密码，于是我便通过root用户使用 passwd 命令重置了一下该用户密码。 接着，我使用 netstat -anltp|grep kswapd0 命令查看了一下kswapd0进程的对外端口，IP竟然来自荷兰。 因为我zookeeper服务端是一直开着的，也不难想象为什么会中病毒了。 病毒处理 杀死进程： 删除腾讯云控制台显示的木马程序所在的文件夹 将木马文件进一步隔离 可以看到

上一篇 说了一个案例是为了说明如何去考量一个Kafka集群的部署，算是一个参考吧，毕竟大家在不同的公司工作肯定也会有自己的一套实施方案。 这次我们再回到原理性的问题，这次会延续 第一篇 的风格，带领大家把图一步一步画出来。 Kafka的Producer原理 首先我们得先有个集群吧，然后集群中有若干台服务器，每个服务器我们管它叫Broker，其实就是一个个Kafka进程。 如果大家还记得 第一篇 的内容，就不难猜出来，接下来肯定会有一个controller和多个follower，还有个ZooKeeper集群，一开始我们的Broker都会注册到我们的ZooKeeper集群上面。 然后controller也会监听ZooKeeper集群的变化，在集群产生变化时更改自己的元数据信息。并且follower也会去它们的老大controller那里去同步元数据信息，所以一个Kafka集群中所有服务器上的元数据信息都是一致的。 上述准备完成后，我们正式开始我们生产者的内容。 名词1——ProducerRecord 生产者需要往集群发送消息前，要先把每一条消息封装成ProducerRecord对象，这是生产者内部完成的。之后会经历一个序列化的过程。之前好几篇专栏也是有提到过了，需要经过网络传输的数据都是二进制的一些字节数据，需要进行序列化才能传输。 此时就会有一个问题

1首先我们去官网下载hbase https://hbase.apache.org/book.html#quickstart_fully_distributed 点击它下载就可以了。 2 上传hbase 下面我们用winSCP或者mobaxterm把hadoop传输到一台虚拟机上的/usr/local/目录下，用软件连接后，选到/usr/local/目录拖进去就可以了 3 解压hadoop并配置环境变量 切换到/usr/local/目录下，执行命令 tar -zxvf hbase-2.0.5-bin.tar.gz 解压完成后，配置环境变量 vi /etc/profile 在末尾加入以下内容 export HBASE_HOME=/usr/local/hbase-2.0.5 export PATH=$PATH:$HBASE_HOME/bin:/$HBASE_HOME/sbin 记得执行 source /etc/profile 使环境变量生效 4修改hadoop中的一系列配置文件 执行命令 cd /usr/local/hbase-2.0.5/conf/ 切换到配置文件目录 4.1配置hbase-env.sh文件 执行命令vi hbase-env.sh 修改以下内容，并取消原文注释(#) export JAVA_HOME=/usr/local/java/jdk1.8.0_211 export

大数据环境安装笔记Hbase全分布式安装 系统环境：centos7 mininal 安装包： https://mirrors.tuna.tsinghua.edu.cn/apache/hbase/1.4.13/ 我安装包放在home目录里的，解压：tar -zxvf /home/hbase-1.4.13-bin.tar.gz 修改conf/文件下的配置文件hbase-env.sh vi hbase-env.sh export JAVA_HOME=/home/java 改jdk的路径 export HBASE_MANAGES_ZK=false 使用外部zookeeper，所以改成false(hbase有内置的zookeeper) 修改/conf里的hbase-site.xml配置文件:vi /home/hbase-1.4.13/conf/hbase-site.xml <!—hbase.root.dir 将数据写入哪个目录 如果是单机版只要配置此属性就可以， value中file:/绝对路径，如果是分布式则配置与hadoop的core-site.sh服务器、端口以及zookeeper中事先创建的目录一致--> <property> <name>hbase.rootdir</name> <value>hdfs://ZT01:9000/hbase</value> </property> <!

一 配置中心介绍 1 微服务架构下关于配置文件的问题 a 配置文件相对分散 在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。 b 配置文件无法区分环境 微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。 c 配置文件无法实时更新 我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说非常不友好。 2 配置中心的思路 首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。 服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。 配置中心参数有更新时，能够通知到微服务实时同步最新的配置信息，使之动态更新。 二 常见配置中心 1 Apollo Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料也写的很详细。 2 Disconf Disconf是由百度开源的分布式配置中心。基于Zookeeper实现配置变更后实时通知和生效。 3 SpringCloud Config Spring Cloud的配置中心组件。和Spring无缝集成