Pusat Tugas

Hub tugas adalah representasi dari status aplikasi saat ini dalam penyimpanan, termasuk semua pekerjaan yang tertunda. Saat aplikasi berjalan, hub tugas terus menerus mencatat perkembangan fungsi orkestrasi, aktivitas, dan entitas. Pendekatan ini memastikan bahwa aplikasi dapat melanjutkan pemrosesan yang ditinggalkannya jika dimulai ulang setelah dihentikan sementara atau terganggu. Hub tugas juga memungkinkan aplikasi untuk menskalakan pekerja komputasi secara dinamis.

Artikel ini menjelaskan apa yang disimpan hub tugas, cara mengonfigurasi dan memberi nama hub tugas, cara membuat dan mengelolanya dengan backend penyimpanan yang berbeda, dan cara kerja hub tugas secara internal.

Penting

Dukungan akan berakhir untuk model dalam proses pada 10 November 2026. Kami sangat menyarankan agar Anda memindahkan aplikasi Anda ke model pekerja terisolasi untuk dukungan penuh.

Cuplikan layar diagram memperlihatkan aplikasi fungsi dan arsitektur hub tugas dalam Tugas Tahan Lama.

Secara konseptual, hub tugas menyimpan informasi berikut:

  • Status semua instans orkestrasi dan instans entitas.
  • Pesan yang akan diproses, termasuk:
    • Setiap pesan aktivitas yang mewakili aktivitas yang menunggu untuk dijalankan.
    • Setiap pesan instans yang menunggu untuk dikirimkan ke instance.

Pesan aktivitas tanpa status dan dapat diproses di mana saja. Pesan instans perlu dikirimkan ke instans stateful tertentu (orkestrasi atau entitas), yang diidentifikasi oleh ID instansnya.

Secara internal, setiap penyedia penyimpanan dapat menggunakan organisasi yang berbeda untuk mewakili status dan pesan instans. Misalnya, penyedia Azure Storage menyimpan pesan dalam antrean Azure Storage, tetapi penyedia MSSQL menyimpannya dalam tabel relasional. Perbedaan ini tidak masalah untuk desain aplikasi, tetapi beberapa di antaranya mungkin memengaruhi karakteristik performa. Untuk informasi selengkapnya, lihat Representasi dalam penyimpanan.

Durable Task SDK menggunakan Durable Task Scheduler sebagai backend untuk hub tugas. Durable Task Scheduler adalah layanan terkelola penuh yang menangani penyimpanan secara internal.

Nama hub penugasan

Hub tugas diidentifikasi dengan nama yang sesuai dengan aturan ini:

  • Hanya berisi karakter alfanumerik
  • Dimulai dengan huruf
  • Memiliki panjang minimum 3 karakter, panjang maksimum 45 karakter

Deklarasikan nama hub tugas dalam file host.json , seperti yang diperlihatkan dalam contoh berikut:

host.json (Fungsi 2.0)

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub"
    }
  }
}

host.json (Fungsi 1.x)

{
  "durableTask": {
    "hubName": "MyTaskHub"
  }
}

Anda juga dapat menyiapkan hub tugas dengan menggunakan pengaturan aplikasi, seperti yang ditunjukkan dalam contoh file berikut host.json :

host.json (Fungsi 2.0)

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%MyTaskHub%"
    }
  }
}

host.json (Fungsi 1.x)

{
  "durableTask": {
    "hubName": "%MyTaskHub%"
  }
}

Nama hub tugas diatur sesuai dengan nilai MyTaskHub pengaturan aplikasi. File berikut local.settings.json menunjukkan cara menentukan MyTaskHub pengaturan sebagai samplehubname:

{
  "IsEncrypted": false,
  "Values": {
    "MyTaskHub" : "samplehubname"
  }
}

Nota

Saat menggunakan slot penyebaran, praktik terbaiknya adalah menyiapkan nama hub tugas melalui pengaturan aplikasi. Jika Anda ingin memastikan bahwa slot tertentu selalu menggunakan task hub tertentu, gunakan pengaturan aplikasi "slot-sticky".

