Message Notification Service

プロダクト紹介

Message Notification Serviceとは

Alibaba Cloud Message Serviceは、大量のメッセージや同時操作をサポートする、高性能、信頼性、安全性、安全性、拡張性を備えた分散メッセージと通知サービスです。アプリケーション間のメッセージ転送とシステムのデカップリングを容易にするのに役立ちます。

メッセージサービスは2つのモデルを提供します:

  • キュー

    ポイントツーポイントでメッセージを送受信するように設計されています。コンシューマはそれをプルダウンしてメッセージを受信します。

  • トピック

    パブ/サブウェイでメッセージを送受信するように設計されています。メッセージはメッセージブローカーからコンシューマにプッシュされます。コンシューマーは、HTTP、キュー、SMS、電子メール、または携帯電話にすることができます。

キューモデルの概要

キューは、非常に並行したシナリオでポイントツーポイント方式でメッセージを消費するように設計されています。各メッセージは1回だけ受信できます。

キューモデルのイラストレーション

キューモデル

キューモデルの特性
  • 複数の属性

    キューモデルは、通常のキュー、遅延キュー、プライオリティキューなど、さまざまなシナリオの要件を満たすさまざまなカスタマイズ可能な属性をサポートしています。

  • 大量の要求を同時にサポート

    1つのキューは、多くのプロデューサまたはコンシューマによって同時にアクセスされることができ、1つのメッセージは、1つのコンシューマによってフェッチされた後、一定期間内に他のコンシューマによってフェッチできません。

  • メッセージ配信の確実性

    キューに正常に送信されたメッセージは、少なくとも1回フェッチされ、他人からの不正アクセスを防ぐことが保証されています。

  • サポートトランザクションメッセージ

    キューに送信されたメッセージをロールバックする機能を提供します。これにより、アプリケーションはトランザクションのロールバックを実行できます。

  • メッセージに対する操作のログ記録をサポートする

    メッセージの送信、受信、削除の操作を照会するログ機能を提供します。デバッグに役立ちます。

  • Alibaba Cloud Watchをサポート

    CloudWatchからキュー情報を取得し、アラートをカスタマイズできます。

トピックモデルの概要

トピックモデルは、あるパブリッシャから複数のサブスクライバにメッセージのパブリッシュ、サブスクリプション、および通知を提供するように設計されています。メッセージ通知のためのいくつかの方法をサポートしています:

  • ユーザーが指定したHTTPサーバーにメッセージをプッシュします。
  • メッセージをMNSキューにプッシュします。
  • 電子メールアドレスまたは電子メールアドレスグループにメッセージをプッシュします。
  • SMSを介して電話番号にメッセージをプッシュ(中国のみ)します。
  • WebSocket経由でブラウザにメッセージを送ります(計画中)。
  • モバイルデバイスにメッセージをプッシュします。
トピックのイラスト

トピックのイラスト

