Apa cara yang tepat untuk menghitung kredit di ruang obrolan komersial?

Saya sedang mengerjakan proyek yang menyediakan pengguna untuk mengobrol dengan para ahli di ruang obrolan pribadi. Pengguna membeli kredit untuk mengobrol dengan para ahli dan mereka akan dikenakan biaya di akhir setiap sesi obrolan berdasarkan menit mereka berbicara. Setiap pakar memiliki tingkat kredit yang berbeda untuk setiap menit obrolan.

Pengatur waktu mulai menghitung pada awal sesi obrolan dan pengguna diberi tahu secara berkala tentang total waktu yang mereka habiskan di ruang obrolan dan total kredit saat ini dari sesi obrolan saat ini. Perhitungan ini harus dilakukan di sisi server dan disimpan di database. Btw sesi chat bisa dijeda/dilanjutkan oleh ahlinya.

Ini adalah skenario sederhana...
Pengguna saat ini memiliki: 10 Kredit
"Pakar A" meminta 2 kredit / per menit

CurrentTime Event       Timer       Credit
  • 10:40 Sesi Obrolan Dimulai 00:01 mnt 2kredit
  • 10:41 Mereka mengobrol 00:02 menit 4kredit
  • 10:42 Pakar saat menganggur 00:02 menit 4kredit (Obrolan dijeda)
  • 10:45 Pakar menjadi online 00:02 menit 4kredit (Obrolan dilanjutkan)
  • 10:46 Mereka mengobrol 00:03 menit 6kredit
  • 10:46 Klien mengakhiri sesi 00:04 menit 8kredit

Klien akan dikenakan biaya sebesar 8 SKS. Dia memiliki sisa 2 SKS.

Sesi Obrolan akan dikenakan biaya di awal menit baru, penghitungan akan dilakukan berdasarkan menit, detik akan dihilangkan.

Pertanyaan saya adalah bagaimana membuat perhitungan ini di sisi server untuk setiap sesi obrolan yang sedang dibicarakan dengan cara yang benar?

Pendekatan saya saat ini adalah;

Pengatur waktu sisi server menyala setiap 15 detik, membuat sesi obrolan saat ini dibicarakan,

Untuk setiap sesi obrolan: jika sesi obrolan tidak dijeda, tambahkan 15 detik ke rentang waktu sesi, lalu hitung total kredit sesi saat ini, jika pengguna hampir kehabisan kredit, beri tahu dia, jika dia sudah menjalankan kehabisan kredit, lalu akhiri sesi obrolan saat ini. Simpan transaksi ini ke database. Perbarui klien sesi obrolan.

Namun ada beberapa kendala dalam pendekatan ini. Misalnya, jika sesi obrolan dimulai sekarang dan pengatur waktu terus berjalan 2 detik, maka total rentang waktu sesi obrolan saat ini akan bertambah 15 detik sehingga terjadi kesalahan perhitungan. Jika saya mengurangi interval centang pengatur waktu, maka mungkin ada 500 sesi obrolan yang sedang dibicarakan, dan interval centang pengatur waktu tidak akan cukup untuk menghitung setiap kredit sesi obrolan dalam 10 detik misalnya.

Apakah ada cara yang lebih baik untuk menangani ini? Semua saran dipersilakan.

Omong-omong, saya menggunakan Asp.net MVC4 C# dan Signalr untuk menangani obrolan waktu nyata.

Terima kasih sebelumnya.