Selain host.json, nama hub tugas juga dapat disiapkan dalam metadata pengikatan klien orkestrasi . Penyiapan ini berguna saat Anda perlu mengakses orkestrasi atau entitas yang berada di aplikasi fungsi yang terpisah. Kode berikut menunjukkan cara menulis fungsi yang menggunakan pengikatan klien orkestrasi untuk bekerja dengan hub tugas yang dikonfigurasi sebagai pengaturan aplikasi:

Model pekerja terisolasi 
[Function("HttpStart")]
public static async Task<HttpResponseData> Run(
  [HttpTrigger(AuthorizationLevel.Function, "post", Route = "orchestrators/{functionName}")] HttpRequestData req,
  [DurableClient(TaskHub = "%MyTaskHub%")] DurableTaskClient starter,
  string functionName,
  FunctionContext executionContext)
{
  string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
  string instanceId = await starter.ScheduleNewOrchestrationInstanceAsync(functionName, requestBody);

  ILogger logger = executionContext.GetLogger("HttpStart");
  logger.LogInformation("Started orchestration with ID = '{instanceId}'.", instanceId);

  return await starter.CreateCheckStatusResponseAsync(req, instanceId);
}

Model dalam proses 
[FunctionName("HttpStart")]
public static async Task<HttpResponseMessage> Run(
    [HttpTrigger(AuthorizationLevel.Function, methods: "post", Route = "orchestrators/{functionName}")] HttpRequestMessage req,
    [DurableClient(TaskHub = "%MyTaskHub%")] IDurableOrchestrationClient starter,
    string functionName,
    ILogger log)
{
    // Function input comes from the request content.
    object eventData = await req.Content.ReadAsAsync<object>();
    string instanceId = await starter.StartNewAsync(functionName, eventData);

    log.LogInformation($"Started orchestration with ID = '{instanceId}'.");

    return starter.CreateCheckStatusResponse(req, instanceId);
}

Nota

Contoh sebelumnya adalah untuk Durable Functions 2.x. Untuk Durable Functions 1.x, gunakan DurableOrchestrationContext alih-alih IDurableOrchestrationContext. Untuk informasi selengkapnya tentang perbedaan antar versi, lihat artikel versi Durable Functions .


Nota

Menyiapkan nama hub tugas dalam metadata pengikatan klien hanya diperlukan saat Anda menggunakan satu aplikasi fungsi untuk mengakses orkestrasi dan entitas di aplikasi fungsi lain. Jika fungsi klien didefinisikan dalam aplikasi fungsi yang sama dengan orkestrasi dan entitas, hindari menentukan nama hub tugas dalam metadata pengikatan. Secara default, semua binding klien memperoleh metadata hub tugas mereka dari pengaturan host.json.

Jika tidak ditentukan, nama hub tugas default digunakan seperti yang diperlihatkan dalam tabel berikut:

Versi ekstensi tahan lama Nama hub tugas bawaan
2.x Saat disebarkan di Azure, nama hub tugas berasal dari nama aplikasi fungsi. Saat berjalan di luar Azure, nama hub tugas default adalah TestHubName.
1.x Nama hub tugas default untuk semua lingkungan adalah DurableFunctionsHub.

Untuk informasi selengkapnya tentang perbedaan antara versi ekstensi, lihat artikel versi Durable Functions.

Menggunakan beberapa aplikasi dengan hub tugas terpisah

Setiap aplikasi yang berbagi backend harus terhubung ke hub tugasnya sendiri untuk menghindari konflik. Jika beberapa aplikasi menggunakan hub tugas yang sama, aplikasi tersebut berebut pesan, yang dapat menyebabkan perilaku tidak terdefinisi — termasuk orkestrasi yang macet secara tak terduga. Satu backend dapat berisi banyak hub tugas; konfigurasikan setiap aplikasi dengan hub tugasnya sendiri.

Persyaratan ini berlaku untuk semua backend penyimpanan. Untuk penyedia penyimpanan BYO (Azure Storage, Netherite, MSSQL), konfigurasikan setiap aplikasi fungsi dengan nama hub tugas terpisah. Persyaratan ini juga berlaku untuk slot penahapan: mengonfigurasi setiap slot penahapan dengan nama hub tugas yang unik.

