Rust + PostgreSQL 极简技术栈应用开发

文章目录Rust PostgreSQL 极简技术栈应用开发核心思路环境准备初始化项目与依赖PostgreSQL 扩展安装初始化代码模块一替代缓存新建业务表与物化视图缓存刷新Axum 接口调用缓存模块二替代消息队列队列表设计生产者发送消息消费者处理消息模块三替代搜索中间件搜索表与索引设计Axum 搜索接口实现架构优势与局限总结Rust PostgreSQL 极简技术栈应用开发在中小规模后端开发场景中我们常常会不自觉地陷入中间件堆砌的困境即便业务逻辑并不复杂、并发量也未达到需要多中间件分流的程度依然会习惯性地引入各类第三方中间件用Redis 来缓存热点数据、RabbitMQ 来处理异步任务等等。这种堆砌现象除了部分开发者对架构完善的认知偏差更多时候还带有明显的面向面试编程成分很多开发者在学习和实践中过度侧重面试高频考点盲目照搬大厂高并发场景下的架构方案却忽略了中小团队、独立开发者的核心需求简洁、可靠、易维护、低成本。最终导致项目部署复杂、维护成本飙升排查问题时需要跨多个中间件定位反而降低了开发效率和系统稳定性。本文将实操演示如何用 PostgreSQL 替代缓存、消息队列、搜索、分布式锁等常用中间件基于 Axum SQLx PostgreSQL 技术栈打造极简且可靠的后端架构适合中小团队、独立开发者快速落地。核心思路摒弃一个场景一个中间件的传统思路利用 PostgreSQL 的以下特性替代对应中间件缓存利用 PostgreSQL 的 Buffer Cache 机制 pg_prewarm 扩展预热缓存配合物化视图实现结果缓存替代 Redis 轻量级缓存场景。消息队列用 PostgreSQL 表模拟队列结合SELECT FOR UPDATE SKIP LOCKED实现并发安全消费搭配 pg_notify 实现消息通知替代 RabbitMQ 轻量级队列场景。搜索利用 PostgreSQL 内置的全文搜索功能tsvector tsquery配合全文索引替代 Elasticsearch 等轻量级搜索中间件。分布式锁借助 PostgreSQL 的 pg_advisory_lock 函数或表级锁实现分布式锁替代 Redis 分布式锁。这种架构的优势的是所有的操作都围绕 PostgreSQL 展开无需跨组件同步数据依托 PostgreSQL 的 ACID 事务保障数据一致性同时减少中间件部署和维护成本。环境准备初始化项目与依赖使用 Cargo 新建项目cargonew rust-postgres-democdrust-postgres-demo在Cargo.toml中添加上依赖[dependencies] axum { version 0.8, features [json] } sqlx { version 0.8, features [ runtime-tokio-rustls, postgres, uuid, chrono, json, migrate, ] } tokio { version 1, features [full] } anyhow 1.0 chrono { version 0.4, features [serde] } uuid { version 1, features [serde, v4] } serde { version 1.0, features [derive] } serde_json 1.0 dotenvy 0.15PostgreSQL 扩展安装在这次项目中我们需要用到以下几个扩展执行以下 SQL 命令需超级用户权限-- 用于生成 UUIDCREATEEXTENSIONIFNOTEXISTSuuid-ossp;-- 用于缓存预热将表数据加载到 Buffer CacheCREATEEXTENSIONIFNOTEXISTSpg_prewarm;-- 用于查看缓存状态CREATEEXTENSIONIFNOTEXISTSpg_buffercache;初始化代码在根目录创建.env文件并配置数据库连接地址DATABASE_URLpostgres://postgres:passwordlocalhost:5432/rust-postgres-demo编辑src/main.rsuseanyhow::Result;useaxum::Router;usesqlx::PgPool;usesqlx::postgres::PgPoolOptions;usestd::time::Duration;#[derive(Clone)]structAppState{pool:PgPool,// 业务连接池}// 初始化全局状态asyncfninit_app_state()-ResultAppState{letdatabase_urlstd::env::var(DATABASE_URL).expect(DATABASE_URL must be set);letpoolArc::new(init_pg_pool(database_url).await?);Ok(AppState{pool})}// 初始化 PostgreSQL 连接池asyncfninit_pg_pool(database_url:str)-ResultPgPool{letpoolPgPoolOptions::new().max_connections(20)// 最大连接数根据业务并发量调整.min_connections(5)// 最小空闲连接保障业务响应速度.acquire_timeout(Duration::from_secs(3))// 连接获取超时避免业务阻塞.idle_timeout(Duration::from_secs(600))// 空闲连接超时释放闲置资源.connect(database_url).await?;Ok(pool)}#[tokio::main]asyncfnmain()-Result(){dotenvy::dotenv().ok();letapp_stateinit_app_state().await?;letappRouter::new().with_state(app_state);letlistenertokio::net::TcpListener::bind(0.0.0.0:3000).await?;axum::serve(listener,app).await?;Ok(())}模块一替代缓存对于传统缓存场景如热点数据查询、接口结果缓存可以直接使用 PostgreSQL 的 Buffer Cache 和物化视图即可实现配合 pg_prewarm 预热缓存。PostgreSQL 的 Buffer Cache 是服务器共享内存中的核心组件用于存储关系页平衡磁盘毫秒级和内存纳秒级的访问时间只要数据页被缓存后续访问无需磁盘操作性能极高。我们可以通过 pg_prewarm 扩展主动将热点表加载到 Buffer Cache再用物化视图存储复杂查询的结果避免重复计算。新建业务表与物化视图-- 用户表核心业务表CREATETABLEIFNOTEXISTSusers(id UUIDPRIMARYKEYDEFAULTuuid_generate_v4(),usernameVARCHAR(50)NOTNULLUNIQUE,emailVARCHAR(100)NOTNULLUNIQUE,created_at TIMESTAMPTZNOTNULLDEFAULTNOW(),updated_at TIMESTAMPTZNOTNULLDEFAULTNOW());-- 物化视图缓存用户列表结果CREATEMATERIALIZEDVIEWIFNOTEXISTSmv_user_listASSELECTid,username,emailFROMusersORDERBYcreated_atDESC;-- 为物化视图创建索引提升查询性能CREATEINDEXIFNOTEXISTSidx_mv_user_list_idONmv_user_list(id);PostgreSQL 的物化视图Materialized View和普通视图View的核心区别在于数据存储与更新机制普通视图是虚拟的不存储数据每次查询动态计算物化视图实际存储查询结果像表一样占用磁盘空间需手动刷新以同步数据。物化视图适合需要快速读取复杂查询结果的场景用空间换时间而普通视图保证了实时性。缓存刷新缓存预热、定时刷新属于后台任务你可以使用 crontab 定时触发也可以手动触发// 缓存预热将物化视图加载到 Buffer Cacheasyncfnwarm_up_cache(pool:PgPool)-Result(){sqlx::query!(SELECT pg_prewarm(mv_user_list::regclass, buffer)).fetch_one(pool).await?;Ok(())}// 刷新物化视图手动触发asyncfnrefresh_user_cache(pool:PgPool)-Result(){sqlx::query!(REFRESH MATERIALIZED VIEW mv_user_list).execute(pool).await?;Ok(())}Axum 接口调用缓存接口查询属于核心业务使用业务连接池保障接口响应速度useaxum::{Json,extract::State};useserde::Serialize;// 定义用户响应结构体#[derive(Serialize, sqlx::FromRow)]structUserDto{id:uuid::Uuid,username:String,email:String,}// 接口查询用户列表从缓存中获取asyncfnget_user_list(State(state):StateAppState)-ResultJsonVecUserDto,axum::Error{letuserssqlx::query_as!(UserDto,r# SELECT id as id!, username as username!, email as email! FROM mv_user_list LIMIT 20 #).fetch_all(state.pool).await.map_err(|e|axum::Error::new(e))?;Ok(Json(users))}模块二替代消息队列轻量级消息队列场景比如异步通知、任务分发用 PostgreSQL 表模拟队列结合SELECT FOR UPDATE SKIP LOCKED实现并发安全消费搭配 pg_notify 实现消息实时通知队列表设计-- 消息队列表CREATETABLEIFNOTEXISTSmessage_queue(id UUIDPRIMARYKEYDEFAULTuuid_generate_v4(),queue_nameVARCHAR(50)NOTNULL,-- 队列名称支持多队列payload JSONBNOTNULL,-- 消息内容JSON 格式适配各类消息statusVARCHAR(20)NOTNULLDEFAULTpending,-- 消息状态pending/processing/completed/failedretry_countINTNOTNULLDEFAULT0,-- 重试次数created_at TIMESTAMPTZNOTNULLDEFAULTNOW(),updated_at TIMESTAMPTZNOTNULLDEFAULTNOW());-- 索引提升消息查询、消费效率CREATEINDEXIFNOTEXISTSidx_queue_name_statusONmessage_queue(queue_name,status);生产者发送消息消息发送属于接口业务使用业务连接池保障接口响应速度// 消息请求结构体#[derive(Deserialize)]structSendMessageRequest{queue_name:String,payload:serde_json::Value,}// 接口发送消息生产者asyncfnsend_message(State(state):StateAppState,Json(req):JsonSendMessageRequest,)-ResultJsonuuid::Uuid,axum::Error{// 插入消息到队列表letmessagesqlx::query!(r# INSERT INTO message_queue (queue_name, payload) VALUES ($1, $2) RETURNING id #,req.queue_name,req.payload).fetch_one(state.pool).await.map_err(|e|axum::Error::new(e))?;// 发送 pg_notify 通知告知消费者有新消息sqlx::query!(SELECT pg_notify($1, $2),req.queue_name,// 通知通道与队列名称一致message.id.to_string()// 消息 ID作为 payload).fetch_one(state.pool).await.map_err(|e|axum::Error::new(e))?;Ok(Json(message.id))}消费者处理消息消息消费属于核心业务异步处理使用业务连接池确保与业务数据操作的一致性usesqlx::postgres::PgListener;// 消息处理函数可根据业务自定义asyncfnhandle_message(payload:serde_json::Value)-Result(){// 模拟消息处理打印消息内容println!(处理消息{},serde_json::to_string(payload)?);// 实际业务发送邮件、异步更新数据等Ok(())}// 消费者监听队列处理消息asyncfnmessage_consumer(state:AppState,queue_name:String)-Result(){// 创建 PgListener监听指定通道letmutlistenerPgListener::connect_with(state.pool).await?;listener.listen(queue_name).await?;println!(消费者已启动监听队列{},queue_name);// 循环监听通知loop{matchlistener.recv().await{Ok(notification){// 解析消息 ID获取消息详情letmessage_idnotification.payload().parse::uuid::Uuid()?;letmuttxstate.pool.begin().await?;// 锁定消息SKIP LOCKED 避免锁竞争标记为 processingletmessagesqlx::query!(r# SELECT id, payload FROM message_queue WHERE id $1 AND status pending FOR UPDATE SKIP LOCKED #,message_id).fetch_optional(mut*tx).await?;ifletSome(msg)message{// 处理消息matchhandle_message(msg.payload).await{Ok(_){// 处理成功标记为 completedsqlx::query!(UPDATE message_queue SET status completed, updated_at NOW() WHERE id $1,msg.id).execute(mut*tx).await?;}Err(e){// 处理失败重试次数1超过3次标记为 failedsqlx::query!(r# UPDATE message_queue SET retry_count retry_count 1, status CASE WHEN retry_count 1 3 THEN failed ELSE pending END, updated_at NOW() WHERE id $1 #,msg.id).execute(mut*tx).await?;eprintln!(处理消息 {} 失败{},msg.id,e);}}}tx.commit().await?;}Err(e){eprintln!(监听队列 {} 失败{},queue_name,e);// 重试监听tokio::time::sleep(Duration::from_secs(3)).await;listener.listen(queue_name).await?;}}}}模块三替代搜索中间件轻量级搜索场景如文章搜索、商品搜索无需部署 Elasticsearch利用 PostgreSQL 内置的全文搜索功能tsvector tsquery配合全文索引即可实现高效的关键词搜索、模糊搜索满足中小规模搜索需求。搜索表与索引设计以文章搜索为例设计文章表添加全文搜索字段和索引-- 文章表需要搜索的核心表CREATETABLEIFNOTEXISTSarticles(id UUIDPRIMARYKEYDEFAULTuuid_generate_v4(),titleVARCHAR(200)NOTNULL,-- 文章标题contentTEXTNOTNULL,-- 文章内容author_id UUIDNOTNULLREFERENCESusers(id),-- 关联作者created_at TIMESTAMPTZNOTNULLDEFAULTNOW(),updated_at TIMESTAMPTZNOTNULLDEFAULTNOW(),-- 全文搜索向量字段存储 title content 的分词结果search_vector tsvector GENERATED ALWAYSAS(to_tsvector(english,title|| ||content))STORED-- 自动生成并存储避免每次查询重新计算);-- 创建全文索引提升搜索性能CREATEINDEXIFNOTEXISTSidx_articles_searchONarticlesUSINGGIN(search_vector);to_tsvector(english, ...)用于英文分词中文分词需要安装pg_jieba扩展然后替换为to_tsvector(jieba, ...)。Axum 搜索接口实现useserde::Deserialize;usechrono::{DateTime,Utc};// 搜索请求结构体#[derive(Deserialize)]structSearchRequest{keyword:String,// 搜索关键词page:u32,// 页码page_size:u32,// 每页条数}// 文章搜索响应结构体#[derive(Serialize, sqlx::FromRow)]structArticleSearchDto{id:uuid::Uuid,title:String,content:String,author_id:uuid::Uuid,created_at:DateTimeUtc,match_score:Optionf32,// 匹配度分数}// 接口文章全文搜索使用业务连接池asyncfnsearch_articles(State(state):StateAppState,Json(req):JsonSearchRequest,)-ResultJsonVecArticleSearchDto,axum::Error{letoffset(req.page-1)*req.page_size;// 将搜索关键词转换为 tsquery支持模糊匹配:* 表示前缀匹配letqueryformat!({}:*,req.keyword);letarticlessqlx::query_as!(ArticleSearchDto,r# SELECT id, title, content, author_id, created_at, ts_rank(search_vector, to_tsquery(english, $1)) AS match_score FROM articles WHERE search_vector to_tsquery(english, $1) ORDER BY match_score DESC LIMIT $2 OFFSET $3 #,// 参数绑定query,req.page_sizeasi64,offsetasi64).fetch_all(state.pool).await.map_err(|e|axum::Error::new(e))?;Ok(Json(articles))}架构优势与局限这套架构的好处是降低运维成本摒弃 Redis、RabbitMQ、Elasticsearch 等中间件仅需部署 PostgreSQL减少服务器资源占用和维护成本尤其适合中小团队和独立开发者。而且性能足够支撑中小规模场景PostgreSQL 的 Buffer Cache、全文索引、advisory 锁性能能满足大部分中小规模业务的缓存、搜索等需求但这套架构的局限性也比较明显以下场景不建议使用高并发缓存场景如秒杀、高频访问的热点数据Redis 的单线程模型和内存操作性能优于 PostgreSQL。高吞吐量队列场景如每秒数万条消息的分发RabbitMQ、Kafka 的吞吐量和消息投递机制更适合。大规模复杂搜索场景如千万级数据量、多维度筛选、分词精度要求极高的场景Elasticsearch 的分布式搜索能力更有优势。总结对于中小规模后端项目、快速迭代的产品用 PostgreSQL 替代缓存、消息队列、定时器、搜索等中间件搭配 Axum SQLx 技术栈是一种性价比极高的架构选择。最后提醒技术选型没有绝对的优劣适合自己业务场景的才是最好的。如果你的项目是中小规模、对性能要求不极致不妨试试这种架构相信能给你带来不一样的开发体验。