在网站上线后，了解访客从何而来、关注哪些内容，是持续优化的基础。 但 Google Analytics 的复杂配置和隐私合规问题，让不少站长望而却步。如果你希望数据完全由自己掌控，又不想牺牲分析能力，Umami 是一个非常值得考虑的选择。 一、什么是 Umami？ Umami 是一个开源、轻量且注重隐私的网站分析工具，定位为 Google Analytics 的替代方案。它的核心特点可以用几个关键词概括： 开源免费，自托管：代码遵循 MIT 许可证，任何人都可以自由使用和修改。你可以将其部署在自己的服务器或云平台上，所有数据都存储在你控制的环境中，无需依赖任何第三方服务。 隐私友好，无需 Cookie：Umami 默认不使用 Cookie，也不收集个人身份信息（PII），符合 GDPR、CCPA 等隐私法规要求。这意味着你不用再为 Cookie 同意弹窗而烦恼。 轻量高效，不影响性能：前端跟踪脚本体积极小，通常小于 2KB，对网站加载速度的影响几乎可以忽略不计。 界面简洁，功能实用：仪表盘清晰展示实时访客数、页面浏览量（PV）、独立访客（UV）、流量来源、设备类型、热门页面等核心指标。 简单来说，Umami 回归了网站分析的本质——了解你的访客，而不打扰他们。 二、 Umami 的优势 相比于其他统计工具，Umami 的优势非常突出： 特点 具体说明 数据所有权 自托管部署，所有数据归你所有，不存在数据被第三方利用的风险。 不限网站数量 一个 Umami 实例可以同时监控无限个网站，甚至子域名和单个 URL。 绕过广告拦截器 因为统计脚本运行在你自己的域名下，可以有效避免被广告拦截器屏蔽。 多账户与共享 可以为团队或客户创建独立账号，也可以通过唯一 URL 公开分享统计数据。 持续进化 最新版本（v3.1.0）已加入会话回放（Session Replay）、自定义看板（Boards） 和 Core Web Vitals 性能监控等专业功能。 三、安装 Umami 对于大多数用户，使用 Docker Compose 是最快捷、最可靠的部署方式。它会帮你把 Umami 应用和 PostgreSQL 数据库一起搞定，维护起来也方便。 此处以Docker为例安装 3.1 前提 A server with Node....

关于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....