Penting

Secara default, nama aplikasi digunakan sebagai nama hub tugas, yang memastikan bahwa berbagi yang tidak disengaja tidak terjadi. Jika Anda secara eksplisit mengonfigurasi nama hub tugas di host.json, pastikan nama tersebut unik. Satu-satunya pengecualian adalah jika Anda menyebarkan salinan aplikasi yang sama di beberapa wilayah untuk pemulihan bencana. Dalam hal ini, gunakan "task hub" yang sama untuk salinan.

Diagram berikut mengilustrasikan satu hub tugas per aplikasi fungsi di akun Azure Storage bersama dan khusus.

Cuplikan layar diagram memperlihatkan satu hub tugas per aplikasi fungsi di akun Azure Storage bersama dan khusus.

Manajemen tugas hub dalam Durable Task Scheduler

Bagian ini membahas cara membuat dan mengelola hub tugas saat menggunakan backend Durable Task Scheduler. Buat sumber daya penjadwal dan hub tugas secara eksplisit sebelum aplikasi Anda menggunakannya.

Membuat penjadwal dan hub tugas

Buat penjadwal dan hub tugas dengan menggunakan portal Azure, Azure CLI, Azure Resource Manager (ARM), atau Bicep.

  1. Di portal Microsoft Azure, cari Durable Task Scheduler dan pilih dari hasilnya.

  2. Pilih Buat untuk membuka panel pembuatan penjadwal.

  3. Isi bidang pada tab Dasar , termasuk grup sumber daya, nama penjadwal, wilayah, dan SKU. Pilih Tinjau + kreasikan.

  4. Setelah melalui validasi, pilih Buat. Penyebaran membutuhkan waktu hingga 15 menit.

  5. Setelah penjadwal dibuat, buka sumber daya penjadwal. Pada halaman Gambaran Umum , buat hub tugas baru.

Penting

Daftar 0.0.0.0/0 izin IP mengizinkan akses dari alamat IP apa pun. Untuk penyebaran produksi, batasi ini hanya untuk rentang IP yang diperlukan.

Contoh sebelumnya menggunakan SKU Khusus. Penjadwal Tugas Tahan Lama juga menawarkan SKU Konsumsi. Untuk informasi selengkapnya tentang mengelola sumber daya Durable Task Scheduler, lihat Mengembangkan dengan Durable Task Scheduler.

Mengonfigurasi autentikasi berbasis identitas

Durable Task Scheduler hanya mendukung autentikasi identitas terkelola. Ini tidak mendukung string koneksi dengan kunci penyimpanan. Tetapkan peran kontrol akses berbasis peran (RBAC) yang sesuai ke identitas terkelola dan konfigurasikan aplikasi Anda untuk menggunakan identitas tersebut.

Peran berikut tersedia:

Peranan Deskripsi
Penyumbang Data untuk Tugas Berkelanjutan Akses data penuh. Superset dari seluruh peran lainnya.
Pekerja Tugas Tahan Lama Berinteraksi dengan penjadwal sistem untuk memproses orkestrasi, aktivitas, dan entitas.
Pembaca Data Tugas Tahan Lama Akses baca-saja ke orkestrasi dan data entitas.

Nota

Sebagian besar aplikasi memerlukan peran Kontributor Data Tugas Berkelanjutan.

Gunakan identitas terkelola yang ditetapkan pengguna jika memungkinkan karena identitas tersebut tidak terkait dengan siklus hidup aplikasi dan Anda dapat menggunakannya kembali setelah aplikasi dihapus.

  1. Buka sumber daya penjadwal atau hub tugas di portal Azure.

  2. Pilih Kontrol akses (IAM) dari menu sebelah kiri.

  3. Pilih Tambahkan>Tambahkan penugasan peran.

  4. Cari dan pilih Kontributor Data Tugas Tahan Lama. Pilih Selanjutnya.

  5. Untuk Tetapkan akses ke, pilih Identitas Terkelola. Pilih + Pilih anggota.

  6. Pilih Identitas terkelola yang ditetapkan pengguna, pilih identitas, dan pilih Pilih.

  7. Pilih Tinjau + tetapkan untuk menyelesaikan.

  8. Buka aplikasi fungsi Anda, dan pilih Pengaturan>Identitas. Pilih tab Pengguna yang ditetapkan , dan tambahkan identitas.