トピックモデルの特徴
  • 通知メッセージをサポートします。
  • 1対多メッセージをサポートします。
  • メッセージのためのサポートタグフィルタリングします。*メッセージをプッシュするさまざまな方法をサポートします。
  • メッセージ配信を保証します。
  • Alibaba Cloudサービスからのイベントメッセージのサポートをします。
  • サポートログを管理します。
  • Alibaba Cloud Watchをサポートします。
  1. メッセージのサポート通知

    • メッセージサービスサーバーは、ユーザーが指定したHTTP URLにメッセージをプッシュします。このように、ユーザーのアプリケーションはメッセージブローカーサーバーをこれ以上処理する必要はなく、ユーザーがCPUなどのリソースを節約し、Message Service SDKへの依存を減らすのに役立ちます。

    • メッセージサービスサーバーは、ネットワークの問題によりユーザーがHTTP URLを提供するのに不便な場合、メッセージをトピックからキューにプッシュします。これにより、アプリケーションはキューからのメッセージを受信します。

  2. 1対多メッセージをサポートします。

    トピックに送信されたメッセージは、複数のコンシューマによってサブスクライブされ、コンシューマによって指定された方法で複数のエンドポイントにプッシュされます。

  3. メッセージのフィルタータグ

    トピックのEndpointを購読する場合、フィルタータグを指定することはできます。メッセージ送信時にはメッセージタグを指定した場合、Message Service は該当メッセージをメッセージタグとフィルタータグが一致したEndpointにのみプッシュします。購読時にEndpointにフィルタータグを指定しなかった場合、トピックにプッシュされたすべてのメッセージが受信されます。メッセージ送信時にメッセージタグを指定しなかった場合、すべてのEndpointに送信されます。

  4. メッセージをプッシュするさまざまな方法をサポート

    次の方法をサポートします。

    • ユーザーが指定したHTTPサーバーにメッセージをプッシュします。HttpEndpointローカルデバッグツール、署名メカニズム、トピック操作を参照ください。
    • MNSキューにメッセージをプッシュします。
    • 電子メールアドレスまたは電子メールアドレスグループにメッセージをプッシュします。
    • SMSを介して電話番号にメッセージをプッシュします。
    • WebSocket経由でブラウザにメッセージをプッシュします(計画中)。
    • モバイルデバイスにメッセージをプッシュします。
  5. メッセージ配信の確実性

    メッセージは、ユーザーが指定した計画と形式でプッシュされます。
    プッシュ計画には次のものがあります。

    • BACKOFF_RETRY:各メッセージの合計で3回(10〜20秒の間隔で)再試行します。
    • EXPONENTIAL_DECAY_RETRY:メッセージごとに合計で176回再試行してください。隣接する再試行間の間隔は、1,2,4,8,16,32,64,128,256,512,512,512 …の順番で連続します。
      最大時間間隔は512秒です。

    メッセージ形式には次のものがあります。

    • XML:メッセージ本体はメッセージ属性を持つXML形式です。
    • JSON:メッセージ本体はメッセージ属性を持つJSON形式です。
    • SIMPLIFIED:メッセージ本文は生のテキストです。
  6. Alibaba Cloudサービスからのイベントメッセージのサポートします。

    メッセージサービスはイベント/通知機能を提供し、OSS(Object Storage Service)、DM(DirectMail)サービス、SLS(Simple Log Service)などの他のAlibaba Cloud Servicesなどが対象になります。クラウドリソースからイベントをサブスクライブすることができます。この機能を使用すると、ユーザーは、CreateObject、DeleteObject、UpdateObjectなど、OSSオブジェクトに対するイベント操作のルールを設定できます。

  7. メッセージに対する操作のログ記録をサポートします。

    メッセージのすべての操作は、SLSまたはOSSにログ保存されます。ユーザーはSLSのメッセージIDでメッセージログを照会できます。

  8. Alibaba Cloud Watchをサポートします。

    ユーザーはCloudWatchからトピック情報を取得し、アラートをカスタマイズできます。

利点

自作キューサービスと比較したメッセージサービスの利点

主な利点 メッセージサービスの使用 自作・キュー・サービスの使用
使いやすい ゼロクラスタとゼロ操作が必要です。
標準のHTTP REST API。
最も普及しているプログラミング言語用の有益なSDKがあります。
クラスターが必要で、開始時にコストが高い。
ビジネスが成長している間に操作とコストの増加が必要です。
標準HTTP REST APIの代わりにプライベートプロトコルです。
安定性 メッセージ用に3つのコピーを保存し、データセキュリティは99.99999999%です。
サービスの可用性は99.9%です。
一度に配信メッセージの確実性を確保します。
メッセージは1台または2台のマシンに保存されます。
高可用性のない小規模クラスタ。
セキュリティ DDoSのような攻撃から防御するために、さまざまなレベルでのプロフェッショナルな保護。
複数のユーザーの分離と専用の名前空間。
認可と認証のためのメインサブアカウントをサポートします。
HTTPSとVPCをサポートします。
セキュリティ戦略はほとんどありません。
スケーラビリティ 待ち行列の数およびメッセージの格納は制限されない。
ユーザーに対して透過的な自動スケールアップ。
世界中に導入されました(現在、13地域)。
キューの数、ストレージの制限によるメッセージの数によって制限されます。
制限リージョン 。スケールアップしません。

