关于rabbitmq的一些问题 一、RabbitMQ的完整工作流程 RabbitMQ 的核心是生产者将消息发送到交换机，交换机根据类型和路由键将消息路由到队列，消费者再从队列中获取消息。 核心组件： Producer（生产者）： 发送消息的应用程序。 Consumer（消费者）： 接收消息的应用程序。 Message（消息）： 包含有效载荷（数据）和标签（元数据，如路由键）。 Exchange（交换机）： 接收生产者发送的消息，并根据特定规则（交换机类型、绑定、路由键）将消息路由到一个或多个队列。 Queue（队列）： 存储消息的缓冲区，等待消费者消费。 Binding（绑定）： 连接交换机和队列的规则。 完整流程： 建立连接： 生产者/消费者与 RabbitMQ Broker 建立一个 TCP 连接。 在连接上创建一个 Channel（信道），Channel 是轻量级的连接，避免了频繁创建/销毁 TCP 开开销。 生产者发送消息： 生产者将消息发送到指定的 Exchange。 发送消息时，必须指定一个 Routing Key（路由键）。 交换机路由消息： Exchange 接收到消息后，根据自身的 类型 和 Binding 规则，决定将消息投递到哪些队列。 主要的交换机类型： Direct： 精确匹配 Routing Key。消息只会被投递到 Binding Key 与 Routing Key 完全一致 的队列。 Fanout： 广播模式。将消息投递到所有绑定到该 Exchange 的队列，忽略 Routing Key。 Topic： 模式匹配。使用通配符（* 匹配一个词，# 匹配零个或多个词）来匹配 Routing Key 和 Binding Key。...

Ollama 简介 介绍 Ollama 是一个开源的大型语言模型（LLM）平台，旨在让用户能够轻松地在本地运行、管理和与大型语言模型进行交互。 Ollama 提供了一个简单的方式来加载和使用各种预训练的语言模型，支持文本生成、翻译、代码编写、问答等多种自然语言处理任务。 Ollama 的特点在于它不仅仅提供了现成的模型和工具集，还提供了方便的界面和 API，使得从文本生成、对话系统到语义分析等任务都能快速实现 安装要求 Ollama 支持多种操作系统，包括 macOS、Windows、Linux 以及通过 Docker 容器运行。 CPU：多核处理器（推荐 4 核或以上） GPU：如果你计划运行大型模型或进行微调，推荐使用具有较高计算能力的 GPU（如 NVIDIA 的 CUDA 支持） 内存：至少 8GB RAM，运行较大模型时推荐 16GB 或更高。 存储：需要足够的硬盘空间来存储预训练模型，通常需要 10GB 至数百 GB 的空间，具体取决于模型的大小。 软件要求：确保系统上安装了最新版本的 Python（如果打算使用 Python SDK）。 下载安装ollama https://ollama.com/download 下载 下载完成后进行安装 运行模型 https://ollama.com/search 查找模型 下载模型 如 ollama run deepseek-r1 使用docker安装UI页面 docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v D:\open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main 进入UI页面，注册本地账号，开始使用 访问 http://localhost:3000/ Ollama API 可参考文档...

关于分布式 一、什么是分布式？ 一个系统，各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。 可以指多个不同组件分布在网络上互相协作 也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中心为了数据不丢失而采取的多个服务备份冗余 分布式最早出现的目的首先是解决单点问题，避免单点故障，然后解决了性能问题 二、分布式和微服务的区别？ 微服务并不一定是分布式系统（微服务中多个服务不一定部署在不同服务器，单机部署情况则不算是分布式） 分布式一定不是微服务 （分布式祖耀侧重服务的部署方式，微服务则是针对应用的一种服务拆分的架构） 三、分布式CAP原则 在设计一个分布式项目的时候会遇到三个特性： 一致性（Consistency）：所有节点数据实时同步，读取始终返回最新值 可用性（Availability）：每个请求必须得到响应（无论数据是否最新），高可用 分区容错（Partition Tolerance）：分布式最基本也是必需要有的特性，系统在遇到某个节点或网络分区故障时，仍然能够对外提供服务 三者无法同时满足，最多只能实现其中两个，网络分区发生时，必须牺牲C或A ‌CP（牺牲可用性）‌：如ZooKeeper，确保数据强一致性但可能拒绝请求 ‌AP（牺牲一致性）‌：如Eureka，保证服务可用但允许数据短暂不一致 三、 BASE理论 BASE理论是分布式系统设计原则，BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。 基本可用（Basically Available）：分布式系统，在出现故障的时候，允许损失部分可用性。类似服务降级 软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。 最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。 四、分布式事务及解决方案 分布式事务 本地事务依赖数据库本身提供的事务特性来实现， 但是在分布式环境下，可能会出现需要远程调用，比如： begin transaction； //1.本地数据库操作：张三减少金额 //2.远程调用：让李四增加金额 commit transation; 张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。 分布式事务解决方案 2PC 2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。偏向数据库 TCC TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm/Cancel 操作若执行失败，TM 会进行重试。偏向代码

