วิธีที่เหมาะสมในการคำนวณเครดิตในห้องสนทนาเชิงพาณิชย์คืออะไร?

ฉันกำลังทำโปรเจ็กต์ที่ให้ผู้ใช้สามารถสนทนากับผู้เชี่ยวชาญในห้องแชทส่วนตัวได้ ผู้ใช้ซื้อเครดิตเพื่อแชทกับผู้เชี่ยวชาญ และจะถูกเรียกเก็บเงินเมื่อสิ้นสุดเซสชันแชททุกครั้งตามนาทีที่พวกเขาได้พูดคุย ผู้เชี่ยวชาญแต่ละคนมีอัตราเครดิตที่แตกต่างกันสำหรับทุกนาทีของการสนทนา

ตัวจับเวลาจะเริ่มนับเมื่อเริ่มเซสชันการแชท และผู้ใช้จะได้รับการแจ้งเตือนเป็นระยะๆ เกี่ยวกับเวลาทั้งหมดที่พวกเขาใช้ในห้องสนทนาและเครดิตรวมปัจจุบันของเซสชันการแชทปัจจุบัน การคำนวณเหล่านี้ต้องทำบนฝั่งเซิร์ฟเวอร์และบันทึกไว้ในฐานข้อมูล เซสชันการแชท Btw สามารถหยุดชั่วคราว / ดำเนินการต่อโดยผู้เชี่ยวชาญ


นี่เป็นสถานการณ์ง่ายๆ...
ผู้ใช้ปัจจุบันมี: 10 เครดิต
"ผู้เชี่ยวชาญ A" ต้องการ 2 เครดิต / ต่อนาที

CurrentTime Event       Timer       Credit
  • 10:40 เซสชันสนทนาเริ่มต้น 00:01 นาที 2เครดิต
  • 10:41 พวกเขากำลังคุยกัน 00:02 นาที 4เครดิต
  • 10:42 ผู้เชี่ยวชาญเรื่องไม่ได้ใช้งาน 00:02 นาที 4เครดิต (แชทหยุดชั่วคราว)
  • 10:45 ผู้เชี่ยวชาญออนไลน์ 00:02 นาที 4เครดิต (สนทนาต่อ)
  • 10:46 พวกเขากำลังคุยกัน 00:03 นาที 6เครดิต
  • 10:46 ลูกค้าสิ้นสุดเซสชัน 00:04 นาที 8เครดิต

ลูกค้าจะถูกเรียกเก็บเงินจำนวน 8 เครดิต เขามีเครดิตเหลืออยู่ 2 หน่วยกิต

เซสชันการแชทจะถูกเรียกเก็บเงินเมื่อเริ่มต้นนาทีใหม่ การคำนวณจะคำนวณตามนาที และจะละเว้นวินาที


คำถามของฉันคือจะคำนวณทางฝั่งเซิร์ฟเวอร์ได้อย่างไรสำหรับทุกเซสชันการสนทนาที่กำลังพูดคุยอยู่ในวิธีที่เหมาะสม?

แนวทางปัจจุบันของฉันคือ

ตัวจับเวลาฝั่งเซิร์ฟเวอร์จะติ๊กทุกๆ 15 วินาที รับการสนทนาเซสชันปัจจุบัน

สำหรับทุกเซสชันการแชท : หากเซสชันแชทไม่ถูกหยุดชั่วคราว ให้เพิ่ม 15 วินาทีให้กับช่วงเวลาของเซสชัน จากนั้นคำนวณเครดิตรวมของเซสชันปัจจุบัน หากผู้ใช้กำลังจะหมดเครดิต ให้แจ้งให้เขาทราบ หากเขาเรียกใช้แล้ว เครดิตหมด จากนั้นจึงสิ้นสุดเซสชันการแชทปัจจุบัน บันทึกธุรกรรมเหล่านี้ลงในฐานข้อมูล อัปเดตไคลเอ็นต์เซสชันการแชท