Setelah Menetapkan identitas, tambahkan variabel lingkungan berikut ke aplikasi Anda:

Variabel Nilai
TASKHUB_NAME Nama pusat tugas Anda.
DURABLE_TASK_SCHEDULER_CONNECTION_STRING Endpoint={scheduler endpoint};Authentication=ManagedIdentity;ClientID={client id}

Nota

Jika Anda menggunakan identitas terkelola yang ditetapkan sistem, hilangkan segmen ClientID dari string koneksi: Endpoint={scheduler endpoint};Authentication=ManagedIdentity.

Untuk detail konfigurasi identitas lengkap, lihat Mengonfigurasi identitas terkelola untuk Durable Task Scheduler.

Manajemen hub tugas penyedia penyimpanan BYO

Bagian ini mencakup pembuatan dan penghapusan hub tugas dan memeriksa konten hub tugas. Ini berlaku untuk penyedia penyimpanan bring-your-own (BYO): Azure Storage, Netherite, dan MSSQL.

Penting

Saat Anda menggunakan penyedia penyimpanan BYO, Anda bertanggung jawab untuk mengamankan sumber daya penyimpanan yang mendasar. Akses tulis ke penyimpanan hub tugas dapat digunakan untuk mengubah perilaku aplikasi, termasuk memicu eksekusi kode arbitrer. Gunakan koneksi berbasis identitas, terapkan RBAC berdasarkan prinsip hak istimewa seminimal mungkin, dan batasi akses jaringan. Untuk daftar periksa pengamanan lengkap, lihat Amankan penyimpanan hub tugas Anda.

Membuat dan menghapus hub tugas

Hub tugas kosong dengan semua sumber daya yang diperlukan secara otomatis dibuat di penyimpanan saat aplikasi fungsi dimulai untuk pertama kalinya.

Jika Anda menggunakan penyedia Azure Storage, tidak diperlukan konfigurasi tambahan. Jika tidak, ikuti instruksi untuk mengonfigurasi penyedia penyimpanan untuk memastikan penyedia penyimpanan dapat menyiapkan dan mengakses sumber daya penyimpanan yang diperlukan untuk hub tugas dengan benar.

Nota

Hub tugas tidak dihapus secara otomatis saat Anda menghentikan atau menghapus aplikasi fungsi. Untuk menghapus data tersebut, secara manual hapus hub tugas, kontennya, atau akun penyimpanan yang berisi.

Petunjuk / Saran

Dalam skenario pengembangan, Anda mungkin perlu sering memulai ulang dari keadaan bersih. Untuk melakukannya dengan cepat, cukup ubah nama hub tugas yang dikonfigurasi. Perubahan ini memaksa pembuatan hub tugas baru yang kosong saat Anda menghidupkan ulang aplikasi. Data lama tidak dihapus dalam kasus ini.

Memeriksa isi dari pusat tugas

Ada beberapa cara umum untuk memeriksa konten hub tugas:

  • Dalam aplikasi fungsi, objek klien menyediakan metode untuk mengkueri penyimpanan instans. Untuk mempelajari selengkapnya tentang jenis kueri apa yang didukung, lihat artikel Manajemen Instans .
  • Demikian pula, HTTP API menawarkan permintaan REST untuk mengkueri status orkestrasi dan entitas. Lihat Referensi API HTTP untuk detail selengkapnya.
  • Alat Durable Functions Monitor dapat memeriksa hub tugas dan menawarkan berbagai opsi untuk tampilan visual.

Untuk beberapa penyedia penyimpanan, Anda juga dapat memeriksa hub tugas dengan langsung masuk ke penyimpanan yang mendasar:

  • Jika Anda menggunakan penyedia Azure Storage, status instans disimpan dalam tabel Instance dan tabel History, yang dapat Anda periksa menggunakan alat seperti Azure Storage Explorer.
  • Jika Anda menggunakan penyedia penyimpanan MSSQL, gunakan kueri dan alat SQL untuk memeriksa konten hub tugas dalam database.

