1 个三级分类
三级分类
技术体系化整理、工程实践与开发笔记。
专题分组
1 个三级分类
三级分类
2 个三级分类
3 个三级分类
2 个三级分类
2 个三级分类
3 个三级分类
1 个三级分类
三级分类
围绕数据库主键 ID 的选型,内容从自增 ID、传统 UUID、雪花算法和 UUIDv7 四类方案展开,重点放在唯一性、顺序性、分布式适配和索引写入性能的取舍上。自增 ID 在单库单实例中简单、可读、范围查询友好,但会暴露业务增长、存在中心化生成瓶颈,并不适合多节点高并发场景。文章解释了聚簇索引和 B+Tree 的存储特性:主键顺序会影响数据物理组织,随机 UUID 作为主键容易造成页分裂、碎片化和更大的索引体积,因此更适合作为业务唯一标识而非数据库主键。雪花算法通过时间戳、机器 ID 和序列号组合实现趋势递增与高并发生成,但需要处理机器时钟回拨、节点配置和生命周期限制。UUIDv7 被作为重点方案分析,它用 48 bit 毫秒时间戳作为前缀,后缀保留随机熵,在保持标准 UUID 128 bit 格式和全局唯一性的同时,让插入更接近顺序写入,尤其适合 PostgreSQL 原生 uuid 类型存储。需要注意的是,同一毫秒内 UUIDv7 仍可能发生局部乱序,但影响通常远小于 UUIDv4;如果业务需要精确按时间筛选或频繁使用时间条件,仍建议保留 create_time 字段及索引。整体适合后端开发和数据库设计人员在单库、分布式、高并发写入等不同场景下评估主键策略。
这篇笔记面向 Elasticsearch 入门实践,围绕本地开发环境搭建、核心存储概念和中文检索示例展开。正文先给出基于 Docker 的 Elasticsearch 8.0.0 启动方式,说明 9200 REST API 端口、9300 节点通信端口、single-node 单节点模式以及关闭 xpack 安全验证的用途,并补充 Kibana 8.0.0 的安装和 5601 可视化访问入口。概念部分用 MySQL 作类比解释 index、document、field、mapping 的关系,强调 Elasticsearch 是面向文档的 NoSQL 数据库,文档以 JSON 存储,字段结构可以灵活变化,但业务上仍应让同一索引保存同类数据。文章还列出常见字段类型,包括 text、keyword、integer、date、boolean 等,并指出动态映射虽然方便,但手机号等关键字段若被默认识别为 text 可能不符合预期,因此需要提前通过 mapping 指定类型。示例部分创建 books 索引,配置 title、content 使用 standard 分词器、price 使用 integer,随后写入书籍文档,并通过 match 查询和 _analyze API 查看字段分词结果。最后,笔记指出标准分词器对中文通常只能得到较粗或不理想的效果,因此演示在 Docker 容器内安装 analysis-ik 插件、重启验证插件列表,并创建使用 ik_smart 的索引来改善中文文本检索体验。
数据库与缓存这篇笔记围绕用 Redis 列表实现一个轻量级消息队列展开,适合在不想引入 RabbitMQ、Kafka 等完整 MQ 组件时,用现有 Redis 承担简单异步任务分发。正文先补充 Redis 的基础定位:它是跨平台的 key-value 非关系型数据库,支持字符串、哈希、列表、集合、有序集合、Pub/Sub、Streams 等数据类型,并具备高性能、原子操作、持久化、主从复制和 Lua 脚本等能力。队列部分的关键在于利用 list 结构和阻塞弹出命令,生产者通过 Python 异步客户端将包含 answer_id、answer_data 的 JSON 任务 rpush 到队列,消费者则在 while True 循环中使用 blpop 阻塞等待任务、解析数据、调用 AI 生成逻辑并更新记录。文章还展示了一个基于 redis.asyncio、Django settings.REDIS_URL 和 asynccontextmanager 封装的 RedisClient,用于管理连接创建、复用和关闭。需要注意的是,这种方案需要自行编写并维护生产者、消费者、异常处理和进程运行方式,示例中生产者写入的 ai_report_task_queue 与消费者监听的 queue 并不一致,实际使用时必须统一队列名。读者可以从中获得 Redis 列表队列的最小实现思路,以及在简单后台任务、异步报告生成等场景下快速落地的基本代码结构。
这篇笔记围绕 FastAPI 项目中使用 SQLAlchemy 异步 ORM 与 PostgreSQL 时如何接入 Alembic 做数据库迁移展开,先说明 Alembic 通过迁移脚本和数据库中的 alembic_version 表来记录结构变更,并依靠 upgrade、downgrade 支持版本升级与回滚。配置部分重点放在 alembic.ini 的 script_location、初始化后生成的 env.py、versions 目录以及数据库连接地址,其中 env.py 需要手动接入项目配置、Base.metadata 和异步引擎,才能让 autogenerate 正确比对模型变化。文章给出一份异步迁移示例:加载项目根路径、读取 settings.DATABASE_URL、动态导入所有 models、使用 create_async_engine 和 connection.run_sync 执行在线迁移,同时在离线模式下生成 SQL。针对 FastAPI 与 Django 共用数据库的场景,示例通过 include_object 排除 django_session、auth_user、django_migrations 等 Django 相关表,避免 Alembic 误管理不属于当前服务的表结构。数据库层还记录了 DATABASE_URL 的拼接方式、Base 的作用、异步 Session 工厂以及 pool_size、max_overflow、pool_timeout、pool_recycle 等连接池参数。迁移命令部分覆盖 PYTHONPATH 设置、revision --autogenerate、upgrade head、history、upgrade/downgrade 指定版本和 downgrade base,并特别提醒迁移文件版本必须与数据库 alembic_version 对齐,新库初始化时不要混用旧版本文件。最后补充多环境迁移隔离思路,可通过不同 alembic 配置文件或在 env.py 中读取环境变量来切换版本目录,适合正在为异步 FastAPI 服务建立可控数据库版本管理流程的后端开发者参考。
消息队列这份笔记系统梳理 RocketMQ 的基础消息模型,先从 NameServer、Broker、Producer、Consumer 的分工讲起,说明 NameServer 只负责 Topic 到 Broker 的路由发现,真正的消息接收、磁盘存储与转发由 Broker 完成。文章重点拆解 Broker 内部组件,包括追加写入消息的 CommitLog、按 Topic-Queue 建索引的 ConsumeQueue、按 Key 查询历史消息的 IndexFile,以及刷盘检查点、主从同步和网络请求处理等配套能力。核心术语部分覆盖 Topic、MessageQueue、Queue ID、Offset、Tag、Key 等概念,帮助读者理解消息如何被路由、过滤、定位和记录消费进度。消息模式部分进一步区分 Pull 与基于长轮询的 Push 体验,并说明顺序消息需要将同一业务 Key 路由到同一队列且串行消费,而并行消费依赖多队列提升吞吐但不保证全局顺序。对于事务消息和延迟消息,文章给出半消息、本地事务回查、delayTimeLevel、延迟队列再投递等实现思路,同时提示延迟精度受预设级别限制。最后围绕消费可靠性解释重试次数、死信队列和 ACK 返回状态的关系,强调取到消息不等于消费成功,只有返回 CONSUME_SUCCESS 才会推进消费进度,异常或 RECONSUME_LATER 会触发重试直至进入 DLQ,适合后端开发者建立 RocketMQ 入门认知和排障框架。
消息队列这是一份面向 M1 Mac 本地用 Python 接入 RocketMQ 的环境配置与排错记录,核心问题是 rocketmq-client-python 依赖 RocketMQ C/C++ 动态库,而 Apache 官方 Darwin 包只提供 x86_64 版本,无法直接被原生 arm64 Python 加载。配置流程包括下载 rocketmq-client-cpp 2.0.0 的 darwin 压缩包,将头文件和 librocketmq.dylib 安装到 /usr/local/include/rocketmq 与 /usr/local/lib,并用 install_name_tool 修正动态库 ID,再通过 DYLD_LIBRARY_PATH 让 Python 能找到该 dylib。针对 M1 上常见的 incompatible architecture 报错,文章给出使用 Rosetta 启动 iTerm,并创建 CONDA_SUBDIR=osx-64 的 conda Python 3.10 环境来安装 rocketmq-client-python 的做法,验证重点是 platform.machine() 返回 x86_64 且能够导入 Producer。后半部分补充腾讯云 RocketMQ 的差异:NameServer 使用云厂商提供的专属地址,Topic 和 Group 必须先在控制台创建、授权,不支持像自建 Apache RocketMQ 那样自动创建 Topic。对于 No route info of this topic,排查路径集中在确认公网/私网地址是否匹配本地开发场景、Topic 队列是否正确绑定到当前集群 Broker、发送测试消息刷新 NameServer 路由缓存,以及用 telnet、ping 验证网络连通性。适合在 macOS Apple Silicon 上调试 RocketMQ Python SDK、同时接入腾讯云 RocketMQ 的后端开发者参考,尤其是需要区分架构兼容、动态库加载和云端路由配置三类问题时。
“消息队列”类别用于归档围绕消息中间件、异步通信和事件驱动协作展开的内容,重点承担站点内主题分流和检索定位的作用。该类别的说明强调,使用分类时应先判断文章是否真正讨论消息队列相关问题,而不是仅在业务流程中偶然出现消息发送或通知机制。其边界需要从使用理由、与既有分类的差异、常见话题范围以及是否应合并等维度来界定,以避免同一类内容分散到架构、后端开发或运维等相邻栏目中。适合纳入的内容通常应围绕消息队列的选型、使用场景、可靠性、消费模型、削峰解耦、配置实践或问题排查等方向展开。它的价值不在于给出某个具体队列产品的教程,而是为后续文章建立一致的归档准则,帮助作者和读者快速判断相关内容应放在哪里。对于维护技术知识库或博客分类体系的人来说,这类说明有助于减少重复分类、模糊归档和后期合并成本。
“数据库与缓存数据库”类别用于沉淀与数据存储、缓存型数据系统及其使用边界相关的内容,其核心作用是为后续文章提供清晰的归类依据,而不只是作为一个宽泛标签存在。该类别强调分类准则:为什么需要单独收纳这类主题、它承担什么检索与组织功能,以及在已有分类之间如何避免交叉和重复。说明重点包括适用话题范围、与相邻类别的区别、是否应独立保留,以及在内容规模或主题重叠时是否可以合并为其他类别或子类别。对于博客维护者来说,它的价值在于帮助数据库和缓存相关笔记形成稳定的知识入口,使读者能更快判断文章是否属于数据层、存储层或缓存体系的讨论范围。该类别更适合作为内容架构和分类治理的依据,而不是具体数据库产品、配置教程或问题排查本身。
计算机知识这篇内容围绕 RTMP 协议在直播与流媒体链路中的作用展开,先说明它是 Adobe/Macromedia 设计的实时消息传输协议,运行在应用层并通常依赖 TCP 1935 端口提供可靠传输。文章把 RTMP 的使用价值放在直播场景中解释:推流端如 OBS 或推流 SDK 将音视频送入 SRS、Nginx-RTMP、Wowza 等服务器,服务器再面向观众侧转成 HTTP-FLV、HLS 或 WebRTC 等更适合播放和互动的协议。正文重点梳理了完整连接流程,从 TCP 三次握手、C0/C1/C2 与 S0/S1/S2 的 RTMP 握手,到 connect 指定 app、stream key 和认证信息,再到 createStream 获取 stream_id,最后通过 publish 或 play 进入推流、拉流阶段。数据传输部分强调 RTMP 通过 Chunk 分块与消息机制持续传递音频帧、视频帧和 metadata,并借助持久连接实现低延迟、多路复用和音视频同步。文章也补充了 RTMP URL 结构、RTMPT、RTMPS、RTMPE 等变体,以及 macOS 下可用 VLC、Live Stream Player 配合测试流地址进行验证。需要注意的是,浏览器端已不再原生适合播放 RTMP,因为 Flash 已被淘汰;同时 RTMP session 与底层 TCP 连接绑定,正常断开需经历 deleteStream、close 和 TCP 释放,异常断开或服务器踢出则会清理相关 stream。整体适合想理解直播推拉流入口协议、服务器接入流程和连接生命周期的后端、音视频与运维开发者。
Python 开发这是一篇围绕 Google Cloud Text-to-Speech 快速接入与一次性生成音频文件的实践记录,适合需要在 Python 服务中把文本转换为语音并落地为文件的开发者参考。文章先从 Google Cloud 控制台入口、价格信息和每月 100 万字符免费额度讲起,随后展示启用 TTS API、创建凭证、生成服务账号密钥、赋予权限并下载 JSON 文件的配置路径。代码部分没有直接读取本地密钥文件,而是把服务账号中的 project_id、private_key、client_email、token_uri 等字段拆入环境变量和配置类,再通过 service_account.Credentials.from_service_account_info 初始化 TextToSpeechClient。一次性合成 SDK 封装为异步 synthesize 方法,支持传入文本、输出路径、language_code、ssml_gender 和 audio_encoding,并用 asyncio.to_thread 调用同步的 synthesize_speech,再通过 aiofiles 写入 MP3、LINEAR16 或 OGG_OPUS 文件。示例还演示了生成 output.mp3 后衔接 MinIO 上传,适合需要把合成音频继续发布到对象存储或 CDN 的场景。文末补充了 TTS 参数含义和云端合成链路,包括文本规范化、音素与韵律预测、神经合成、编码封装等概念,帮助读者理解一次性返回 audio_content 背后的处理流程。