その他の利点

ハイパフォーマンスプライスレシオ
  • 高性能で低価格。
  • リソースパッケージを購入する際の割引。
プロフェッショナルテクニックサポート

年中無休の製品サポート。

SB Cloud サポートセンターにお問い合わせください。

コア概念

メッセージはキューに格納しています。メッセージにはデータと属性が含まれています。
MessageIdとReceiptHandleはキューに格納されているメッセージを識別するために使用される2種類の識別子です。

アカウント

AlibabaクラウドサービスのユーザーIDです。

キューのオーナー

メッセージサービスのCreateQueue APIによりキューを作成した場合、該当アカウントがキューのオーナーになります。キューのオーナーはキューに対して全ての操作権限を持ちます。AccountIDはAlibaba Cloud WebSiteから確認可能です。

producer

メッセージの送信者(キューに送信します)。

Consumer

メッセージの受信者、キューの中からメッセージを削除します。

Endpoint

メッセージサービスのアクセスURLであり、フォーマートは以下の形になります。https://$AccoundId.mns.$Region.aliyuncs.com $Regionはメッセージサービスが展開された地域です。 $AccountIdはユーザーがAlibabaクラウドサービスを登録時に作成したユーザーIDです。

Normal Message

キューに送信され、受信者がすぐに受け取ることが可能なメッセージです。

Delay Message

キューに送信され、遅延期間が終了するまで受信者は受け取ることができません。

Normal Queue

メッセージの遅延時間はデフォルトでゼロに設定されます。つまり、遅延時間が設定されていないため、すぐにキューから受信可能です。

Delay Queue

メッセージの遅延時間はデフォルトでゼロ以上に設定されます。指定された時間後にメッセージが受信可能になります。

MessageID

キューの中のメッセージを識別するためのIDです。同じキューの中でメッセージは重複しないMessageIDが付与されています。ただし、MessageIDは異なるキューの間では重複している可能性があります。MessageIDはメッセージの作成者がメッセージサービスによりメッセージをキューに送信する際に作成されます。メッセージ送信リクエストをキューに送信するとメッセージサービスによりMessageIDが返されます。

注:MessageIDを使用してメッセージを削除することはできません。

ReceiptHandle

ReceiptHandleはメッセージサービスにより作成され、メッセージを受信する時受信者に返された一時的な識別子です。受信者はReceiptHandleを使用してメッセージの削除や、メッセージのvisibility timeout値を変更することができます。ただし、ReceiptHandleはメッセージのステータスが変わると期限切れになります。

メッセージのステータス

メッセージのステータス

  • キュー内のメッセージには3つのステータスがあります: Active, Delayed,
  • Inactive:
  • Normal Messageは、Activeの状態で初期化されます。Delay messageはDelayedの状態で初期化されます。
  • Delayedの状態にあるメッセージの合計時間が設定された遅延時間に達すると、Active状態に遷移します。
  • Active状態のメッセージは受信者が受信すると、メッセージの状態がInactive状態に遷移し、 受信者から見えなくなります。
  • 全てのInactive状態のメッセージに対してvisibility timeout値が設定されています。visibility timeout値で設定された時間内で受信者により削除されなかった場合、メッセージの状態が再びActiveに遷移します。
  • メッセージの遅延時間とvisibility timeout時間はユーザアプリケーションで指定することができます。

メッセージライフサイクル

メッセージライフサイクル

トピックの概念

