上一页 1 ··· 43 44 45 46 47 48 49 50 51 ··· 55 下一页
摘要: 首先需要有处理网络连接通讯的模块,负责连接建立、管理和消息的传输。其次需要有编解码的模块,因为网络通讯都是传输的字节码,需要将我们使用的对象序列化和反序列化。剩下的就是客户端和服务器端的部分,服务器端暴露要开放的服务接口,客户调用服务接口的一个代理实现,这个代理实现负责收集数据、编码并传输给服务器然 阅读全文
posted @ 2020-05-31 00:23 咔啡 阅读(247) 评论(0) 推荐(0)
摘要: (1)Eureka取CAP的AP,注重可用性,Zookeeper取CAP的CP注重一致性。 (2)Zookeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但选举期间不可用。 (3)eureka的自我保护机制,会导致一个结果就是不会再从注册列表移除因长时间没收到心跳而过期的服务。依然能接受新服务 阅读全文
posted @ 2020-05-31 00:22 咔啡 阅读(1568) 评论(0) 推荐(0)
摘要: (1)远程调用,比如feign调用,直接通过远程过程调用来访问别的service。 (2)消息中间件 阅读全文
posted @ 2020-05-31 00:16 咔啡 阅读(147) 评论(0) 推荐(0)
摘要: 维度(springcloud) 服务开发:springboot spring springmvc 服务配置与管理:Netfix公司的Archaiusm ,阿里的Diamond 服务注册与发现:Eureka,Zookeeper 服务调用:Rest RPC gRpc 服务熔断器:Hystrix 服务负载均 阅读全文
posted @ 2020-05-30 23:59 咔啡 阅读(153) 评论(0) 推荐(0)
摘要: 答:&运算符有两种用法:(1)按位与;(2)逻辑与。&&运算符是短路与运算。逻辑与跟短路与的差别是非常巨大的,虽然二者都要求运算符左右两端的布尔值都是true整个表达式的值才是true。&&之所以称为短路运算是因为,如果&&左边的表达式的值是false,右边的表达式会被直接短路掉,不会进行运算。很多 阅读全文
posted @ 2020-05-30 23:57 咔啡 阅读(339) 评论(0) 推荐(0)
摘要: Zookeeper保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用) (1)当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的信息,但不能容忍直接down掉不可用。就是说,服务注册功能对高可用性要求比较高,但zk会出现这样一种情况,当master节点因为 阅读全文
posted @ 2020-05-30 23:55 咔啡 阅读(345) 评论(0) 推荐(0)
摘要: 答:会执行,在方法返回调用者前执行。 阅读全文
posted @ 2020-05-30 23:54 咔啡 阅读(296) 评论(0) 推荐(0)
摘要: ribbon是一个负载均衡客户端,可以很好的控制htt和tcp的一些行为。feign默认集成了ribbon。 阅读全文
posted @ 2020-05-30 23:51 咔啡 阅读(544) 评论(0) 推荐(0)
摘要: 当Eureka Server 点在短时间内丢失了过多实例的连接时(比如网络故障或频繁启动关闭客户端)节点会进入自我保护模式,保护注册信息,不再删除注册数据,故障恢复时,自动退出自我保护模式。 阅读全文
posted @ 2020-05-30 22:52 咔啡 阅读(243) 评论(0) 推荐(0)
摘要: (1)Zuul 包含了对请求的路由和过滤两个最主要的功能:其中 责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础而过滤器功能则负 请求的处理过程进行干预,是实现请求校验、服务聚合等功能的基础、 (2)Zuul和Eureka进行整合,将Zuul自身注册为Eureka服务治理下的应用, 阅读全文
posted @ 2020-05-30 22:41 咔啡 阅读(400) 评论(0) 推荐(0)
摘要: @EnableHystrix:开启熔断 @HystrixCommand(fallbackMethod=”XXX”):声明一个失败回滚处理函数XXX,当被注解的方法执行超时(默认是 0毫秒),就会执行fallback函数,返回错误提示。 阅读全文
posted @ 2020-05-30 21:33 咔啡 阅读(228) 评论(0) 推荐(0)
摘要: (1)Eureka保证的是可用性和分区容错性,Zookeeper 保证的是一致性和分区容错性 。 (2)Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障。而不会像zookeeper那样使整个注册服务瘫痪。 阅读全文
posted @ 2020-05-29 22:58 咔啡 阅读(150) 评论(0) 推荐(0)
摘要: (1)Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。 (2)Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等。简单的说,就是在配置文件中列出Load Balancer(简称LB)后面所有的机器,Ribbon会自动的帮助你基于某种 阅读全文
posted @ 2020-05-29 18:56 咔啡 阅读(287) 评论(0) 推荐(0)
摘要: (1)将用户的请求平摊的分配到多个服务上 (2)集中式LB即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件,如F5, 也可以是软件,如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方; (3)进程内LB将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,然后 阅读全文
posted @ 2020-05-29 16:52 咔啡 阅读(384) 评论(0) 推荐(0)
摘要: (1)feign采用的是基于接口的注解 (2)feign整合了ribbon,具有负载均衡的能力 (3)整合了Hystrix,具有熔断的能力 使用: (1)添加pom依赖。 (2)启动类添加@EnableFeignClients (3)定义一个接口@FeignClient(name=“xxx”)指定调 阅读全文
posted @ 2020-05-29 16:26 咔啡 阅读(512) 评论(0) 推荐(0)
摘要: (1)Ribbon都是调用其他服务的,但方式不同。 (2)启动类注解不同,Ribbon是@RibbonClient feign的是@EnableFeignClients (3)服务指定的位置不同,Ribbon是在@RibbonClient注解上声明,Feign则是在定义抽象方法的接口中使用@Feig 阅读全文
posted @ 2020-05-28 17:09 咔啡 阅读(1163) 评论(0) 推荐(1)
摘要: spring cloud bus 将分布式的节点用轻量的消息代理连接起来,它可以用于广播配置文件的更改或者服务直接的通讯,也可用于监控。 如果修改了配置文件,发送一次请求,所有的客户端便会重新读取配置文件。 使用: (1)添加依赖 (2)配置rabbimq 阅读全文
posted @ 2020-05-28 14:32 咔啡 阅读(226) 评论(0) 推荐(0)
摘要: 当一个服务调用另一个服务由于网络原因或自 原因出现问题,调用者就会等 调用者的响应 当更多的服务请求到这些资源导致更多的请求等待,发生连锁效应(雪崩效应) 断路器有完全打开状态:一段时间内 到一定的次数无法调用 并且多次监 没有恢复的迹象 断路器完全打开 那么下次请求就不会请求到该服务 半开:短时间 阅读全文
posted @ 2020-05-28 00:45 咔啡 阅读(225) 评论(0) 推荐(0)
摘要: (1)服务发布时,指定对应的服务名,将服务注册到 注册中心(eureka zookeeper) (2)注册中心加@EnableEurekaServer,服务用@EnableDiscoveryClient,然后用ribbon或feign进行服务直接的调用发现。 阅读全文
posted @ 2020-05-28 00:38 咔啡 阅读(307) 评论(0) 推荐(0)
摘要: (1)Eureka取CAP的AP,注重可用性,Zookeeper取CAP的CP注重一致性。 (2)Zookeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但选举期间不可用。 (3)eureka的自我保护机制,会导致一个结果就是不会再从注册列表移除因长时间没收到心跳而过期的服务。依然能接受新服务 阅读全文
posted @ 2020-05-27 21:21 咔啡 阅读(1073) 评论(0) 推荐(0)
摘要: 当Eureka Server 点在短时间内丢失了过多实例的连接时(比如网络故障或频繁启动关闭客户端)节点会进入自我保护模式,保护注册信息,不再删除注册数据,故障恢复时,自动退出自我保护模式。 阅读全文
posted @ 2020-05-27 21:00 咔啡 阅读(547) 评论(0) 推荐(0)
摘要: 维度(springcloud) 服务开发:springboot spring springmvc 服务配置与管理:Netfix公司的Archaiusm ,阿里的Diamond 服务注册与发现:Eureka,Zookeeper 服务调用:Rest RPC gRpc 服务熔断器:Hystrix 服务负载均 阅读全文
posted @ 2020-05-27 19:29 咔啡 阅读(206) 评论(0) 推荐(0)
摘要: (1)远程调用,比如feign调用,直接通过远程过程调用来访问别的service。 (2)消息中间件 阅读全文
posted @ 2020-05-27 19:27 咔啡 阅读(1241) 评论(0) 推荐(0)
摘要: 请参考答案中的示例代码。只要记住在同步块中调用 wait() 和 notify()方法,如果阻塞,通过循环来测试等待条件。 阅读全文
posted @ 2020-05-27 18:04 咔啡 阅读(291) 评论(0) 推荐(0)
摘要: 请参考答案中的示例代码,这里面一步一步教你创建一个线程安全的 Java 单例类。当我们说线程安全时,意思是即使初始化是在多线程环境中,仍然能保证单个实例。Java 中,使用枚举作为单例类是最简单的方式来创建线程安全单例模式的方式。 阅读全文
posted @ 2020-05-27 17:18 咔啡 阅读(868) 评论(0) 推荐(0)
摘要: 日志收集:一个公司可以用Kafka可以收集各种服务的log,通过kafka以统一接口服务的方式开放给各种consumer,例如hadoop、HBase、Solr等。 消息系统:解耦和生产者和消费者、缓存消息等。 用户活动跟踪:Kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、搜 阅读全文
posted @ 2020-05-27 07:06 咔啡 阅读(404) 评论(0) 推荐(0)
摘要: Producer :消息生产者,就是向 kafka broker 发消息的客户端。 Consumer :消息消费者,向 kafka broker 取消息的客户端。 Topic :可以理解为一个队列,一个 Topic 又分为一个或多个分区, Consumer Group:这是 kafka 用来实现一个 阅读全文
posted @ 2020-05-27 05:59 咔啡 阅读(224) 评论(0) 推荐(0)
摘要: kafka 中的每个 partition 中的消息在写入时都是有序的,而且单独一个 partition 只能由一个消费者去消费,可以在里面保证消息的顺序性。但是分区之间的消息是不保证有序的。 阅读全文
posted @ 2020-05-27 05:33 咔啡 阅读(1764) 评论(1) 推荐(0)
摘要: ISR:In-Sync Replicas 副本同步队列 OSR:Out-of-Sync Replicas AR:Assigned Replicas 所有副本 ISR是由leader维护,follower从leader同步数据有一些延迟,超过相应的阈值会把 follower 剔除出 ISR, 存入OS 阅读全文
posted @ 2020-05-27 05:25 咔啡 阅读(1730) 评论(0) 推荐(0)
摘要: Kafka最初考虑的问题是,customer应该从brokes拉取消息还是brokers将消息推送到consumer,也就是pull还push。在这方面,Kafka遵循了一种大部分消息系统共同的传统的设计:producer将消息推送到broker,consumer从broker拉取消息。 一些消息系 阅读全文
posted @ 2020-05-27 04:09 咔啡 阅读(12521) 评论(0) 推荐(1)
摘要: Kafa consumer消费消息时,向broker发出fetch请求去消费特定分区的消息,consumer指定消息在日志中的偏移量(offset),就可以消费从这个位置开始的消息,customer拥有了offset的控制权,可以向后回滚去重新消费之前的消息,这是很有意义的 阅读全文
posted @ 2020-05-26 21:32 咔啡 阅读(4347) 评论(0) 推荐(0)
摘要: 在启动 Kafka 集群之前,我们需要配置好 log.dirs 参数,其值是 Kafka 数据的存放目录,这个参数可以配置多个目录,目录之间使用逗号分隔,通常这些目录是分布在不同的磁盘上用于提高读写性能。 当然我们也可以配置 log.dir 参数,含义一样。只需要设置其中一个即可。 如果 log.d 阅读全文
posted @ 2020-05-26 16:04 咔啡 阅读(703) 评论(0) 推荐(0)
摘要: 旧的 Kafka 消费者 API 主要包括:SimpleConsumer(简单消费者) 和 ZookeeperConsumerConnectir(高级消费者)。SimpleConsumer 名字看起来是简单消费者,但是其实用起来很不简单,可以使用它从特定的分区和偏移量开始读取消息。高级消费者和现在新 阅读全文
posted @ 2020-05-26 15:30 咔啡 阅读(566) 评论(0) 推荐(0)
摘要: Kafka是分布式消息系统,需要处理海量的消息,Kafka的设计是把所有的消息都写入速度低容量大的硬盘,以此来换取更强的存储能力,但实际上,使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几个方式实现了超高的吞吐率: 顺序读写; 零拷贝 文件分段 批量发送 数据压缩。 阅读全文
posted @ 2020-05-26 15:12 咔啡 阅读(566) 评论(0) 推荐(0)
摘要: 在Kafka中,当有新消费者加入或者订阅的topic数发生变化时,会触发Rebalance(再均衡:在同一个消费者组当中,分区的所有权从一个消费者转移到另外一个消费者)机制,Rebalance顾名思义就是重新均衡消费者消费。Rebalance的过程如下: 第一步:所有成员都向coordinator发 阅读全文
posted @ 2020-05-26 02:47 咔啡 阅读(1087) 评论(0) 推荐(0)
摘要: 我们可以使用 bin/kafka-topics.sh 命令对 Kafka 增加 Kafka 的分区数据,但是 Kafka 不支持减少分区数。 Kafka 分区数据不支持减少是由很多原因的,比如减少的分区其数据放到哪里去?是删除,还是保留?删除的话,那么这些没消费的消息不就丢了。如果保留这些消息如何放 阅读全文
posted @ 2020-05-26 00:06 咔啡 阅读(4914) 评论(0) 推荐(1)
摘要: zookeeper 是一个分布式的协调组件,早期版本的kafka用zk做meta信息存储,consumer的消费状态,group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题,新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部 阅读全文
posted @ 2020-05-25 23:31 咔啡 阅读(6154) 评论(0) 推荐(0)
摘要: broker 是消息的代理,Producers往Brokers里面的指定Topic中写消息,Consumers从Brokers里面拉取指定Topic的消息,然后进行业务处理,broker在中间起到一个代理保存消息的中转站。 阅读全文
posted @ 2020-05-25 23:03 咔啡 阅读(11842) 评论(1) 推荐(2)
摘要: leader会维护一个与其基本保持同步的Replica列表,该列表称为ISR(in-sync Replica),每个Partition都会有一个ISR,而且是由leader动态维护 ,如果一个follower比一个leader落后太多,或者超过一定时间未发起数据复制请求,则leader将其重ISR中 阅读全文
posted @ 2020-05-25 17:47 咔啡 阅读(503) 评论(0) 推荐(0)
摘要: Kafka的复制机制既不是完全的同步复制,也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完,这条消息才会被认为commit,这种复制方式极大的影响了吞吐率。而异步复制方式下,Follower异步的从Leader复制数据,数据只要被Leader写入log就被认为已经c 阅读全文
posted @ 2020-05-25 14:24 咔啡 阅读(1897) 评论(0) 推荐(0)
上一页 1 ··· 43 44 45 46 47 48 49 50 51 ··· 55 下一页