突然就涨知识了

小菜yh

于 2024-09-02 22:26:01 发布

阅读量589

点赞数 22

文章标签：开发语言缓存数据库 redis 分布式 java

本文链接：https://blog.csdn.net/m0_53369973/article/details/141831904

版权

cap理论

主要应用于分布式系统的设计与分析
在这里插入图片描述
在分布式系统中，有三个基本的特性：

一致性（Consistency）：
- 一致性指的是所有的节点在同一时间看到的数据是一致的。换句话说，每次读取操作都能获取到最新写入的数据。
- 在保证一致性的系统中，所有的读操作都返回最近的写操作的结果。
可用性（Availability）：
- 可用性指的是系统总是能够响应客户端的请求，无论是读取还是写入请求。即使部分节点出现故障，系统仍能继续提供服务。
- 在保证可用性的系统中，即使部分节点失败，系统仍能继续处理请求并返回响应。
分区容错性（Partition Tolerance）：
- 分区容错性指的是系统能够继续操作，即使系统的网络部分出现了分区（即网络无法正常通信）。系统应能在网络分区时继续提供服务，并最终恢复到一致的状态。
- 在保证分区容错性的系统中，即使网络分区，系统仍能继续处理请求。

核心内容

根据 CAP 理论，一个分布式系统在任何时刻最多只能同时满足两个特性，而不能同时满足三个特性。具体来说：

CP 系统（Consistency and Partition Tolerance）：这些系统优先保证数据的一致性和分区容错性，可能会牺牲部分可用性。例如：HBase、Zookeeper。
AP 系统（Availability and Partition Tolerance）：这些系统优先保证系统的可用性和分区容错性，可能会牺牲一致性。例如：Cassandra、Riak。
CA 系统（Consistency and Availability）：这些系统在没有网络分区的情况下保证一致性和可用性，但在出现分区时可能无法正常工作。例如：传统的单节点数据库系统，如 MySQL 或 PostgreSQL，在没有网络分区的情况下可以提供一致性和可用性。

实际应用

在设计分布式系统时，开发人员需要根据实际需求选择合适的策略：

如果数据一致性对业务至关重要，可以选择 CP 类型的系统，并接受一定程度的不可用性。
如果系统的可用性是关键，即使在网络分区时也需要继续服务，可以选择 AP 类型的系统，并接受一定程度的数据不一致。
在没有网络分区的情况下，CA 类型的系统可以很好地满足一致性和可用性，但在现代分布式系统中，网络分区是不可避免的，因此设计时必须考虑到 CAP 的限制。

对主从架构的了解

1. 定义与基本概念

主节点（Master）：在主从架构中，主节点是系统中的核心节点，它负责处理所有的写操作（或写请求），并且通常也承担读操作的任务。主节点通常负责数据的更新和变更。
从节点（Slave）：从节点则是主节点的副本，它们从主节点接收数据的副本，并保持与主节点的数据同步。从节点通常处理读操作，以减轻主节点的负担。

2. 数据同步

同步机制：从节点通过不同的机制（如日志复制、快照复制）与主节点保持数据同步。这种同步可以是实时的，也可以是定时的，具体取决于实现和配置。
主从同步的挑战：在数据同步过程中，可能会出现延迟或者同步失败的情况，因此需要设计良好的同步机制和容错机制。

3. 应用场景

数据库系统：在数据库系统中，主从架构用于实现读写分离。主数据库处理所有的写操作（如插入、更新、删除），而从数据库处理读操作（如查询）。这样可以提高数据库的性能和可伸缩性。
分布式系统：在分布式系统中，主从架构可以用于任务调度和负载均衡。例如，任务调度系统可以有一个主节点负责调度任务，而从节点负责执行任务。
缓存系统：在缓存系统中，主节点可以用作缓存的写入和更新，而从节点则提供对缓存数据的读取。

4. 优缺点

优点：
- 性能优化：通过将读操作分散到多个从节点，可以提高系统的读取性能和并发处理能力。
- 负载均衡：通过读写分离，可以减轻主节点的负担，避免主节点过载。
- 高可用性：主从架构可以提供一定的高可用性，因为如果主节点发生故障，可以将从节点提升为新的主节点。
缺点：
- 同步延迟：从节点的数据可能会存在延迟，不适合对实时性要求极高的应用场景。
- 复杂性：维护主从节点的数据一致性和处理故障恢复可能会增加系统的复杂性。
- 故障恢复：主节点的故障可能会影响到整个系统的正常运行，虽然可以通过切换主节点来恢复，但切换过程可能会影响系统的可用性。

