暮色之狐

为什么选择WireGuard？公司需要远程访问内网资源，但你还在为VPN配置头疼？试试WireGuard吧，从零到实现远程互联，真的只需要10分钟。 它轻量、极速、安全，配置告别繁琐证书，目前已集成于 Linux 内核主线，广泛用于服务器组网和远程访问。 服务端操作安装WireGuardUbuntu 20.04/22.04/24.04： 12345# 更新软件包索引sudo apt update# 安装WireGuard及管理工具sudo apt install -y wireguard wireguard-tools WireGuard已内置于Linux 5.6+内核，这里安装的是用户态管理工具。 Ubuntu 18.04（内核较旧，需添加PPA）： 123sudo add-apt-repository ppa:wireguard/wireguardsudo apt updatesudo apt install -y wireguard wireguard-tools wireguard-dkms Debian 1apt install wireguar...

用Docker部署OpenVPN服务端，让几台机器之间能够互相访问，结果在“宿主机访问VPN客户端”这一步卡住了整整一个下午。 容器内能ping通，宿主机却死活不通。traceroute显示数据包到了容器门口就消失了…… 今天就把完整的排查过程和解决方案分享出来，希望对遇到类似问题的你有所帮助。 一、我的网络拓扑 机器A：一台云服务器，通过Docker运行OpenVPN服务端 机器B：家里的一台开发机，安装了OpenVPN客户端 机器C：家里的NAS，同样安装了OpenVPN客户端 需求很简单：三台机器要能互相访问，就像在同一个局域网里一样。 B和C连接成功后，各自拿到了VPN虚拟IP：10.8.0.3和10.8.0.4。从容器内部ping 10.8.0.3是通的，但从宿主机A上ping，却一直超时。 二、问题到底出在哪？经过一番排查，发现问题出在三个环节： 第一层：宿主机没有到VPN子网的路由宿主机根本不知道10.8.0.0/24这个网段该往哪儿走。 第二层：容器的防火墙挡住了转发就算加了路由，数据包到了容器门口，也被iptables的FORWARD链拦截了。 第三层：源地址...

很多朋友会遇到这样的情况：手上有三台机器——机器A、机器B、机器C，它们各自处于不同的网络中，只有机器A拥有公网IP，机器B和机器C要么在NAT后面，要么在完全隔离的内网里，外面根本访问不到。 这时候问题来了：怎么让这三台机器像在同一个局域网里一样互相通信？ 用OpenVPN就能搞定！把有公网IP的机器A作为VPN服务端，机器B和机器C作为客户端拨入，三台机器就在同一个虚拟内网里了 网络拓扑图先看一下整体架构： 核心思路很简单：机器B和机器C主动向机器A发起VPN连接，建立加密隧道后，三台机器就在同一个虚拟子网（如10.8.0.0/24）里了。 完整配置步骤第一步：机器A（服务端）配置在机器A上编辑OpenVPN服务端配置文件（通常是/etc/openvpn/server.conf）： 12# 开启客户端之间互访client-to-client 如果机器B和机器C各自还有自己的内网子网需要互通（比如机器B后面还连着一个192.168.1.0/24的局域网），还需要在服务端配置中添加路由推送： 123# 推送路由给所有客户端push "route 192.168.1.0...

为什么选择 Keycloak？ 特性 Keycloak 开箱即用 OAuth2/OIDC/SAML 全支持 单点登录 原生支持 SSO 社交登录 微信/GitHub/Google 等开箱即用 用户管理 完整的管理控制台 企业认可度 Red Hat 出品，大量企业使用 本文聚焦 Docker 环境下的 Keycloak 部署与日常运维。 一、快速部署1. 准备数据库Keycloak支持多种数据库，下面以MySQL数据库举例 123456789101112131415-- 1. 创建数据库（指定字符集为 utf8mb4，以支持 Emoji 等特殊字符）CREATE DATABASE IF NOT EXISTS keycloakCHARACTER SET utf8mb4COLLATE utf8mb4_unicode_ci;-- 2. 创建用户（如果用户已存在，会先删除再重建，请确保数据安全）DROP USER IF EXISTS 'keycloak'@'%';CREATE US...

