weixiaohuai的博客

原创 Java面试题视频讲解汇总

写在前面：2022年面试必备的Java后端进阶面试题总结了一些视频在B站上，内容详细，逻辑清晰，有需要学习、找工作的朋友可以点赞、关注一下！后续会发布更多MySQL，Redis，并发，JVM，分布式等面试热点知识。

原创 十四、Nacos源码系列：Nacos配置发布原理

一般情况下，我们是通过Nacos提供的web控制台登录，然后通过界面新增配置信息。后续客户端只要配置了对应的NameSpace，group，dataId就可以在客户端获取到对应的配置信息。既然这样，服务端肯定会存储我们在web控制台配置的配置信息。web控制台发布配置的入口肯定也是一个controller接口：com.alibaba.nacos.config.server.controller.ConfigController#publishConfig。// 内容加密} else {

原创 十三、Nacos源码系列：Nacos配置中心原理（五）- 总结

原创 十二、Nacos源码系列：Nacos配置中心原理（四）- RefreshEvent 事件处理

回到refreshAll()方法，在 refreshAll()中调用 super.destroy()方法时会将该 scope 的这些 Bean 都销毁掉，在下次 get()的时候会重新新触发spring的createBean，创建出一个新的bean对象，新创建的 Bean 就有了我们最新的配置。我们继续回到前面处理RefreshEvent事件的ContextRefresher#refresh()方法，接着会有一步 refreshAll 的操作，会调用父类的destroy()方法。

原创 十一、Nacos源码系列：Nacos配置中心原理（三）- 配置热更新

从源码可以看到，NacosConfigManager 中会进行一个 ConfigService 单例对象的创建，创建流程最终会委托给 ConfigFactory，使用反射方式创建一个 NacosConfigService 的实例对象，NacosConfigService 是一个很核心的类，配置的获取，监听器的注册都需要经此。上面章节我们讲了服务启动的时候从远程 Nacos 服务端拉到配置，以及服务启动后对需要支持热更新的配置都注册了一个监听器，这个章节我们来说下配置变动后具体是怎么处理的。

原创 十、Nacos源码系列：Nacos配置中心原理（二）- 注册配置监听器

在spring-cloud-starter-alibaba-nacos-config-2.2.9.RELEASE.jar的META-INF/spring.factories文件中，除了引入了NacosConfigBootstrapConfiguration自动配置类，还引入了NacosConfigAutoConfiguration这个自动配置类，这个配置类就负责配置监听器的注册。到这里，在服务启动后向每一个需要支持热更新的配置都注册了一个监听器，用来监听远程配置的变动，以及做相应的处理。

原创 九、Nacos源码系列：Nacos配置中心原理（一）- SpringCloud应用启动时拉取配置

至此，在项目启动的时候（上下文准备阶段）通过NacosPropertySourceLocator就拉取到了远程 Nacos 中的配置信息，并且封装成 NacosPropertySource对象，然后PropertySourceBootstrapConfiguration依靠ApplicationContextInitializer机制（容器刷新之前支持一些自定义初始化工作），将前面封装好的NacosPropertySource对象放到了 Spring 的环境变量Environment 中。

原创 八、Nacos源码系列：Nacos集群数据同步

在Nacos以集群模式运行时，当Nacos服务器收到服务注册请求后，发生了ClientEvent.ClientChangedEvent事件，就会触发将注册的服务信息同步给集群中的其他Nacos-server节点。同步时，会涉及到一个负责节点和非负责节点。

原创 七、Nacos源码系列：Nacos服务发现

/ 调用栈如下：// getInstances(serviceId)方法最终会调用NacosNamingService#selectInstances()获取实例信息。// 集群名称,使用逗号分隔// 是否订阅，默认是订阅的/*** 1.从缓存中获取ServiceInfo* key: groupName@@serviceName 或者 groupName@@serviceName@@clusterString*/

原创 线上服务CPU/内存问题快速定位

原创 六、Nacos源码系列：Nacos健康检查

/ 启动了一个定时任务，无延迟，每隔5s执行一次// 具体就是执行ExpiredClientCleaner.run()方法@Override// 判断客户端是否超时if (null!// 超时连接处理客户端释放连接事件、客户端断开连接事件。

原创 五、Nacos源码系列：Nacos服务注册总结

总结图：一张图超过csdn上传文件最大限制了，只能分为几张图片：

原创 四、Nacos源码系列：Nacos服务注册流程(三)