Mysql 简易安装 安装Mysql8.0(centos8为例)， 可参考 MySQL官方文档 # CentOS el8下载 MySQL YUM 仓库（替换为最新版本） wget https://dev.mysql.com/get/mysql80-community-release-el8-6.noarch.rpm # el9 使用sudo yum install mysql84-community-release-el9-x86_64.noarch.rpm sudo rpm -Uvh mysql80-community-release-el*.rpm sudo yum makecache # 安装 MySQL 社区版服务器 # el9 的话sudo yum install mysql84-community-release-el9-x86_64.noarch.rpm sudo yum install -y mysql-community-server # 可以通过手动编辑/etc/yum.repos.d/mysql-community.repo文件来选择发布系列。 # **install时如果出现GPG 密钥问题** # sudo curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2023 https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 # sudo chmod 644 /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2023 # sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2023 # 重新执行 yum install -y mysql-community-server # 启动 MySQL 服务 sudo systemctl start mysqld sudo systemctl enable mysqld sudo systemctl status mysqld #MySQL 首次启动会生成一个临时 root 密码： sudo grep 'temporary password' /var/log/mysqld....

MySQL事务与隔离级别深度解析 一、 事务基础概念 1. 什么是事务 事务(Transaction)是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作。事务具有以下四个关键特性(ACID)： 原子性(Atomicity)：事务中的所有操作要么全部完成，要么全部不完成 一致性(Consistency)：事务执行前后，数据库从一个一致状态变到另一个一致状态 隔离性(Isolation)：多个事务并发执行时，一个事务的执行不应影响其他事务 持久性(Durability)：事务一旦提交，其结果就是永久性的 2. MySQL中的事务控制语句 START TRANSACTION; -- 或 BEGIN -- 执行SQL操作 COMMIT; -- 提交事务 ROLLBACK; -- 回滚事务 二、事务隔离级别详解 1. 四种标准隔离级别 MySQL支持四种事务隔离级别，控制不同事务之间的可见性： 隔离级别 脏读 不可重复读 幻读 说明 READ UNCOMMITTED（读未提交） 可能 可能 可能 最低隔离级别 READ COMMITTED（读已提交） 不可能 可能 可能 大多数数据库默认级别 REPEATABLE READ（可重复读） 不可能 不可能 可能 MySQL默认级别 SERIALIZABLE（序列化） 不可能 不可能 不可能 最高隔离级别 2. 并发问题说明 脏读(Dirty Read)：读取到其他事务未提交的数据 不可重复读(Non-repeatable Read)：同一事务内多次读取同一数据结果不同 幻读(Phantom Read)：同一事务内多次查询返回不同的行集合 3. 隔离级别设置与查看 -- 设置当前会话隔离级别 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 设置全局隔离级别 SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- 查看当前隔离级别 SELECT @@transaction_isolation; 三、各隔离级别实现机制 1....

