Apa arsitektur server terbaik untuk game waktu nyata?

Saya sedang mengembangkan game Real-Time yang seharusnya menampung ribuan pemain secara real-time (seperti FPS. Max 1s lag). Apa infrastruktur terbaik untuk ini?

Ide saya menggunakan 2 cluster server - satu untuk Server End (semua sisi komputasi) dan satu untuk Database, di mana load balancer "bertanggung jawab" untuk masing-masing cluster. Satu server utama akan menerima permintaan dari pengguna dan mengirimkan kembali alamat IP dari server terkait yang dapat digunakan oleh pengguna ini.

Cluster database akan menggunakan replikasi database untuk konsistensi antara database.

Harus ada penyeimbang beban geografis juga - jadi ini akan menetapkan penyeimbang beban regional untuk setiap pengguna untuk respons terbaik.

Saya menggunakan .NET + MSSQL untuk game.

Terima kasih!

server client-server .net

— Roma
sumber

Ketika Anda mengatakan "infrastruktur" maksud Anda perangkat lunak, perangkat keras, layanan, atau apakah Anda hanya ingin kami mengkritik rencana Anda yang ada?

— Tetrad

@Nate - kami berencana untuk meningkatkan, bukan duplikat - jadi itu harus sepenuhnya scalable.

— Roman

-1 karena teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html - Anda tidak memenuhi persyaratan kapasitas apa pun, Anda mengatakan game tidak berbelok tapi dikategorikan zonasi , dll. Sifat optimalisasi kinerja - termasuk skalabilitas - memerlukan informasi spesifik, dan tidak ada arsitektur terbaik mutlak.

Saya akan mengubah pertanyaan Anda menjadi sesuatu yang lebih konkret. Apa yang 'terbaik', dengan cara faktual, non-subyektif? Apakah yang Anda maksud adalah skala termudah, termudah untuk dikelola, termudah untuk maju, tercepat, atau apa?

— Bebek Komunis

"Paling mudah" juga subjektif. Paling mudah untuk siapa, selama jangka waktu berapa, diberikan sumber daya apa? Stack Exchanges bekerja paling baik dengan pertanyaan spesifik - "Saya telah membangun server ini menggunakan LINQ dan MSSQL, tetapi jatuh setelah 70 transaksi / detik, berikut adalah dua transaksi teratas saya yang menghitung 73% dari runtime saya, bagaimana saya harus meningkatkan throughput saya? "

Jawaban:

Tidak ada arsitektur terbaik tanpa mengetahui lebih banyak tentang persyaratan Anda, mis. jenis interaksi antar karakter, berapa banyak data yang akan bertahan, dan sebagainya.

Jika Anda dapat mengatasi latensi 1 detik, Anda mungkin dapat meng-host 1000 pemain di server tunggal tanpa masalah - tetapi itu sebenarnya bertentangan dengan ide FPS karena mereka biasanya membutuhkan latensi yang jauh lebih rendah, misalnya. kurang dari 100 ms. Tetapi sistem yang dapat menangani latensi tinggi mampu melakukan semuanya melalui pesan yang membuat konsistensi cukup sepele. Memberikan logika Anda cukup sederhana, yaitu - logika kompleks menjadi lebih buruk ketika Anda mengubahnya menjadi sistem berbasis pesan daripada sistem objek-terkunci - tetapi semuanya tergantung pada kebutuhan aplikasi Anda.

Demikian pula, jika Anda tidak memiliki banyak data, Anda tidak perlu mesin database sama sekali, tetapi tanpa menyadarinya, sulit untuk mengatakannya. Jika Anda bertahan dalam jumlah kecil data, dan mungkin hanya melakukannya pada akhir turnamen atau sesuatu, sekali lagi Anda tidak memerlukan database terpisah, tentu saja bukan sekelompok mereka. Di sisi lain, jika Anda tidak banyak membaca tetapi banyak membaca, di situlah basis data yang direplikasi dapat membantu Anda - tetapi juga menunjukkan bahwa basis data relasional mungkin bukan yang paling cocok untuk masalah Anda. Seringkali cache dalam memori adalah solusi yang lebih baik. Demikian pula, jika tidak ada interaksi gaya transaksi antara karakter, maka konsistensi menjadi kurang penting. (Dan jika hanya ada beberapa transaksi seperti itu, Anda dapat menjadikannya sebagai kasus khusus.)

Bahkan, berhati-hatilah dalam mengadopsi RDBMS hanya karena itu adalah hal yang dilakukan dalam sistem besar. Meskipun saya pribadi setuju untuk menggunakannya dalam game online, yang terbaik adalah melihat kebutuhan Anda dan mencari tahu strategi kegigihan Anda dari itu, daripada mengambil database pilihan Anda dan kemudian mencoba untuk men-tweak dengan cache dan replikasi agar sesuai dengan kebutuhan Anda aplikasi. Anda mungkin menemukan bahwa yang Anda butuhkan adalah kemampuan pelaporan offline, dalam hal ini mungkin yang terbaik untuk memiliki proses latar belakang masuk dari mekanisme kegigihan game Anda ke RDBMS jarak jauh di tempat lain.

