เมื่อใดที่ไม่ควรใช้นักแสดงใน akka / erlang

ฉันทำงานกับ akka มา 7-8 เดือนแล้วทุกวัน เมื่อฉันเริ่มฉันจะทำงานกับแอพพลิเคชั่นและสังเกตว่านักแสดงจะถูกใช้โดยทั่วไปทุกครั้งที่อยู่ในระบบของนักแสดงเพื่อสื่อสารระหว่างวัตถุส่วนใหญ่ ดังนั้นฉันจึงทำแบบเดียวกัน - หมุนนักแสดงคนอื่นให้กับ x / y / z

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

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

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

นี่เป็นคำถามที่ฉันสนใจและฉันได้ทำการวิจัยเกี่ยวกับ สำหรับมุมมองอื่น ๆ ให้ดูโพสต์บล็อกนี้โดย Noel Walshหรือคำถามนี้ใน Stack Overflow ฉันมีความคิดเห็นที่ฉันต้องการนำเสนอ:

• ฉันคิดว่า Akka เพราะมันใช้งานได้กับข้อความ บ่อยครั้งสำหรับการเห็นพ้องฉันจะเถียงว่านี่ไม่ใช่สิ่งที่คุณต้องการ ดึงปลอดภัยกว่ามาก ตัวอย่างเช่นรูปแบบหนึ่งที่พบบ่อยสำหรับระบบการกระจายที่จะมีชุดของคนงานประมวลผลข้อมูลในคิว เห็นได้ชัดว่านี้เป็นไปได้ใน Akkaแต่มันไม่จำเป็นต้องดูเหมือนจะเป็นคนวิธีแรกลอง Akka ยังมีกล่องจดหมายที่ทนทานแต่ก็ขึ้นอยู่กับวิธีการใช้งานของคุณอีกด้วย - คิวที่ใช้ร่วมกันครั้งเดียวนั้นมีความยืดหยุ่นมากกว่าการต่อคิวงานสำหรับการปรับสมดุล / การมอบหมายงานอีกครั้ง
• เป็นเรื่องง่ายที่จะนึกถึงการแทนที่ชั้นเรียนของคุณด้วยนักแสดง ในความเป็นจริงบางคนดูเหมือนจะสนับสนุนโดยบอกว่านักแสดงควรทำสิ่งเดียวเท่านั้น ข้อสรุปเชิงตรรกะนี้เพิ่มความซับซ้อนของรหัสตามที่เจสันอธิบายเพราะถ้าทุกคลาสเป็นนักแสดงนั่นเป็นข้อความพิเศษจำนวนมากและรับ / ส่งบล็อค นอกจากนี้ยังทำให้มันยากที่จะเข้าใจและทดสอบโค้ดเพราะคุณจะสูญเสียความเป็นทางการของอินเตอร์เฟซ - และผมไม่เชื่อว่าการแสดงความคิดเห็นเป็นวิธีแก้ปัญหานี้ นอกจากนี้แม้จะมีประสิทธิภาพตามตำนานของ Akkaฉันสงสัยว่าการเพิ่มจำนวนนักแสดงไม่ได้เป็นความคิดที่ดี - เมื่อเราใช้ Java thread เรารู้ว่ามันมีค่าและประหยัดตามนั้น
• มันเกี่ยวข้องกับประเด็นก่อนหน้านี้ แต่สิ่งที่น่ารำคาญอีกประการคือการสูญเสียข้อมูลประเภทที่ Noel และ Pino เน้นสำหรับพวกเราหลายคนนั่นคือสาเหตุที่เราใช้ Scala มากกว่าภาษาอื่นเช่น Python มีวิธีการบางอย่างรอบนี้มี แต่พวกเขามีทั้งที่ไม่ได้มาตรฐาน , ไม่แนะนำหรือการทดลอง
• ในที่สุดการเห็นพ้องด้วยกันแม้ว่าคุณจะมีความคิดว่า "ปล่อยให้มันพัง"มันก็ยาก รูปแบบการเขียนโปรแกรมทางเลือกสามารถช่วย แต่พวกเขาไม่ได้ทำให้ปัญหาหายไป - พวกเขาเปลี่ยนพวกเขา - ที่ว่าทำไมมันเป็นเรื่องที่ดีที่จะคิดเกี่ยวกับพวกเขาอย่างเป็นทางการ นอกจากนี้ยังเป็นสาเหตุที่นักพัฒนา Joe Average เข้าถึงเครื่องมือที่สร้างขึ้นอย่างพร้อมเช่น RabbitMQ, Storm, Hadoop, Spark, Kafka หรือฐานข้อมูล NoSQL Akka มีเครื่องมือและส่วนประกอบที่สร้างไว้ล่วงหน้าแล้วซึ่งเท่ห์ แต่ก็ให้ความรู้สึกในระดับต่ำดังนั้นองค์ประกอบทั่วไปที่สร้างขึ้นพร้อมของระบบกระจายจะช่วยนักพัฒนาและสร้างระบบที่ถูกต้อง

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

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

1. รูปแบบการทำงานพร้อมกัน
2. ที่หลีกเลี่ยงการเข้าถึงพร้อมกันไปยังสถานะที่ไม่แน่นอน
3. ใช้กลไกการสื่อสารแบบอะซิงโครนัสเพื่อจัดเตรียมการทำงานพร้อมกัน

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

• คุณไม่อนุญาตให้มีการทำงานพร้อมกันหรือ
• คุณไม่อนุญาตให้ใช้สถานะที่ไม่แน่นอน
• คุณต้องพึ่งพากลไกการสื่อสารแบบซิงโครนัส

จากนั้นตัวแบบนางแบบจะไม่ให้ประโยชน์มากนัก

หวังว่าจะช่วย

สัญชาตญาณของคุณถูกต้อง IMHO การใช้นักแสดงทุกที่เปรียบเหมือนการใช้ค้อนสุภาษิต

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

ในการสั่งซื้อการส่งข้อความเข้า / ส่งออก:

เมื่อเร็ว ๆ นี้ฉันได้พบกับแอปพลิเคชั่นที่ใช้ akka ซึ่งโมเดลของนักแสดงทำให้เกิดปัญหาการเกิดขึ้นพร้อมกันจริง ๆ

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

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

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

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

ฐานข้อมูลเช่น mnesia อาจถือได้ว่าเป็นการจัดเก็บข้อมูลภายนอกจากกระบวนการสืบค้น