2023年Q2用戶偏好榜：12+256G版本成新主流
3月份的性能榜、性價比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機潮已經過去，最明顯的肯定就是大內存和存儲的機型了，另外部分中端機也取消了屏幕塑料支架
如果你正在運行一個服務器，假設服務器需要從磁盤讀取一些文件，比如證書或密鑰。證書經常會發生變化，因此你的服務器必須重新加載它們。如何告訴服務器重新加載這些文件？
傳統的方法是使用Unix信號，你的服務器偵聽特定的信號，如SIGUSR1(用戶定義的信號#1)或SIGHUP(掛起信號)，并且可以在接收到信號時執行你編寫的任何代碼。因此，你的服務器等待適當的信號，接收它，然后重新加載證書。
這種方法工作得很好，但是在實際應用中出現了一些可用性的問題。使用單獨的一個http服務器來處理信號會更好。
下面我們先來看一下使用Unix信號的例子，然后我們使用服務器處理信號來改進這個例子。
首先，我們先創建一個Rust項目：
cargo new signals-servers在Cargo.toml文件中加入以下依賴項：
[dependencies]axum = "0.7.2"tokio = { version = "1.25.0", features = ["macros", "rt-multi-thread", "signal"] }在項目根目錄下創建一個cert.pem文件，內容隨便寫，只是為了演示。
我們看一個完整的服務器偵聽信號的示例，當你啟動你的服務器時，也啟動一個異步任務(或進程，或線程)來監聽這個信號，當接收到信號時，重新加載證書。
創建一個src/bin/unix_signal.rs文件，代碼如下：
use axum::{routing::get, Router};use std::process;use tokio::signal::unix::{signal, SignalKind};#[tokio::main]async fn main() { let _cert = std::fs::read_to_string("cert.pem"); println!("已加載證書，正在啟動web服務器"); println!("PID: {}", process::id()); tokio::select! { _ = start_normal_server(8080) => { println!("Web服務器關閉") } _ = listen_for_reload(SignalKind::hangup()) => { println!("信號監聽器停止") } }}async fn start_normal_server(port: u32) { // 構建我們的應用程序 let app = Router::new().route("/hello", get(|| async { "Hello, world!" })); let addr = format!("127.0.0.1:{port}"); let listener = tokio::net::TcpListener::bind(addr).await.unwrap(); axum::serve(listener, app).await.unwrap();}async fn listen_for_reload(signal_kind: SignalKind) -> Result<(), std::io::Error> { // 監聽信號 let mut stream = signal(signal_kind)?; loop { stream.recv().await; match std::fs::read_to_string("cert.pem") { Ok(_) => eprintln!("重新加載證書成功"), Err(e) => eprintln!("無法重新加載證書: {e}"), } }}運行如下命令啟動服務器：
cargo run --bin unix_signal已加載證書，正在啟動web服務器PID: 41945然后打開一個新的終端，輸入以下命令：
kill -s sighup 41945這是服務器的日志如下：
已加載證書，正在啟動web服務器PID: 41945重新加載證書成功這是可行的，但對于發送信號的人來說，這不是一個很好的用戶體驗。假設你是SRE或系統管理員，當需要重新加載服務器證書時，首先查找進程的PID，并使用kill -s sighup pid發送信號。
服務器可能重新加載了，但也許它沒有，可能出現了錯誤，例如新證書無效，或者服務器沒有讀取新證書的權限。系統管理員如何知道是否發生了這種情況？他們應該檢查一下服務器的日志，但這需要切換窗口，或者打開一個不同的程序。
這不是一個很好的用戶體驗。通常，當你運行命令時，希望得到一些反饋。但是當你發送Unix信號時，終端不會給你任何響應。你必須查找服務器的日志并檢查它們，以確保重新加載成功完成。閱讀一個不熟悉的程序日志是很困難的，特別是當日志中有很多其他錯誤時。
Unix信號的主要問題是，它們讓用戶向進程發出信號，但程序不向用戶發送響應。
因此，我們希望進程接受請求(“重新加載您的證書”)，并響應(“是的，它成功了”或“它失敗了，原因如下”)。這聽起來很熟悉——它只是一個普通的請求-響應協議。沒有必要重新發明輪子——我們可以在這個過程中啟動第二個小HTTP服務器。
創建一個src/bin/http_signal.rs文件，代碼如下：
use axum::{ http::StatusCode, response::IntoResponse, routing::{get, post}, Router,};#[tokio::main]async fn main() { let _cert = std::fs::read_to_string("cert.pem"); println!("已加載證書，正在啟動web服務器"); tokio::select! { _ = start_normal_server(8080) => { println!("Web服務器關閉") } _ = start_control_server(3000) => { println!("信號服務器關閉") } }}async fn start_normal_server(port: u32) { // 構建我們的應用程序 let app = Router::new().route("/hello", get(|| async { "Hello, world!" })); let addr = format!("127.0.0.1:{port}"); let listener = tokio::net::TcpListener::bind(addr).await.unwrap(); axum::serve(listener, app).await.unwrap();}async fn start_control_server(port: u32) { // 構建信號控制服務器 let app: Router = Router::new().route( "/reload_certs", post(|| async { println!("重新加載證書"); match std::fs::read_to_string("cert.pem") { Ok(_) => "重新加載證書成功".into_response(), Err(e) => { let error = format!("無法重新加載證書: {e}"); eprintln!("{error}"); let resp = (StatusCode::INTERNAL_SERVER_ERROR, error); resp.into_response() } } }), ); let addr = format!("127.0.0.1:{port}"); let listener = tokio::net::TcpListener::bind(addr).await.unwrap(); axum::serve(listener, app).await.unwrap();}對于SRE或系統管理員來說，這是一個更好的用戶體驗。使用如下命令重新加載證書：
$ curl -X POST 0.0.0.0:3000/reload_certs重新加載證書成功%如果沒有找到證書，會立即得到有關錯誤的反饋：
$ curl -X POST 0.0.0.0:3000/reload_certs無法重新加載證書: No such file or directory (os error 2)如果你的程序不需要HTTP或網絡，那么引入一個完整的HTTP框架來監聽信號可能有點多余。因此，根據程序的大小，以及系統管理員的需求或SRE團隊的大小，來決定是否添加HTTP服務器，因為這對于管理流程的人員和軟件來說，它有更好的用戶體驗。
本文鏈接：http://m.www897cc.com/showinfo-26-80844-0.htmlRust中的信號處理：Unix信號 vs 信號服務器
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： 我們一起聊聊如何三分鐘學會異步任務基礎
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號