Tugas kerja

Pesan aktivitas dan pesan instans di hub tugas mewakili pekerjaan yang perlu diproses aplikasi. Saat aplikasi berjalan, aplikasi terus mengambil item kerja dari hub tugas. Setiap item kerja memproses satu atau beberapa pesan. Ada dua jenis item kerja:

  • Item kerja aktivitas: Jalankan fungsi aktivitas untuk memproses pesan aktivitas.
  • Item kerja orkestrator: Jalankan fungsi orkestrator atau entitas untuk memproses satu atau beberapa pesan instans.

Pekerja dapat memproses beberapa item kerja secara bersamaan, tunduk pada batas konkurensi per pekerja yang dikonfigurasi.

Untuk informasi selengkapnya tentang pembatasan konkurensi, lihat Performa dan skala.

Setelah pekerja menyelesaikan item kerja, itu menerapkan efek kembali ke hub tugas. Efek ini bervariasi menurut jenis fungsi yang dijalankan:

  • Fungsi aktivitas yang selesai membuat pesan instans yang berisi hasilnya, yang ditujukan ke instans orkestrator induk.
  • Fungsi orkestrator yang telah selesai memperbarui status dan riwayat orkestrasi, dan dapat membuat pesan baru.
  • Fungsi entitas yang selesai memperbarui status entitas, dan juga dapat membuat pesan instans baru.

Untuk setiap orkestrasi, setiap item kerja mewakili satu episode dari eksekusi orkestrasi tersebut. Episode adalah satu putaran orkestrator yang berjalan, memproses hasil yang tersedia, lalu menjeda hingga hasil berikutnya tiba. Misalnya, episode dimulai saat orkestrasi dimulai, saat aktivitas selesai dan mengembalikan hasil, atau saat peristiwa eksternal tiba. Episode berakhir ketika orkestrator selesai atau mencapai titik di mana ia harus menunggu pesan baru.

Contoh eksekusi

Pertimbangkan orkestrasi fan-out-fan-in yang memulai dua aktivitas secara paralel dan menunggu kedua aktivitas tersebut selesai.

Model pekerja terisolasi 
[Function("Example")]
public static async Task Run([OrchestrationTrigger] TaskOrchestrationContext context)
{
  Task t1 = context.CallActivityAsync("MyActivity", 1);
  Task t2 = context.CallActivityAsync("MyActivity", 2);
  await Task.WhenAll(t1, t2);
}

Model dalam proses 
[FunctionName("Example")]
public static async Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    Task t1 = context.CallActivityAsync<int>("MyActivity", 1);
    Task t2 = context.CallActivityAsync<int>("MyActivity", 2);
    await Task.WhenAll(t1, t2);
}


using Microsoft.DurableTask;

public class Example : TaskOrchestrator<object?, object?>
{
    public override async Task<object?> RunAsync(TaskOrchestrationContext context, object? input)
    {
        Task t1 = context.CallActivityAsync("MyActivity", 1);
        Task t2 = context.CallActivityAsync("MyActivity", 2);
        await Task.WhenAll(t1, t2);
        return null;
    }
}

