จะป้องกันผู้ใช้สองคนจากการลงทะเบียนในเวลาเดียวกันด้วยชื่อผู้ใช้เดียวกันได้อย่างไร?


11

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

สมมติว่าฐานข้อมูลไม่มีชื่อผู้ใช้ 'user1' เมื่อผู้ใช้สองคนพยายามที่จะลงทะเบียนในเวลาเดียวกันด้วย 'user1' ก็จะยอมรับมัน แต่จะทำให้เกิดปัญหาในภายหลัง สิ่งนี้ไม่ควรเกิดขึ้น

ฉันกำลังมองหาวิธีแก้ปัญหาเชิงตรรกะ ไม่เฉพาะเจาะจง แค่ความคิดที่จะแก้ปัญหานี้



4
มันเป็นปัญหาสถาปัตยกรรมซอฟต์แวร์ที่ถูกกฎหมาย ไม่ใช่ปัญหาที่ทำให้คำถามสัมภาษณ์ดีเท่านั้นและไม่มีอะไรอื่น
Karl Bielefeldt

7
ผู้ใช้หลายล้านคนที่ลงทะเบียนในเวลาเดียวกัน? จริงๆ? หากคุณมีผู้ใช้หลายล้านคนที่ลงทะเบียนในเวลาเดียวกันคุณมีปัญหาที่ใหญ่กว่าเช่นการจัดการผู้ใช้ที่ลงทะเบียนหลายพันล้านคน และอาจเป็นเงินที่จะจ่ายเซิร์ฟเวอร์ที่จัดการกับมัน
gnasher729

2
@AddzyK นี่เป็นปัญหาสมมุติฐานที่ต้องเผชิญในอนาคตที่คุณต้องการทางออกที่สมเหตุสมผล? ค่อนข้างแน่ใจว่าอยู่นอกขอบเขตที่นี่
paparazzo

3
นี่คือคำตอบสมมุติ: จ่ายคนอื่นให้ทำที่รู้อยู่แล้วว่าจะทำอย่างไร ด้วยผู้ใช้ใหม่นับล้าน / วินาทีคุณจะได้รับเงินสด
whatsisname

คำตอบ:


15

สมมติว่าฐานข้อมูลไม่มีชื่อผู้ใช้ 'user1' เมื่อผู้ใช้สองคนพยายามที่จะลงทะเบียนในเวลาเดียวกันด้วย 'user1' ก็จะยอมรับมัน

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

คุณควรจะสามารถใช้ธุรกรรมฐานข้อมูลเพื่อใช้ฐานข้อมูลเพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้นได้ มิฉะนั้นจะไม่มีแอปพลิเคชันใด ๆ ที่สามารถรักษาค่าคงที่ในข้อมูลฐานข้อมูล

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


การล็อกการลงทะเบียนไม่ป้องกันผู้ใช้รายอื่นจากการลงทะเบียนพร้อมกันหรือไม่?
Addzy K

2
+1, วิ่งคณิตศาสตร์อย่างคร่าวๆและแม้แต่ Facebook ก็เฉลี่ยการสมัครเพียงไม่กี่ครั้งต่อวินาที ดังนั้นการพึ่งพาข้อ จำกัด ของฐานข้อมูลจึงควรเพียงพอ
GrandmasterB

2
@AddzyK: การล็อกเกิดขึ้นในช่วงเวลาสั้น ๆ เท่านั้นซึ่งฐานข้อมูลจะต้องบังคับใช้ข้อ จำกัด ใช่ผู้ใช้รายอื่นที่ลงทะเบียนพร้อมกันต้องรอเข้าแถว แต่การรอนั้นสั้นมากและไม่ค่อยเกิดขึ้นอยู่ดีแม้ในระบบที่ใหญ่ที่สุด
Robert Harvey

1
@GrandmasterB ค่าเฉลี่ยอาจไม่สามารถบอกเรื่องราวทั้งหมดได้ที่นี่ ฉันสันนิษฐานตามคำถามที่ว่านี้คือการจัดการภาระสูงสุดหนัก - ยกตัวอย่างเช่นการสำรวจสำมะโนประชากรของออสเตรเลีย
DeadMG

@AddzyK มันอาจจะทำ โดยพื้นฐานแล้วคุณสามารถหนีไปได้ด้วยการล็อคเพียงบางส่วนของตาราง มีแผนการมากมายในการจัดการกับสิ่งนี้เช่นคำตอบของ gnasher729 แต่ฉันเชื่อว่าคุณควรจะได้รับผลิตภัณฑ์ฐานข้อมูลแบบกระจายนอกชั้นวางที่สามารถจัดการสิ่งนี้ให้คุณได้ แม้ว่าคุณจะต้องม้วนโครงร่างการล็อคบางส่วนของคุณเอง แต่ก็มีวิธีมากมายที่จะจัดการกับมันเช่น DHT
DeadMG

