"Rabbitmq"
- RabbitMQ → Kafka：從『處理即承諾』到『寫入即承諾 + 可 replay』的 paradigm shift
RabbitMQ 跟 Kafka 不是同類產品（work queue vs event streaming log）、把 work queue 直接搬成 topic 會踩 paradigm 落差；本文先跑 6 維 diff dimension audit（paradigm 跟 data topology 差最大）、釐清什麼 workload 真該遷什麼不該、再展開 application 重設計的 5 個踩雷（manual ack 觀念帶到 offset commit / routing key → partition key 的 ordering 邊界 / DLX → 自建 DLQ topic / prefetch → max.poll.records / 即刪 vs retention 的 replay 差異）、以及 dual-write / shadow consume 漸進 cutover 與長期混合架構
- RabbitMQ DLQ 與分層 retry：別把失敗訊息 requeue 回隊首
RabbitMQ 處理失敗訊息最常見的錯是直接 requeue 回原隊列——它回到隊首、反覆失敗、把後面的訊息全卡住（head-of-line blocking）。正解是用 dead-letter exchange + TTL 組出 work → delay → DLQ 的分層 escalation。本文展開 DLX 求值模型、實機驗證的三層拓樸、5 個把 retry 寫成無限迴圈與隊列阻塞的 production 踩坑，以及 retry 拓樸的容量邊界
- RabbitMQ → AWS SQS：交出 broker 維運、把 routing 收斂進 application
自管 RabbitMQ 叢集遷到 AWS SQS 是 operational redesign：protocol 不相容、application 要從 manual ack 改成 visibility timeout + delete、exchange routing 收斂成 SNS fan-out 或多 queue；本文跑 6 維 diff dimension audit（operational 差最大）、釐清什麼該遷什麼不該遷、5 個 production 故障演練（DLX → redrive policy / prefetch → batch + visibility / fan-out → SNS-to-SQS / 256KB 大小限制 / ordering 到 FIFO 的吞吐取捨）跟漸進 cutover
- RabbitMQ Queue Type 選型：Classic、Quorum、Stream 的責任邊界與容量取捨
RabbitMQ 3.x 三種 queue type 的選型 deep article — classic queue（mirrored 已 deprecated）、quorum queue（Raft 一致性、取代 mirrored）、stream（3.9+ append-only log、可重複消費）。涵蓋三種模型在 throughput / retention / replay / 記憶體成本的判讀、宣告語意差異（實機驗證）、4 個 production 故障演練（mirrored 網路放大 / quorum loss / stream retention 超量 / classic→quorum in-flight message），與容量規劃。
- RabbitMQ Network Partition 與 Cluster 一致性：腦裂下要保誰
RabbitMQ Erlang cluster 在 network partition 下的行為與處置 — disc/ram node 拓樸、cluster_partition_handling 三策略（ignore / pause_minority / autoheal）的可用性與一致性取捨、腦裂偵測機制、quorum queue 在失去 quorum 時的 Raft 行為。含 3-node OrbStack 實機演練（pause_minority 暫停少數派、quorum queue 失去 quorum 後寫入阻塞、classic queue 同情境續寫對照）。
- 3.C23 Bloomberg：多租戶 vhost + 自助平台化
Bloomberg 從幾個團隊推到上百個團隊、靠自助 vhost 註冊跟專用叢集分離應用與 broker。
- 3.C24 SoundCloud：AMQP fan-out 音訊處理 pipeline
SoundCloud 每秒 20-30K persistent message、不同處理類型分開隊列、各自獨立 scale。
- 3.C25 Indeed：Delay queue + DLQ 三層 escalation
Indeed 每天 35M+ 職缺、設計 Requeue → Delay queue → DLQ 三層 escalation 避開 head-of-line blocking。
- 3.C26 GoCardless：Hutch + 單一 topic exchange service mesh
GoCardless 單一 RabbitMQ cluster 作所有 service 通訊中樞、routing key 用 service.subject.action 格式、JSON 多語言可讀。
- 3.C27 Zalando：RabbitMQ on AWS 自動化 master selection
Zalando 用 sidekick 服務查 AWS API 動態識別 cluster、指定最老 instance 當 master、跨版本升級用 federation 過渡。
- 3.C28 WeWork：Consistent hash exchange 保證帳戶順序
WeWork 固定數量 queue + account ID hash 路由、每 queue 一個 worker + exclusive consumer 保 partition-level ordering。
- 3.C29 WeWork：Bunny + Puma 多執行緒 channel pool
WeWork 從 Unicorn 切到 Puma 後遇 ConnectionClosedError、根因是 AMQP channel 跨執行緒共用、改用 connection_pool 管理。
- 3.C30 Runtastic：Mirrored queue 網路負載瓶頸
Runtastic 2020 lockdown 流量暴增、performance test 揭露 mirroring 邏輯把網路元件壓垮、調整 mirroring 配置消除瓶頸。
- 3.C31 Mozilla Pulse：命名前綴 + ACL 取代 vhost 多租戶
Mozilla Pulse 不用 vhost、改用權限 + 命名前綴 (exchange/{user}/*) 做隔離、CloudAMQP 託管、PulseGuardian 管使用者。
- 3.C32 LoyaltyLion：監控數千 RabbitMQ queue
LoyaltyLion 跑數千 queue、用 rabbitmqctl + statsd 推 Datadog、揭露大規模 queue 拓樸下原生 plugin API 不夠用。
- 3.C33 Wargaming：World of Tanks 戰後 dossier 解耦
Wargaming WoT server 全 Linux、戰後 dossier 寫 RabbitMQ、portal 顯示統計而不增 game server load。