— Kylotan
sumber

Penafian: pengalaman pemrograman gim saya didasarkan pada gim pemain tunggal sisi-klien, tetapi saya memiliki latar belakang dalam aplikasi web (khususnya pada tumpukan Microsoft), jadi dari sanalah saya berasal dengan jawaban ini, saya merasa bahwa banyak yang akan berlaku, tetapi tanpa pengujian server game sebenarnya sulit untuk mengatakan bagaimana itu akan berlaku, tapi begini. Ketahuilah ini: Saya belum menggunakan server game, hanya webapps.

Saya akan menyarankan pendekatan dua (server). Tingkat basis data dan tingkat "aplikasi"; dengan tingkat ketiga (presentasi) menjadi klien gim Anda.

Database relasional, hebat dalam query data, dan layak dalam menulis data. Kuncinya adalah untuk membuat serialisasi penulisan database Anda menjadi potongan ukuran yang dapat dikelola yang dapat ditangani oleh kluster Anda. Edisi yang lebih canggih (Pusat data / Perusahaan) dari SQL Server mendukung pengelompokan dan replikasi. Saya akan mulai dengan membangun sebuah cluster kecil dan menjalankan beberapa pertanyaan untuk mengetahui cara kerjanya.

Di tier aplikasi, jika Anda melakukan "zonasi" atau sesuatu yang serupa, Anda mungkin bisa pergi tanpa mengatur cluster apa pun, dan cukup menyiapkan server per zona. Jika zona Anda menjadi besar, Anda bisa menyiapkan cluster untuk setiap zona.

Anda akan ingin membangun proses serialisasi untuk mengirim data dari tingkat aplikasi -> tingkat basis data. Kuncinya adalah memiliki beberapa tingkat serialisasi yang terjadi. Sesuatu seperti ini:

Level 1: Simpan ke DB setiap X detik, termasuk data penting:
- Kesehatan Pemain
- Item Pemain / Pickup
Level 2: Simpan ke DB setiap 2X detik, termasuk data sedang:
- Lokasi pemain
- Lokasi NPC
Level 3: Segala sesuatu yang lain, sesering mungkin

Ini akan membuat tulisan Anda konsisten dan dapat diprediksi, tergantung pada sifat permainan Anda, Anda bisa menulis database yang jarang. Kuncinya adalah menyadari bahwa jika server aplikasi Anda macet, Anda harus kembali online dari status di basis data Anda, sehingga membuat serialisasi inventaris pemain setiap 90 menit mungkin membuat pemain kesal.

Untuk membaca data, Anda harus memuat sebanyak mungkin ke dalam memori di tingkat aplikasi sebanyak mungkin, lalu pastikan bahwa semua kode Anda menggunakan kumpulan memori ini, di latar belakang Anda dapat menyinkronkan kumpulan memori dengan database. Seperti yang ditunjukkan oleh Joe, akan ada saatnya Anda membutuhkan transaksi "real-time". Dengan membuat serial sebagian besar tulisan Anda, Anda masih harus memiliki IO yang cukup pada database Anda untuk melakukan transaksi real-time bila perlu, dengan anggapan hardware yang memadai pada server database / cluster.

— Nate
sumber

-1 karena Anda baru saja membuang ACID dan hanya menggunakan database sebagai penyimpan data besar. Tidak apa-apa, penjadwal disk Windows cukup jelek yang masih merupakan peningkatan kinerja, dan Anda mungkin dapat melakukan beberapa metrik offline yang rapi dengan data di dalamnya, tetapi Anda masih memerlukan ACID - yaitu database - yang mendukung transaksi dalam game itu sendiri, dalam waktu (ish) yang sebenarnya.

Meskipun jarang, itulah yang akan saya tuju di paragraf terakhir. Saya merekomendasikan sedikit hibrida, di mana Anda menggunakan IN-Memory jika memungkinkan, dan database bila perlu.

— Nate

Masalahnya adalah bahwa Anda telah menutupi apa yang ada dalam memori, yang merupakan seluruh basis data lainnya, dan Anda tidak memberikan arahan tentang bagaimana mengimplementasikannya, yang sebenarnya merupakan bagian yang sulit.

Benar, meskipun pertanyaannya adalah tentang arsitektur gambar besar, bukan detail implementasi.

— Nate

Benar, tetapi Anda telah meninggalkan seluruh tingkat menengah. Apakah RDB latensi rendah? Sebuah ODB? Toko kunci / nilai? Tidak ada DB dan menyerah pada ACID? STM atau mengunci? Agar adil, sangat sulit untuk menjawab itu karena tidak ada banyak informasi dalam pertanyaan, tetapi semua jawaban ini terhadap diagram arsitektur adalah mengambil gelembung besar di tengah dengan tanda "?" di dalamnya dan menghubungkan dua layanan lagi ke sana, tidak benar-benar mengisi apa "?" adalah.