身边不少朋友在搞开发测试时，习惯性把云服务器买最小配置——2C4G ，跑个 Nacos 或一堆微服务，内存分分钟见底。 然后呢？服务莫名其妙挂了，SSH 连不上，compactd 进程卡死 200 多秒……在内存受限的服务器环境下，swap 已然成了必备配置。 为什么测试环境更要开swap?1. 稳住系统，避免被“杀”与被“卡” 防 OOM Killer：内存耗尽时内核会随机“枪毙”进程，Swap 给了缓冲，优先换出不活跃数据，保住关键服务。 防 compactd 假死：内存极度紧张时内核会疯狂做内存压缩（导致 CPU 飙升、SSH 断连），Swap 能直接换出内存页，瞬间释放连续空间，告别卡死。 2. 把物理内存留给真正需要的应用 系统会自动将后台日志、不常用服务的冷数据挪到 Swap，腾出的 RAM 全给应用，让有限的内存用在刀刃上。 一键创建 2GB Swap（开发测试标配）123456789101112# 创建 2GB 文件并启用sudo fallocate -l 2G /swapfilesudo chmod 600 /swapfilesudo mkswap /s...

上周做Redis故障演练，主节点A宕机，从节点B升主。A恢复后，我本以为它会走增量同步——毕竟B的缓冲区足够大，A的偏移量也在范围内。但日志显示：全量同步。这是怎么回事？ 如果你也遇到过类似的现象，或者单纯好奇Redis主从复制在故障转移后到底怎么决策的——这篇文章就是为你写的。我们不背八股文，而是从这次排查经历出发，把背后的设计逻辑彻底理清楚。 先理解核心问题：主从复制到底在解决什么？Redis的主从复制，本质上是在多节点之间保持数据一致。一个主节点负责写，多个从节点复制主节点的数据，提供读服务或作为容灾备份。 但复制不是一次性的，它面临两个核心挑战： 网络闪断：从节点和主节点断开几秒又重连，难道要全量同步吗？ 故障转移：主节点挂了，从节点升为新主，其他从节点怎么同步？旧主恢复后又怎么处理？ 这两个问题，引出了Redis复制机制中最核心的两个概念——复制ID（Replication ID） 和复制偏移量（Replication Offset）。 复制ID和偏移量：数据历史的身份证和页码复制偏移量：精确记录同步进度偏移量是一个不断递增的字节数，代表复制流中已发送的数据位置。 ...

这大概是 Redis 面试里最常见的一道“送命题”。 面试官问：“Redis 怎么持久化？” 你心里一喜，这题我背过：“RDB 和 AOF，RDB 是做快照的，AOF 是记录命令的，两个可以一起用。” 面试官点点头，追问道：“那 RDB 的 fork 具体是怎么工作的？会不会阻塞主线程？AOF 的刷盘策略有哪几种，AOF日志重写流程是怎样的，7.0 前后有什么变化？” 空气突然安静。 如果你也有过类似的经历，或者正在为这样的场景做准备，这篇文章就是为你写的。我们不背八股文，而是把 Redis 持久化的底层逻辑从头梳理一遍——搞懂原理，自然不怕追问。 为什么要有持久化？先理解问题本身Redis 是一款内存数据库，数据主要存放在内存中，读写速度极快。但内存有一个致命的弱点：一旦进程退出、服务器断电或系统崩溃，内存中的数据就会全部消失。 持久化要解决的问题，本质上就是：如何在性能和数据安全之间找到一个可接受的平衡点。 Redis 提供了两种核心持久化手段——RDB 和 AOF，以及它们的组合方式。接下来，我们逐一拆解。 RDB：一次全量快照什么是 RDB？RDB（Redis Datab...

提到 Redis，大多数开发者的第一反应是缓存、分布式锁、或者消息队列。但你可能不知道是，这个陪伴了我们很多年的老朋友，如今已经在向量数据库的赛道上一路狂奔——不仅跑得快，还跑得相当稳。 什么是向量检索？传统搜索依托字面匹配逻辑：当输入“苹果”进行检索时，系统仅能定位到包含“苹果”二字的文档，若文本涉及“iPhone”或泛指水果，便无法被检索到。与之不同，向量检索采用语义匹配机制，它能够洞察“苹果”与“iPhone”在特定语境下的关联性，即便文本中未出现“苹果”一词，也能精准挖掘出相关内容。 计算机无法直接理解人类的语言或图像，其运算基础仅为数字。因此，向量检索的首要环节，便是将现实世界的事物转化为一组数字序列，即向量。例如，模型会将“狗”转化为由数百个小数构成的向量[0.5, 0.8, -0.2, ...]，将“猫”转化为[0.6, 0.7, -0.1, ...]。 在计算机的视角里，每一个向量都是高维空间中的一个坐标点。语义相似的内容，点与点之间就离得近；语义无关的，就离得远。向量检索要做的，就是在这个庞大的坐标地图上，快速找出离目标点最近的几个邻居。 当用户检索“小狗”时，...