トピック

Topicは、メッセージPub / Subモデル内のメッセージの宛先と格納アドレスです。

アカウント

Alibaba CloudのユーザーIDで、一連の数字で構成されています。

パブリッシャー

トピックにメッセージを送信するクライアントは、プロデューサとも呼ばれます。

サブスクライバー

クライアントはトピックからメッセージを受信します。トピックの所有者は、所有しているトピックをサブスクライブする権限を持っています。

サブスクライブ

メッセージのサブスクライバとトピックの関係。パブリッシャーがトピックに送信するメッセージは、サブスクライバーのみが受信できます。

エンドポイント

httpアドレス、電子メールアドレス、電話番号(SMSの場合)など、サブスクライバーがメッセージを受信するために使用したアドレス

トピックURL

フォーマットのインジケータ:http(s)://$AccountId.mns.$Region.aliyuncs.com/topics/$TopicNameの$AccountIdは、ユーザーアカウントのID(UID)、$Regionはリージョンの名前を示し、$TopicNameはトピックの名前を示します。

メッセージ

トピック単位でパブリッシャからサブスクライバに転送される情報の単位です。同じトピックのすべてのメッセージに一意のMessageIDがありますが、異なるトピックで重複している可能性があります。

トピックへの送信後、すべてのメッセージは1日間保存されます。1日以上経過したメッセージは期限切れとなり、すぐにリサイクルされます。

FAQ

MNSのよくある質問

  • MNS は、Message and Notification Service (メッセージおよび通知サービス) の略です。これは Alibaba Cloud が提供する、効率的で信頼性と安全性が高く、便利で、弾力的なスケーラビリティを備えた分散型のメッセージおよび通知サービスです。
  • アプリケーション開発者はアプリケーションの分散コンポーネントの間でデータを自由に転送できるため、疎結合のシステムを構築できます。

MNS の用途は何ですか?

典型的なアプリケーションシナリオは次のとおりです。

  1. MNS を他の Alibaba Cloud プロダクトと統合して、アプリケーションの信頼性と柔軟性を高めます。
  2. MNS を作業キューに使用します。キュー内の各メッセージは 1 つのタスクに対応し、1 つのプロセスで完了する必要があります。1 つまたは複数の ECS がキューからタスクを読み取り、実行することができます。
  3. サービスプロセス内の主要なイベントの通知を MNS に保管します。各イベントに対して、キュー内に 1 つの対応するメッセージが存在します。イベントを取得する必要があるアプリケーションは、対応するメッセージを読み取り、処理します。

各リージョンのメッセージサービスのアクセスアドレスは何ですか?

リージョン パブリックアクセスアドレス プライベートアクセスアドレス VPC プライベートアクセスアドレス
青島 (中国北部 1) http(s)://{AccountId}.mns.cn-qingdao.aliyuncs.com http://{AccountId}.mns.cn-qingdao-internal.aliyuncs.com Unavailable for the moment
北京 (中国北部 2) http(s)://{AccountId}.mns.cn-beijing.aliyuncs.com http://{AccountId}.mns.cn-beijing-internal.aliyuncs.com http://{AccountId}.mns.cn-beijing-internal-vpc.aliyuncs.com
杭州 (中国東部 1) http(s)://{AccountId}.mns.cn-hangzhou.aliyuncs.com http://{AccountId}.mns.cn-hangzhou-internal.aliyuncs.com http://{AccountId}.mns.cn-hangzhou-internal-vpc.aliyuncs.com
上海 (中国東部 2) http(s)://{AccountId}.mns.cn-shanghai.aliyuncs.com http://{AccountId}.mns.cn-shanghai-internal.aliyuncs.com http://{AccountId}.mns.cn-shanghai-internal-vpc.aliyuncs.com
深セン (中国南部 1) http(s)://{AccountId}.mns.cn-shenzhen.aliyuncs.com http://{AccountId}.mns.cn-shenzhen-internal.aliyuncs.com http://{AccountId}.mns.cn-shenzhen-internal-vpc.aliyuncs.com
シンガポール http(s)://{AccountId}.mns.ap-southeast-1.aliyuncs.com http://{AccountId}.mns.ap-southeast-1-internal.aliyuncs.com http://{AccountId}.mns.ap-southeast-1-internal-vpc.aliyuncs.com
シリコンバレー (米国西部 1) http(s)://{AccountId}.mns.us-west-1.aliyuncs.com http://{AccountId}.mns.us-west-1-internal.aliyuncs.com http://{AccountId}.mns.us-west-1-internal-vpc.aliyuncs.com
東京 (日本) http(s)://{AccountId}.mns.ap-northeast-1.aliyuncs.com http://{AccountId}.mns.ap-northeast-1-internal.aliyuncs.com  
シドニー (オーストラリア) http(s)://{AccountId}.mns.ap-southeast-2.aliyuncs.com http://{AccountId}.mns.ap-southeast-2-internal.aliyuncs.com  
ドバイ (UAE) http(s)://{AccountId}.mns.me-east-1.aliyuncs.com http://{AccountId}.mns.me-east-1-internal.aliyuncs.com  

