ZK

客户端连接 zkServer.sh start 启动zookeeper服务，运行 zkCli.sh –server ip 进入命令行工具 连接localhost的zookeeper的shell窗口 zkCli.sh -server localhost 连接hadoop01的zookeeper的shell窗口 zkCli.sh -server hadoop01 输入help，输出zk shell提示： [ zk : localhost : 2181 ( CONNECTED ) 7 ] help ZooKeeper - server host : port cmd args stat path [ watch ] set path data [ version ] ls path [ watch ] delquota [ - n | - b ] path ls2 path [ watch ] setAcl path acl setquota - n | - b val path history redo cmdno printwatches on | off delete path [ version ] sync path listquota path rmr path get path [ watch ] create [ - s ] [ - e ] path data acl

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文属于原创，转载注明出处，欢迎关注微信小程序 小白AI博客 微信公众号 小白AI 或者网站 https://xiaobaiai.net 或者我的CSDN http://blog.csdn.net/freeape [TOC] 1 前言 Kafka其他特点这里就不罗嗦了，本篇主要是集群开发环境的搭建。具体Kafka相关介绍内容和周边分析可以见另一篇文章《Kafka及周边深度了解》。Kafka是依赖Zookeeper的，单机单服务也需要。Apacke Kafka维护团队开始讨论去除Zookeeper了( 2019年11月6日 )，目前，Kafka使用ZooKeeper来存储分区和代理的元数据，并选择一个Broker作为Kafka控制器，而希望通过删除对ZooKeeper的依赖，将使Kafka能够以一种更具伸缩性和健壮性的方式管理元数据，实现对更多分区的支持，它还将简化Kafka的部署和配置。但是目前我们还是需要Zookeeper。 Zookeeper是由Java编写的，所以需要先安装JDK。 本篇文章主要实现以下内容： 单机单Kafka Broker和单Zookeeper(默认安装好后启动ZK和Kafka就是了) 单机Kafka Broker集群和Zookeeper集群 多机Kafka

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言 在传统的开发中，我们通常是将所有的功能打包在一起，然后统一部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。如下图所示： 这种开发方式虽然操作简单，代码重用率高，没有分布式的管理和调用消耗，但是由于代码功功能耦合在一起，通常是牵一发动全身，一个微小的问题，都可能导致整个应用挂掉。这对于大型应用来说，是很不可行的。因此，有人提出能不能将每一个小的服务独立开来，分别部署维护呢？如产品服务独立成一块，订单服务独立成一块，用户服务也独立成一块。这样，每一个服务之间都不会有高耦合性，后期维护升级也更加方便。 是的，将每一个服务独立部署分开维护，的确可以解决传统开发中的高耦合性，但是我们也要考虑在传统的开发方式中所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的服务器或进程中，客户端UI如何互相访问呢？ 后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。 另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）、和P（分区容错性）。由于分区容错性P在分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。 因此： Zookeeper保证的是CP， Eureka则是AP。 Zoopkeeper保证CP： 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但是不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样的一种情况，当master节点因网路故障与其他节点失去联系时，剩余的节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群是都是不可用的，这就导致在选举期间注册服务瘫痪，在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。 Eureka保证AP： Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其他的节点

1. 集群API   “curl -iXGET " http://192.168.127.100:9200/_cluster/health?pretty=true "” 这样的命令可能大家在日常工作中会经常使用，它用来显示当前集群的健康程度，在返回结果中，包含当前集群有关的一些关键信息（文献2提到了一个使用“wait_for_status”的小技巧）。   ES提供了类似上面命令的集群API用于获取集群即时状态与信息。根据API的URI可分为几类API,如下图所示：   请注意，“_cluster”API与“_cat”API提供的功能大部分重复，不同的是“_cat”API的输出结果非JSON格式，对于熟悉*nux的系统管理员来说更加亲切。 2. 应用客户端访问   除了可使用显式地HTTP rest请求访问ES集群，ES还提供了基于java的两种客户端开发包供ES用户在应用代码中调用： Transport Client：可用于向远程集群发送请求的轻量级传输客户机。它本身并不是ES集群的一部分，只承担向集群发送请求的职责。 Node client：使用该客户端的应用节点作为一个非数据节点加入ES集群。这个非数据节点并不保存数据，但它知道集群中所存储数据的元数据，可以直接将请求发送到对应数据节点。   TC客户端是应用程序与ES集群之间的桥梁