Membangun sistem notifikasi [ditutup]

Saya pada awalnya membangun sistem pemberitahuan gaya Facebook untuk halaman kami (tipe game sosial) dan saya sekarang sedang meneliti apa yang akan menjadi cara terbaik untuk merancang sistem seperti itu. Saya tidak tertarik tentang cara mendorong pemberitahuan ke pengguna atau hal-hal seperti itu (untuk saat ini bahkan). Saya sedang meneliti bagaimana membangun sistem di server (cara menyimpan notifikasi, tempat menyimpannya, cara mengambilnya, dll ...).

Jadi ... beberapa persyaratan yang kami miliki:

• pada waktu puncak, kami memiliki sekitar 1 r pengguna yang masuk secara bersamaan (dan lebih banyak tamu, tetapi mereka tidak penting di sini karena mereka tidak akan memiliki pemberitahuan) yang akan menghasilkan banyak acara
• akan ada berbagai jenis notifikasi (pengguna A telah menambahkan Anda sebagai teman, pengguna B telah mengomentari profil Anda, pengguna C menyukai gambar Anda, pengguna D telah mengalahkan Anda di game X, ...)
• sebagian besar acara akan menghasilkan 1 pemberitahuan untuk 1 pengguna (pengguna X menyukai gambar Anda), tetapi akan ada kasus di mana satu acara akan menghasilkan banyak pemberitahuan (misalnya, ulang tahun pengguna Y)
• pemberitahuan harus dikelompokkan bersama; jika misalnya empat pengguna berbeda menyukai beberapa gambar, pemilik gambar tersebut harus mendapatkan satu pemberitahuan yang menyatakan bahwa empat pengguna menyukai gambar dan bukan empat pemberitahuan terpisah (seperti halnya FB)

OK jadi yang saya pikirkan adalah saya harus membuat semacam antrian di mana saya akan menyimpan acara ketika itu terjadi. Lalu saya akan memiliki pekerjaan latar belakang ( tukang gigi ?) Yang akan melihat antrian itu dan menghasilkan pemberitahuan berdasarkan peristiwa-peristiwa itu. Pekerjaan ini kemudian akan menyimpan notifikasi dalam database untuk setiap pengguna (jadi jika suatu peristiwa memengaruhi 10 pengguna, akan ada 10 notifikasi terpisah). Kemudian ketika pengguna akan membuka halaman dengan daftar notifikasi saya akan membaca semua notifikasi untuknya (kami berpikir untuk membatasi ini hingga 100 notifikasi terbaru) dan mengelompokkannya bersama dan akhirnya menampilkannya.

Hal yang saya khawatirkan dengan pendekatan ini:

• kompleks sekali :)
• adalah basis data penyimpanan terbaik di sini (kami menggunakan MySQL) atau haruskah saya menggunakan sesuatu yang lain (redis sepertinya cocok juga)
• apa yang harus saya simpan sebagai pemberitahuan? ID pengguna, ID pengguna yang memprakarsai acara, jenis acara (sehingga saya dapat mengelompokkannya dan menampilkan teks yang sesuai) tetapi kemudian saya agak tidak tahu cara menyimpan data notifikasi yang sebenarnya (misalnya URL & judul gambar yang disukai). Haruskah saya "memanggang" info itu ketika saya menghasilkan pemberitahuan, atau haruskah saya menyimpan ID catatan (gambar, profil, ...) yang terpengaruh dan menarik info keluar dari DB saat menampilkan pemberitahuan.
• kinerja harusnya OK di sini, bahkan jika saya harus memproses 100 notifikasi secara langsung saat menampilkan halaman notifikasi
• kemungkinan masalah kinerja pada setiap permintaan karena saya harus menampilkan jumlah pemberitahuan yang belum dibaca kepada pengguna (yang bisa menjadi masalah tersendiri karena saya akan mengelompokkan pemberitahuan bersama). Ini bisa dihindari meskipun jika saya membuat tampilan pemberitahuan (di mana mereka dikelompokkan) di latar belakang dan tidak on-the-fly

Jadi apa yang Anda pikirkan tentang solusi yang saya usulkan dan kekhawatiran saya? Berikan komentar jika Anda pikir saya harus menyebutkan hal lain yang relevan di sini.

Oh, kami menggunakan PHP untuk halaman kami, tapi itu seharusnya tidak menjadi faktor besar di sini.

Pemberitahuan adalah sesuatu (objek = acara, pertemanan ..) sedang diubah (kata kerja = ditambahkan, diminta ..) oleh seseorang (aktor) dan dilaporkan kepada pengguna (subjek). Berikut adalah struktur data yang dinormalisasi (meskipun saya telah menggunakan MongoDB). Anda perlu memberi tahu pengguna tertentu tentang perubahan. Jadi itu adalah pemberitahuan per pengguna .. artinya jika ada 100 pengguna yang terlibat, Anda menghasilkan 100 pemberitahuan.

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║—1:n—→║ID                 ║—1:n—→║ID                  ║
║userID       ║      ║notificationID     ║      ║notificationObjectID║
╚═════════════╝      ║object             ║      ║verb                ║
                     ╚═══════════════════╝      ║actor               ║
                                                ╚════════════════════╝