データセキュリティのため、メッセージサービスがパブリックネットワークに HTTPS インタフェースを提供しています。パブリックアクセスアドレスに http:// を https:// を入れ換えて利用できます。

AccountId とは何ですか?

AccountId は、Alibaba Cloud の公式 Web サイトにあるユーザーセンターにアクセスできる Alibaba Cloud Account IDです。

メッセージサービスはどのような操作をサポートしていますか?

次の表に、メッセージサービスキューでサポートされている操作コマンドを示します。

操作 説明
CreateQueue 新しいメッセージキューを作成します。
SetQueueAttributes キューの属性を変更します。
GetQueueAttributes キューの属性を取得します。
DeleteQueue キューを削除します。
ListQueue ユーザー名でキューリストを一覧表示します。
SendMessage 指定されたキューにメッセージを送信します。
BatchSendMessage 指定されたキューにバッチでメッセージを送信します。
ReceiveMessage コンシューマはキュー内のメッセージを消費します。
BatchReceiveMessage コンシューマはキュー内のメッセージをバッチで消費します。
DeleteMessage 消費されたメッセージを削除します。
BatchDeleteMessage バッチで消費されたメッセージを削除します。
PeekMessage キュー内のメッセージを見る。
BatchPeekMessage キュー内のメッセージを一括して表示します。
ChangeMessageVisibility 消費され、現在非アクティブになっているメッセージの次の消費時間を変更します。

次の表に、メッセージサービスのトピックでサポートされている操作コマンドを示します。

操作 説明
CreateTopic 新しいトピックを作成します。
SetTopicAttributes トピックの属性を変更します。
GetTopicAttributes トピックの属性を取得します。
DeleteTopic トピックを削除します。
ListTopic ユーザー名でトピックリストを一覧表示します。
Subscribe トピックを購読します。
SetSubscriptionAttributes サブスクリプションの属性を変更します。
GetSubscriptionAttributes サブスクリプションの属性を取得します。
Unsubscribe 購読したトピックを取り消します。
ListSubscriptionByTopic トピックのサブスクリプションリストを一覧表示します。
PublishMessage トピックにメッセージを公開します。

自社開発、商用、またはオープンソースのメッセージキューシステムと比較した MNS の利点は何ですか?

キューを管理するためのシステムを構築することや、商用またはオープンソースのメッセージおよび通知サービスを使用することと比較して、MNS には次の利点があります

  1. 初期段階で開発や設定のための大規模な投資が不要です。
  2. サービスの量が増えても追加のハードウェアや管理リソースが不要です。
  3. 冗長性のあるメッセージストレージがデフォルトで実装されているため、ハードウェア障害の際にもメッセージは失われず、また、システムの投資、開発、設定、およびデプロイメントが容易です。
  4. 後の段階で、メッセージおよび通知サービスのためにデプロイメントおよびメンテナンスのリソースを投入する必要がありません。MNS は、簡単な設定だけで運用環境に導入できます。

