주제에 게시된 메시지를 받으려면 해당 주제에 대한 구독을 생성해야 합니다. 구독자 클라이언트는 구독이 생성된 이후에 주제에 게시된 메시지만 사용할 수 있습니다. 구독자 클라이언트는 주제에 게시된 메시지를 수신하고 처리합니다. 한 주제에 여러 구독이 존재할 수 있지만, 한 구독은 하나의 주제에만 연결됩니다.
주제 보관 기능을 사용하면 주제에 연결된 구독이 이전 시간에서 찾고 이전에 게시된 메시지를 재생할 수 있습니다. 메시지 재생 및 삭제 주제에서 이 기능에 대해 자세히 알아보세요.
구독 워크플로
메시지가 구독자에게 전달되면 구독자는 메시지를 확인해야 합니다.
전달되었지만 아직 구독자가 확인하지 않은 메시지를 대기 상태라고 합니다.
Pub/Sub는 아직 확인되지 않은 메시지를 전달하기 위해 반복해서 시도합니다. 하지만 Pub/Sub는 동일한 구독에서 다른 구독자에게 대기 중인 메시지를 전달하려 시도하지 않습니다.
구독자는 대기 중인 메시지를 확인하기 위한 ackDeadline이라고 하는 구성 가능하며 제한된 시간을 갖습니다. 기한이 지나면 메시지는 더 이상 대기 상태로 간주되지 않으며 Pub/Sub에서는 메시지를 다시 전송하려고 합니다.
구독 유형
구독을 만들 때 메시지 전송 유형을 지정해야 합니다.
Pub/Sub는 다음 구독 유형을 제공합니다.
풀 구독은 구독자 클라이언트를 사용하여 Pub/Sub 서버에서 메시지를 요청합니다.
푸시 구독은 Pub/Sub 서버를 사용하여 구독자 애플리케이션에 메시지 전송을 요청합니다.
내보내기 구독을 사용하면 메시지를 Google Cloud 리소스로 직접 내보낼 수 있습니다. 이러한 구독에는 다음이 포함됩니다.
기본적으로 Pub/Sub는 모든 구독 유형에 대해 순서에 관계없이 최소 1회 전송을 제공합니다. 또는 메시지에 동일한 순서 키가 있고 메시지가 동일한 리전에 있다면 메시지 순서를 사용할 수 있습니다. 메시지 순서 속성을 설정하면 Pub/Sub 서비스에서 동일한 순서 키를 사용해 Pub/Sub 서비스가 메시지를 수신하는 순서대로 메시지를 전송합니다.
일반적으로 Pub/Sub는 각 메시지를 게시된 순서대로 1회 전달합니다. 하지만 간혹 메시지가 순서대로 전달되지 않거나 여러 번 전달되기도 합니다. Pub/Sub가 메시지에 대한 확인 요청이 성공적으로 반환된 후에도 메시지를 다시 전송할 수 있습니다. 이러한 재전송은 서버 측 다시 시작 등의 문제나 클라이언트 측 문제로 인해 발생할 수 있습니다. 따라서 드물지만 언제든 아무 메시지나 다시 전송될 수 있습니다.
기본적으로, 구독은 31일 동안 구독자가 활동이 없거나 구독이 업데이트되지 않은 경우에 만료됩니다. 구독자 활동 예시에는 연결 열기, 활성 풀 또는 성공한 push가 있습니다. Pub/Sub가 구독자 활동 또는 구독 속성의 업데이트를 감지하면 구독 삭제 시계가 다시 시작됩니다. 구독 만료 정책을 사용하면 비활동 기간을 구성하거나 활동에 관계없이 구독 기간을 무한대로 설정할 수 있습니다. 구독 수동 삭제도 가능합니다.
삭제된 구독과 동일한 이름으로 새 구독을 생성할 수 있지만 생성한 새 구독은 이전 구독과 아무 관련이 없습니다. 삭제한 구독에 확인하지 않은 메시지가 많이 있더라도 동일한 이름으로 생성된 새 구독은 생성 시점에 백로그가 없을 것입니다(전달 대기 중인 메시지가 없음).
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-22(UTC)"],[],[],null,["# Subscription overview\n\n| **Key Point:** Learn about the basic workflow and properties for a Pub/Sub subscription.\n\nTo receive messages published to a topic, you must create a subscription to that\ntopic. Only messages published to the topic after the subscription is created\nare available to subscriber clients. The subscriber client receives and\nprocesses the messages published to the topic. A topic can have multiple\nsubscriptions, but a given subscription belongs to a single topic.\n\nThe topic retention feature lets a subscription attached to a topic to seek back\nin time and replay previously published messages. You can learn more about the\nfeature in the topic [Replaying and purging messages](/pubsub/docs/replay-overview).\n\nSubscription workflow\n---------------------\n\n1. After a message is sent to a subscriber, the subscriber must acknowledge the\n message.\n\n2. If a message is sent out for delivery and a subscriber is yet to acknowledge\n it, the message is called outstanding.\n\n3. Pub/Sub repeatedly attempts to deliver any message that is\n not yet acknowledged. However, Pub/Sub tries not to deliver\n an outstanding message to any other subscriber on the same subscription.\n\n4. The subscriber has a configurable, limited amount of time, known as the\n `ackDeadline`, to acknowledge the outstanding message. After the deadline\n passes, the message is no longer considered outstanding, and\n Pub/Sub attempts to redeliver the message.\n\nTypes of subscriptions\n----------------------\n\nWhen you create a subscription, you must specify the type of message delivery.\nPub/Sub offers the following types of subscriptions:\n\n- **Pull subscriptions** use a subscriber client to request messages from\n the Pub/Sub server.\n\n- **Push subscriptions** use the Pub/Sub server to initiate\n requests to your subscriber application to deliver messages.\n\n- **Export subscriptions** help you export your messages directly to a\n Google Cloud resource. These subscriptions include the following:\n\n - **BigQuery subscriptions** export data to a\n BigQuery table.\n\n - **Cloud Storage subscriptions** export data to a\n Cloud Storage bucket.\n\nTo choose the correct subscription for your business requirements, see\n[Choose a subscription type](/pubsub/docs/subscriber). You can [update the\ntype of message delivery](/pubsub/docs/manage-subscriptions) for a subscription\nat any time after its creation.\n\nDefault subscription properties\n-------------------------------\n\nBy default, Pub/Sub offers at-least-once delivery with no\nordering guarantees on all subscription types. Alternatively, if messages have\nthe same ordering key and are in the same region, you can enable [message\nordering](/pubsub/docs/ordering). After you set the message ordering property,\nthe Pub/Sub service delivers messages with the same ordering key\nand in the order that the Pub/Sub service receives the messages.\n\nPub/Sub also supports [exactly-once delivery](/pubsub/docs/exactly-once-delivery).\n\nIn general, Pub/Sub delivers each message once and in the order\nin which it was published. However, messages may sometimes be delivered out of\norder or more than once. Pub/Sub might redeliver a message even\nafter an acknowledgment request for the message returns successfully. This\nredelivery can be caused by issues such as server-side restarts or client-side\nissues. Thus, although rare, any message can be redelivered at any time.\n\nAccommodating more-than-once delivery requires your subscriber to be\n[idempotent](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning)\nwhen processing messages.\n\nSubscription expiry\n-------------------\n\nBy default, subscriptions expire after 31 days of subscriber inactivity or if\nthere are no updates made to the subscription. Examples of subscriber activities\ninclude open connections, active pulls, or successful pushes. If\nPub/Sub detects subscriber activity or an update to the\nsubscription properties, the subscription deletion clock restarts. Using\n[subscription expiration](/pubsub/docs/subscription-properties#expiration_period) policies,\nyou can configure the inactivity duration or make the subscription persistent\nregardless of activity. You can also\n[delete](/pubsub/docs/delete-subscriptions) a subscription manually.\n\nAlthough you can create a new subscription with the same name as a deleted one,\nthe new subscription has no relationship to the old one. Even if the deleted\nsubscription had many unacknowledged messages, a new subscription created with\nthe same name would have no backlog (no messages waiting for delivery) at the\ntime it's created.\n\nWhat's next\n-----------\n\n- Choose the [correct type of subscription](/pubsub/docs/subscriber) for your business requirements.\n\n- Understand the workflow for each type of subscription:\n\n - [Pull](/pubsub/docs/pull)\n\n - [Push](/pubsub/docs/push)\n\n - [BigQuery](/pubsub/docs/bigquery)\n\n - [Cloud Storage](/pubsub/docs/cloudstorage)\n\n- Read about the different [subscription properties](/pubsub/docs/subscription-properties)."]]