(Tambahkan bidang waktu yang Anda inginkan)

Ini pada dasarnya untuk mengelompokkan perubahan per objek, sehingga Anda dapat mengatakan "Anda memiliki 3 permintaan teman". Dan pengelompokan per aktor berguna, sehingga Anda bisa mengatakan "Pengguna James Bond membuat perubahan di tempat tidur Anda". Ini juga memberikan kemampuan untuk menerjemahkan dan menghitung notifikasi sesuka Anda.

Tapi, karena objek hanyalah ID, Anda perlu mendapatkan semua info tambahan tentang objek yang Anda inginkan dengan panggilan terpisah, kecuali objek benar-benar berubah dan Anda ingin menunjukkan riwayat itu (jadi misalnya "pengguna mengubah judul acara menjadi ... ")

Karena notifikasi dekat dengan realtime untuk pengguna di situs, saya akan mengikat mereka dengan klien nodejs + websockets dengan php mendorong pembaruan ke nodejs untuk semua pendengar saat perubahan ditambahkan.

Ini benar-benar sebuah pertanyaan abstrak, jadi saya kira kita hanya perlu membahasnya daripada menunjukkan apa yang harus atau tidak seharusnya Anda lakukan.

Inilah yang saya pikirkan tentang kekhawatiran Anda:

• Ya, sistem notifikasi itu rumit, tetapi tidak terlalu besar. Anda dapat memiliki banyak pendekatan berbeda dalam pemodelan dan penerapan sistem seperti itu, dan mereka dapat memiliki dari tingkat kompleksitas menengah hingga tinggi;

• Biasanya, saya selalu mencoba membuat hal-hal yang didorong oleh basis data. Mengapa? Karena saya dapat menjamin memiliki kendali penuh atas semua yang terjadi - tetapi itu hanya saya, Anda dapat memiliki kontrol tanpa pendekatan berbasis database; percayalah, Anda akan ingin mengendalikan kasus itu;

• Biarkan saya memberi contoh kasus nyata untuk Anda, sehingga Anda dapat mulai dari suatu tempat. Pada tahun lalu saya telah membuat model dan menerapkan sistem notifikasi di beberapa jenis jejaring sosial (tidak seperti facebook, tentu saja). Cara saya dulu menyimpan notifikasi di sana? Saya memiliki notificationstabel, tempat saya menyimpan generator_user_id(ID pengguna yang menghasilkan notifikasi), target_user_id(agak jelas, bukan?), notification_type_id(Yang merujuk ke tabel berbeda dengan tipe notifikasi), dan semua hal-hal yang perlu kita isi dengan tabel kita (cap waktu, bendera, dll). notification_typesTabel saya dulunya memiliki hubungan dengannotification_templates tabel, yang menyimpan template spesifik untuk setiap jenis notifikasi. Sebagai contoh, saya memiliki POST_REPLYtipe, yang memiliki jenis template seperti {USER} HAS REPLIED ONE OF YOUR #POSTS. Dari sana, saya baru saja merawat{}sebagai variabel dan #sebagai tautan referensi;

• Ya, kinerja harus dan harus baik-baik saja. Ketika Anda memikirkan pemberitahuan, Anda berpikir tentang server mendorong dari ujung ke ujung. Entah jika Anda akan melakukannya dengan permintaan ajax atau apa pun, Anda harus khawatir tentang kinerja. Tapi saya pikir itu adalah keprihatinan kedua kalinya;

Model yang saya rancang, tentu saja, bukan satu-satunya yang dapat Anda ikuti, bukan yang terbaik juga. Saya harap jawaban saya, setidaknya, mengikuti Anda ke arah yang benar.

╔════════════════════╗
║notification        ║
╟────────────────────╢
║Username            ║
║Object              ║
║verb                ║
║actor               ║
║isRead              ║
╚════════════════════╝

Ini terlihat jawaban yang bagus daripada memiliki 2 koleksi. Anda dapat meminta nama pengguna, objek, dan isRead untuk mendapatkan acara baru (seperti 3 permintaan pertemanan yang tertunda, 4 pertanyaan diajukan, dll ...)

Beri tahu saya jika ada masalah dengan skema ini.

Saya pribadi tidak mengerti dengan baik diagram untuk jawaban yang diterima, Jadi saya akan melampirkan basis data diagram berdasarkan apa yang bisa saya pelajari dari jawaban yang diterima dan halaman lain.

Perbaikan diterima dengan baik.