MNS はどのように使用するのですか?

  1. Alibaba Cloud アカウントを作成し、MNS オンラインに登録します。
  2. [User Center] - [My Service] - [Security Authentication] にアクセスして、アクセスキー (AccessKeyID) を取得します。
  3. 管理コンソールで、キューの作成と削除、メッセージの受信と送信などの基本操作を視覚的に実行します。
  4. アプリケーションから API (SDK) を起動して、すべての MNS 操作を実行します。

メッセージはシステムの中でどのように識別されるのですか?

  • キュー内でメッセージを識別するには、MessageId が使用されます。MessageId は、同じキューの中でのみ一意です。
  • メッセージが MNS キューに送られると、MNS によって MessageId が生成されます。生成された MessageId が変更されることはありません。
  • メッセージが取得されると、MNS からユーザーにこのリクエストに対応するメッセージ本文、MessageId、および一時的なハンドル (ReceiptHandle) が返されます。ReceiptHandle は、メッセージを取得した後で、有効期間の間にメッセージを削除する際に使用します。

MNS ではロングポーリングはサポートされますか?

はい。従来のショートポーリングと比較すると、ロングポーリングで応答が返されるのはメッセージがキューに入るかロングポーリングがタイムアウトした後です。メッセージが取得可能になると、ロングポーリングは直ちに MNS キュー内のメッセージを単純で効率的な方法によって取得できます。

ロングポーリングの設定については、MNS API のドキュメントで PollingWaitSeconds 属性の説明を参照してください。

MNS はメッセージを FIFO (first-in-first-out) で処理しますか?

MNS は、メッセージができるだけ FIFO 方式で取得されるように試みます。ただし、分散メッセージキューの性質上、必ずしも送信された順番どおりにメッセージを取得できるとは限りません。FIFO を必要とするサービスでは、取得した後で並べ替えられるようにメッセージに連番を追加することをお勧めします。

MNS を他の Alibaba Cloud プロダクトと連携させることはできますか?

MNS を ECS、OSS、OTS などの Alibaba Cloud サービスと連携させて、アプリケーションの柔軟性とスケーラビリティを高めることができます。一般的なケースの 1 つは、互いの間で通信する必要があり、同時に同じサービスボリュームを処理することはできない複数のコンポーネントまたはモジュールを作成する場合です。このケースでは、MNS キューにメッセージを保持すると、ECS インスタンス上で実行されるアプリケーションはメッセージを順番に処理することができます。ECS インスタンスはキューを読み取り、タスクを処理してから、結果を別の MNS キューにメッセージとしてパブリッシュすることが (そこからさらに他のアプリケーションによって処理することも) できます。ECS ではアプリケーションの動的な拡張が可能であるため、アプリケーション開発者はタスクが遅延なく処理されるように、MNS キュー内のメッセージの量 (サービスボリューム) に応じてコンピューティングインスタンスの量を簡単に変更できます。

MNS に保管されるデータの信頼性をどのようにして確保しますか?

MNS では、すべてのキューとメッセージは、高い信頼性と可用性を備えた Alibaba Cloud のデータセンター間を結んで形成されるネットワークに保管されます。すべてのメッセージは、複数のサーバーに冗長モードで保管されます。1 台のサーバーに障害が発生すると、自動的に他のサーバーに冗長データがコピーされます。そのため、MNS キュー内のメッセージのセキュリティは、1 台のサーバーまたは 1 か所のネットワークの障害が発生しただけでは影響を受けません。

MNS では複数のコンシューマーが同時にキューにアクセスしたときに、メッセージが失われたり繰り返し取得されることを、どのようにして防いでいますか?

