自己选择的路，跪着也要走完

事务消息用于确保跨服务的操作要么全部成功，要么全部失败，解决数据不一致问题。以电商平台为例，用户下单支付时，需同时完成扣减库存和通知物流系统发货两个操作。若不同步，可能导致库存扣减但物流未收到通知，或物流收到通知但库存未扣减。事务消息通过两阶段提交实现：第一阶段，生产者发送半消息到RocketMQ，Broker确认后生产者执行本地事务并记录结果；第二阶段，生产者根据本地事务结果通知Broker提交或回滚消息。若生产者宕机，Broker会主动回查未确认的消息，确保事务一致性。

RocketMQ的顺序消息实现原理主要涉及生产者发送、Broker存储和消费者消费三个环节，分为全局有序和分区有序两种模式。全局有序要求所有消息严格按FIFO顺序处理，适用于低并发场景；分区有序则保证同一业务分组的消息顺序，不同分组可并行处理，是生产环境的主流方案。关键技术包括生产者的同步发送和队列选择器、Broker的顺序存储和锁机制、消费者的顺序监听器和重试策略。典型应用场景包括订单流程、库存扣减和事件溯源。注意事项包括性能权衡、异常处理和动态扩容。通过这些机制，RocketMQ在分布式环境下高效实现了

RocketMQ提供了两种消息拉取模式：Pull模式和Push模式。Pull模式由消费者主动向Broker请求消息，适合需要精确控制消费节奏的场景，但实现复杂且需自行管理消费位点。Push模式基于Pull模式封装，对用户表现为推送体验，使用简单且实时性好，但消费速率由RocketMQ控制。Pull模式的核心实现包括位点管理、队列遍历和状态处理，而Push模式则通过长轮询机制、负载均衡和流控参数来优化消费。最佳实践建议常规场景使用Push模式，特殊需求使用Pull模式，并注意性能调优和容错处理。

SecurityContextHolder：存储安全上下文信息Authentication：存储当前用户的认证信息UserDetails：用户信息的核心接口UserDetailsService：加载用户信息的核心接口AuthenticationProvider：认证的具体实现者

这位小侠虽然只认可已经确定的事情，但是优柔寡断，看来看去总是变要么果断一点，看到就决定要么霸道一点，直接锁定不让改实在不行，就升级成大侠，一次看定终身！这位大侠虽然保证了看到的东西不会变，但有时会遇到"鬼影"（新插入的数据）。要么用火眼金睛（加锁）要么一气呵成（快速处理）要么练绝世武功（升级隔离级别）

1、REPEATABLE READ 的一致性视图主要保护的是快照读操作2、当涉及到当前读操作时，仍可能遇到幻读问题3、MySQL通过间隙锁部分解决幻读，但会影响并发性能4、在实际应用中，需要根据具体业务场景选择合适的处理方式。

在生产环境中使用Docker启动MySQL 5.7时，需要考虑数据持久化、配置文件管理、安全性等多个方面。以下是一个详细的步骤指南。

解决拉取镜像报错：Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while

查看已安装的软件包、检查docker服务状态、查看Docker版本

安装Redis在macOS上通常通过Homebrew进行，Homebrew是macOS上一个流行的包管理器。Redis的配置文件通常位于/usr/local/etc/redis.conf，可以根据需要进行自定义配置。如果Redis正在运行，会返回 PONG。一 使用Homebrew安装Redis。

【代码】centos 安装 nacos。

配置环境变量、启动NameServer、启动Broker、测试消息是否发送成功

tar -zxvf jdk-版本号-linux-架构.tar.gz。二 tar.gz 包手动安装。

Mac编译dubbo失败找不到tools:jar

首先生成一个maven项目，不会生成的参考（写的过程中遇到过的问题：mybatis-plus 生成controller中的代码， RequestMapping除了双斜杠问题@RequestMapping("//article")。解决方法： pc.setModuleName(null) ）

没有旗舰版的Idea授权，所以安装了社区版的idea。不知道从何时开始，社区版IDEA的插件不好用了，所以就换了个方法生成Springboot项目。

MySQL 的数据同步通常采用主从复制（Master-Slave）的方式。主从复制基于二进制日志（binlog）。主服务器（Master）在 binlog 中记录数据更改，从服务器（Slave）将这些日志读取并应用到自己的数据库，以此实现数据的同步。从服务器有两个线程：IO线程从主服务器读取 binlog 并保存在本地的中继日志（relay log）；SQL线程读取中继日志，执行其中的事件，确保从服务器数据与主服务器保持一致。

INT：4字节，范围从-2,147,483,648到2,147,483,647（有符号），0到4,294,967,295（无符号）。​VARCHAR：可变长度字符串，占用的字节数根据存储的数据长度而变化，最多65,535字节。SMALLINT：2字节，范围从-32,768到32,767（有符号），0到65,535（无符号）。用于中等大小的整数。TINYINT：1字节，范围从-128到127（有符号），0到255（无符号）。BIGINT：8字节，范围更大，适用于非常大的整数，如用户ID或订单号。

通常，应在搜索条件（WHERE子句）、连接条件（JOIN 子句）以及需要排序的字段（ORDER BY子句）上创建索引。覆盖索引：当所有要检索的列都包含在索引中时，查询可以只利用索引来完成，而无需额外访问数据表。使用函数，如 UPPER(column)，会使索引失效，因为它修改了列的原始值。注意复合索引的列顺序，尤其是当某些列只用于过滤，而其他列用于排序或连接时。试图设计查询和索引，使得查询可以只使用索引，避免访问实际的数据行。高选择性的列（即包含许多唯一值的列）是创建索引的好候选者。

不必搜索整个数据库，通过使用索引，数据库系统可以直接找到存储在磁盘上的特定行的地址。索引失效指的是在进行数据库查询时，虽然存在合适的索引，但由于某种原因，查询并没有使用该索引，从而可能导致性能下降。与普通索引类似，但要求索引列的所有值都是唯一的（不包括NULL值，因为在MySQL中，多个NULL值是被视为相互不同的）。InnoDB存储引擎的表中，数据的物理存储顺序与主键的顺序相同，也即主键索引是聚簇索引。文章主要有以下内容：MySQL性能优化、索引优化、索引失效，索引原理、索引分类。使用R-Tree算法。