c# asp.net-mvc signalr algorithm
person Fevzi Apaydın    schedule 17.04.2013    source sumber
comment
Sepertinya Anda perlu mengetahui secara akurat jam berapa obrolan dimulai/dihentikan/dijeda/dilanjutkan. Jika sistem obrolan yang Anda gunakan tidak menyediakan hal tersebut, maka mungkin setiap detik (atau beberapa detik) Anda dapat menyimpan daftar semua sesi obrolan yang aktif, dan menggunakan data ini setiap 15 detik untuk melakukan pekerjaan yang lebih mahal untuk memproses sepenuhnya semuanya. Berhati-hatilah jika Anda tidak dapat memproses beban Anda saat ini dalam 10 detik, maka beban tersebut hanya perlu ditingkatkan sebesar 50% dan Anda juga tidak akan dapat melakukannya dalam 15 detik. Jadi, Anda mungkin harus segera mempertimbangkan untuk membuatnya lebih efisien, atau menambah kapasitas.   -  person Steve Jessop    schedule 17.04.2013
comment
Mengapa perhitungan ini dijalankan secara batch? Menurut saya akan lebih mudah untuk menjadikannya berdasarkan peristiwa: setiap n kali pesan dikirim melalui program obrolan (baik dari pakar atau pengguna), periksa total waktu yang dihabiskan dan hitung kredit dan bertindak karenanya pada mereka dari sana. Dengan begitu, ini dilakukan per sesi obrolan, dan lebih tepat serta lebih mudah diskalakan dibandingkan menganalisis semua sesi secara massal.   -  person Scott Mermelstein    schedule 17.04.2013
comment
@ScottMermelstein Ada banyak sekali kasus berbeda, seperti Jika pakar tidak menulis selama 2 menit atau lebih, jeda sesi obrolan. Jadi menurut saya saya harus menggunakan pengatur waktu. Mungkin, saya tidak akan dapat mendeteksi apakah pengguna kehabisan kredit jika seseorang tidak menulis selama 2 menit pada pendekatan Anda.   -  person Fevzi Apaydın    schedule 17.04.2013
comment
Anda dapat menjadikan obrolan di satu sisi atau sisi lain sebagai master penghitungan waktu. Jika pengguna mengajukan pertanyaan dan pakar tidak pernah menjawab, sebenarnya tidak ada biaya apa pun. Setelah pakar merespons, Anda dapat menggunakan stempel waktu respons tersebut untuk menghitung durasi obrolan saat ini, dll.   -  person Chris Pratt    schedule 17.04.2013

Jawaban (1)


arrow_upward
0
arrow_downward

Saya rasa penting bagi Anda untuk tidak melakukan operasi secara massal. Seperti yang Anda nyatakan, Anda mendapatkan masalah dengan ketepatan cara mengisi daya. Dan saya yakin Anda menyadari bahwa penskalaan yang cepat menjadi sebuah masalah. Jauh lebih baik jika semuanya didorong oleh peristiwa.

Seperti yang saya sarankan di komentar, bagian dari ini memerlukan penghitungan waktu yang digunakan dengan tepat. Hal ini mudah dilakukan - simpan waktu mulai (atau waktu mulai pakar, bergantung pada preferensi Anda), dan kurangi dari waktu berakhir, lalu tagih sesuai dengan itu.

Masalah yang dapat ditimbulkan:

  • Kapan waktu berakhirnya? Saat itulah program chat ditutup, baik melalui waktu tunggu sesi, akhir pakar, atau akhir pengguna. Bergantung pada struktur penagihan Anda, saya menganjurkan agar waktu berakhir dalam konteks ini juga menyertakan jeda sesi. Untuk tujuan penghitungan biaya, setiap iterasi mulai-jeda dapat dihitung secara terpisah (meskipun idealnya, iterasi tersebut dikelompokkan bersama dalam ringkasan penagihan). Anda dapat memeriksa setiap kali pesan dikirim untuk melihat apakah pengguna masih memiliki pulsa.
  • What about idle time? How do we account for the user idling for more time than they have, between messages? It shouldn't matter, really. Next time a message is sent, you can tell them they're past due. They may get annoyed that they spent a few minutes typing a message that won't get sent, but there are ways to avoid that.
    • If you do check the billing every time a message is sent, it's easy to note when they're running low, and issue a warning.
    • Berikut cara berpikir penagihan yang sangat berbeda: setelah sesi dimulai, server Anda dapat menghitung berdasarkan tarif dan saldo berapa lama sesi dapat berlangsung. Kecuali ada event stop atau jeda sebelum itu, Anda tahu persis kapan kreditnya habis, dan jika ada resume dari jeda, Anda bisa menghitung ulang berdasarkan sisa waktu.