MYSQL中的回（Back to Table）表说明 一、 基本概念 回表是指当使用非聚簇索引（二级索引）进行查询时，首先在索引中查找到所需数据的主键值，然后再根据这个主键值回到主键索引（聚簇索引）中查找完整数据行的过程。 二、核心原理 聚簇索引 vs 非聚簇索引 -- 创建测试表 CREATE TABLE user_info ( id INT PRIMARY KEY, -- 主键，聚簇索引 name VARCHAR(50), email VARCHAR(100), age INT, created_at DATETIME, INDEX idx_email (email), -- 非聚簇索引（二级索引） INDEX idx_name_age (name, age) -- 复合非聚簇索引 ); 索引结构对比 聚簇索引（主键索引）结构： 索引节点 -> 叶子节点包含完整数据行 [id:1] -> [id:1, name:'张三', email:'zhang@xx.com', age:25, ...] [id:2] -> [id:2, name:'李四', email:'li@xx.com', age:30, ...] 非聚簇索引（二级索引）结构： 索引节点 -> 叶子节点只包含索引列 + 主键值 [email:'li@xx.com'] -> [主键id:2] [email:'zhang@xx....

MYSQL中的锁 一、 MySQL锁概述 MySQL锁机制是数据库管理系统实现并发控制的核心技术，它通过在共享资源上实施访问限制，确保数据的一致性和完整性。作为PHP高级开发者，深入理解MySQL锁机制对于构建高性能、高并发的Web应用至关重要。 二、 MySQL锁分类体系 1. 按锁的粒度划分 1. 表级锁 特点 开销小，加锁快 锁定整个表 并发度低 使用场景 -- 显式加表锁 LOCK TABLES users READ; -- 共享锁 LOCK TABLES users WRITE; -- 排他锁 -- 操作完成后释放 UNLOCK TABLES; 注意事项： MyISAM引擎默认使用表锁 在InnoDB上应谨慎使用，会严重影响并发 2. 行级锁 特点 开销大，加锁慢 只锁定需要的行 并发度高 使用场景 -- 共享锁(S锁) SELECT * FROM accounts WHERE id = 1 LOCK IN SHARE MODE; -- MySQL 8.0+推荐语法 SELECT * FROM accounts WHERE id = 1 FOR SHARE; -- 排他锁(X锁) SELECT * FROM accounts WHERE id = 1 FOR UPDATE; 注意事项：...

MySQL分库分表（无中间件） 一、 分库分表方案设计 1. 垂直拆分 (按业务模块) -- 原始单体数据库 CREATE DATABASE ecommerce; USE ecommerce; -- 垂直拆分后的数据库 -- 用户库 CREATE DATABASE user_center; USE user_center; CREATE TABLE users ( user_id BIGINT PRIMARY KEY, username VARCHAR(50) UNIQUE, email VARCHAR(100) UNIQUE, password VARCHAR(100), mobile VARCHAR(20), status TINYINT DEFAULT 1, created_at DATETIME, updated_at DATETIME ); CREATE TABLE user_profiles ( user_id BIGINT PRIMARY KEY, real_name VARCHAR(50), avatar VARCHAR(200), gender TINYINT, birthday DATE, bio TEXT ); CREATE TABLE user_address ( address_id BIGINT PRIMARY KEY, user_id BIGINT, province VARCHAR(50), city VARCHAR(50), district VARCHAR(50), detail VARCHAR(200), is_default TINYINT DEFAULT 0, INDEX idx_user_id (user_id) ); -- 订单库 CREATE DATABASE order_center; USE order_center; CREATE TABLE orders ( order_id BIGINT PRIMARY KEY, user_id BIGINT, total_amount DECIMAL(10,2), status TINYINT, payment_status TINYINT, created_at DATETIME, paid_at DATETIME ); CREATE TABLE order_items ( item_id BIGINT PRIMARY KEY, order_id BIGINT, product_id BIGINT, product_name VARCHAR(100), price DECIMAL(10,2), quantity INT, INDEX idx_order_id (order_id) ); -- 商品库 CREATE DATABASE product_center; USE product_center; CREATE TABLE products ( product_id BIGINT PRIMARY KEY, name VARCHAR(100), category_id INT, price DECIMAL(10,2), stock INT, status TINYINT, created_at DATETIME ); CREATE TABLE categories ( category_id INT PRIMARY KEY, name VARCHAR(50), parent_id INT ); 2....

MySQL索引类型 索引是帮助MySQL高效获取数据的数据结构，类似于书籍的目录，可以大大加快查询速度。 一、索引类型 1. B-Tree 索引（最常用） 特点 默认的索引类型 适用于全键值、键值范围或键值前缀查找 支持排序和分组 创建语法 -- 单列索引 CREATE INDEX idx_name ON table_name(column_name); -- 多列复合索引 CREATE INDEX idx_name ON table_name(col1, col2, col3); -- 创建表时指定 CREATE TABLE users ( id INT PRIMARY KEY, name VARCHAR(50), email VARCHAR(100), age INT, INDEX idx_name (name), INDEX idx_email_age (email, age) ); 适用查询类型 -- 全值匹配 SELECT * FROM users WHERE name = 'John'; -- 前缀匹配（最左前缀） SELECT * FROM users WHERE name LIKE 'Joh%'; -- 范围查询 SELECT * FROM users WHERE age BETWEEN 20 AND 30; -- 精确匹配左列 + 范围匹配右列 SELECT * FROM users WHERE email = 'john@example....

rabbitmq工作原理 AMQP协议 AMQP是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。 AMQP协议是一种二进制协议，提供客户端应用与消息中间件之间异步、安全、高效地交互。 AMQP作为中间层服务，把消息生产和消费分割出来，当消息生产者出现异常，不影响消费者对消息的消费，当消费者异常时，生产者生产的消息可以存放到服务的内存或者磁盘，不以影响到消息的消费，同时，消息也可以基于路由的规则可以投递到指定的消费者消费。 AMQP基于模块化通过Exchange和Message Queue两个组件组合实现消息路由分发 生产者和消费者 生产者是生产消息的主体，消费者是消费消息的主体 数据集成与系统解耦、异步处理与事件驱动、流量削峰、事务消息与分布式事务的最终一致等 生产者生产一条消息丢给消息代理，消息代理根据投递规则将消息传送到消费者手上 交换机 交换机就像是消息代理的路由器，负责拿到一个消息之后，根据确定的规则（路由键）将他路由给一个或零个队列、交换机具备多种路由模式。 基于消息生产者和路由规则可以将消息投递到指定的Message Queue，交换机收到生产者投递的消息，基于路由规则及队列绑定关系匹配到投递对应的交换机或者队列进行分发，交换机不存储消息，只做转发 直连交换机：根据路由键完全匹配的投递到对应的队列。 扇形交换机：无视路由键，将消息进行拷贝，并路由到给绑定到它身上的所有队列，提供了一个广播的效果 主题交换机： 根据路由键按模式匹配的投递到对应的队列 交换机也具备自己的属性，可以定义自己的名字，是否持久化等选项 队列 消息的暂存地，至少有一个消费者订阅了队列的话，消息会立即发送给这些订阅的消费者。但是如果消息到达了无人的订阅队列，消息会在队列中等待，等待有了消费者便进行分发 Exchange和Message Queue之间存在绑定关系，消息到了Exchange后基于路由策略可以将消息投递到已绑定且符合路由策略的Message Queue。 消息队列会将消息存储到内存或者磁盘中，并将这些消息按照一定顺序转发给一个或多个消费者，每个消息队列都是独立隔离的，相互不影响。 消息队列具有不同的属性：私有，共享，持久化，临时，客户端定义或者服务端定义等，可以基于实际需求选择对应的类型 消息 消息是信息的载体，也是MAQP协议的一个实体，消息包含以下两部分 载荷：就是真正的信息，是你想要传输的任何内容，该部分内容对消息代理来说是透明的 元消息：包含路由键、内容类型、编码、是否持久化等等消息属性，会被消息代理所解析，消息代理根据消息的属性对这条消息进行投递，存储等。这部分被消息代理所关心，而消费者对其是不关心的 信道 网络信道，是建立在Connection连接之上的一种轻量级的连接。几乎所有的操作都在Chanel中进行，Channel是进行消息读写的通道，客户端可以建立对各Channel，每个Channel代表一个会话任务 如果把Connection比作一条光纤电缆的话，那么Channel信道就比作成光纤电缆中的其中一束光纤。一个Connection上可以创建任意数量的Channel。 大部分的业务操作是在Channel这个接口中完成的 队列声明 queueDeclare 交换机的声明 ExchangeDeclare 队列的绑定 queueBind 发布消息 basicPublish 消费消息 basicConsume Rabbitmq 工作模式 一、简单模式 生产者发送消息到队列，消费者进行消费，没有交换机 二、工作模式 一个生产者发送消息到队列中，队列分配消息给不同的队列，队列接收到消息进行消费 三、订阅模式 每个队列的消息都是一样的，生产者把消息发送给交换机，交换机把消息发送给消息绑定的队列，让消费者消费 四、路由模式 根据路由键发送到不同的消息队列中 五、主题模式 根据路由键分类，发送到不同的消息队列中