Setelah orkestrasi ini dimulai oleh klien, aplikasi memprosesnya sebagai urutan item kerja. Setiap item kerja yang selesai memperbarui status hub tugas saat dikonfirmasi. Berikut langkah-langkahnya:

  1. Klien meminta untuk memulai orkestrasi baru dengan instance-id "123". Setelah klien menyelesaikan permintaan ini, hub tugas berisi tempat penampung untuk status orkestrasi dan pesan instans:

    Cuplikan layar diagram yang memperlihatkan status pusat tugas setelah permintaan memulai orkestrasi di langkah pertama.

    Label adalah salah satu dari banyak jenis peristiwa riwayat yang mengidentifikasi berbagai jenis pesan dan peristiwa yang merupakan bagian dari riwayat orkestrasi.

  2. Pekerja menjalankan item kerja orkestrator untuk memproses ExecutionStarted pesan. Ini memanggil fungsi orkestrator yang mulai menjalankan kode orkestrasi. Kode ini menjadwalkan dua aktivitas dan kemudian berhenti mengeksekusi saat menunggu hasilnya.

    Cuplikan layar diagram memperlihatkan status hub tugas setelah item kerja orkestrator pertama diterapkan di langkah kedua.

    Status runtime sekarang Running, dan riwayat mencatat episode pertama ini: orkestrator dimulai, eksekusi dimulai, dua tugas dijadwalkan, dan orkestrator menyelesaikan episode.

  3. Pekerja menjalankan item kerja aktivitas untuk memproses satu TaskScheduled pesan. Ini memanggil fungsi aktivitas dengan input "2". Ketika fungsi aktivitas selesai, fungsi tersebut membuat pesan yang TaskCompleted berisi hasilnya.

    Cuplikan layar diagram memperlihatkan status hub tugas setelah item kerja aktivitas pertama diterapkan di langkah ketiga.

  4. Pekerja menjalankan item kerja orkestrator untuk memproses TaskCompleted pesan. Jika orkestrasi masih di-cache dalam memori, dapat langsung melanjutkan eksekusi. Jika tidak, pekerja terlebih dahulu memutar ulang riwayat untuk memulihkan status orkestrasi saat ini. Kemudian melanjutkan proses orkestrasi, mengantarkan hasil dari aktivitas tersebut. Setelah menerima hasil ini, orkestrasi masih menunggu hasil aktivitas lain, sehingga sekali lagi berhenti menjalankan.

    Cuplikan layar diagram yang memperlihatkan status pusat tugas setelah komitmen item kerja orkestrator kedua pada langkah keempat.

    Riwayat mencatat episode kedua: tugas selesai dan pengendali sistem dihentikan sejenak.

  5. Pekerja menjalankan item kerja aktivitas untuk memproses pesan yang tersisa TaskScheduled . Ini memanggil fungsi aktivitas dengan input "1".

    Cuplikan layar diagram memperlihatkan status hub tugas setelah item kerja aktivitas kedua diterapkan di langkah lima.

  6. Pekerja menjalankan item kerja orkestrator lain untuk memproses TaskCompleted pesan. Setelah menerima hasil kedua ini, orkestrasi selesai.

    Cuplikan layar diagram yang memperlihatkan status hub tugas setelah penggabungan item kerja terakhir oleh orkestrator di langkah enam.

    Status runtime sekarang Completed, dan riwayat mencatat episode ketiga dan terakhir: tugas kedua selesai dan eksekusi selesai.

Nota

Jadwal yang ditampilkan bukan satu-satunya kemungkinan. Misalnya, jika aktivitas kedua selesai sebelumnya, kedua TaskCompleted pesan dapat diproses oleh satu item kerja, yang hanya menghasilkan dua episode, bukan tiga.

Representasi dalam penyimpanan

Setiap penyedia penyimpanan menggunakan organisasi internal yang berbeda untuk mewakili hub tugas dalam penyimpanan. Memahami organisasi ini, meskipun tidak diperlukan, dapat membantu saat memecahkan masalah atau saat mencoba memenuhi target performa, skalabilitas, atau biaya.

Durable Task SDK menggunakan Durable Task Scheduler sebagai backend, yang mengelola status hub tugas secara internal.

Penyedia Penjadwal Tugas Tahan Lama

Durable Task Scheduler adalah penyedia backend terkelola penuh yang menyimpan semua status hub tugas secara internal. Tidak seperti penyedia penyimpanan bring-your-own (BYO), Anda tidak perlu menyiapkan atau mengelola infrastruktur penyimpanan yang mendasar. Setiap sumber daya penjadwal (Microsoft.DurableTask/schedulers) memiliki sumber daya komputasi dan memori khusus, dan dapat berisi satu atau beberapa hub tugas (Microsoft.DurableTask/schedulers/taskHubs).

Karena Penjadwal Tugas Tahan Lama mengelola penyimpanan secara internal, Anda tidak dapat langsung memeriksa data yang mendasar. Sebagai gantinya, gunakan dasbor Durable Task Scheduler untuk memantau dan mengkueri instans orkestrasi.