5. 实现例子

MySQL：在MySQL数据库中，主从复制是一个常见的实现。主数据库处理所有写请求，从数据库复制主数据库的数据，并处理读取请求。
Redis：Redis的主从复制允许主节点将数据同步到一个或多个从节点，从而实现数据备份和读写分离。

分库分表的理解以及如何实现

分库（Database Sharding）：将数据分散到多个数据库实例中，每个实例存储数据的一部分。通常基于某种分片策略来决定数据的分布，例如按用户ID范围或地理位置。
分表（Table Sharding）：在同一个数据库实例中，将数据分散到多个表中。这样可以减小单个表的大小，提高查询性能。分表通常是基于某种规则，例如按时间或数据类型分表。
1. 分库
- 选择分库策略：选择合适的分库策略，例如按用户ID范围、地理位置、业务模块等进行分库。每种策略有其适用场景和优缺点。
- 数据分片：根据分库策略，将数据分配到不同的数据库实例中。例如，用户ID在1-10000的用户数据存储在数据库A，10001-20000的数据存储在数据库B。
- 路由逻辑：实现路由逻辑来决定数据请求发送到哪个数据库实例。通常，应用程序或中间件会负责这一部分的路由决策。
2. 分表
- 选择分表策略：选择合适的分表策略，例如按时间（每天、每月）、数据量（每个表存储一定数量的数据）或其他业务逻辑（例如用户类型）进行分表。
- 创建表结构：根据分表策略创建多个表。例如，如果按时间分表，可以创建多个按月命名的表：orders_2023_01, orders_2023_02等。
- 数据管理：在应用程序中实现分表管理逻辑，确保在插入、查询、更新和删除操作时选择正确的表。

3. 实施挑战

复杂的查询：跨库或跨表的复杂查询可能需要合并多个查询结果，这会增加实现的复杂性和性能开销。

事务管理**：分库分表可能会影响跨库或跨表事务的管理，需要采用分布式事务解决方案或最终一致性策略。

数据一致性**：确保数据在多个数据库和表中保持一致性是一个挑战，尤其是在高并发和故障恢复场景下。

4. 示例

分库：一个电商平台可能按地区将用户数据分布到不同的数据库实例中，例如北美用户数据存储在数据库A，欧洲用户数据存储在数据库B。
- 分表：一个日志系统可能按时间将日志数据分表，每个月创建一个新的日志表，如logs_2024_09, logs_2024_10。

分库分表的有效实施可以显著提高系统的可扩展性和性能，但也需要针对具体业务需求和技术条件进行合理的设计和调整。

JDBC的工作流程

加载JDBC驱动程序：首先，需要加载特定数据库的JDBC驱动程序。通常使用Class.forName()方法加载驱动类。
```
javaClass.forName("com.mysql.cj.jdbc.Driver");
```
建立数据库连接：使用DriverManager.getConnection()方法建立与数据库的连接。需要提供数据库的URL、用户名和密码。
```
javaConnection connection = DriverManager.getConnection(
    "jdbc:mysql://localhost:3306/mydatabase", "username", "password");
```
创建Statement对象：使用Connection对象创建Statement或PreparedStatement对象，以便执行SQL查询或更新操作。
```
javaStatement statement = connection.createStatement();
```
执行SQL语句：通过Statement对象执行SQL语句，如查询、插入、更新等操作。
```
javaResultSet resultSet = statement.executeQuery("SELECT * FROM mytable");
```

处理结果集：使用ResultSet对象处理查询结果。可以遍历结果集并提取数据。

javawhile (resultSet.next()) {
    int id = resultSet.getInt("id");
    String name = resultSet.getString("name");
    // 处理数据
}

关闭资源：使用完毕后，需要关闭ResultSet、Statement和Connection对象以释放资源。
```
javaresultSet.close();
statement.close();
connection.close();
```

3. JDBC接口和类

DriverManager：管理数据库驱动程序，提供建立数据库连接的方法。
Connection：表示与数据库的连接，提供执行SQL语句的方法。
Statement：用于执行SQL语句，Statement对象可以是Statement、PreparedStatement或CallableStatement的实例。
ResultSet：表示SQL查询的结果集，可以用于检索数据。
SQLException：处理数据库访问中的异常。

