# JavaRoute **Repository Path**: leiyuee/java-route ## Basic Information - **Project Name**: JavaRoute - **Description**: 学习路线 - **Primary Language**: Java - **License**: AGPL-3.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2021-12-09 - **Last Updated**: 2026-01-16 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 1、计算机基础 1. 计算机硬件 - 中央处理器：CPU是计算机的大脑，从内存中获取指令，然后执行这些指令 控制单元：控制和协调其他单元的动作 算术/逻辑单元：用于完成数值运算和逻辑运算 每台计算机都有一个内部时钟，该时钟以固定速度发射电子脉冲，时钟速度越快，给定时间内能执行的指令就越多，其计量单位是赫兹（Hz）, 1Hz 约等于每秒1个脉冲，现在以千兆赫（GHz）来表述 1GHz = 11024MHz = 110241024kHz =1102410241024Hz 核数：提高CPU的处理能力 - 内存：主存 - 存储设备：磁盘等 - 输入设备：鼠标、键盘 - 输出设备：显示器、打印机 - 通信设备：网卡、调制解调器等 个人计算机上，总线搭建在主板上，主板是一个连接计算机各个部分的电路板 2. 冯诺依曼体系结构 3. # 2、Java学习 ## 2.1 Java基础 - 程序设计：创建或开发软件→写代码👉通过代码指令告诉计算机要做什么 - 在c和c++ 的基础上 # 2.1.1 1.自动类型提升 2.1.2 JVM相关 核心机制：垃圾回收 什么是虚拟机？ Java 内存区域是怎么划分的？ 大对象放在哪个内存区域？ 垃圾回收有哪些算法？ GC 的流程 什么是类加载？ 何时类加载？ 类加载流程？ 知道哪些类加载器。类加载器之间的关系？ 类加载器的双亲委派了解么？ 结合 Tomcat 说一下双亲委派（Tomcat 如何打破双亲委托机制？…）。 常见调优参数有哪些？ ## 2.2 数据库 动力节点《mysql数据库视频》 安全：登录、增加/删除用户、备份数据和还原数据 数据库操作： 建库建表/删库删表、用户权限分配 …… MySQL 中常用的数据类型、字符集编码 MySQL 简单查询、条件查询、模糊查询、多表查询以及如何对查询结果排序、过滤、分组…… MySQL 中使用索引、视图、存储过程、游标、触发器 …… 如果你想让自己更加了解 MySQL ，同时也是为了准备面试的话，下面这些知识点要格外注意： 索引：索引优缺点、B 树和 B+树、聚集索引与非聚集索引、覆盖索引 事务：事务、数据库事务、ACID、并发事务、事务隔离级别 存储引擎（MyISAM 和 InnoDB） 锁机制与 InnoDB 锁算法 redis Redis 和 Memcached 的区别和共同点 为什么要用 Redis/为什么要用缓存？ Redis 常见数据结构以及使用场景分析 Redis 没有使用多线程？ 为什么不使用多线程？ Redis6.0 之后为何引入了多线程？ Redis 给缓存数据设置过期时间有啥用？ Redis 是如何判断数据是否过期的呢？ 过期的数据的删除策略了解么？ Redis 内存淘汰机制了解么？ Redis 持久化机制(怎么保证 Redis 挂掉之后再重启数据可以进行恢复) Redis 缓存穿透、缓存雪崩？ 如何保证缓存和数据库数据的一致性？ …… ## 2.3 常用框架 一定要搞懂 AOP 和 IOC 这两个概念。 Spring 中 bean 的作用域与生命周期、 SpringMVC 工作原理详解等等知识点都是非常重要的，一定要搞懂。 ## 2.4 Netty 学习 Netty 基于 NIO （NIO 是一种同步非阻塞的 I/O 模型，在 Java 1.4 中引入了 NIO ）。 使用 Netty 可以极大地简化并简化了 TCP 和 UDP 套接字服务器等网络编程, 并且性能以及安全性等很多方面都非常优秀。 我们平常经常接触的 Dubbo、RocketMQ、Elasticsearch、gRPC、Spark、Elasticsearch 等等热门开源项目都用到了 Netty。 大部分微服务框架底层涉及到网络通信的部分都是基于 Netty 来做的， 比如说 Spring Cloud 生态系统中的网关 Spring Cloud Gateway 《Netty 实战》 ## 2.5 分布式微服务 极客时间《从零开始学架构》 事务与锁、分布式（CAP、分布式事务……）、高并发、高可用 ### ### 2.5.1 服务注册与发现 ### 2.5.2 API网关 ### 2.5.3 配置中心 ### 2.5.4 声明式服务调用 服务消费者去调用服务提供者，服务提供者暴露接口，服务消费者通过接口调用服务提供者 #### 2.5.4.1 restTemplate RestTemplate：通过getForObjet(),postForObject()等方法，可以方便的调用RESTful接口，并将返回结果转换为Java对象。 可以配置@LoadBalanced注解开启客户端负载均衡，自动负载均衡 #### 2.5.4.2 OpenFeign 声明式服务调用和负载均衡组件，基于RestTemplate的封装， 只需要声明一个借口，并通过注解进行简单的配置，即可实现对HTTP借口的绑定 ### 2.5.5 分布式ID ### 2.5.7 分布式缓存 为什么需要缓存：长期不变的数据放缓存里面？数据库只做数据的持久化工作；第一次查出来数据后将将数据存入缓存 - 对即使性，数据一致性要求不高的（如：物流信息，商品信息，商品分类） - 读多写少的数据 - 访问量大，更新频率低的数据 本地缓存：一台机器，部署到一个服务器上，很快 分布式环境就需要分布式缓存了 整合redis: 整合redisson 缓存一致性： 写读和写写，用canal读取binlog更新缓存,解决数据异构 问题1：双写模式 问题2：失效性→用读写锁 加过期时间 - 1、想要提高应用的性能，可以引入「缓存」来解决 - 2、引入缓存后，需要考虑缓存和数据库一致性问题，可选的方案有：「更新数据库 + 更新缓存」、「更新数据库 + 删除缓存」 - 3 、更新数据库 + 更新缓存方案，在「并发」场景下无法保证缓存和数据一致性，且存在「缓存资源浪费」和「机器性能浪费」的情况发生 - 4 、在更新数据库 + 删除缓存的方案中，「先删除缓存，再更新数据库」在「并发」场景下依旧有数据不一致问题，解决方案是「延迟双删」，但这个延迟时间很难评估，所以推荐用「先更新数据库，再删除缓存」的方案 - 5、在「先更新数据库，再删除缓存」方案下，为了保证两步都成功执行，需配合「消息队列」或「订阅变更日志」的方案来做，本质是通过「重试」的方式保证数据一致性 - 6、在「先更新数据库，再删除缓存」方案下，「读写分离 + 主从库延迟」也会导致缓存和数据库不一致，缓解此问题的方案是「延迟双删」，凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率 - 7、性能和一致性不能同时满足，为了性能考虑，通常会采用「最终一致性」的方案 - 8 、掌握缓存和数据库一致性问题，核心问题有 3 点：缓存利用率、并发、缓存 + 数据库一起成功问题 - 9、失败场景下要保证一致性，常见手段就是「重试」，同步重试会影响吞吐量，所以通常会采用异步重试的方案 - 10、订阅变更日志的思想，本质是把权威数据源（例如 MySQL）当做 leader 副本， 让其它异质系统（例如 Redis / Elasticsearch）成为它的 follower 副本，通过同步变更日志的方式，保证 leader 和 follower 之间保持一致 ### 2.5.6 分布式事务 #### 2.5.6.1 cap理论 - 一致性（Consistency）:客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取的都是刚写入的数据👉保证了不管向哪台服务器写入数据，其他服务器能实时同步数据 - 可用性（Availability）:每次 向未崩溃的节点发送请求，总能保证收到响应数据（允许不是最新数据） - 分区容错（Partition tolerancd）:系统遇到网络分区故障的时候，能对外部提供满足一致性和可用性的服务👉 服务A和B因意外情况，数据无法同步，系统要能容忍这种情况 首先 P是必须满足的，因此只能在C和A中做出取舍　（CA应该只能是单体架构）、、、 在分布式事务的最终解决方案中，一般选择牺牲一致性来获取可用性和分区容错性。（放弃强一致性，换取弱一致性） - 强一致性：系统中的某个数据更新成功后，后续任何对该数据的读操作，获取到的都是更新后的数据→任何时候所有节点的数据是一样的👉原子一致性、线性一致性 一个集群对外提供强一致性：集群内的某一台服务器的数据发生了改变，就需要等集群内其他服务器的数据同步完成后，才能正常的对外提供服务👉保证强一致性需损耗可用性 - 弱一致性：系统中的某个数据更新成功后，系统可以容忍后续对访问只能访问到部分，后者全部访问不到👉后续对该数据的读取不一定是最新的值 - 最终一致性：（弱一致性的特殊形式）存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值👉一段事件后，节点间的数据会最终达到一致状态 #### 2.5.6.2 base理论 针对CAP中的一致性和可用性进行一个权衡的结果：我们无法做到强一致，但是每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性 - BA（Basic Available）（基本可用）： - S（Soft State）（柔性状态）：系统内的数据存在中间状态，并认为中间状态的存在不会影响系统的整体可用性👉即允许系统不同节点的数据副本之间进行数据同步的过程存在延时 - E（Eventual Consisstency）（最终一致性）：同一数据的不同副本的状态，可用不需要实时一致，但是一定要保证经过一定时间后仍然是一致的 #### 2.5.6.3 分布式事务的解决方案 在分布式系统中，一个事务跨多个节点时，为了保证事务的原子性和一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示他们是否要把操作结果进行真正的提交或者回滚 1 二阶段提交（2PC）、三阶段提交（3PC）、事务补偿（TCC） - 2PC:性能问题参与节点是阻塞形的，如果调用了公共资源，会导致第三方节点阻塞；可靠性问题，参与者故障→协调者指定超时机制， 协调者故障→参与者会一致阻塞，需要额外的备机进行容错；数据一致性问题 协调者commit后宕机，接收到消息的参与者也宕机了，无人知道这条事务的状态 - 3PC: - TCC： 2 MQ事务 3 Seata 为用户提供了 AT、TCC、SAGA、XA事务模式，打造一站式的分布式解决方案（https://seata.io/zh-cn/index.html ） - 对业务无侵入：减少技术架构上微服务化所带来的分布式事务问题对业务的影响 - 高性能：减少分布式事务解决方案所带来的性能影响 - TC（Transaction Coordinator）：事务协调者。管理全局的分支事务的状态，用于全局性事务的提交和回滚。 - TM（Transaction Manager）：事务管理者。用于开启、提交或回滚事务。 - RM（Resource Manager）：资源管理器。用于分支事务上的资源管理，向 TC 注册分支事务，上报分支事务的状态，接收 TC 的命令来提交或者回滚分支事务 #### 2.5.6.3 Paxos 算法和 Raft 算法 #### 2.5.6.4 RPC ### 2.5.10 分布式链路追踪 ### ### 2.5.12 负载均衡 ### 2.5.12 消息队列 消息队列解决了什么问题、 常见消息队列对比、 如何保证消息只被消费一次、 如何保证消息不被重复消费. - 为什么使用消息队列？ 解耦：模块需要调用PO的接口（PO在我看来有点类似于网关，所有到SAP系统的接口都走PI，如何由PO转发） 异步： 销峰： 解耦 ### 2.5.13 限流&降级&熔断-Sentinel 以流量为切入点，从流量控制、流量路由、熔断降级、系统自适应过载保护、热点流量防护等多个维度保护系统的稳定性。 Sentinel 是阿里巴巴开源的分布式系统的流量防卫兵，主要用于保护微服务架构中的服务免受雪崩效应、降级、熔断、流量控制等一系列的异常流量控制。 - 资源 - - Java应用程序中的任何内容-- 程序、程序里的方法、甚至是一段代码，都可以被 Sentinel 保护。 - 规则 - - 围绕资源设定的规则，比如每秒钟的请求数、每分钟的请求数、每小时的请求数、每天的请求数等。 ### 2.5.14 ElasticSearch #### 2.5.14.1 全文检索 全存在内存中，装多个ES 存不同的服务器，分片存储； 为什么用这个：开源的搜索分析引擎； mysql 主要做数据的持久化管理：CRUD ； es可以秒级百万数据中读取，mysql承受不了太大压力 底层是lucence:提供了rest API的接口操作：👉参考官方的英文文档 1、倒排索引：快速检索出要查询的数据→插入时，维护一张索引表，分词插入 1、将数据存到ES中：上架功能→上架了才能查到 #### 2.5.14.2 日志收集 ### 2.5.20 压测 为了寻找当前系统在当前环境当前配置下的最大负荷量：找到系统瓶颈 找到内存泄露、并发与同步的问题； 2.5.20.1 性能指标： - 响应时间：客户端发起请求开始→服务器接收到请求→处理等到数据→我们看到数据 - HPS：每秒点击数 - TPS：每秒处理交易数：每秒处理的事务（每秒处理的业务） - QPS：每秒查询数 - 最大响应时间：用户发出请求到系统做出响应的最大时间 - 最少响应时间：用户发出请求到系统做出响应的最小时间 主要关注的指标： - 吞吐量：每秒钟系统能处理的请求数、并发数 - 响应时间：服务处理一个请求或者一个任务的耗时 - 错误率：一批请求中结果出错的请求所占比例 使用JMeter👉需要Java环境 ## 架构设计 ### keepalived #### keepalived 是什么？ ```markdown Keepalived是一个基于VRRP协议的高可用性软件，它可以将多台服务器组成一个虚拟服务器群集，实现IP地址和服务的高可用性和负载均衡。 其主要作用是在多个服务器之间共享一个虚拟IP地址，并且当其中一台服务器故障时，自动将虚拟IP地址切换到其他可用的服务器上，以确保服务不中断。 Keepalived通过VRRP协议实现了IP地址漂移和故障转移功能。 每个Keepalived节点会定期向其他节点发送VRRP消息，以选举出一个主节点来管理VIP地址。 当主节点故障或离线时，其他节点会自动接管VIP地址，并继续提供服务。 除了VRRP协议外，Keepalived还支持多种健康检查方式，如TCP、HTTP、SMTP等，以检测后端服务器的运行状态，并及时发现并处理故障。 同时，它还提供了灵活的配置选项和可扩展的插件机制，可以与其他软件配合使用，如HAProxy、Nginx、LVS等，以实现更复杂的负载均衡和高可用性方案。 Keepalived已经得到广泛的应用，在互联网、电信、金融、医疗等领域都有大量的部署案例，是一种可靠、稳定和高效的高可用性解决方案 ``` #### VRRP协议 -Virtual Router Redundance Protocol ```markdown VRRP（Virtual Router Redundancy Protocol）是一种用于实现虚拟路由冗余的协议，它允许多个路由器组成一个逻辑组，并共享同一个虚拟IP地址和MAC地址。 当其中一台路由器故障或离线时，其他路由器可以自动接管虚拟IP地址，以确保网络服务的连续性和可靠性。 VRRP协议的基本思想是将多个物理路由器组成一个虚拟路由器，该虚拟路由器具有单一的IP地址和MAC地址。 所有的数据包都被发送到该虚拟路由器，然后由其中一台实际的物理路由器进行处理。 这样就可以实现路由器的冗余备份和负载均衡功能。 VRRP协议使用交互式消息来选择虚拟路由器组中的主机路由器。 主机路由器负责管理虚拟IP地址，并在需要时转移虚拟地址到另一台路由器上。每个路由器都向其他路由器发送VRRP通告消息，以表明它是否处于活动状态和优先级大小。 当主机路由器离线或故障时，其他路由器会接管虚拟IP地址并将其转移到自己身上。 VRRP协议已经被广泛应用于企业网络、数据中心、互联网等领域，是一种可靠、灵活和高效的网络冗余解决方案。 同时，VRRP协议也支持IPv6地址，并且可以通过其他技术（如ARP代理）与其他协议（如BGP）相结合使用。 ``` #### VIP --虚拟ip ```markdown Keepalived中的虚拟IP（Virtual IP，VIP），是指一个虚拟的IP地址，它不是与具体的服务器或网络接口卡（NIC）绑定的，而是通过软件定义的一种逻辑地址。 VIP的作用在于：当某个节点出现故障时，能够自动将请求转移到其他可用的节点上，保证服务的高可用性。 在Nginx、LVS等负载均衡软件中，VIP通常被用来管理后端Web服务器集群。在这种情况下，客户端的请求都是通过VIP进行访问的，而不需要直接访问其中任何一台Web服务器。 这样可以实现负载均衡和故障转移的功能，并且确保Web服务器对外提供的服务始终处于高可用状态。 使用VIP时，需要在所有负载均衡节点上定义同一个VIP。如果某个节点出现故障或关机，负载均衡软件会自动将VIP漂移到另一台可用节点上。 为了使VIP能够被正确路由，需要确保所有节点都位于同一局域网（即同一网段）内，并且所有节点的网卡上都配置了相同的VIP。 需要注意的是，在使用VIP时，还需要考虑负载均衡算法、监控和故障转移策略等方面，以确保系统能够持续运行，并且客户端请求可以平衡地分配到可用的Web服务器上。 除此之外，还需要考虑网络拓扑结构、安全性、负载均衡性能等方面，以确保系统能够提供高可用性和稳定性服务。 ``` #### 怎么用 ```markdown 在使用Nginx Keepalived来实现高可用性时，VIP（Virtual IP）是非常重要的一部分。选择一个正确的VIP对于确保高可用性至关重要。 在选择VIP时应该考虑以下几个因素： 1. 网络拓扑：VIP必须位于与所有Web服务器和客户端都能够直接通信的网络子网上。这需要仔细评估网络拓扑结构，并确保VIP能够在整个网络中正确路由。 2. IP地址冲突：在不同的网络设备和web服务器上配置相同的IP地址会导致IP地址冲突。因此，在选择VIP时，需要检查网络中是否已经有其他设备或服务器使用了该IP地址。 3. 负载均衡算法：选择适当的负载均衡算法可以帮助提高系统的可用性。有多种负载均衡算法可供选择，如轮询、加权轮询、最少连接数等。 4. 动态IP地址分配：在一些环境下，使用动态IP地址分配可能会使VIP发生改变，从而影响高可用性。为避免这种情况，可以使用静态IP地址或者通过DHCP服务器进行静态分配。 5. 监控和故障转移：检测到故障后，需要将请求自动转移到备用节点以确保高可用性。为此，需要使用一些监控工具，并设置相应的故障转移策略。 总之，在选择VIP时，需要结合实际网络环境和负载均衡需求进行综合考虑。通过仔细评估和测试，可以确保所选的VIP能够提供高可用性，并减少系统中断时间和数据丢失的风险。 ``` #### Nginx+Keepalived如果VIP为内网段地址，那么Nginx公网IP服务器挂了，还能用吗？ ```markdown 如果使用内网IP地址作为VIP，在Nginx域名解析的服务器挂掉后，仍然可以继续使用VIP进行负载均衡。 这是因为VIP不依赖于域名解析，而与具体的IP地址相关联。即使某个Web服务器宕机或某个Nginx的DNS解析服务器不可用，VIP仍然可以在整个网络中正确路由，并且客户端请求可以平衡地分配到其他可用的Web服务器上。 但是，使用内网IP地址作为VIP也存在一些限制和风险。例如，如果VIP所在的服务器出现故障或网络发生故障，可能会导致VIP无法正常工作。此时需要使用故障转移技术，将请求自动转移到备用节点以确保高可用性。 总之，在使用内网IP地址作为VIP时，需要仔细评估网络拓扑结构并采取相应的故障转移策略，以确保系统能够持续运行并提供高可用性服务。 ``` #### Nginx+Keepalived客户端访问是通过VIP，还是公网IP地址？ ```markdown 在Nginx+Keepalived的架构中，客户端通常是通过VIP（Virtual IP）地址来访问服务的。 这是因为，VIP地址是实现负载均衡和高可用性的关键所在，可以将多个后端服务器组成一个逻辑集群，提供统一的服务入口。 当客户端发送请求到VIP地址时，Keepalived会根据负载均衡策略自动将请求转发到某个后端服务器上，并返回相应的响应数据。 如果某个后端服务器故障或离线，Keepalived会自动将VIP地址切换到其他可用的服务器上，从而实现服务的高可用性和容错能力。 需要注意的是，VIP地址通常是配置在内部网络中，只对内部用户可见。如果需要对外提供服务，可以通过防火墙、NAT等技术将VIP地址映射到公网IP地址上。 另外，为了提高服务性能和安全性，可以使用CDN、WAF等辅助技术，来加速响应速度、保护服务免受攻击和恶意访问。 总之，在Nginx+Keepalived架构中，客户端访问通常是通过VIP地址来访问服务的，这是实现负载均衡和高可用性的基础。 但是，在具体应用中需要根据实际需求和网络环境来进行相应的配置和优化，从而保障服务的稳定性和可用性。 ``` #### Nginx+Keepalived客户端请求都是通过VIP进行访问，那么VIP是不是必须映射到公网上面？ ```markdown 当使用Nginx Keepalived实现高可用性时，公网客户端请求通常是通过VIP（Virtual IP）进行访问的，因此VIP必须映射到公网上才能确保客户端可以正常访问Web服务器。 这通常涉及到网络地址转换（NAT）和端口转发等技术。 具体来说，如果Nginx服务器部署在内部网络中，并且使用了内网IP地址作为VIP，那么需要将VIP映射到公网IP地址上，以便从公网访问Nginx服务器。 这可以通过在防火墙或路由器上设置NAT规则来实现。例如，可以将公网IP地址的端口80转发到VIP的内网IP地址和端口上。这样就可以确保客户端可以通过公网访问Nginx服务器。 需要注意的是，在使用NAT规则和端口转发时，需要仔细评估网络设备和防火墙的配置，以确保安全性和高可用性。 另外，还需要考虑负载均衡算法、监控和故障转移策略等方面，以确保系统能够持续运行，并提供高可用性服务。 ``` #### 假如两台Nginx部署在内网，客户端通过域名访问Nginx服务，Nginx服务只有一台对应域名，那么使用Keepalived高可用方案时，VIP怎么定义? ```markdown 如果两台Nginx都部署在内网中，客户端通过域名访问Nginx服务，并且只有一台服务器对应该域名，那么可以使用以下方式来定义VIP（Virtual IP）以实现高可用： 1. 确定备用节点：选择另一台Nginx作为备用节点。 2. 定义VIP：创建一个虚拟IP地址，例如192.168.1.3，并绑定到主服务器（即对应域名的服务器）和备用服务器上。这样，在发生故障时，VIP会自动漂移到备用节点，从而确保系统的可用性。 3. 设置负载均衡策略：基于Keepalived等软件的负载均衡策略进行配置，以确保客户端请求能够平衡地分配到可用的Web服务器上。 需要注意的是，在使用VIP时，还需要设置监控和故障转移策略，以及合适的负载均衡算法，以确保系统能够持续运行，并且客户端请求可以平衡地分配到可用的Web服务器上。 除此之外，还需要考虑网络拓扑结构、安全性、负载均衡性能等方面，以确保系统能够提供高可用性和稳定性服务。 ``` #### Keealived怎么将VIP地址绑定到公网IP? ```markdown 在Keepalived中，可以通过设置Virtual IP（VIP）和Floating IP（FIP）来将VIP地址绑定到公网IP上，从而实现负载均衡和故障转移功能。 具体操作步骤如下： 1. 在阿里云ECS控制台上申请一个弹性公网IP，并将其绑定到需要使用的ECS实例上。 2. 在ECS实例上配置网络参数，包括内网IP地址、子网掩码、网关和DNS等信息。确保ECS实例可以正常访问公网和内网资源。 3. 安装Nginx服务并配置好Nginx的监听端口、反向代理规则、健康状态检测等信息。同时，在每个ECS实例上安装Keepalived服务，并配置好VIP地址、FIP地址、监控脚本等参数。 4. 修改Keepalived的主配置文件/etc/keepalived/keepalived.conf，设置Virtual IP（VIP）和Floating IP（FIP），并将它们与公网IP地址进行绑定。 具体地，可以在keepalived.conf文件的global_defs块中添加以下配置项： vrrp_instance VI_1 { state MASTER/BACKUP interface eth0 virtual_router_id 51 priority 101/100 advert_int 1 authentication { auth_type PASS auth_pass Your_Auth_Password } virtual_ipaddress { 192.168.1.10/24 dev eth0 label eth0:0 } virtual_ipaddress_excluded { 192.168.1.200/24 dev eth0 label eth0:1 } } 其中，192.168.1.10为VIP地址，192.168.1.200为FIP地址。eth0为网卡名称，101和100为主备节点的优先级，Your_Auth_Password为密码。 1. 启动Keepalived服务，并检查系统日志以验证配置是否正确。在ECS实例上执行以下命令： sudo service keepalived start tail -f /var/log/messages 通过以上操作，就可以将VIP地址绑定到公网IP上，并使用Keepalived实现Nginx Keepalive高可用方案。注意，在实际应用中，还需要考虑安全性、网络拓扑结构、负载均衡算法等因素，以确保系统能够提供高可用性和可靠性服务。 ``` #### Keealived将VIP地址绑定到公网IP的具体原理是什么 ```markdown 在Keepalived中，将VIP地址绑定到公网IP的实现原理是利用了虚拟化技术和ARP协议的特性。 具体地，当一个ECS实例运行Keepalived服务时，它会把网络接口【本机的】上的VIP地址加入到一个虚拟MAC地址下，并通过ARP协议广播这个MAC地址。 此时，所有与该ECS实例相连的设备（如交换机、路由器等）都会记录下这个MAC地址和VIP地址之间的对应关系。 当客户端访问服务时，它首先会向Keepalived服务器发送请求。由于VIP地址已经被绑定到公网IP上，请求会被传输到公网IP地址所在的网络接口上。 此时，Keepalived服务器会根据负载均衡算法选择其中一台ECS实例，并将请求转发到该实例上。由于该实例已经预先广播了VIP地址和虚拟MAC地址之间的映射关系，因此请求可以正确路由到该实例上。 需要注意的是，在VIP地址和公网IP地址之间进行路由转发时，可能会遇到ARP欺骗等安全问题。 为了防止这些攻击，可以采取安全措施，如开启ARP防火墙、使用静态ARP表、限制ARP请求等。同时，还应将FIP地址与VIP地址分离，并将FIP独立绑定到公网IP地址上，以实现高可用性和负载均衡功能。 ``` #### Keealived将VIP地址绑定到公网IP后，客户端访问的域名，应该解析到哪个地址？ ```markdown 当Keepalived将VIP地址绑定到公网IP后，客户端访问的域名应该解析到绑定了VIP地址的公网IP上。 具体地，在Nginx Keepalive高可用方案中，可以使用DNS轮询（DNS Round-Robin）等技术将域名解析到多个公网IP地址上，并通过Keepalived服务将请求路由到相应的Nginx服务器上。 例如，假设有两台ECS实例，对应的公网IP地址为1.2.3.4和5.6.7.8，VIP地址为192.168.0.10，则可以在DNS服务器上将域名解析成以下两个IP地址： codeexample.com IN A 1.2.3.4 example.com IN A 5.6.7.8 当客户端访问example.com域名时，DNS服务器会随机选择其中一台服务器的IP地址并返回给客户端，例如1.2.3.4。然后，客户端会向1.2.3.4发送请求，并将请求传输到绑定了VIP地址的公网IP上。 在该公网IP地址上运行的Keepalived服务会根据负载均衡算法选择其中一台ECS实例，并将请求转发到该实例上。 需要注意的是，在实际应用中，DNS解析存在缓存机制，可能会导致某些客户端无法立即获取更新后的IP地址。 因此，可以采用动态DNS（Dynamic DNS）或TTL控制等技术，来使DNS解析信息能够及时更新并生效。同时，还应该考虑安全性、网络拓扑结构、负载均衡算法等因素，以确保系统能够提供高可用性和稳定性的服务。 ``` #### 当Keepalived将VIP地址绑定到公网IP后，客户端访问的域名解析到公网IP上，如果这样的话，客户端实际访问的地址是VIP还是公网IP？ ```markdown 当Keepalived将VIP地址绑定到公网IP后，客户端访问的域名应该解析到绑定了VIP地址的公网IP上。这样做的目的是通过VIP地址实现多台后端服务器的负载均衡和故障转移。 因此，客户端实际访问的地址应该是VIP地址，而不是公网IP地址。 具体地，在Nginx Keepalive高可用方案中，客户端向域名发起请求时，DNS服务器会返回一个包含多个IP地址的轮询列表，其中包括绑定了VIP地址的公网IP地址和其他备用IP地址。 客户端会选择其中一个IP地址连接服务器并发送请求。由于绑定了VIP地址的公网IP地址已被Keepalived服务处理，所以请求会被路由到相应的Nginx服务器上，从而实现负载均衡和故障转移的功能。 需要注意的是，虽然客户端实际访问的地址是VIP地址，但在网络传输过程中，数据包是通过公网IP地址进行传输的。 这是因为客户端首先需要将请求发送到公网IP地址所在的网络接口上，然后再由Keepalived服务将请求路由到相应的ECS实例上。 因此，在配置Nginx Keepalive高可用方案时，需要考虑安全性、网络拓扑结构、负载均衡算法等因素，以确保系统能够提供高可用性和稳定性的服务。 解释： 网络接口（Network Interface）是连接计算机与网络之间的物理或逻辑接口，它负责处理计算机与网络之间的数据传输和交换。在实际应用中，每个网络接口都有一个唯一的IP地址，用于标识该接口所在的网络。 在Nginx Keepalive高可用方案中，ECS实例需要绑定公网IP地址和VIP地址两个IP地址。假设公网IP地址为1.2.3.4，VIP地址为192.168.0.10，则在ECS实例上，会分别配置两个网络接口，一个连接公网，一个连接内网。 当客户端向域名发起请求时，DNS服务器会返回一个包含多个IP地址的轮询列表，其中包括绑定了VIP地址的公网IP地址1.2.3.4和其他备用IP地址（如果有的话）。客户端会选择其中一个IP地址连接服务器并发送请求。 具体地，在客户端请求到达Network Layer（网络层）时，系统会根据目标IP地址和子网掩码来判断该IP地址是否与客户端所在的网络属于同一网段。如果属于同一网段，则直接将数据包发送到目标地址； 否则，将数据包发送到默认网关所在的网络接口上。由于公网IP地址1.2.3.4和VIP地址192.168.0.10不属于同一网段，因此客户端需要将请求发送到公网IP地址所在的网络接口上。 一旦数据包到达公网IP地址所在的网络接口，就会被路由到相应的ECS实例上。具体地，在ECS实例上运行的Keepalived服务会根据负载均衡算法选择其中一台Nginx服务器，并将请求转发到该服务器上。 由于VIP地址已经被绑定到该服务器上，因此Nginx服务器可以正确地处理该请求。 需要注意的是，在实际应用中，可能会存在多个公网IP地址、多个VIP地址、多个网络接口等复杂场景。为了确保系统能够正常运行，需要合理配置网络拓扑结构、路由表、防火墙、安全组等功能，并对系统进行充分测试和调试。 ``` #### 两个Nginx服务，仅一台存在公网IP，当Keepalived将VIP地址绑定到公网IP后，假如此时公网IP服务器关机了，那么公网客户端还能正常访问吗? ```markdown 如果存在两个nginx服务，仅一台存在公网IP，并且使用Keepalived将VIP地址绑定到公网IP后，如果此时公网IP服务器关机了，那么公网客户端将无法正常访问。 由于只有一台服务器具有公网IP，当该服务器失效时，无法继续提供服务。即使使用Keepalived将VIP地址转移到另一台服务器上也无法解决问题，因为公网客户端需要重新建立与新服务器的连接，而此时已经无法通过原来的公网IP地址进行连接。 为了避免这种情况的发生，可以考虑以下措施： 增加公网IP：在保证网络规划和IP管理的前提下，可以增加一个或多个公网IP地址，从而提高服务的可用性和容错能力。 使用负载均衡器：负载均衡器可以代替单个服务器提供统一的服务入口，并自动将请求分发到不同的服务器上。当某个服务器失效时，负载均衡器可以将请求转发到其他可用的服务器上，从而保证服务的连续性和可靠性。 使用弹性IP：弹性IP可以让ECS实例的IP地址与特定的公网IP地址进行映射，从而实现地址的固定和可动态调整。当ECS实例发生变化时，只需要将弹性IP重新映射到新的ECS实例上即可，无需修改负载均衡器或DNS配置。 综上所述，在公网场景下，为了保障服务的稳定性和可用性，需要注意公网IP的规划和管理，使用负载均衡器、弹性IP等技术来提高服务的容错能力，并采取相应的监控、告警和灾备等措施。 ``` #### 总结Keepalived在网络处理中都做了那些事情？ ```markdown 在网络处理中，Keepalived主要负责实现高可用性和故障转移的功能，具体来说，它做了以下几件事情： 1. 绑定VIP地址：Keepalived会将VIP地址绑定到公网IP地址上，并通过ARP协议更新虚拟MAC地址。这样做可以使多台后端服务器共享同一个IP地址，从而实现负载均衡和故障转移的功能。 2. 监听VIP地址：Keepalived会在后台监听绑定了VIP地址的网络接口上的数据包，并根据预设的健康检查规则来判断后端服务器的健康状态。一旦某个服务器不可用，Keepalived会自动将VIP地址切换到其他可用的服务器上。 3. 更新路由表：当Keepalived将VIP地址切换到其他服务器上时，它会更新路由表，使新的请求都能正确地路由到新的服务器上。同时，也会更新ARP表和虚拟MAC地址，以确保客户端能够正确地连接到服务端。 4. 实现负载均衡算法：为了实现负载均衡，Keepalived支持多种负载均衡算法，如轮询（Round-Robin）、加权轮询（Weighted Round-Robin）、最小连接数（Least Connections）等。根据不同的场景和需求，可以选择不同的负载均衡算法。 5. 支持健康检查机制：为了提高服务的稳定性和可用性，Keepalived支持多种健康检查机制，如TCP连接检测、HTTP请求检测、ICMP Ping检测等。通过对后端服务器的健康状态进行检测，可以及时发现故障，并自动切换到其他可用的服务器上。 6. 实现VIP地址漂移：为了提高系统的可用性和容错能力，Keepalived支持VIP地址漂移功能。当主备节点之间发生切换或发生网络故障时，Keepalived会自动将VIP地址从一个节点切换到另一个节点上，从而实现无中断地服务切换。 综上所述，Keepalived在网络处理中扮演着非常重要的角色，它通过一系列的机制和算法来实现负载均衡和故障转移的功能，提高了系统的可用性和稳定性。 ``` ## Spring cloud alibaba #### 1. 版本说明 https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E #### 2. 组件介绍 Spring Cloud Alibaba是阿里巴巴开源的一套致力于提供微服务开发的一站式解决方案。 此项目包含了开发分布式应用微服务的必须组件，方便开发者通过Spring Cloud编程模型轻松使用这些组件来开发分布式应用服务。 依托Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将Spring Cloud应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。 ##### 官网 https://spring.io/projects/spring-cloud-alibaba/#overview ##### ```markdown （一）Spring Cloud的几大痛点： （1）Spring Cloud的部分组件停止维护和更新，给开发带来不便； （2）Spring Cloud的部分环境搭建复杂，没有完善的可视化界面，我们需要大量的二次开发和定制； （3）Spring Cloud配置复杂，难以上手，部分配置难以区分和合理应用； （二）Spring Cloud Alibaba的优点： （1）阿里使用过的组件经历了考验，性能强悍，设计合理，现在开源出来大家用； （2）成套的产品搭配完善的可视化界面，给开发和运维带来了极大的便利； （3）搭建简单，学习成本低； ``` ##### ```markdown （一）Spring Cloud Alibaba - nacos： （1）注册中心：服务注册 & 服务发现 （2）配置中心：动态配置管理 https://github.com/alibaba/nacos/releases?page=3 （二）Spring Cloud - Ribbon：负载均衡 https://github.com/Netflix/ribbon/wiki/Getting-Started https://docs.spring.io/spring-cloud-commons/reference/spring-cloud-commons/loadbalancer.html （三）Spring Cloud - Feign：声明式HTTP客户端（调用远程服务）； https://github.com/spring-cloud/spring-cloud-openfeign （四）Spring Cloud Alibaba - Sentinel：服务容错（限流、降级、熔断）； https://github.com/alibaba/Sentinel/wiki/%E4%B8%BB%E9%A1%B5 （五）Spring Cloud - GateWay：API网关（WebFlux编程模式）； https://spring.io/projects/spring-cloud-gateway/#overview （六）Spring Cloud - Sleuth：调用链监控； （七）Spring Cloud Alibaba - Seata：原Fescar，分布式事务解决方案； ```