Untuk informasi selengkapnya tentang opsi penyedia penyimpanan BYO dan bagaimana perbandingannya, lihat penyedia penyimpanan Durable Functions.

penyedia penyimpanan Azure

Penyedia Azure Storage mewakili hub tugas dalam penyimpanan menggunakan komponen berikut:

  • Dua tabel Azure menyimpan status instans.
  • Satu Azure Queue menyimpan pesan aktivitas.
  • Satu atau beberapa antrean "Azure Queues" menyimpan pesan instans. Setiap antrean kontrol ini mewakili sebuah partisi yang ditugaskan subset dari semua pesan instans, berdasarkan hash dari ID instans.
  • Beberapa kontainer blob tambahan yang digunakan untuk blob sewa atau pesan besar.

Sebagai contohnya, hub tugas bernama xyz dengan PartitionCount = 4 berisi antrean dan tabel berikut:

Cuplikan layar diagram memperlihatkan organisasi hub tugas penyedia Azure Storage dengan empat antrean kontrol.

Bagian berikut menjelaskan komponen-komponen ini dan perannya secara lebih rinci.

Untuk informasi selengkapnya tentang bagaimana hub tugas diwakili oleh penyedia Azure Storage, lihat dokumentasi penyedia Azure Storage.

Penyedia penyimpanan Netherite (Jalur penghentian penggunaan)

Netherite mempartisi semua status hub tugas ke dalam jumlah partisi tertentu. Di penyimpanan, sumber daya ini menyimpan data:

  • Satu Azure Storage kontainer blob yang berisi semua blob, dikelompokkan menurut partisi.
  • Satu tabel Azure yang berisi metrik yang telah dipublikasikan tentang partisi.
  • Namespace Azure Event Hubs untuk mengirimkan pesan antar partisi.

Misalnya, hub tugas bernama mytaskhub dengan PartitionCount = 32 diwakili dalam penyimpanan sebagai berikut:

Cuplikan layar diagram memperlihatkan organisasi penyimpanan Netherite untuk hub tugas dengan 32 partisi.

Nota

Semua status hub tugas disimpan di dalam x-storage kontainer blob. Tabel DurableTaskPartitions dan namespace Layanan Pusat Aktivitas berisi data berlebihan: jika kontennya hilang, mereka dapat dipulihkan secara otomatis. Oleh karena itu, Anda tidak perlu mengonfigurasi namespace Azure Event Hubs untuk mempertahankan pesan melewati waktu kedaluwarsa default.

Netherite menggunakan mekanisme sumber peristiwa, berdasarkan log dan titik pemeriksaan, untuk mewakili status partisi saat ini. Blob blok dan blob halaman keduanya menyimpan data. Anda tidak dapat membaca format ini dari penyimpanan secara langsung, sehingga aplikasi fungsi harus berjalan saat Anda mengkueri penyimpanan instans.

Untuk informasi selengkapnya tentang hub tugas untuk penyedia penyimpanan Netherite, lihat Informasi Hub Tugas untuk penyedia penyimpanan Netherite.

Penyedia penyimpanan MSSQL

Semua data hub tugas disimpan dalam database relasional tunggal, menggunakan tabel ini:

  • Tabel dt.Instances dan dt.History menyimpan status instans.
  • Tabel dt.NewEvents menyimpan pesan instans.
  • Tabel dt.NewTasks menyimpan pesan aktivitas.

Cuplikan layar diagram memperlihatkan organisasi hub tugas penyedia penyimpanan MSSQL dengan tabel database.

Untuk memungkinkan beberapa hub tugas berdampingan dalam keadaan independen di database yang sama, setiap tabel menyertakan kolom TaskHub sebagai bagian dari kunci utamanya. Tidak seperti dua penyedia lainnya, penyedia MSSQL tidak memiliki partisi.

Untuk informasi selengkapnya tentang hub tugas untuk penyedia penyimpanan MSSQL, lihat Informasi Hub Tugas untuk penyedia penyimpanan Microsoft SQL (MSSQL).

Langkah berikutnya

Pelajari cara menangani versi orkestrasi

Langkah berikutnya

Mulai menggunakan Durable Task SDK

  • Last updated on