- 博客(273)
- 收藏
- 关注
RSS订阅原创 Mysql--实战篇--大数据量表的分页优化（自增长主键，子查询主键主查询全部，查询条件加索引，覆盖索引等）
当Mysql数据表存储大量数据时（百万级别数据），分页查询的性能问题是一个常见的挑战。特别是当使用LIMIT和OFFSET时，随着OFFSET的增加，查询性能会显著下降。原因在于MySQL需要扫描并跳过前面的行，这会导致I/O操作和CPU使用率增加。OFFSET是导致分页查询变慢的主要原因之一。随着OFFSET的增大，MySQL需要扫描并跳过越来越多的行，这会导致查询时间线性增长。因此，应该尽量避免使用OFFSET。
2025-01-16 21:35:23
710
原创 Mysql--实战篇--读写分离（动态数据源配置，AbstractRoutingDataSource接口，自定义读写注解和AOP切换，ThreadLocal防止多线程问题等）
创建两个自定义注解，分别用于标识读操作和写操作。
2025-01-16 21:05:35
432
原创 Mysql--实战篇--SQL优化（查询优化器，常用的SQL优化方法，执行计划EXPLAIN，Mysql性能调优，慢日志开启和分析等）
SQL查询优化是一个多方面的过程，涉及到索引设计、查询语句编写、表结构调整、数据库配置等多个方面。通过合理使用索引、优化查询语句、调整表结构和数据库配置，可以显著提高查询性能，减少资源消耗，并最终提升系统的响应速度。1、创建合适的索引：使用覆盖索引、组合索引、前缀索引等，确保查询能够高效地使用索引。2、优化查询语句：避免使用SELECT ，使用EXISTS替代IN，使用JOIN替代子查询，避免隐式类型转换，优化分页查询。3、优化表结构：选择合适的数据类型，使用分区表、垂直拆分表、水平拆分表等技术。
2025-01-15 22:28:19
1322
原创 Mysql--实战篇--数据库设计（范式和反范式，数据表设计原则）
通过逐步应用范式化的原则，我们可以有效地减少数据冗余、提高数据一致性和可维护性。每个范式级别都解决了特定类型的数据冗余问题。1NF：确保每个字段都是不可再分的基本数据项，并且每个表都有唯一的主键。（即：每个字段仅存储1个值，不能存多个值）2NF：消除非主属性对部分主键的依赖，确保所有非主属性完全依赖于整个主键。（即：组合主键的情况时会出现，一般较少）3NF：消除传递依赖，确保所有非主属性只依赖于主键。（即：间接通过非主键属性才能和主键产生关联的情况）
2025-01-15 21:00:44
829
原创 Mysql--运维篇--安全性（数据库访问控制，最小权限原则，表空间加密，TLS加密，证书签发，SQL注入及防范等）
MySQL的访问控制是确保数据库安全的重要机制。通过合理的用户权限管理、网络配置和强密码策略，可以有效防止未经授权的访问、篡改和泄露。遵循最小权限原则，为每个用户分配仅限于完成其任务所需的最小权限。定期审查和清理用户权限，确保系统中没有不必要的用户或权限。使用强密码策略，启用密码强度检查并定期更改密码。限制MySQL端口的访问，使用防火墙和SSL/TLS加密保护网络通信。启用日志审计，定期检查日志，及时发现并响应潜在的安全威胁。
2025-01-14 23:12:18
986
原创 Java WEB技术-文件断续加载（RandomAccessFile，请求头Range，Content-Range，Accept-Ranges等）
但这种方式也会有一个问题，就像开篇所说的那样，通常为了安全系统的安全，文件服务器的IP地址可能不会暴漏给互联网访问的，甚至有些还会限制只有固定的IP才能访问文件服务器，所以这种方式有一定的局限性。互联网用户需要在线播放视频或者音频，如果文件大小非常大的话，要把文件全部下载完成之后在播放就会非常耗时，用户的宽带或服务器的宽带网速不一定能那么给力，所以这个时候我们就要通过断续加载的方式实现该功能（即：下载一部分时就可以开始播放）。此时接口响应的是一个如上的界面，且能够正常播放文件，说明就成功了。
2025-01-14 11:20:19
814
原创 Mysql--运维篇--空间管理（表空间，索引空间，临时表空间，二进制日志，数据归档等）
MySQL的空间管理是一个多方面的任务，涉及表空间、索引、临时表、二进制日志等多个方面。提高数据库的性能，减少磁盘I/O。节省存储成本，避免磁盘空间不足导致的服务中断。优化查询性能，减少不必要的索引和临时表。有效管理历史数据，避免数据膨胀。通过合理的配置、定期的维护和监控，可以确保MySQL数据库高效、稳定地运行。乘风破浪会有时，直挂云帆济沧海！！！
2025-01-13 22:28:59
1004
原创 Mysql--运维篇--备份和恢复（逻辑备份，mysqldump，物理备份，热备份，温备份，冷备份，二进制文件备份和恢复等）
二进制日志是MySQL中的一种日志文件，记录了所有对数据库的更改操作。它以二进制格式存储，因此不能直接阅读，但可以通过工具解析。主从复制：主库将二进制日志发送给从库，从库根据日志重放这些操作，保持与主库同步。增量备份：在全量备份的基础上，使用二进制日志进行增量备份，减少备份时间和存储空间。时间点恢复：通过二进制日志，可以在某个特定的时间点恢复数据，避免不必要的数据丢失。
2025-01-13 21:57:27
1170
原创 Mysql--运维篇--库表分离（垂直分库，水平分库，垂直分表，水平分表）
分库是指将一个大的数据库拆分成多个独立的数据库实例，适用于需要分布式架构和高可用性的场景。分表是指将一个大表拆分成多个小表，适用于需要减少单表行数或列数的场景。垂直分库/分表是按列或表的功能进行划分，适用于字段较多且某些字段不常用的情况。水平分库/分表是按行进行划分，适用于数据量大、并发访问高的场景。两者结合 可以在更大规模的应用中提供更好的性能和可扩展性。分库是把表或者数据分布到不同的数据库上，减轻数据库压力。分表是把表结构或者表数据拆分到不同的表上，减轻数据库压力。
2025-01-12 22:24:42
1405
原创 Mysql--运维篇--主从复制和集群（主从复制I/O线程，SQL线程，二进制日志，中继日志，集群NDB）
MySQL的主从复制（Master-Slave Replication）是一种数据冗余和高可用性的解决方案，它通过将一个或多个从服务器（Slave）与主服务器（Master）同步来实现。主从复制的基本原理是：在主服务器上记录所有的数据变更操作（如INSERT、UPDATE、DELETE等），然后这些变更被传输到从服务器，并在从服务器上重放这些操作，从而保持数据的一致性。编辑配置文件（通常是config.ini），定义集群的拓扑结构，包括管理节点、数据节点和SQL节点的数量及地址。
2025-01-12 22:10:44
1083
原创 Mysql--运维篇--日志管理（连接层，SQL层，存储引擎层，文件存储层）
重做日志是InnoDB用于确保事务持久性的关键组件。它记录了所有对数据页的物理修改操作，确保在系统崩溃后可以重新应用这些修改，恢复数据的一致性。位置：重做日志文件通常位于ib_logfile0和ib_logfile1中。Redo日志不是文本格式的日志，不能直接查看其内容。大小：每个重做日志文件的大小由innodb_log_file_size参数控制，默认值为48MB。数量：可以通过innodb_log_files_in_group参数指定重做日志文件的数量，默认为2。
2025-01-11 21:53:04
1097
2
原创 Mysql--重点篇--索引（索引分类，Hash和B-tree索引，聚簇和非聚簇索引，回表查询，覆盖索引，索引工作原理，索引失效，索引创建原则等）
索引是数据库中的一种数据结构，用于加速对表中数据的检索。它类似于书籍的目录，通过索引可以快速找到特定的数据行，而不需要逐行扫描整个表。索引通常存储在磁盘上，并与表的数据分开管理。按照数据结构分类：HASH索引，B+Tree索引，Full-text索引、R-Tree索引。按照规功能分类：主键索引，唯一索引，普通索引，复合索引，全文索引 ，空间索引。按照存储形式分类：聚簇索引，非聚簇索引。按照是否建立在主键上分类：主键索引，辅助索引。
2025-01-11 21:35:02
1247
原创 Mysql--架构篇--存储引擎InnoDB（内存结构，磁盘结构，存储结构，日志管理，锁机制，事务并发控制等）
默认存储引擎：从MySQL 5.5版本开始，InnoDB成为MySQL的默认存储引擎。事务支持：InnoDB支持ACID（原子性、一致性、隔离性、持久性）事务，确保数据的完整性和可靠性。行级锁：InnoDB使用行级锁，允许多个事务并发访问不同行的数据，减少了锁冲突，适合高并发读写场景。外键约束：InnoDB支持外键约束，确保表与表之间的关系完整性。崩溃恢复：InnoDB具有自动崩溃恢复功能，能够在系统崩溃后快速恢复数据。
2025-01-10 22:43:08
1262
原创 Mysql--架构篇--体系结构（连接层，SQL层，存储引擎层，文件存储层）
MySQL是一种广泛使用的关系型数据库管理系统（RDBMS），其体系结构设计旨在提供高效的数据存储、查询处理和事务管理。MySQL的体系结构可以分为多个层次，每个层次负责不同的功能模块。
2025-01-10 20:50:32
1027
原创 Mysql--基础篇--视图，存储过程，触发器
触发器可以用来维护数据的完整性和一致性，执行复杂的业务规则，或者在数据库中实现事件驱动的逻辑。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。另外，一些视图是可以更新的，即可以通过视图来插入、更新或删除数据，但不是所有的视图都支持这些操作，这取决于视图的复杂程度以及基础表的结构。例如，假设有一个名为employees的表，你可以创建一个视图来显示所有部门编号为10的员工信息。假设我们有一个名为orders的订单表，并且每次插入新的订单时，我们都想记录下该订单的创建时间。
2025-01-09 22:29:06
728
原创 Mysql--基础篇--多表查询（JOIN，笛卡尔积）
JOIN是MySQL中用于从多个表中检索数据的强大工具。通过不同的JOIN类型（如INNER JOIN、LEFT JOIN、RIGHT JOIN等），你可以根据业务需求灵活地组合多个表的数据。性能优化是多表查询中不可忽视的一部分。通过合理的索引设计、选择合适的JOIN类型、避免不必要的列以及使用EXPLAIN分析查询计划，可以显著提升查询的性能。常见问题（如笛卡尔积、N+1查询、重复数据等）需要特别注意，并采取相应的解决方案。
2025-01-09 22:10:41
1410
原创 Mysql--基础篇--事务（ACID特征及实现原理，事务管理模式，隔离级别，并发问题，锁机制，行级锁，表级锁，意向锁，共享锁，排他锁，死锁，MVCC）
原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不完成。如果事务中的任何一个操作失败，整个事务将被回滚，恢复到事务开始之前的状态。一致性（Consistency）：事务必须确保数据库从一个一致状态转换到另一个一致状态。事务执行前后，数据库的完整性约束不能被破坏。隔离性（Isolation）：并发执行的多个事务之间是相互隔离的，一个事务的中间状态不会影响其他事务。事务的隔离性通过不同的隔离级别来实现。
2025-01-08 23:30:12
1576
原创 Mysql--基础篇--约束（主键，外键，唯一，检查，枚举及复合约束等）
MySQL提供了多种类型的约束来确保数据的完整性和一致性。主键约束：确保每一行都有唯一的标识符。外键约束：维护表之间的引用完整性。唯一约束：确保列中的值是唯一的。非空约束：确保列中的值不能为空。默认值约束：为列提供默认值。检查约束：确保列中的值满足特定条件。枚举约束：限制列的取值范围为预定义的值。集合约束：允许列存储多个预定义的值。通过合理使用这些约束，你可以有效地保护数据库中的数据，防止不合法的数据进入系统，从而提高数据的质量和可靠性。乘风破浪会有时，直挂云帆济沧海！！！
2025-01-08 21:37:31
1047
原创 Mysql--基础篇--函数（字符串函数，日期函数，数值函数，聚合函数，自定义函数及与存储过程的区别等）
MySQL提供了丰富多样的内置函数，涵盖了字符串处理、数值计算、日期和时间操作、聚合统计、控制流、加密和哈希操作等多个方面。合理使用这些函数可以大大简化SQL查询，提高开发效率并增强数据处理能力。除了内置函数，MySQL还支持自定义函数（User-Defined Functions, UDF），允许用户根据自己的需求编写复杂的逻辑。存储函数（Stored Functions）：使用SQL语法自定义编写函数，可以在数据库中存储并调用。
2025-01-07 21:49:09
909
原创 Mysql--基础篇--数据类型（整数，浮点数，日期，枚举，二进制，空间类型等）
MySQL提供了丰富的数据类型，涵盖了数值、字符串、日期时间、枚举、二进制和空间数据等多种类型。选择合适的数据类型不仅有助于优化存储空间，还能提高查询性能并确保数据的完整性。根据你的具体需求，选择最适合的数据类型来设计表结构。
2025-01-07 21:05:13
553
原创 Mysql--基础篇--SQL（DDL，DML，窗口函数，CET，视图，存储过程，触发器等）
DDL用于定义和管理数据库的结构，包括创建、修改和删除数据库对象（如表、索引、视图等）。CREATE：创建数据库对象。ALTER：修改现有数据库对象的结构。DROP：删除数据库对象。TRUNCATE：清空表中的所有数据，但保留表结构。RENAME：重命名数据库对象。创建数据库：创建表：age INT,修改表结构：删除表：清空表数据：重命名表：SQL是一种强大且灵活的查询语言，广泛应用于关系型数据库的管理和操作。
2025-01-06 22:42:52
972
原创 Mysql--基础篇--概述
InnoDB：MySQL的默认存储引擎，支持事务、行级锁、崩溃恢复等高级特性。MyISAM：早期的默认存储引擎，支持表级锁，适合读多写少的场景。Memory：基于内存的存储引擎，适合临时数据存储，性能极高但不持久。其他存储引擎：如TokuDB、MyRocks、Aria等，各有不同的应用场景。
2025-01-06 20:15:07
219
原创 Mysql--前言篇（数据，数据库，数据库管理系统DBMS，数据库系统，CAP定理）
CAP理论（也称为Brewer定理）是由加州大学伯克利分校的计算机科学家Eric Brewer在2000年提出的。后来由麻省理工学院的研究人员后来由麻省理工学院的研究人员Seth Gilbert和Nancy Lynch证明。（1）、一致性 (Consistency)：所有节点在同一时间看到相同的数据。换句话说，读操作总是返回最新写入的数据。（2）、可用性(Availability)：每个请求都能在合理的时间内收到非错误的响应，但不保证数据是最新的。
2025-01-06 20:06:22
1127
原创 Redis篇--应用篇4--自动提示，自动补全
Redis本身并不直接提供自动补全（Auto-Complete）功能，但可以通过合理的数据结构和算法设计实现自动补全的功能。常见的实现方式是使用有序集合（Sorted Set）或前缀树（Trie）结合键值对（String）来存储和查询前缀匹配的词项。词项存储：使用Redis的Sorted Set来存储所有词项及其权重，以便根据权重排序。前缀索引：使用Redis的Set类型来存储每个前缀对应的词项列表。通过合理使用Redis的有序集合和键值对，结合前缀索引和权重排序，可以实现一个自动补全词语的方案。
2024-12-26 19:23:25
1049
原创 Redis篇--应用篇3--数据统计（排行榜，计数器）
如果想要实现排行榜，可以使用有序集合（Sorted Set）实现，可以根据分数对成员进行排序。如果需要防止重复投票，可以使用一个SET集合存储用户id与投票用户id。如投票，计算评分，根据评分来决定如何排序和展示。
2024-12-26 16:55:21
375
原创 Redis篇--应用篇2--消息队列（List，pub/sub模式，Streams）
选择建议如果你需要一个简单的、临时性的消息队列，并且对持久性和可靠性要求不高，可以选择Redis List。它实现简单，适合快速开发和小规模应用。如果你需要实现实时通信，并且消息的持久性和可靠性不是主要关注点，可以选择Redis Pub/Sub。它非常适合用于通知系统、聊天应用等实时场景。如果你需要一个高可靠、持久化的消息队列，并且希望支持复杂的分布式场景（如任务调度、日志聚合等），Redis Streams 是最佳选择。它提供了丰富的功能和保障，适合构建大型、复杂的分布式系统。
2024-12-26 16:51:03
1095
原创 Redis篇--应用篇1--会话存储（session共享）
实现Session共享是构建分布式Web应用时的一个重要需求，尤其是在水平扩展和高可用性要求较高的场景下。在分布式服务或集群服务中往往会出现这样一个问题：用户登录A服务后可以正常访问A服务中的接口。但是我们知道，分布式服务通常都是有多个微服务一起构建形成的。如果后续请求转发到了B服务，B服务后端没有这个用户的Session信息，就会强制让用户重新登录，导致业务无法顺利完成。因此，就需要将Session进行共享，保证每个系统都能获取用户的Session状态。
2024-12-26 16:35:38
1260
原创 Redis篇--常见问题篇9--其他一些问题
Redis是基于内存的键值存储系统，因此当Redis的内存使用量超过服务器的物理内存时，可能会触发OOM Killer，导致Redis进程被杀死，进而影响整个系统的稳定性。Redis是一个单线程模型的数据库，所有操作都在主线程中执行。如果Redis与客户端之间的网络延迟过高，或者发生了网络分区（即部分节点无法通信），可能会导致Redis响应变慢，甚至出现连接超时或丢失的情况。
2024-12-22 17:14:53
873
原创 Redis篇--常见问题篇8--缓存一致性3（注解式缓存Spring Cache）
Spring Cache是Spring框架提供的一个缓存抽象层，旨在简化应用程序中的缓存管理。通过使用Spring Cache，开发者可以轻松地将缓存机制集成到业务逻辑中，而无需关心具体的缓存实现细节。Spring Cache支持多种缓存提供者（如EhCache、Caffeine、Redis、Hazelcast等），并且提供了统一的API来操作缓存。Spring Cache的主要目标是减少对后端数据源（如数据库、远程服务等）的访问次数，从而提高应用的性能和响应速度。
2024-12-22 16:25:43
1010
原创 Redis篇--常见问题篇7--缓存一致性2（分布式事务框架Seata）
在传统的单体应用中，事务管理相对简单，通常使用数据库的本地事务（如MySQL的BEGIN和COMMIT）来保证数据的一致性。然而，在微服务架构中，由于每个服务都有自己的数据库，跨服务的事务管理变得复杂。Seata正是为了解决这一问题而设计的，它提供了一种轻量级的分布式事务解决方案，能够在多个微服务之间协调事务，确保数据的一致性。Seata是阿里巴巴开源的一款分布式事务解决方案，旨在解决微服务架构中的分布式事务问题。
2024-12-22 12:01:07
1196
原创 Redis篇--常见问题篇6--缓存一致性1（Mysql和Redis缓存一致，更新数据库删除缓存策略）
在使用Redis作为MySQL的缓存层时，缓存一致性问题是指Redis中的缓存数据与MySQL数据库中的实际数据不一致的情况。这可能会导致读取到过期或错误的数据，从而影响系统的正确性和用户体验。为了减轻数据库的压力，通常读操作都是先读缓存，缓存没有则读数据库数据在写入缓存；而增/删/改操作介于数据库和缓存之间，由于操作步骤和并发问题，可能产生不一致的现象。
2024-12-22 11:53:24
1063
原创 Redis篇--常见问题篇5--热Key（Hot Key，什么是热Key，服务降级，一致性哈希）
热键问题是Redis在高并发场景下常见的性能瓶颈之一。由于Redis是单线程模型，热键的频繁访问会导致性能下降、延迟增加，甚至影响整个系统的稳定性。要解决热键问题，比较推荐的方式就是Redis集群和降级的方式。即上面优化建议的前3点当系统出现故障或遇到瓶颈时，为了保证系统可用，采用一些方法以牺牲一定的次要功能为代价，保证主业务还可以继续使用的手段，我们称之为降级。限流和熔断只是实现降级的一种策略，实际降级的策略还有很多。例如：一个饭店既卖黄焖鸡，又卖西红柿炒鸡蛋。
2024-12-21 23:32:37
1179
原创 Redis篇--常见问题篇4--大Key（Big Key，什么是大Key，影响及使用建议）
大Key：通常是指值（Value）的长度非常大，实际上键（Key）长度很大也算。通常来说，键本身不会很长，占用的内存较少，因此判断一个键是否为bigKey主要看它对应的值的大小。（1）、键（Key）非常大（2）、值（Value）非常大大Key的定义：Redis中的"大 Key"既可以指键（Key）非常大，也可以指值（Value）非常大。无论是键还是值，过大的大小都会对Redis的性能和内存使用产生负面影响。
2024-12-21 21:25:41
842
原创 Redis篇--常见问题篇3--缓存击穿（数据查询上锁，异步操作，熔断降级，三种缓存问题综合优化策略）
缓存击穿是指某个热点数据在缓存中过期后，大量并发请求同时访问该数据，导致这些请求全部穿透到数据库，形成瞬间的高负载，给数据库和服务带来巨大的压力，甚至会崩溃。这种情况通常发生在高并发场景下，尤其是在某些热点数据的缓存过期时。对于不存在的数据，缓存空结果（如null），并设置较短的过期时间。（推荐）使用布隆过滤器快速判断数据是否存在。（不太推荐，过滤器准确度以及需要维护成本）为每个缓存项设置随机的过期时间，避免所有缓存项在同一时间点失效。（推荐）
2024-12-21 21:00:40
1173
原创 Redis篇--常见问题篇2--缓存雪崩（过期时间分散，缓存预热，多级缓存）
缓存雪崩是指在短时间内，大量的缓存同时失效或过期，导致大量的请求穿透到后端数据库或服务，从而引发系统负载骤增，甚至可能导致系统崩溃。这种情况通常发生在缓存的过期时间设置不合理时，所有缓存的过期时间相同，导致它们在同一时间点失效。
2024-12-21 20:27:54
777
原创 Redis篇--常见问题篇1--缓存穿透（缓存空值，布隆过滤器，接口限流）
缓存穿透是指客户端请求的数据既不在Redis缓存中，也不在数据库中。换句话说，缓存和数据库中都不存在该数据，但客户端仍然发起了查询请求。这种情况下，缓存无法命中，请求会直接穿透到数据库，而数据库中也找不到相应的数据，最终返回null或者空结果。如果这种请求量非常大的话，不仅会浪费网络带宽、CPU和I/O等资源，还会额外增大数据库的压力，甚至会导致数据库崩溃。
2024-12-21 17:37:44
1063
原创 Redis篇--数据结构篇8--Redis数据结构架构篇（全局键空间，key存储结构，值存储结构，对象头）
字典（Dictionary）：Redis使用字典来存储键值对。字典是一个键到值的映射结构，支持快速查找、插入和删除操作。- 哈希表（Hash Table）：字典的底层实现是哈希表。每个哈希表由多个桶（bucket）组成，每个桶可以存储多个键值对。为了减少哈希冲突，Redis使用了拉链法（Separate Chaining），即当多个键的哈希值相同（发生冲突）时，它们会被存储在一个链表中。- 渐进式 rehash：为了应对哈希表扩展或收缩时的性能问题，Redis实现了渐进式rehash。
2024-12-18 23:41:16
1334
原创 Redis篇-21--运维篇3-集群（分片，水平扩展，高可用，集群配置案例，扩展哨兵案例）
Redis集群（Cluster）通过分片（sharding）实现了水平扩展，允许数据分布在多个节点上，从而提升性能和存储容量。在Redis集群中，数据被分割成16384个哈希槽（hash slots），每个哈希槽可以分配给集群中的不同节点。每个节点负责一部分哈希槽，并且每个哈希槽都有一个主节点和零个或多个从节点（用于高可用性）。客户端在发送命令时，会根据键的哈希值计算出对应的哈希槽，并直接连接到持有该槽的主节点。通过上述配置，你可以搭建一个包含3个主节点和3个从节点的Redis集群。
2024-12-16 20:18:42
1194
原创 Redis篇-20--运维篇2-哨兵机制（主从节点监听，故障转移，高可用，配置案例）
Redis哨兵机制是一种高可用的解决方案，它通过一组哨兵进程来监控Redis主从节点的运行状态。当主节点出现故障时，哨兵会自动将其中一个从节点提升为新的主节点，并通知其他从节点和客户端更新配置，从而实现自动故障转移。1、主观下线 (Subjectively Down, SDOWN)当一个哨兵节点认为某个主服务器（master）不可达时，它会将这个主服务器标记为“主观下线”。
2024-12-16 19:59:08
992
原创 Redis篇-19--运维篇1-主从复制（主从复制，读写分离，配置实现，实战案例）
Redis的主从复制（Master-Slave Replication）是一种数据冗余机制，它允许将一台Redis服务器的数据复制到其他Redis服务器。在主从复制中，有一台主服务器（Master）和一个或多个从服务器（Slave）。主服务器负责写操作，而从服务器可以用于读操作，从而实现读写分离，减轻主服务器的负载压力。首次同步是从服务发起，之后RDB文件同步，缓冲区写日志同步，都是主服务主动发起给从服务器的。
2024-12-16 19:30:50
1030
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人