为什么选择 OpenVPN？ 特性 OpenVPN WireGuard 成熟度 20+ 年历史，久经考验 较新，生态还在完善 防火墙穿透 TCP 模式几乎 100% 穿透 UDP 可能被拦截 客户端支持 Windows/macOS/Linux/手机 同样支持 企业认可度 高，很多企业 IT 标配 新项目首选 本文聚焦 Docker 环境下的 OpenVPN 部署与日常运维。 一、快速部署1. 目录结构123456service/openvpn/├── compose.yml          # Docker Compose 配置└── openvpn-data/        # OpenVPN 数据目录（自动生成）    ├── server/          # 服务端配置    └── clients/         # 客户端配置文件 2. Docker Compose 配置123456789101112131415161718services:    openvpn:        image: hwdsl...

日志管理，是每一位后端开发者和运维工程师都绕不开的必修课。今天，我们就来聊聊Nginx 日志管理的最佳实践——logrotate。 为什么 logrotate 是业界标准？在众多日志管理方案中，logrotate 之所以能成为最主流、最推荐的选择，主要得益于以下几点： 稳定可靠：logrotate 是 Linux 系统自带的日志轮转工具，经过几十年的生产环境考验，成熟度极高，能自动完成切割、压缩和清理的全流程。 无性能损耗：与某些基于 Nginx 第三方模块或脚本的方案不同，logrotate 在日志轮转时对 Nginx 的请求处理不产生额外计算开销。 配置灵活：可以精细控制轮转周期、保留份数、是否压缩、权限设置等，满足各种运维需求。 核心配置详解在主机的 /etc/logrotate.d/ 目录下为 Nginx 日志创建配置文件（如 /etc/logrotate.d/nginx）。配置生效后，系统的 cron 服务会每日自动触发 logrotate 运行，实现全程无人值守。 1234567891011121314/var/log/nginx/*.log { ...

Trojan是一款比较流行的代理工具，支持代理流量和伪装网站共用443端口，不支持搭配CDN使用。 Trojan可以将科学上网流量伪装为HTTPS网页浏览，相比Shadowsocks/SSR/V2ray等其它工具，Trojan因为有真实的网页做为掩护，因此伪装效果更好，更不容易被封锁。从这一点来说，Trojan与V2ray的WS+TLS模式非常相似，两者的使用效果也很接近。 Trojan的优点： 使用TLS协议加密，安全性有保证。 使用真实网站伪装流量，不容易被封锁。 由于被认为是网站流量，基本不会被QOS限速，科学上网速度更快、更稳定。 由于Trojan的开发目的很明确，所以参数更少，配置更简单。 Trojan的不足： 出于实现原理，Troian的搭建，需要购买一个域名指向伪装网站。 需要在VPS服务器建立一个伪装网站并申请SSL证书。 ⚠说明以下内容仅作为技术学习，请科学上网 准备工作 一台境外 VPS：并已安装 Ubuntu 20.04 / 22.04 等 Linux 系统，拥有 root 权限 一个域名：并将域名的 A ...

做业务开发时，我们经常遇到这类需求： ✅ 同城筛选附近门店、外卖骑手匹配✅ 社交APP附近的人、同城动态✅ 网约车就近派单、地理位置打卡 面对这些地理位置检索场景，无需引入笨重的专业GIS引擎，Redis自带的GEO地理空间索引是一个轻量、高性能的方案。 Redis GeoRedis Geo 没有创造新结构，完全基于有序集合 Sorted Set（ZSet）实现，底层核心组合：GeoHash 编码 + Sorted Set 索引。简单来说就是：把二维的经纬度坐标，通过算法压缩成一维整数分值，利用ZSet天然的排序、范围检索能力，实现高效的地理位置查询。 Key：地理集合名（如 stores:location 门店位置集合） Member：位置唯一标识（店铺ID、用户ID、设备ID） Score：经纬度编码后的52位GeoHash整数（排序、检索的核心） GeoHash 编码GeoHash的核心价值：将二维经纬度，转化为可排序、可比对的一维字符串。相近的地理位置，会拥有高度相似的编码前缀，这也是“附近查询”能够高效实现的根本原因。 GeoHash编码流程： 区间划分：针对地球...