แต่มีข้อผิดพลาดบางประการในแนวทางนี้ ตัวอย่างเช่น หากเซสชันการแชทเริ่มต้นในขณะนี้และตัวจับเวลาทำเครื่องหมายใน 2 วินาที จากนั้นจะเพิ่ม 15 วินาทีจากระยะเวลารวมของเซสชันการแชทปัจจุบัน ดังนั้นจึงคำนวณผิด ถ้าฉันลดช่วงเวลาติ๊กของตัวจับเวลา อาจมีการสนทนาปัจจุบัน 500 เซสชัน และช่วงเวลาติ๊กของตัวจับเวลาจะไม่เพียงพอที่จะคำนวณเครดิตของเซสชันแชททุกครั้งใน 10 วินาที เป็นต้น

มีวิธีที่ดีกว่าในการจัดการเรื่องนี้หรือไม่? ยินดีรับข้อเสนอแนะทั้งหมด

อย่างไรก็ตาม ฉันใช้ Asp.net MVC4 C# และ Signalr เพื่อจัดการแชทแบบเรียลไทม์

ขอบคุณล่วงหน้า.


person Fevzi Apaydın    schedule 17.04.2013    source แหล่งที่มา
comment
ดูเหมือนว่าคุณจะต้องวัดเวลาได้อย่างแม่นยำว่าแชทเริ่ม/หยุด/หยุดชั่วคราว/กลับมาทำงานต่อเมื่อใด หากระบบแชทที่คุณใช้ไม่มีข้อมูลดังกล่าว บางทีทุกๆ วินาที (หรือไม่กี่วินาที) คุณสามารถจัดเก็บรายการเซสชันแชทที่ใช้งานอยู่ทั้งหมด และใช้ข้อมูลนี้ทุกๆ 15 วินาทีเพื่อทำงานที่มีราคาแพงกว่าเพื่อดำเนินการอย่างเต็มที่ ทุกอย่าง. ระวังว่าหากคุณไม่สามารถประมวลผลโหลดปัจจุบันของคุณได้ภายใน 10 วินาที ก็จะต้องเพิ่มขึ้นเพียง 50% และคุณจะไม่สามารถทำได้ใน 15 วินาทีเช่นกัน ดังนั้นเร็วๆ นี้คุณอาจต้องพิจารณาทำให้มีประสิทธิภาพมากขึ้น หรือเพิ่มความจุ   -  person Steve Jessop    schedule 17.04.2013
comment
เหตุใดจึงทำให้การคำนวณเหล่านี้ทำงานเป็นชุด ฉันคิดว่ามันจะง่ายกว่ามากในการขับเคลื่อนเหตุการณ์: ทุกๆ n ครั้งที่ข้อความถูกส่งผ่านโปรแกรมแชท (ไม่ว่าจะจากผู้เชี่ยวชาญหรือผู้ใช้) ตรวจสอบเวลาทั้งหมดที่ใช้ และคำนวณเครดิตและดำเนินการ ตามลำดับจากที่นั่น ด้วยวิธีนี้ จะเป็นต่อเซสชันแชท และแม่นยำยิ่งขึ้น และปรับขนาดได้ง่ายกว่าการวิเคราะห์เซสชันทั้งหมดเป็นกลุ่ม   -  person Scott Mermelstein    schedule 17.04.2013
comment
@ScottMermelstein มีกรณีต่างๆ มากมาย เช่น หากผู้เชี่ยวชาญไม่เขียนเป็นเวลา 2 นาทีขึ้นไป ให้หยุดเซสชันการแชทชั่วคราว ฉันคิดว่าฉันต้องใช้ตัวจับเวลา อาจเป็นไปได้ว่าฉันไม่สามารถตรวจพบได้ว่าผู้ใช้เครดิตหมดหากมีคนไม่ได้เขียนแนวทางของคุณเป็นเวลา 2 นาที   -  person Fevzi Apaydın    schedule 17.04.2013
comment
คุณสามารถสนทนาด้านใดด้านหนึ่งหรืออีกด้านหนึ่งเป็นต้นแบบเพื่อนับเวลา หากผู้ใช้ถามคำถามแต่ผู้เชี่ยวชาญไม่ตอบกลับ ก็ไม่ควรเรียกเก็บเงินใดๆ ทั้งสิ้น เมื่อผู้เชี่ยวชาญตอบกลับ คุณสามารถใช้การประทับเวลาของการตอบกลับนั้นเพื่อคำนวณระยะเวลาการแชทปัจจุบัน ฯลฯ   -  person Chris Pratt    schedule 17.04.2013


