<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>非同步 on BenzHub</title><link>https://benzhub.github.io/tags/%E9%9D%9E%E5%90%8C%E6%AD%A5/</link><description>Recent content in 非同步 on BenzHub</description><generator>Hugo</generator><language>zh-TW</language><lastBuildDate>Tue, 01 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://benzhub.github.io/tags/%E9%9D%9E%E5%90%8C%E6%AD%A5/index.xml" rel="self" type="application/rss+xml"/><item><title>Workflows steps 深入:重試、sleep 與等待事件 | Cloudflare 完整教學</title><link>https://benzhub.github.io/post/cloudflare/032-workflows-steps/</link><pubDate>Tue, 01 Sep 2026 00:00:00 +0000</pubDate><guid>https://benzhub.github.io/post/cloudflare/032-workflows-steps/</guid><description>&lt;blockquote&gt;
&lt;p&gt;上一篇《&lt;strong&gt;Workflows 持久化執行入門&lt;/strong&gt;》,我們寫出了第一個 Workflow,學會用 &lt;code&gt;step.do(名稱, 函式)&lt;/code&gt; 把每個有副作用的動作包成一個持久化步驟。但那只是最基本的兩參數形式。真正讓 &lt;strong&gt;Cloudflare Workflows&lt;/strong&gt; 強大的,是 &lt;code&gt;step&lt;/code&gt; 的深水區:&lt;strong&gt;每一步要怎麼設定重試與指數退避?怎麼讓流程睡上七天卻完全不計費?怎麼暫停下來等待一個外部的人工審核事件?&lt;/strong&gt; 這一篇,我們就把 &lt;code&gt;step.do&lt;/code&gt;、&lt;code&gt;step.sleep&lt;/code&gt;、&lt;code&gt;step.waitForEvent&lt;/code&gt; 這三支 API 一次拆透,並釐清背後那條所有人都會踩的紅線——&lt;strong&gt;決定性(determinism)&lt;/strong&gt;。&lt;/p&gt;
&lt;/blockquote&gt;</description></item><item><title>Workflows 持久化執行入門:崩潰也不重來 | Cloudflare 完整教學</title><link>https://benzhub.github.io/post/cloudflare/031-workflows-intro/</link><pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate><guid>https://benzhub.github.io/post/cloudflare/031-workflows-intro/</guid><description>&lt;blockquote&gt;
&lt;p&gt;上一篇《&lt;strong&gt;Queues 批次、重試與 DLQ&lt;/strong&gt;》,我們把訊息佇列的容錯練到了生產級。但 Queues 有個天生的邊界:&lt;strong&gt;訊息即狀態,無法跨步驟保存進度,也不能睡眠等待&lt;/strong&gt;。當一件工作需要「&lt;strong&gt;跨越多個步驟、每步獨立保存結果、就算中途崩潰也能從斷點續跑&lt;/strong&gt;」時,你需要的是另一種更強的原語——&lt;strong&gt;Cloudflare Workflows&lt;/strong&gt; 提供的 &lt;strong&gt;durable execution(持久化執行)&lt;/strong&gt;。這一篇,我們就從零寫出第一個 Workflow,搞懂它為什麼「崩潰也不用重來」。&lt;/p&gt;
&lt;/blockquote&gt;</description></item><item><title>Queues 批次、重試與 DLQ:生產級容錯調校 | Cloudflare 完整教學</title><link>https://benzhub.github.io/post/cloudflare/030-queues-batch-retry-dlq/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate><guid>https://benzhub.github.io/post/cloudflare/030-queues-batch-retry-dlq/</guid><description>&lt;blockquote&gt;
&lt;p&gt;上一篇《&lt;strong&gt;Queues 訊息佇列入門&lt;/strong&gt;》,我們把 &lt;strong&gt;producer → queue → consumer&lt;/strong&gt; 的最小骨架搭了起來,學會用 &lt;code&gt;send()&lt;/code&gt; 送、用 &lt;code&gt;queue()&lt;/code&gt; handler 收。但那只是「能跑」;要在&lt;strong&gt;生產環境&lt;/strong&gt;穩穩扛住流量,你還需要三樣東西:懂得調&lt;strong&gt;批次(Batch)&lt;strong&gt;與&lt;/strong&gt;併發(Concurrency)&lt;strong&gt;來平衡吞吐與延遲、用&lt;/strong&gt;指數退避(Exponential Backoff)&lt;strong&gt;聰明重試、以及設一張接住失敗訊息的安全網——&lt;strong&gt;Dead Letter Queue(DLQ,死信佇列)&lt;/strong&gt;。這一篇,我們就把這些&lt;/strong&gt;容錯&lt;/strong&gt;能力一次補齊。&lt;/p&gt;
&lt;/blockquote&gt;</description></item><item><title>Queues 訊息佇列入門:Worker 非同步解耦第一步 | Cloudflare 完整教學</title><link>https://benzhub.github.io/post/cloudflare/029-queues-intro/</link><pubDate>Sat, 29 Aug 2026 00:00:00 +0000</pubDate><guid>https://benzhub.github.io/post/cloudflare/029-queues-intro/</guid><description>&lt;blockquote&gt;
&lt;p&gt;上一篇《&lt;strong&gt;DO 實戰:多人協作&lt;/strong&gt;》,我們把 &lt;strong&gt;Durable Objects&lt;/strong&gt; 的所有積木串成一個完整的即時系統,替「儲存資料」這條主線收了尾。這一篇,我們正式踏進&lt;strong&gt;非同步與工作流&lt;/strong&gt;的新章節:當一個請求要做的事太重、或有大量彼此獨立的背景工作要跑時,同步處理會拖垮回應速度。&lt;strong&gt;Cloudflare Queues&lt;/strong&gt; 就是那個「削峰填谷」的緩衝機制——它讓你的 &lt;strong&gt;Worker&lt;/strong&gt; 學會把耗時工作丟進&lt;strong&gt;訊息佇列(Message Queue)&lt;/strong&gt;,再由獨立的 &lt;strong&gt;consumer&lt;/strong&gt; 非同步批次消化,producer 與 consumer 徹底&lt;strong&gt;解耦&lt;/strong&gt;,又快又穩。&lt;/p&gt;
&lt;/blockquote&gt;</description></item></channel></rss>