5. JDBC的最佳实践

使用连接池：为了提高性能和资源利用率，建议使用数据库连接池（如Apache DBCP或HikariCP）来管理数据库连接。
避免SQL注入：使用PreparedStatement代替Statement来避免SQL注入问题。
事务管理：在需要的情况下，手动管理事务，确保数据的一致性和完整性。
资源管理：确保在使用完毕后关闭数据库资源，防止资源泄漏。

总结

JDBC是Java与数据库之间的重要桥梁，提供了一种标准的方式来执行数据库操作。通过合理使用JDBC接口和最佳实践，可以高效地进行数据库交互，实现数据的读写和管理。

Spring事务底层用什么技术实现

1. AOP（面向切面编程）

Spring的事务管理是基于AOP的。AOP允许你将事务逻辑（如开始事务、提交事务和回滚事务）从业务逻辑中分离出来，使得事务管理变得更加模块化。Spring使用AOP来织入事务管理逻辑。具体来说：

事务管理切面：Spring提供了一个或多个事务管理切面，这些切面会拦截被注解（如@Transactional）标记的方法，并在这些方法执行前后进行事务处理。
事务拦截器：Spring的TransactionInterceptor是负责事务管理的核心组件。它会拦截目标方法的调用，在调用前开启事务，执行方法后提交事务，若方法抛出异常则回滚事务。

2. Transaction Manager（事务管理器）

Spring支持不同类型的事务管理器，以便与不同的事务管理技术和数据源进行集成。主要有：

DataSourceTransactionManager：用于JDBC和DataSource基础上的事务管理。这是最常用的事务管理器之一，负责管理基于JDBC的数据源事务。
JpaTransactionManager：用于JPA（Java Persistence API）实体管理的事务管理器，通常与Spring Data JPA一起使用。
HibernateTransactionManager：用于Hibernate ORM框架的事务管理器，适用于使用Hibernate作为持久层的应用。
TransactionSynchronizationManager：一个帮助类，用于管理事务的同步状态和当前事务上下文。

3. 底层数据库事务

底层的数据库事务处理是通过JDBC或者ORM框架（如Hibernate）的事务管理功能来实现的。这些底层的事务操作包括：

开启事务：在事务开始时，数据库会创建一个新的事务上下文。
提交事务：在事务成功完成后，数据库会提交事务，将所有更改永久保存。
回滚事务：如果事务中出现异常，数据库会回滚事务，撤销所有未提交的更改。

4. 事务属性和配置

Spring的事务管理允许你配置不同的事务属性，例如：

传播行为（Propagation Behavior）：定义了事务的传播规则，如REQUIRED, REQUIRES_NEW, MANDATORY等。
隔离级别（Isolation Level）：定义了事务如何隔离其他并发事务的影响，如READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE等。
回滚规则（Rollback Rules）：定义了在什么情况下事务会被回滚，如根据异常类型或自定义规则。

5. 配置方式

Spring事务可以通过XML配置或注解来实现：

XML配置：在Spring配置文件中配置事务管理器和事务相关的切面。
注解配置：使用@Transactional注解来标记需要事务管理的方法或类，Spring会自动应用相应的事务管理逻辑。

支付宝h5支付操作(手机网站)：

后端发起支付，返回form表单格式的字符中

前端通过js模拟触发form提交，进行支付宝的支付界面（输入密码进行支付）

支付完成，通过return_url，返回我们自己的前端页面

如果中途取消支付，通过quit_ur返回我们紫的前端页面

另外，支付完成后，支付宝端通过回调的url(notify_url)，通知后台系统支付完成

针对回调可能失败的情况，后台进行掉单处理

如何实现秒杀

秒杀功能涉及到高并发请求处理和库存管理。实现的基本步骤：

预热和缓存：使用缓存（如 Redis）存储商品库存，减少数据库压力。提前加载秒杀商品信息到缓存中，以提高响应速度。
限制请求：通过限流（如令牌桶算法、漏桶算法）控制用户请求频率，防止过多请求同时到达服务器。
分布式锁：使用分布式锁（如 Redis 的 SETNX 命令）确保在高并发情况下，每个用户请求只被处理一次，避免超卖。
异步处理：将秒杀请求异步处理，将秒杀请求放入队列中，按顺序处理，防止直接处理带来的系统压力。
库存扣减：在处理请求时，首先从缓存中扣减库存，然后更新数据库库存，确保库存准确性。
用户排队：使用排队系统（如 Redis 的列表或消息队列）对请求进行排队处理，避免并发冲突。
结果通知：处理完请求后，向用户发送秒杀结果通知，包括成功或失败信息。

