Aliran Data TPL vs Semafor biasa

Proses ini sebagian besar memiliki operasi IO dengan beberapa operasi CPU kecil (terutama deserialisasi string).

Itu hanya I/O. Kecuali jika string tersebut besar, deserialisasi tidak akan layak untuk diparalelkan. Jenis pekerjaan CPU yang Anda lakukan akan hilang dalam kebisingan.

Jadi, Anda sebaiknya fokus pada asinkroni secara bersamaan.

• SemaphoreSlim adalah pola standar untuk ini, seperti yang Anda temukan.
• TPL Dataflow juga dapat melakukan konkurensi (baik bentuk asinkron maupun paralel).

ForEachAsync dapat mengambil beberapa bentuk; perhatikan bahwa dalam postingan blog yang Anda rujuk, ada 5 implementasi berbeda dari metode ini, yang masing-masing valid. "[T]ada banyak semantik berbeda yang mungkin untuk diulang, dan masing-masing akan menghasilkan pilihan desain dan implementasi yang berbeda." Untuk tujuan Anda (tidak menginginkan paralelisasi CPU), Anda tidak boleh mempertimbangkan yang menggunakan Task.Run atau mempartisi. Dalam dunia konkurensi asinkron, implementasi ForEachAsync apa pun hanya akan menjadi gula sintaksis yang menyembunyikan semantik mana yang diimplementasikan, itulah sebabnya saya cenderung menghindarinya.

Ini menyisakan SemaphoreSlim vs. ActionBlock. Saya biasanya menyarankan orang-orang memulai dengan SemaphoreSlim terlebih dahulu, dan mempertimbangkan untuk pindah ke TPL Dataflow jika kebutuhan mereka menjadi lebih kompleks (dengan cara yang tampaknya mereka akan mendapat manfaat dari saluran dataflow).

Misalnya, "Bagian dari persyaratannya adalah membuat derajat paralelisme dapat dikonfigurasi."

Anda dapat memulai dengan mengizinkan tingkat konkurensi - di mana hal yang dibatasi adalah satu keseluruhan operasi (mengambil data dari url, membatalkan serialisasi data yang diunduh ke objek, bertahan dalam dinamika crm dan ke database lain, dan memperbarui database pertama). Di sinilah SemaphoreSlim akan menjadi solusi sempurna.

Namun Anda mungkin memutuskan ingin memiliki beberapa tombol: katakanlah, satu tingkat konkurensi untuk berapa banyak url yang Anda unduh, dan tingkat konkurensi terpisah untuk bertahan, dan tingkat konkurensi terpisah untuk memperbarui database asli. Dan kemudian Anda juga perlu membatasi "antrian" di antara titik-titik ini: hanya sejumlah objek yang dideserialisasi dalam memori, dll. - untuk memastikan bahwa url cepat dengan database lambat tidak menyebabkan masalah dengan aplikasi Anda yang menggunakan terlalu banyak Penyimpanan. Jika ini adalah semantik yang berguna, maka Anda sudah mulai mendekati masalah dari perspektif aliran data, dan itulah poin yang mungkin lebih baik Anda gunakan dengan pustaka seperti TPL Dataflow.

Berikut adalah nilai jual dari pendekatan Semaphore:

1. Kesederhanaan

Dan inilah nilai jual dari pendekatan TPL Dataflow:

1. Paralelisme tugas di atas paralelisme data
2. Pemanfaatan sumber daya secara optimal (bandwidth, CPU, koneksi database)
3. Tingkat paralelisme yang dapat dikonfigurasi untuk setiap operasi heterogen
4. Mengurangi jejak memori

Mari kita tinjau implementasi Semaphore berikut sebagai contoh:

string[] urls = FetchUrlsFromDB();
var cts = new CancellationTokenSource();
var semaphore = new SemaphoreSlim(10); // Degree of parallelism (DOP)
Task[] tasks = urls.Select(url => Task.Run(async () =>
{
    await semaphore.WaitAsync(cts.Token);
    try
    {
        string rawData = DownloadData(url);
        var data = Deserialize(rawData);
        PersistToCRM(data);
        MarkAsCompleted(url);
    }
    finally
    {
        semaphore.Release();
    }
})).ToArray();
Task.WaitAll(tasks);

Implementasi di atas memastikan bahwa maksimal 10 url akan diproses secara bersamaan pada saat tertentu. Namun tidak akan ada koordinasi antara alur kerja paralel ini. Jadi, misalnya, sangat mungkin bahwa pada saat tertentu seluruh 10 alur kerja paralel akan mengunduh data, pada saat lain kesepuluh alur kerja tersebut akan melakukan deserialisasi data mentah, dan pada saat lain kesepuluh alur kerja tersebut akan menyimpan data ke CRM. Ini jauh dari ideal. Idealnya, Anda ingin agar kemacetan seluruh operasi, baik adaptor jaringan, CPU, atau server database, bekerja tanpa henti sepanjang waktu, dan tidak kurang dimanfaatkan (atau benar-benar menganggur) pada berbagai momen acak.

Pertimbangan lainnya adalah seberapa banyak paralelisasi yang optimal untuk setiap operasi heterogen. 10 DOP mungkin optimal untuk komunikasi dengan web, namun terlalu rendah atau terlalu tinggi untuk komunikasi dengan database. Pendekatan Semaphore tidak memungkinkan adanya tingkat penyesuaian seperti itu. Satu-satunya pilihan Anda adalah berkompromi dengan memilih nilai DOP di antara nilai optimal ini.

Jika jumlah url sangat besar, katakanlah 1.000.000, maka pendekatan Semaphore di atas juga menimbulkan pertimbangan penggunaan memori yang serius. Sebuah url mungkin memiliki ukuran rata-rata 50 byte, sedangkan Task yang terhubung ke CancellationToken mungkin 10 kali lebih berat atau lebih. Tentu saja Anda dapat mengubah penerapannya dan menggunakan SemaphoreSlim dengan cara yang lebih cerdas sehingga tidak menghasilkan banyak tugas, namun hal ini bertentangan dengan nilai jual utama (dan satu-satunya) dari pendekatan ini, yaitu kesederhanaannya.

Pustaka Aliran Data TPL memecahkan semua masalah ini, dengan mengorbankan kurva pembelajaran (yang kecil) yang diperlukan untuk dapat menjinakkan alat canggih ini.