คำถามติดแท็ก eventual-consistency

สมมติว่าเรามีฟังก์ชั่นที่อัปเดตรหัสผ่านของผู้ใช้ เมื่อคลิกปุ่ม 'อัปเดตรหัสผ่าน' จะมีการส่ง UpdatePasswordEvent ไปยังหัวข้อที่สมัครใช้บริการอื่น 3 บริการ: บริการที่อัพเดตรหัสผ่านของผู้ใช้จริง บริการที่อัพเดตประวัติรหัสผ่านของผู้ใช้ บริการที่ส่งอีเมลแจ้งให้ผู้ใช้ทราบว่ารหัสผ่านของเขาถูกเปลี่ยน จากสิ่งที่ฉันเข้าใจเกี่ยวกับความสอดคล้องในที่สุดบริการเหล่านี้ (ผู้บริโภค) จะได้รับเหตุการณ์ในเวลาเดียวกันและดำเนินการแยกต่างหากซึ่งในสถานการณ์ที่ดีจะนำไปสู่ข้อมูลที่สอดคล้องกัน อย่างไรก็ตามจะเกิดอะไรขึ้นถ้าบริการล้มเหลวในการประมวลผลเหตุการณ์ เช่นการตัดการเชื่อมต่ออย่างฉับพลันข้อผิดพลาดของฐานข้อมูล ฯลฯ ... รูปแบบ / การปฏิบัติที่ดีในการจัดการกับความล้มเหลวของธุรกรรมคืออะไร ฉันกำลังคิดที่จะสร้าง RollbackTopic ซึ่งหากมีเหตุการณ์ใดที่ไม่สามารถประมวลผลได้ RollbackEvent จะถูกสร้างขึ้นในหัวข้อที่ "บริการการย้อนกลับ" จะทำงานและเปลี่ยนกลับเป็นข้อมูล

22 eventual-consistency 

ฉันกำลังสร้างบริการที่อยู่ด้านบนของ Google App Engine Datastore ซึ่งเป็นที่เก็บข้อมูลที่สอดคล้องกันในที่สุด สำหรับแอปพลิเคชันของฉันนี่ใช้ได้ อย่างไรก็ตามฉันกำลังพัฒนาแบบทดสอบที่ทำสิ่งต่าง ๆ เช่นวัตถุ PUT จากนั้นรับวัตถุและตรวจสอบคุณสมบัติบนวัตถุที่ส่งคืน น่าเสียดายที่ในที่สุดเนื่องจากที่เก็บข้อมูลมีความสอดคล้องกันการทดสอบอย่างง่ายเหล่านี้จึงไม่สามารถทำซ้ำได้ คุณจะทดสอบบริการที่สอดคล้องกันได้อย่างไรในที่สุด?

17 google-app-engine  eventual-consistency  google-cloud-datastore 

ดังนั้นตอนนี้ฉันก็เลยเริ่มมีการจัดหากิจกรรมและ CQRS มาระยะหนึ่งแล้วแม้ว่าฉันจะไม่เคยมีโอกาสใช้รูปแบบในโครงการจริง ฉันเข้าใจถึงประโยชน์ของการแยกข้อกังวลการอ่านและการเขียนของคุณและฉันขอขอบคุณที่การจัดหากิจกรรมทำให้ง่ายต่อการเปลี่ยนสถานะโครงการเป็นฐานข้อมูล "อ่านแบบจำลอง" ซึ่งแตกต่างจาก Event Store ของคุณ สิ่งที่ฉันไม่ชัดเจนเป็นพิเศษคือเหตุผลที่คุณจะต้องคืนค่าการรวมของคุณจาก Event Store เอง หากการฉายการเปลี่ยนแปลงกับฐานข้อมูล "อ่าน" นั้นง่ายมากทำไมไม่ฉายโครงการการเปลี่ยนแปลงไปยังฐานข้อมูล "เขียน" ซึ่งสคีมาตรงกับรูปแบบโดเมนของคุณอย่างสมบูรณ์ นี่จะเป็นฐานข้อมูลสแน็ปช็อตอย่างมีประสิทธิภาพ ฉันคิดว่านี่จะต้องเป็นเรื่องธรรมดาใน ES + CQRS ในแอพพลิเคชั่น หากเป็นกรณีนี้ Event Store จะมีประโยชน์เฉพาะเมื่อสร้างฐานข้อมูล "เขียน" ของคุณใหม่เนื่องจากการเปลี่ยนแปลงสคีมาหรือไม่ หรือฉันกำลังพลาดอะไรที่ใหญ่กว่านี้?

14 cqrs  event-sourcing  eventual-consistency  read-model 

ฉันได้อ่านเกี่ยวกับการจัดหากิจกรรมเมื่อเร็ว ๆ นี้และชอบความคิดที่อยู่เบื้องหลัง แต่ติดอยู่กับปัญหาต่อไปนี้ สมมติว่าคุณมีกระบวนการที่เกิดขึ้นพร้อมกัน N กระบวนการซึ่งรับคำสั่ง (เช่นเว็บเซิร์ฟเวอร์) สร้างเหตุการณ์เป็นผลลัพธ์และเก็บไว้ในที่จัดเก็บส่วนกลาง สมมติว่าสถานะแอพพลิเคชั่นชั่วคราวทั้งหมดนั้นถูกเก็บรักษาไว้ในหน่วยความจำของแต่ละกระบวนการโดยการใช้เหตุการณ์ตามลำดับจากที่จัดเก็บ ตอนนี้สมมติว่าเรามีกฎเกณฑ์ทางธุรกิจดังต่อไปนี้ผู้ใช้แต่ละคนต้องมีชื่อผู้ใช้ที่ไม่ซ้ำกัน หากทั้งสองกระบวนการได้รับคำสั่งการลงทะเบียนผู้ใช้สำหรับชื่อผู้ใช้ X เดียวกันพวกเขาทั้งคู่ตรวจสอบว่า X ไม่ได้อยู่ในรายการชื่อผู้ใช้กฎจะตรวจสอบความถูกต้องของกระบวนการทั้งสองและพวกเขาทั้งสองเก็บเหตุการณ์ "ผู้ใช้ใหม่ . ขณะนี้เราได้ป้อนสถานะโกลบอลที่ไม่สอดคล้องกันเนื่องจากละเมิดกฎธุรกิจ (มีผู้ใช้สองรายที่แตกต่างกันด้วยชื่อผู้ใช้เดียวกัน) ในเซิร์ฟเวอร์ N แบบดั้งเดิม <-> 1 ระบบสไตล์ RDBMS ฐานข้อมูลจะใช้เป็นจุดศูนย์กลางของการซิงโครไนซ์ซึ่งช่วยป้องกันความไม่สอดคล้องดังกล่าว คำถามของฉันคือโดยทั่วไปแล้วเหตุการณ์ที่มาจากระบบจะแก้ไขปัญหานี้ได้อย่างไร พวกเขาเพียงแค่ประมวลผลทุกคำสั่งตามลำดับ (เช่น จำกัด จำนวนของกระบวนการที่สามารถเขียนไปยังร้านค้าถึง 1)?

12 distributed-computing  event-sourcing  eventual-consistency