Apa yang sebenarnya saya sarankan agar Anda lakukan didasarkan pada poin-poin terakhir itu. Saat memulai atau melanjutkan sesi, hitung berdasarkan kredit kapan sesi akan berakhir. Pertahankan sesi dalam daftar yang diurutkan, diurutkan berdasarkan waktu kedaluwarsa. Kemudian, sisi server Anda akan mempermudahnya - periksa apakah waktunya sudah setelah waktu berakhirnya sesi. Jika ya, tekan pemberitahuan akhir.

Saat membaca kembali kebutuhan Anda, ide saya mungkin terlalu pasif untuk apa yang Anda butuhkan. Satu pertanyaannya adalah seberapa pentingkah semua perhitungan dilakukan di sisi server? Saya akan menganjurkan agar klien tetap menjalankan pengatur waktu sesi dan kalkulator biaya, supaya pengguna dapat melihatnya tanpa lalu lintas klien/server. Server itu sendiri masih bertanggung jawab atas sisi penagihan.

Jika tidak, jika Anda harus mengirimkan pemberitahuan untuk waktu dan keseimbangan, saya akan tetap melakukannya secara individual, bukan dalam operasi massal. Anda dapat memperbarui setiap pesan dan menambahkan pengatur waktu untuk setiap obrolan. Setel ulang pengatur waktu setiap kali ada pesan, jika tidak, saat pengatur waktu terpicu, kirimkan pembaruan waktu dan keseimbangan. Atau jika Anda tidak memiliki sumber daya untuk pengatur waktu sebanyak itu, lakukan ide yang sama dengan daftar yang diurutkan - perbarui daftar setiap kali ada aktivitas, dan urutkan berdasarkan waktu aktif terakhir + 15 detik. Yang berada di urutan teratas daftar mungkin perlu mendapatkan pembaruan waktu dan keseimbangan.

Bagaimanapun, saya akan fokus pada gagasan mengirimkan waktu dan keseimbangan dalam setiap pesan, dan menemukan cara untuk membuatnya berhasil dari sana.

person Scott Mermelstein    schedule 17.04.2013
comment
Terima kasih Scott atas penjelasan solusi terperinci Anda. Solusi daftar terurut Anda mungkin bukan cara yang baik karena klien tidak akan membeli kredit untuk setiap sesi obrolan. Mereka dapat menggunakan kreditnya sebanyak yang mereka mau. Saya telah menambahkan skenario sederhana pada pertanyaan saya. Pendekatan saya tidak masuk akal karena tidak terukur seperti yang Anda nyatakan. Saya memiliki kekhawatiran tentang penambahan pengatur waktu untuk setiap obrolan, tetapi saya akan mempertimbangkannya. - person Fevzi Apaydın; 18.04.2013
comment
Saya tidak akan memaksakan hal ini terlalu keras, namun saya ingin menyebutkan bahwa solusi saya tidak mengasumsikan kredit dibeli per sesi obrolan. Hanya dengan mempertimbangkan jumlah kredit yang dimiliki pengguna dan biaya per sesi, Anda dapat menghitung waktu maksimum yang tersedia. Dalam skenario sampel, Anda dapat mengetahui di awal sesi bahwa pengguna akan memiliki waktu aktif maksimal 5 menit dengan pakar. Saya tidak yakin apa yang harus dilakukan dengan itu, tapi ada baiknya juga melihat Anda menagih per menit. Dalam hal ini, presisi 15 detik sudah cukup, dan Anda hanya perlu mengkhawatirkan skalabilitas. - person Scott Mermelstein; 18.04.2013