ApplicationContext

Spring框架中，ApplicationContext 是一个核心容器，用于管理和配置应用程序中的bean（组件）。

它负责bean的创建、初始化和生命周期管理，同时提供依赖注入功能，使得应用程序的各个组件能够轻松地互相协作。

bean的实例化通常发生在应用上下文启动时

雪花算法

雪花算法（Snowflake Algorithm）是一种分布式唯一ID生成算法，由 Twitter 提出。它用于在分布式系统中生成唯一且有序的ID，通常用于数据库主键、分布式系统中的对象标识符等场景。雪花算法的设计目的是提供高性能、高可用性和有序的唯一ID。

结构

雪花算法生成的ID是一个64位的整数，通常被表示为一个十进制或十六进制的长整数。这个64位整数被划分为以下几个部分：

符号位（1位）：固定为0，表示ID是正数。
时间戳部分（41位）：表示从一个固定的时间点（通常是自定义的纪元时间）开始经过的毫秒数。41位可以支持大约69年的时间跨度。
工作机器ID部分（10位）：用于区分不同的工作节点或服务器。通常，10位可以表示最多1024台不同的机器（或服务器）。在实际应用中，工作机器ID可能会被划分成多个部分，例如数据中心ID和机器ID，以避免不同的数据中心和机器之间的ID冲突。
序列号部分（12位）：在同一毫秒内生成的ID序列号，确保在同一时间戳内生成的ID是唯一的。12位的序列号可以支持每毫秒生成最多4096个唯一的ID。

生成过程

获取当前时间戳：计算当前时间戳与纪元时间的差值。
获取机器ID：确定当前生成ID的工作机器ID。
生成序列号：在同一毫秒内生成的ID需要确保唯一性，因此使用序列号来区分。
合成ID：将上述各部分合并成一个64位的唯一ID。

优点

高性能：由于ID是由工作机器本地生成的，避免了中心化的ID生成服务，减少了网络延迟和瓶颈。
有序性：生成的ID按时间顺序排列，符合时间的先后顺序，这对于某些应用场景（如日志记录、时间排序）非常有用。
分布式：算法设计可以适应分布式环境，避免了集中式ID生成服务的单点故障问题。
可扩展性：支持大规模分布式系统，可以通过配置不同的工作机器ID来扩展。

缺点

时间回拨问题：如果系统时间回拨，可能会导致ID冲突。为避免这个问题，需要确保时间同步和监控系统时间的变化。
复杂度：需要管理和配置工作机器ID，尤其是在多数据中心或多地域的分布式环境中。

雪花算法广泛应用于许多分布式系统和大数据系统中，如 Twitter、Snowflake 数据仓库、以及各种微服务架构中。

线程安全的集合

Vector：线程安全的动态数组，支持同步。
Hashtable：线程安全的哈希表，支持同步。
ConcurrentHashMap：线程安全的哈希表，提供更高的并发性能，适用于高并发场景。
CopyOnWriteArrayList：线程安全的动态数组，适合读操作远多于写操作的场景。
CopyOnWriteArraySet：线程安全的集合，基于CopyOnWriteArrayList实现。

MyBatis的一级缓存是会话级缓存，用于缓存同一`SqlSession`中执行的SQL查询的结果。

应用场景包括：

减少数据库访问：在同一个SqlSession中重复查询相同的数据时，能够避免多次访问数据库，提高性能。
提高查询效率：对于频繁读取不经常变化的数据，一级缓存可以显著提高查询速度。
事务范围内的数据一致性：一级缓存确保在事务期间的一致性，使得同一会话中的数据访问一致。

反射机制可以用来：

获取类信息：使用Class类可以获取类的名字、方法、字段等信息。
创建对象：通过Class.forName()和newInstance()方法动态创建对象。
访问字段和方法：使用getField(), getMethod()等方法访问或修改对象的字段和方法。
动态代理：创建动态代理对象，以便在运行时处理方法调用。

如何实现序列化？

