Minor的Java技术博客

对于Leader新写入的消息，consumer不能立即消费，Leader会等待该消息被所有的ISR节点同步后更新HW，此时消息才能够被消费者消费，这样就保证了如果Leader所在的Broker节点挂了，该消息仍然可以从新选举的Leader中获取。当Kafka集群启动的时候，会自动选举一个Broker作为控制器，选举的过程就是让每一个Broker去zookeeper中创建一个/controller的临时节点，创建成功的Broker就成为控制器。kafka定期清理topic里的消息，最后保留最新的数据。...

例如，TopicA分布在2个Broker节点上，每一个Broker节点都有默认4个这个TopicA的队列，如果此时只有1个消费者，那么这个消费者就会分摊8个队列的任务，如果此时加入一个消费者，那么每一个消费者就会平均分配4个。当队列数量和消费者数量持平的时候，此时再加入消费者，是不会触发Reblance的，多出来的消费者没有任何任务负担。（这种方式的缺点是有可能重试会再一次失败，因为如果第一次失败了大部分情况是这个Broker有问题了，所以当第二次选择这个Broker的其他队列时，大概率也会失败。.....

Sentinel组件和其它微服务组件一样，SpringBoot只需要引入一个sentinel的starter即可。Sentinel提供了一个可视化的UI控制台界面，在上面可以直观的看到微服务的状态和配置信息。Sentinel是阿里开源的一款分布式服务流控组件，主要以流量为切入点，从限流、流量塑形、熔断降级、负载保护、热点防护等多个维度来进行服务的稳定性保障。在分布式环境下，多个服务之间会存在频繁的依赖调用，在流量洪峰面前可能会造成某一个节点的资源耗尽或者是由于调用链依赖关系导致全链路发生故障、不可用。...

Redis虽然是通过C语言编写，但是他的字符串类型并没有采用C语言的字符串，而是自己定义了一个字符串类型叫SDS来作为Redis字符串类型的默认实现。例如执行，name作为key也是使用的SDS，value张三仍然是一个SDS对象作为底层实现。再例如，student作为key使用的是SDS，键值对的值是Redis五大结构中的List列表对象，列表对象底层也有对应的底层实现，那么列表的元素张三、李四仍然是通过SDS存储的。SDS除了用来保存数据库中的字符串值以外，SDS还用来作为一些缓冲区Buffer，例

Dubbo是阿里开源的一款RPC框架，现在已经是Apache的顶级项目，Dubbo的设计定位是一款高性能的RPC框架，随着Dubbo的发展，Dubbo还提供了服务治理、服务监控、服务网关等功能，所以Dubbo现在已经不单单是一款RPC框架了，还是一个具有不错生态的服务框架，但是单论服务生态能力还是和SpringCloud有所不足。Dubbo的SPI机制主要封装在一个叫。Dubbo的服务暴露的本质就是将服务端提供的接口服务告诉给客户端或者注册中心怎么访问具体的服务，就是将服务的请求路径URL暴露出来。...

就是一旦发生了加锁失败，大量的客户端都来watch同一个节点，这样可能会导致一旦锁被释放也就是临时节点被删除，那么zk就会通知所有的监听者。因为zk提供了watch监听机制，且zk同一个目录下的节点名字是不能重复的，基于这两个特性可以用来做分布式锁。这种方式相比于第一种而言，可以优化羊群效应。但是这种方式是一种公平锁的实现方式。但是这种实现方式有一个缺陷，类似于。...

客户端的写事务请求，都转交给Leader接受，Leader将该写事务请求发送给所有的Follower，然后根据集群内Follower的反馈来决定是否执行事务提交的命令发放(过半原则如果Follower超过半数得到ack回应就认为这次写事务可以做提交准备了)。Zookeeper是ApacheHadoop旗下的一款开源的分布式协调框架，它是一个分布式的kv存储系统，他类似于文件系统的目录的方式存储数据，还可以对数据进行监听和管理。zk的目录节点可以按照两个维度来划分是否有序、是否持久。...

不管是单机的锁还是分布式锁，要达成锁的功能一定要有原子性、互斥性的能力，Redis提供了好几个命令可以选择，其中使用最常用的就是命令：如果key不存在，就设置，否则就什么也不做。在分布式环境下，多个线程都来对某个key执行SETNX命令，Redis能够保证只有1个线程能够执行成功，这样就可以基于这个特点来做一个分布式锁。如果单纯用Redis的SETNX命令来实现分布式锁，还有很多问题。例如某个线程加锁成功，如果这个线程发生了永久性的阻塞或者进程结束，那么Redis里面的这个Key就永远无法释放，这样就发生了

所谓一致性问题，指的是缓存和数据库对同一份变量如何保持一致。一致性问题根据对缓存不一致的容忍程度可以划分为强一致和最终一致。强一致性保证只能通过一致性协议、分布式锁来进行控制。最终一致性可以通过MQ、最大努力通知等手段来实现。这个方案是最不可取的，因为如果一旦更新缓存成功，但是数据库写入失败就会发生脏数据问题。有可能发生数据库成功更新但是缓存更新失败，那么缓存中值永远都是旧的值。这个设计存在2个问题：1.如果先把缓存删掉，那么将会有大量读请求直接落地到DB层，造成DB压力。2.如果A线程删了缓存，还没来