7

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

สำหรับปริมาณคำร้องขอชนิดนี้ให้พิจารณาที่เก็บค่าคีย์แบบกระจายเช่นความเสี่ยงแทนฐานข้อมูลทั้งหมดเป็นแหล่งข้อมูล


2

มันเป็นปัญหาหรือไม่?

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

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

ใช่มันเป็นปัญหา

ตามที่คุณถามฉันคิดว่าชื่อผู้ใช้ควรเป็นรหัสที่ไม่ซ้ำกัน วิธีการดังต่อไปนี้สามารถนำมาใช้:

  1. ก่อน:ในกระบวนการลงทะเบียนให้มองเห็นขั้นตอนที่ผู้ใช้ใหม่ต้องตรวจสอบความพร้อมของชื่อของเขา เมื่อทำเช่นนั้นให้บันทึกชื่อบัญชีที่พร้อมใช้งานด้วยสถานะชั่วคราวและรหัสเซสชันที่จะช่วยให้การลงทะเบียนเสร็จสิ้น
  2. เวลาเดียวกัน:การตอบกลับที่แตกต่างและยืดหยุ่นกว่าของการตอบกลับของgnasher729คือการใช้ฟังก์ชันแฮชแบบง่าย (เช่นที่ใช้สำหรับจัดการตารางสัญลักษณ์) เพื่อกำหนดรหัสให้กับเซิร์ฟเวอร์การลงทะเบียนที่ไม่ซ้ำกัน i (i = h (ชื่อผู้ใช้) โมดูโล number_of_servers) ที่จะจัดการเอกลักษณ์ในขอบเขตที่ จำกัด / แบ่งกลุ่มของเขา
  3. หลัง:ในตอนท้ายของการลงทะเบียนเมื่อผู้ใช้คลิกที่registerส่งคำขอไปยังฐานข้อมูลของคุณหากคุณสามารถกำหนดเขตข้อมูลที่ไม่ซ้ำกัน เมื่อเกิดข้อผิดพลาดส่งข้อความ "โอ๊ะโอผู้ใช้ที่โชคร้ายมีปัญหา" และขอให้เขาเลือก ID อื่น
  4. อะซิงโครนัส:ลงทะเบียนผู้ใช้ อ่านเรคคอร์ดผู้ใช้อีกครั้งเพื่อให้แน่ใจว่าไม่มีการเปลี่ยนแปลงและเรคคอร์ดเดียว หากเป็นปัญหาขอให้ผู้ใช้เปลี่ยน (ไม่ใช่แบบอะซิงโครนัส) หรือส่งอีเมลถึงเขาว่ามีปัญหา (แบบอะซิงโครนัส แต่น่ารำคาญจากมุมมองของผู้ใช้) หรือให้เขาลงทะเบียน แต่ขออีเมล์ของเขา บังคับให้เขาเปลี่ยนชื่อผู้ใช้เป็นส่วนหนึ่งของขั้นตอนการเข้าสู่ระบบ

1

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


0

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


5
... และจากนั้นเจ้าของผลิตภัณฑ์ของคุณต้องการเดินทางไปต่างประเทศ ...
Telastyn

2
หลักการเดียวกันนี้ใช้กับสตริง Unicode ตราบใดที่ยังอยู่ในรูปแบบที่ทำให้เป็นมาตรฐานเช่น NFKD คุณสามารถแฮชชื่อผู้ใช้และใช้มันตามแฮช อย่างไรก็ตามคำตอบนี้เป็นเพียงการใช้ฐานข้อมูลแบบกระจายของคุณเอง
DeadMG

1
คุณหมายถึงพวกเขามีผู้ใช้หลายล้านคนที่ลงทะเบียนในเวลาเดียวกันในประเทศใดประเทศหนึ่ง ? ในกรณีนี้พวกเขาควรมีเงินมากพอที่จะจ่ายเพิ่มเพื่อหาทางออกที่แท้จริง
gnasher729

โดยเฉพาะอย่างยิ่งนี่เป็นเพียงจุดเริ่มต้นของวิธีการทำ DHT
DeadMG

วิธีนี้แก้ไขปัญหาของผู้ใช้สองคนที่ลงทะเบียนชื่อเดียวกันในเวลาเดียวกัน - ทั้งสองชื่อจะเริ่มต้นด้วยอักขระสองตัวที่เหมือนกันและจัดการโดยเซิร์ฟเวอร์การลงทะเบียนเดียวกัน
HorusKol
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.