定义序列化结构：在数据结构中标识哪些数据需要被序列化，并定义如何将其转换成一个可存储的格式（如二进制、JSON、XML等）。
使用锁机制：在数据库事务中实现序列化隔离级别时，可以使用锁机制。具体地，可以使用“排他锁”（exclusive locks）来确保事务在执行过程中不会被其他事务干扰，避免读写冲突。
两阶段锁协议：为了实现序列化，数据库系统通常使用两阶段锁协议（2PL）。该协议分为两个阶段：增长阶段（事务获取锁）和收缩阶段（事务释放锁）。在增长阶段，事务只能获取锁而不能释放；在收缩阶段，事务只能释放锁而不能获取。
验证和重试：在某些情况下，事务在执行时可能会被发现不符合序列化要求。此时，可以采用重试机制来重新执行事务，直到达到序列化要求。

垃圾回收原理

Spring事务数据库事务

如何进行sql优化

1. 查询优化

选择性字段：
- 只选择必要的字段，而不是使用SELECT *。这可以减少数据传输的量和数据库的处理负担。
使用合适的WHERE子句：
- 确保WHERE子句能够有效过滤数据。避免在WHERE子句中使用函数或运算符，这可能导致索引失效。
避免子查询：
- 尽量使用JOIN替代子查询，特别是在涉及大量数据时。JOIN通常比子查询性能更优。
使用EXISTS代替IN：
- 在处理大数据集时，EXISTS通常比IN更高效，尤其是当IN列表较大时。
限制结果集：
- 使用LIMIT（在MySQL中）或TOP（在SQL Server中）来限制查询结果的数量，尤其是在进行分页查询时。
合理使用JOIN：
- 确保JOIN条件正确且合理。使用适当的JOIN类型（如INNER JOIN, LEFT JOIN等），并确保连接条件能够利用索引。

2. 索引优化

创建适当的索引：
- 为常用的查询条件、JOIN字段和排序字段创建索引。索引可以显著提高查询速度。
避免过多的索引：
- 虽然索引可以提高查询性能，但过多的索引会增加数据修改（INSERT, UPDATE, DELETE）操作的成本。因此，保持索引的平衡非常重要。
使用复合索引：
- 当查询涉及多个列时，使用复合索引（多列索引）比单列索引更有效。
定期重建索引：
- 随着数据的不断变化，索引可能会变得不够高效。定期重建或重新组织索引可以优化查询性能。

3. 数据库设计优化

规范化与反规范化：
- 适当的规范化可以减少数据冗余，提高数据一致性。然而，在某些情况下，反规范化（例如将冗余数据存储在表中）可以提高查询性能。需要根据实际需求来决定。
分区表：
- 对于非常大的表，可以使用表分区技术将数据划分为更小的、可管理的部分。这可以提高查询性能和管理效率。
数据类型选择：
- 使用合适的数据类型来存储数据。过大的数据类型会浪费存储空间并影响性能。

Mysql慢查询

在这里插入图片描述

TCP三握手四次挥手

TCP三次握手（连接建立）

SYN：客户端发送一个SYN（同步）包到服务器，标志着客户端希望建立连接。这个包中包含客户端的初始序列号。
SYN-ACK：服务器回应一个SYN-ACK（同步-确认）包，确认收到客户端的SYN包，并发送自己的SYN包给客户端。这个包中包含服务器的初始序列号和确认号（客户端序列号+1）。
ACK：客户端再发送一个ACK（确认）包，确认收到服务器的SYN-ACK包。此包中的确认号是服务器序列号+1。

连接建立后，客户端和服务器可以开始数据传输。

TCP四次挥手（连接断开）

FIN：客户端发送一个FIN（结束）包，表示客户端没有数据发送了，要求关闭连接。
ACK：服务器回应一个ACK包，确认收到客户端的FIN包。此时连接的一端关闭，但服务器仍可以继续发送数据。
FIN：服务器发送一个FIN包，表示服务器也没有数据发送了，要求关闭连接。
ACK：客户端回应一个ACK包，确认收到服务器的FIN包。此时连接完全断开。

SYN-ACK：服务器回应一个SYN-ACK（同步-确认）包，确认收到客户端的SYN包，并发送自己的SYN包给客户端。这个包中包含服务器的初始序列号和确认号（客户端序列号+1）。
3. ACK：客户端再发送一个ACK（确认）包，确认收到服务器的SYN-ACK包。此包中的确认号是服务器序列号+1。

连接建立后，客户端和服务器可以开始数据传输。