SQS
角色
Producer、Meeeage、Queue、Consumer
graph LR;
A(Producer)-->B(Message,max=256k);
B-->C(Queue);
C-->D(Consumer);
- Producer：負責將用戶的需求轉換成Message，並轉送到消息佇列
- Message：服務之間傳遞的任務資訊(最大256K)
- Queue：存放待完成任務的訊息，提供Consumer取用
資料量過大可將處理完的檔案放置S3
消息不可見性，避免任務重複處理
當第一個Consumer拉取之後，會將消息改成Invisibility(消息不可見)
當使用完Message之後，Consumer會傳送Delete Message訊息，避免重複取用
處理順序
FIFO
- 高輸送量：每秒高達300個訊息(300次傳送、接收或刪除操作)。每個操作都要批次處理10則訊息時，FIFO柱列每秒最多可支援3,000則訊息。
- 恰好處理一次：訊息只會船第一次並保持可用狀態，直到消費者處理訊息並將之刪除。佇列尚未引進複製功能
- 先入先出交付：嚴格保持訊息傳送和接收的順序
Standard
- 無限制傳送量：每個API每秒近乎無限個交易數(TPS)
- 至少船第一次：一個運席至少船第一次，偶爾會傳遞一個以上
- 盡力按順序傳遞：訊息偶爾不會按到傳送順序傳遞
小結
最常使用場景就是用來處理大運算無法即時回應的任務
- 影片轉檔處理(Youtube)
- 蝦皮下訂單(直接先產生訂單編號，帳款資訊、購物車轉訂單後續處理)
- 註冊會員(先儲存會員資料，後續觸發生日檢查、Coupon券發送、發送簡訊)
Producer 接受使用者任務後，將其轉化為Message，並轉存在Queue裡面。
Consumer會按照我方設定的輪詢方式(Short Polling/Long Polling)去存取Queue，併發取Message進行處理。處理過程中，會讓消息進入不可見時限(Visibility timeout)，讓消息避免被重複處理。
Redis、Kafka、RabbitMQ 都有類似的功能，都可以拿來實作在EGO上