各 MNS キューには、設定可能な ChangeMessageVisibility 属性 (キューから取得されたメッセージが不可視になる期間) があります。メッセージがキューから取得されると、不可視期間の間、他のコンシューマーはこのメッセージを取得できません。不可視期間の間にユーザーが取得した場合は、一時的なハンドル (ReceiptHandle) を使用してメッセージが削除されます。ユーザーが不可視期間の間に取得しない場合は、不可視期間を延長するリクエスト (ChangeVisibilityTimeout) を送信する必要があります。送信しないと、不可視期間が経過した後、他のコンシューマーがこのメッセージを取得します。

各メッセージは何回受信されますか?

このシステムは、キュー内のすべてのメッセージが少なくとも 1 回必ず取得されるように設計されています。しかし念のため、同じメッセージが何回も処理されたときにエラーや不整合が発生するのを避けるために、アプリケーションサービスのフォールトトレランスを強化することをお勧めします。

キュー内のメッセージのセキュリティを確保するにはどのようにすればよいですか?

Alibaba Cloud は、お使いの MNS キューを不正なアクセスから保護するために、安全かつ信頼性の高い ID 認証メカニズムを用意しています。キューにアクセスできるのは、そのキューを作成した Alibaba Cloud アカウントオーナーだけです。

長いメッセージ保持期間に対応するように MNS を設定するには、どのようにすればよいですか?

メッセージ保持期間を設定するには、SetQueueAttributes を使用して MessageRetentionPeriod 属性を設定します。この属性は、MNS キュー内にメッセージが保持される秒数を指定します。現在、デフォルトのメッセージ保持期間は 4 日です。MessageRetentionPeriod は、60 秒 (1 分) から 1296000 秒 (15 日) の間の値に設定できます。

MNS でメッセージが保持される期間はどのくらいですか?

MNS では、メッセージ保持期間を設定することができます。1 分から 15 日の間の任意の値に設定できます。デフォルト値は 4 日です。メッセージ保持期間が経過したメッセージは自動的に削除されます。メッセージ保持期間を長くすると、柔軟性が高まり、メッセージの生成から取得までの間隔を長くすることができます。

大きなメッセージに対応するように MNS を設定するには、どのようにすればよいですか?

最大メッセージサイズを設定するには、SetQueueAttributes を使用して MaximumMessageSize 属性を設定します。この属性は、MNS キュー内のメッセージのバイト数を指定します。1024 バイト (1 KB) から 65536 バイト (64 KB) の間の任意の値に設定できます。メッセージの長さが 64 KB を超える場合は、データは OSS で格納し、MNS ではそのデータのアクセスアドレスだけを格納することをお勧めします。

長期間メッセージが格納されないキューはどうなりますか?

MNS を通常の方法で使用している限り、アクティブでないキューであっても削除されません。ただし、債務不履行などの理由で MNS が停止された場合は、すべてのキューが削除されます。

なぜ計算された署名がよく間違っていますか?

署名の計算の原理と注意事項については、MNS API のリファレンスマニュアルを参照してください。署名の方法を以下に示します。リクエストの HTTP ヘッダーは次のようになります。

  1. GET /MyQueue HTTP/1.1
  2. Host: $AccountId.mns.cn-hangzhou.aliyuncs.com
  3. Date: Thu, 09 Jul 2015 03:01:34 GMT
  4. x-mns-version:2015-06-06

暗号化される署名のソース文字列は次のようになります。暗号化される署名のソース文字列は次のようになります。

  1. GET
  2. (line feed)
  3. (line feed)
  4. Thu, 09 Jul 2015 03:01:34 GMT
  5. x-mns-version:2015-06-06
  6. /MyQueue

accessId が TestAccessID、accesskey が TestAccessSecret であるとします。暗号化アルゴリズムによって取得される署名値は、uwx3yeWoILzgmvesW0BQSgfM7b8= です。