คำตอบ (1)


ฉันคิดว่าจำเป็นอย่างยิ่งที่คุณจะต้องไม่ดำเนินการเป็นกลุ่ม ตามที่คุณระบุไว้ คุณจะพบปัญหาเกี่ยวกับความแม่นยำในการชาร์จ และฉันแน่ใจว่าคุณตระหนักดีว่าการปรับขนาดอย่างรวดเร็วกลายเป็นปัญหา จะดีกว่ามากถ้าทำให้ทุกอย่างขับเคลื่อนด้วยเหตุการณ์

อย่างที่ฉันแนะนำในความคิดเห็น ส่วนหนึ่งของสิ่งนี้เกี่ยวข้องกับการคำนวณเวลาที่ใช้อย่างแน่นอน ทำได้ง่ายมาก - เก็บเวลาเริ่มต้น (หรือเวลาเริ่มต้นของผู้เชี่ยวชาญ ขึ้นอยู่กับความต้องการของคุณ) แล้วลบออกจากเวลาสิ้นสุด และเรียกเก็บเงินตามนั้น

ปัญหาที่อาจเกิดขึ้น:

  • เวลาสิ้นสุดคือเมื่อใด นั่นคือเวลาที่โปรแกรมแชทปิด ไม่ว่าจะผ่านการหมดเวลาเซสชัน การสิ้นสุดของผู้เชี่ยวชาญ หรือการสิ้นสุดของผู้ใช้ ขึ้นอยู่กับโครงสร้างการเรียกเก็บเงินของคุณ ฉันขอแนะนำให้กำหนดให้เวลาสิ้นสุดในบริบทนี้รวมถึงการหยุดเซสชันชั่วคราวด้วย เพื่อวัตถุประสงค์ในการคำนวณต้นทุน การวนซ้ำเริ่ม-หยุดชั่วคราวแต่ละครั้งสามารถนับแยกกันได้ (แต่ตามหลักการแล้ว ควรจะรวมกลุ่มเข้าด้วยกันในสรุปการเรียกเก็บเงิน) คุณสามารถตรวจสอบทุกครั้งที่ส่งข้อความเพื่อดูว่าผู้ใช้ยังมีเครดิตอยู่หรือไม่
  • 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.
    • ต่อไปนี้เป็นวิธีคิดการเรียกเก็บเงินที่แตกต่างไปจากเดิมอย่างสิ้นเชิง: เมื่อเซสชันเริ่มต้น เซิร์ฟเวอร์ของคุณจะสามารถคำนวณตามอัตราและสมดุลว่าเซสชันจะคงอยู่ได้นานแค่ไหน เว้นแต่ว่าจะมีการหยุดหรือหยุดชั่วคราวก่อนหน้านั้น คุณจะทราบได้อย่างแน่ชัดว่าเครดิตจะหมดเมื่อใด และหากมีการดำเนินการต่อจากการหยุดชั่วคราว คุณสามารถคำนวณใหม่ตามเวลาที่เหลือได้

สิ่งที่ฉันอยากจะแนะนำให้คุณทำนั้นอิงจากสัญลักษณ์แสดงหัวข้อย่อยสุดท้าย เมื่อเริ่มต้นหรือเริ่มเซสชันใหม่อีกครั้ง ให้คำนวณตามเครดิตเมื่อเซสชันจะหมดอายุ รักษาเซสชันไว้ในรายการเรียงลำดับ เรียงตามเวลาหมดอายุ จากนั้นฝั่งเซิร์ฟเวอร์ของคุณก็ทำได้อย่างง่ายดาย - ตรวจสอบว่าเวลาคือหลังจากเวลาหมดอายุเซสชันใดๆ หรือไม่ หากเป็นเช่นนั้น ให้กดการแจ้งเตือนสิ้นสุด