接下来我们看下抽象的任务引擎类AbstractNacosTaskExecuteEngine。它有两个私有变量，分别是ConcurrentHashMap类型的taskProcessors，这个是对处理类NacosTaskProcessor的缓存。另一个是NacosTaskProcessor，这是一个默认的处理类，如果处理类缓存中不存在的话，就用这个处理类去处理。其源码如下：/*** 对处理类NacosTaskProcessor的缓存* key: Service服务。

原创 三、Nacos源码系列：Nacos服务注册流程(二) - NotifyCenter事件发布机制

NotifyCenter是Nacos中的统一事件通知中心。// 典型的单例模式（饿汉式）通过源码，我们可以发现，NotifyCenter使用了单例，说明整个进程共享这个实例，所有的内部变量归所有线程共享，我们需要考虑并发问题。也就是操作内部变量的时候，需要加锁去操作，防止其它线程也同时操作导致出错。/*** ringBufferSize/shareBufferSize这两个变量因为在静态块中初始化，然后并没有改变其初始值，所以不需要特殊处理*//*** EventPublisher工厂。

原创 二、Nacos源码系列：Nacos服务注册流程(一)

本篇文章中，我们从Nacos客户端自动注册在何时触发开始，然后分析了客户端向Nacos服务端提交服务注册请求，最后到Nacos服务端处理这个注册请求，整个流程大概梳理了一下，下一篇文章，我们将会详细分析NotifyCenter这个事件-发布机制的原理，然后继续分析服务端处理注册请求过程中涉及到的后续流程处理。

原创 一、Nacos源码系列：源码环境搭建

使用git clone https://github.com/alibaba/nacos命令将源码clone下来，或者先fork到自己的GitHub，然后clone到本地，这样阅读的时候，可以添加一些注释，提交到自己的GitHub上面，方便后续再次回来查看时快速回想起代码的含义。至此，Nacos源码阅读的环境就搭建好了，后续我们会进行服务注册、服务发现、以及服务心跳等功能进行分析。截止到编写这篇文章，Nacos的最新版本为2.3.0，为了学习，我们也是拿最新的源码来学习。

原创 四、Sharding-JDBC系列04：分库分表后，如何不停机迁移数据？

如果读出来的数据在新库里没有，或者这条数据的update_time最后修改的时间，比新库的数据新才会写。导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，对比新老库每个表的每条数据，如果有不一样的，就针对那些不一样的，从老库读数据再次写。迁移完了之后，修改系统的数据库连接配置啥的，包括可能代码和SQL也许有修改，那你就用最新的代码，然后直接启动连到新的分库分表上去。简单来说，就是在线上系统里面，之前所有对数据库增删改的操作，除了对老库增删改，都加上对新库的增删改，这就是所谓的双写。

原创 三、Sharding-JDBC系列03：自定义分片算法

使用场景：SQL 语句中有>，>=,

原创 二、Sharding-JDBC系列02：自定义主键生成策略

实际应用中，大部分场景按照MySQL主键ID自增就能满足需求，但是在分库分表后，MySQL的自增主键就不能使用了，为了避免重复，我们需要全局唯一的ID，比如会员表的会员ID、订单表的订单ID等。// UUID: 采用UUID.randomUUID()的方式产生分布式主键// SNOWFLAKE: 雪花算法，生成64bit的长整型数据还抽离出分布式主键生成器的接口，方便用户自行实现自定义的自增主键生成器。

原创 一、Sharding-JDBC系列01：整合SpringBoot实现分库分表，读写分离

Sharding-JDBC定位为轻量级Java框架，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

原创 22、Kubernetes核心技术 - 整合Rancher通过界面管理k8s集群

Rancher 是为使用容器的公司打造的容器管理平台。Rancher 简化了使用 Kubernetes 的流程，开发者可以随处运行 Kubernetes（Run Kubernetes Everywhere），满足 IT 需求规范，赋能 DevOps 团队。Rancher 可以创建来自 Kubernetes 托管服务提供商的集群，自动创建节点并安装 Kubernetes 集群，或者导入任何已经存在的 Kubernetes 集群。

原创 21、Kubernetes核心技术 - 高可用集群搭建（kubeadm+keepalived+haproxy）

前面我们介绍了使用kubeadm搭建k8s集群，当时只使用了一个master节点，其实是不满足k8s高可用的。因为当master节点发生宕机时，通过node节点将无法继续访问，所以整个集群将无法正常提供服务。本篇文章，我们将使用kubeadm，配合keepalived、haproxy来实现k8s集群的高可用。

原创 20、Kubernetes核心技术 - 基于Prometheus和Grafana搭建集群监控平台

Prometheus是一个开源系统监控和警报工具包，最初由SoundCloud构建。自2012年Prometheus项目启动以来，许多公司和组织都采用了它，该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。为了强调这一点，并澄清项目的治理结构，Prometheus于2016年加入了云原生计算基金会，成为继Kubernetes之后的第二个托管项目。开源监控、报警、数据库以 HTTP 协议周期性抓取被监控组件状态。

原创 19、Kubernetes核心技术 - 资源限制

当定义 Pod 时，我们可以定义多个容器，我们知道，容器的程序要运行肯定是要占用一定资源的，比如CPU和内存等，默认情况下，Pod运行没有CPU和内存的限额。如果不对某个容器的资源进行限制，那么它就可能消耗大量资源，导致其他容器无法运行。limits用于限制运行时容器的最大占用资源，当容器占用资源超过limit时就会被终止，并将进行重启。当为容器指定了 limit 资源时，kubelet 就可以确保运行的容器不会使用超出所设限制的资源，设置为0表示对使用的资源不做限制, 可无限的使用。requests。

原创 18、Kubernetes核心技术 - InitContainer（初始化容器）

InitContainer即初始化容器，是 K8S官方为我们提供的一个可以用来判断环境是否已经满足运行 Pod 应用前所需要的条件。比如我们有一个应用，需要部署到Tomcat环境，那么在部署这个应用Pod之前，我们需要检查Tomcat环境是否已经准备好，InitContainer就可以用来做这个事情，我们可以让InitContainer运行 until 命令进行判断，判断是否满足我们应用运行的要求，如果满足运行要求，执行成功后便会退出，否则将会一直进行循环操作，直到条件成功。

原创 17、Kubernetes核心技术 - 污点（Taints）和污点容忍（Tolerations）

上一篇文章介绍了节点亲和性，它主要实现的是将Pod强制或者尽可能调度到满足某些条件的node节点上【通过在Pod上添加属性，来确定Pod是否要调度到指定的节点上，k8s中的污点，它的行为刚好与节点亲和性相反，污点可以将节点和 Pod 达到互斥的效果，让Pod不被调度到存在污点的那些节点上【在Node节点上添加污点属性（Taints），来避免Pod被分配到不合适的节点上】；k8s中的污点容忍，则可以让 Pod 调度到带有污点的节点上。taints（污点）

原创 16、Kubernetes核心技术 - 节点选择器、亲和和反亲和

在 Kubernetes 中 Pod 的调度都是由kube-scheduler组件来完成的，整个调度过程都是自动完成的，也就是说我们并不能确定 Pod 最终被调度到了哪个节点上。而在实际环境中，可能需要将Pod调度到指定的节点上。机器学习相关应用希望调度到有 GPU 硬件的节点上；数据库应用需要调度到有 SSD 的节点上；为了保证应用的高可用性，需要将同一应用的不同Pod分散在不同的节点上，以防节点所在机器出现宕机等情况导致Pod重建；两个不同的应用需要调度到同一个节点上；

原创 15、Kubernetes核心技术 - 探针

在k8s中，我们不能仅仅通过查看应用的运行状态，来判断应用是否正常，因为在某些时候，容器正常运行并不能代表应用健康，因此，k8s提供了探针（Probe）技术，来帮助我们判断容器内运行的应用是否运行正常，探针有点类似心跳检测。

原创 14、Kubernetes核心技术 - 生命周期回调

Kubernetes 为容器提供了生命周期回调。回调使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期回调时运行在处理程序中实现的代码。Kubernetes 支持 postStart 和 preStop 事件。当一个容器启动后，Kubernetes 将立即发送 postStart 事件；在容器被终结之前， Kubernetes 将发送一个 preStop 事件。容器可以为每个事件指定一个处理程序。通过postStart指定容器启动后需要执行的一些逻辑。

原创 13、Kubernetes核心技术 - Ingress

1、NodePort但是这两种方式在集群规模比较大的时候，都会存在一些问题。NodePort：每个主机节点都要暴露出一个端口，如果Service很多的话，会占用很多集群机器的端口，并且端口过多，也不便于管理；LoadBalancer：每一个Service 都需要一个 LB（负载均衡器），如果Service很多的话，将会造成LB浪费，并且LoadBalancer需要外部的负载均衡设备进行支持；

原创 12、Kubernetes中KubeProxy实现之iptables和ipvs

iptables和ipvs其实都是依赖的一个共同的Linux内核模块：Netfilter。Netfilter是Linux 2.4.x引入的一个子系统，它作为一个通用的、抽象的框架，提供一整套的hook函数的管理机制，使得诸如数据包过滤、网络地址转换(NAT)和基于协议类型的连接跟踪成为了可能。Netfilter的架构就是在整个网络流程的若干位置放置了一些检测点（HOOK），而在每个检测点上登记了一些处理函数进行处理。

原创 11、Kubernetes核心技术 - Service

在k8s中，Pod是应用程序的载体，我们可以通过Pod的IP地址来访问应用程序，但是当Pod宕机后重建后，其IP地址等状态信息可能会变动，也就是说Pod的IP地址不是固定的，这也就意味着不方便直接采用Pod的IP地址对服务进行访问。为了解决这个问题，k8s提供了Service资源，Service会对提供同一个服务的多个Pod进行聚合，并且提供一个统一的入口地址，通过访问Service的入口地址就能访问到后面的Pod服务 ，并且将请求负载分发到后端的各个容器应用上。Service引入主要是。

原创 10、Kubernetes核心技术 - Label标签

Label（标签）是Kubernetes系统中一个比较重要的概念，给某个资源对象（Node、Pod、Service等）定义一个Label，就相当于给它打了一个标签，然后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过label对资源进行分区和管理。Label的特点：我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。示例如下：这是一个有 envir

原创 9、Kubernetes核心技术 - Volume

1、容器中的文件在磁盘上是临时存放的，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失，因为容器会以干净的状态（镜像最初的状态）重新启动【持久化存储】；2、当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件【多容器数据共享】；Kubernetes 支持很多类型的卷。Pod 可以同时使用任意数目的卷类型。临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长。当 Pod 不再存在时，Kubernetes 也会销毁临时卷；

原创 8、Kubernetes核心技术 - ConfigMap

ConfigMap 功能在 Kubernetes1.2 版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配 置信息。ConfigMap API给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON 二进制大对象。ConfigMap 的主要作用就是为了让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。注意：ConfigMap 并不提供保密或者加密功能。如果你想存储的数据是加密的，请使用Secret。

原创 7、Kubernetes核心技术 - Secret

Secret 解决了密码、令牌、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec 中，它把 Pod 想要访问的加密数据存放到 Etcd 中，然后用户就可以通过在 Pod 的容器里挂载 Volume 的方式或者环境变量的方式访问到这些 Secret 里保存的信息。

原创 @ConditionalOnBean、@ConditionalOnMissingBean、@ConditionalOnClass

是 Spring Boot 中的一个条件注解，用于在 Spring 容器中存在指定类型的 Bean 时才会生效。这个注解通常用于在某个 Bean 存在的前提下才加载另外一些相关的配置或 Bean，以实现根据已有的 Bean 进行条件化加载其他配置或 Bean。它可以帮助实现依赖于其他 Bean 存在与否的功能。

原创 6、Kubernetes核心技术 - Pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod 里面是由一个或多个容器组成【一组容器的集合】，这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 是 Kubernetes 的最重要概念，每一个 Pod 都有一个特殊的被称为”根容器“的Pause容器。Pause 容器对应的镜像属于 Kubernetes 平台的一部分，除了Pause 容器，每个Pod还包含一个或多个紧密相关的用户业务容器。资源共享一个 Pod 里的多个容器可以共享存储和网络。

原创 5、Kubernetes核心技术 - Controller控制器工作负载

我们看到，最下面的Scaled up replica set nginx-deployment-85996f8dbd to 3，其实就是运行三个副本的Pod，在k8s中它是通过ReplicaSet（副本集）来实现的，当我们创建一个deployment的时候，会自动创建一个ReplicaSet来管理pod的副本数量。在实际的场景中，并不能满足所有应用，尤其是分布式应用，会部署多个实例，这些实例之间往往有依赖关系，例如主从关系、主备关系，这种应用称为“有状态”，例如MySQL主从、Etcd集群。

原创 4、Kubernetes 集群 YAML 文件详解

k8s 集群中对资源管理和资源对象编排部署都可以通过声明YAML文件来解决，也就是可以把需要对资源对象操作编辑到 YAML 格式文件中，我们把这种文件叫做资源清单文件，通过 kubectl 命令直接使用资源清单文件就可以实现对大量的资源对象进行编排部署了。YAML 文件 : 就是资源清单文件，用于资源编排。