名前が同じでリージョンが異なるキューは、同一のものですか?

いいえ。名前が同じでリージョンが異なるキューは、互いに独立した存在です。

キューのインスタンスが削除された後も請求が継続されますか?

キューが不要になった場合は、キューインスタンスを削除した後で、キューに対するすべての API リクエストを停止する必要があります。それ以外の場合、メッセージサービスは API リクエストの数に応じて請求を継続します。

トピックインスタンスが削除された後も請求は継続されますか?

トピックが不要になった場合は、トピックインスタンスが削除されてから翌日にインスタンスの料金が請求されることはありません。トピックのすべての API リクエストを停止する必要があります。それ以外の場合、メッセージサービスは API リクエストの数に応じて請求を継続します。

MNS のデータが失われたか、見つかりません

MNS に挿入したデータが表示されない場合は、公式 Web サイトのコンソールでテストデータを使用し、トラブルシューティングを実行します。

挿入したデータがコンソールに表示されない場合。

メッセージのライフサイクル (秒): メッセージが無効になるまでの時間を示します。この時間が短すぎると、メッセージはすぐに無効になります。

メッセージレイテンシ (秒): メッセージが MNS に挿入された後、表示されるまでの時間を示します。この時間が長すぎると、データはなかなか表示されません。

不可視タイムアウト (秒): クライアントによる照会後に、メッセージが他のコンシューマーに表示されなくなる時間を示します。

コンソールの [キューリスト] で “アクティブなメッセージ”、”非アクティブなメッセージ”、”遅延メッセージ” を確認し、設定の問題かどうかを判定します。

挿入されたデータがコンソールに表示されるものの、コードに見当たらない場合。

コードエラーがないか確認します。SDK の場合は、最新バージョンであることを確認してください。

問題が解決しない場合は、テクニカルサポートにお問い合わせください。

Message Service でのメッセージの一括操作に関する注意事項

Message Service はメッセージを一括で送受信するインターフェイスを提供し、QPS を向上させるだけでなく、リクエストの数とコストを削減します。

バッチ操作時の考慮事項
  • BatchPutMessage インターフェイスを使用すると、一度に最大 16 件のメッセージを送信することができます。送信メッセージの合計サイズは 64 KB までです。
    他の指定がない限り、送信メッセージは Base64 でエンコードされます (元のメッセージ本文が増幅されます)。したがって、送信メッセージの実際のサイズは 47 KB を超えることはできません。
    次のコマンドを実行すると Base64 エンコーディングをキャンセルし、元のメッセージ本文を使用することができます。
    message.setMessageBody(“message_body”, Message.MessageBodyType.RAW_STRING);
  • BatchReceiveMessage インターフェイスを使用すると、一度に最大 16 件のメッセージを受信することができます。
    10 件のメッセージがある場合に、BatchReceiveMessage で 5 件のメッセージしか受信できないのはなぜでしょうか。
    テストを実行してみましょう。キューに含まれる 10 件のメッセージは順番に送信されます (m1、m2、m3、m4、m5、m6、m7、m8、m9、m10)。BatchReceiveMessage の最初の呼び出しで 5 件のメッセージ (m2、m4、m6、m8、m10) が取得され、2 回目の呼び出しで残りの 5 件 (m1、m3、m5、m7、m9) が取得されます。
    Message Service は複数の スライス にデータを格納し、1 回のバッチ取得操作ごとに 1 つの スライス からデータを取得します。必要なデータを取得した後、Message Service はすべての スライス からデータを取得するまで待機せず、すぐにメッセージを返します。データの送信時には、スライス がどのように分散しているかに応じて、各回のバッチ取得操作で返されるメッセージが決まります。
    これが、Message Service でメッセージの取得順が一定でない理由の 1 つです。

問題が解決しない場合は、テクニカルサポートにお問い合わせください。