เมื่ออ่านข้อกำหนดของคุณอีกครั้ง ความคิดของฉันอาจจะเฉยๆ เกินไปสำหรับสิ่งที่คุณต้องการ คำถามหนึ่งคือการคำนวณทั้งหมดบนฝั่งเซิร์ฟเวอร์มีความสำคัญเพียงใด ฉันขอแนะนำให้ไคลเอ็นต์ใช้ตัวจับเวลาเซสชันและเครื่องคำนวณต้นทุนทำงานอยู่ เพียงเพื่อให้ผู้ใช้สามารถดูได้โดยไม่ต้องมีการรับส่งข้อมูลไคลเอ็นต์/เซิร์ฟเวอร์ แม้ว่าเซิร์ฟเวอร์จะยังคงรับผิดชอบด้านการเรียกเก็บเงินก็ตาม

มิฉะนั้น หากคุณต้องส่งการแจ้งเตือนเกี่ยวกับเวลาและความสมดุล ฉันก็ยังจะดำเนินการเป็นรายบุคคล แทนที่จะดำเนินการเป็นกลุ่ม คุณสามารถอัปเดตทุกข้อความและเพิ่มตัวจับเวลาสำหรับการแชทแต่ละครั้ง รีเซ็ตตัวจับเวลาทุกครั้งที่มีข้อความ มิฉะนั้น เมื่อตัวจับเวลาเริ่มทำงาน ให้ส่งเวลาและอัปเดตยอดคงเหลือ หรือหากคุณไม่มีทรัพยากรสำหรับตัวจับเวลาจำนวนมากขนาดนั้น ให้ทำแนวคิดเดียวกันกับรายการที่จัดเรียง - อัปเดตรายการทุกครั้งที่มีกิจกรรม และจัดเรียงตามเวลาที่ใช้งานล่าสุด + 15 วินาที รายการที่อยู่ด้านบนสุดของรายการอาจต้องได้รับการอัปเดตเวลาและความสมดุล

ไม่ว่าในกรณีใด ฉันจะเน้นไปที่แนวคิดในการส่งเวลาและความสมดุลให้กับทุกข้อความ และค้นหาวิธีทำให้มันได้ผลจากที่นั่น

person Scott Mermelstein    schedule 17.04.2013
comment
ขอบคุณ Scott สำหรับคำอธิบายโซลูชันโดยละเอียดของคุณ โซลูชันการจัดเรียงรายการของคุณอาจไม่ใช่วิธีที่ดี เนื่องจากลูกค้าจะไม่ซื้อเครดิตสำหรับเซสชันการแชทแต่ละครั้ง พวกเขาสามารถใช้เครดิตได้มากเท่าที่ต้องการ ฉันได้เพิ่มสถานการณ์ง่าย ๆ ในคำถามของฉัน แนวทางของฉันไม่สมเหตุสมผลเนื่องจากไม่สามารถปรับขนาดได้ตามที่คุณระบุ ฉันกังวลเกี่ยวกับการเพิ่มตัวจับเวลาสำหรับการแชทแต่ละครั้ง แต่ฉันจะพิจารณาเรื่องนี้ - person Fevzi Apaydın; 18.04.2013
comment
ฉันจะไม่กดดันประเด็นนี้มากเกินไป แต่ฉันอยากจะบอกว่าโซลูชันของฉันไม่ได้ถือว่าเครดิตถูกซื้อต่อเซสชันการแชท เพียงระบุจำนวนเครดิตที่ผู้ใช้มีและราคาต่อเซสชัน คุณก็สามารถคำนวณเวลาสูงสุดที่มีอยู่ได้ ในสถานการณ์ตัวอย่างของคุณ คุณสามารถบอกได้เมื่อเริ่มต้นเซสชันว่าผู้ใช้จะมีเวลาใช้งานสูงสุด 5 นาทีกับผู้เชี่ยวชาญ ฉันไม่แน่ใจว่าต้องทำอย่างไร แต่ก็เป็นการดีที่เห็นคุณเรียกเก็บเงินต่อนาที ในกรณีนั้น ความแม่นยำ 15 วินาทีก็เพียงพอแล้ว และคุณเพียงแค่ต้องกังวลเกี่ยวกับความสามารถในการขยายขนาด - person Scott Mermelstein; 18.04.2013