ทำไม Akka ถึงดีสำหรับการเกิดพร้อมกัน?

ฉันยังใหม่กับกรอบของอัคคาและนักแสดง - ฉันแน่ใจว่าฉันขาดอะไรที่ชัดเจนโปรดยอมรับคำขอโทษล่วงหน้า

ฉันอ่านต่อไปว่าหนึ่งในประเด็นหลักในการเลือก Akka คือวิธีที่มันจัดการการทำงานพร้อมกัน

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

ฉันจะยังคงต้องล็อคการทำงานพร้อมกันบางอย่าง (มองโลกในแง่ร้าย / แง่ดี / ฯลฯ .. )?

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

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

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

การใช้กลยุทธ์การทำงานพร้อมกันช่วยในการระบุกรณีเหล่านี้และสามารถแก้ไขได้ตามกฎเกณฑ์ทางธุรกิจ ยกตัวอย่างเช่น Optimistic Concurrency ให้ผู้ใช้ส่งเวอร์ชันของแบบฟอร์มที่มีการอัพเดท เมื่อนักแสดงทำการประมวลผลการเปลี่ยนแปลงผู้ใช้คนที่สองคิดว่าเป็นการอัปเดตเวอร์ชัน 5 เมื่อฟอร์มนั้นเป็นเวอร์ชัน 6 เนื่องจากการอัปเดตครั้งแรกของผู้ใช้ อย่างน้อยตอนนี้เราสามารถแจ้งผู้ใช้คนที่ 2 ว่าฟอร์มได้เปลี่ยนไปแล้วตั้งแต่พวกเขาเริ่มแก้ไข หรืออะไรก็ตามที่กฎเกณฑ์ทางธุรกิจต้องการบังคับใช้

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

ฉันเชื่อว่า Akka มีมิติอื่น ๆ มากมายเช่นวิธีจัดการกับความล้มเหลวหัวหน้างาน ฯลฯ ซึ่งเป็นข้อพิจารณาที่สำคัญสำหรับผู้พัฒนา

ฉันจะเขียนเกี่ยวกับ Actor Model โดยทั่วไป (ไม่ใช่แค่ Akka) เมื่อเปรียบเทียบกับโมเดลภาวะพร้อมกันอื่น ๆ เช่น concurrency แบบล็อคแบบคลาสสิกและหน่วยความจำแบบ transactional

ข้อดี

1. แนวคิดที่ง่ายต่อการเข้าใจและใช้งาน

   • การล็อคการทำงานพร้อมกันนั้นเป็นเรื่องยาก โดยเฉพาะอย่างยิ่งยากที่จะทำให้ถูกต้องเนื่องจากมีแนวคิดมากมายที่จะเข้าใจและใช้งานเพื่อให้ถูกต้องและมีประสิทธิภาพ: ล็อคเซมาฟอร์เธรดการซิงโครไนซ์การแยกซึ่งกันและกันการกีดกันหน่วยความจำ ฯลฯ

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

2. บังคับไม่เปลี่ยนรูป

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

3. ข้อผิดพลาดน้อยได้ง่าย

   • เนื่องจากเหตุผลสองข้อข้างต้น

4. ที่มีประสิทธิภาพ

   • ไม่ค่อยมีประสิทธิภาพเท่าที่เขียนดีล็อคตาม แต่โดยทั่วไปมีประสิทธิภาพมากกว่าหน่วยความจำทรานแซคชันของซอฟต์แวร์

5. ปรับขนาดได้อย่างง่ายดาย

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

ข้อเสีย

1. ไม่ใช่ทุกภาษาที่บังคับให้เปลี่ยนรูปไม่ได้อย่างง่ายดาย

   • Erlang ภาษาที่นักแสดงที่ได้รับความนิยมอันดับแรกมีความไม่สามารถเปลี่ยนแปลงได้ที่แกนกลาง แต่ Java และ Scala (ที่จริงแล้ว JVM) ไม่ได้บังคับใช้กับการเปลี่ยนไม่ได้

2. ยังค่อนข้างซับซ้อน

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

3. ไม่ป้องกันการหยุดชะงักหรือความอดอยาก

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

4. ไม่มีประสิทธิภาพ

   • เนื่องจากการบังคับที่ไม่สามารถบังคับได้และเนื่องจากนักแสดงหลายคนต้องเปลี่ยนไปใช้การใช้เธรดตัวแสดงเดียวกันจะไม่มีประสิทธิภาพเท่ากับการล็อกพร้อมกัน

ข้อสรุป

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