#135 - Commands and Events in a Distributed System

Aug 23, 2020

Những bài viết hay

Distributed Hash Tables And Why They Are Better Than Blockchain For Exchanging Health Records — medium.com

Distributed Hash Tables (DHT) là một dạng cơ sở dữ liệu phân tán giúp ta lưu trữ và truy cập thông tin với một key trong 1 mạng lưới các máy (nodes), các máy này có thể tham gia và rời khỏi mạng lưới này bất cứ lúc nào. Các nodes sẽ tương tác với nhau để cân bằng và lưu trữ dữ liệu trong network mà không có sự can thiệp của bất kì node điều phối trung tâm nào. Cách thức phân bố dữ liệu cũng tương phản với mô hình Blockchain, nơi mà mỗi node chứa toàn bộ copy của 1 cả hệ thống. Đây là khác biệt cơ bản giúp việc lưu trữ thông tin y tế trên Blockchain là không khả thi khi lượng thông y tế của bệnh nhân thường rất lớn. Ngoài ra, dù Blockchain được tối ưu hoá để lưu trữ lượng nhỏ dữ liệu đã được nén, nguy cơ bảo mật vẫn rất lớn trong trường hợp 1 node bị tấn công. Trường hợp ta mã hoá thông tin thì sẽ hạn chế những ích lợi của việc lưu trữ thông tin trên Blockchain, ví dụ như khả năng truy cập thông tin y tế trong trường hợp khẩn cấp sẽ rất khó để thiết kế.

Một số đặc tính của DHT:

Dữ liệu trong DHT được replicated để đảm bảo tính tin cậy của hệ thống.
Cấu trúc của keys: Các key sẽ được phân bố đều qua các nodes.
Chi phí Routing và Lookup: Về cơ bản, các DHT nodes chỉ có thông tin routing của 1 vài node trong network. Điều này có nghĩa khi 1 node tham gia vào network, chỉ 1 vài node biết đến thông tin này. Do đó, quá trình tìm kiếm và lưu trữ 1 key/value cần tương tác giữa nhiều nodes. Lookup complexity là O(log n), với n là số node trong network.
Có hai phương pháp để tìm kiếm node chứa 1 key bất kì: Iterative lookup và Rescursive lookup

Effective Microservices: 10 Best Practices — towardsdatascience.com

Thiết kế hệ thống microservice một cách đúng đắn luôn là một thách thức đòi hỏi kinh nghiệm và hiểu biết nhiều về kiến trúc này. Microservices luôn có nhiều cách giải quyết cho những vấn đề khác nhau, nhưng nếu lựa chọn sai phương pháp thì nó sẽ là một quả bom nổ chậm cho ứng dụng của bạn. Vì thế nắm rõ những best practices khi thiết kế hệ thống microservice là điều cần thiết.

Domain-Driven Design: Một trong những vấn đề quan trọng nhất khi tách một ứng dụng ra microservice là làm thế nào để chia một ứng dụng lớn và phức tạp ra từng phần nhỏ hơn và ít phụ thuộc, nhất là với những phần còn lại. Nếu tách sai sẽ dẫn đến việc các service bị phụ thuộc vào nhau từ đó không thể tận dụng được lợi thế của kiến trúc này mà còn làm mọi thứ phức tạp hơn. Domain-Driven design là một trong những cách thiết kế để giải quyết vấn đề này.
Database per Microservice: Sau khi đã chia tách xong một ứng dụng thì vấn đề tiếp theo đó là liệu chúng ta có nên share chung một database giữa các service. Việc share chung database có thể tạo ra sự phụ thuộc rất lớn giữa các service, chỉ cần một sự thay đổi nhỏ trong database schema cũng có thể làm ảnh hưởng đến những service khác, quản lý các transactions, locking cũng trở nên khó khăn hơn. Nhưng nếu mỗi service có một database của riêng mình thì những vấn đề trên cũng trở nên dễ dàng hơn, khi có thay đổi trong schema cũng sẽ không làm ảnh hưởng đến những service khác.

Mời bạn đọc thêm những best practice khác của bài viết sau đây

Commands and Events in a Distributed System — medium.com

Trong cuộc sống nói chung và lập trình nói riêng, việc hiểu rõ các khái niệm cơ bản, đặc biệt là các khái niệm dễ gây nhầm lẫn, giúp bạn đưa ra các quyết định nhanh chóng và nhất quán.

Trong hệ thống phức tạp như hệ thống phân tán (distributed system) có hai khái niệm bạn cần phân biệt là mệnh lệnh - commands và sự kiện - events. Một khi phân biệt được hai khái niệm này, bạn có thể dễ dàng đưa ra sự lựa chọn giữa hai hướng tiếp cận command-processing hay event-handling

Command-processing: kích hoạt một hoặc nhiều service cụ thể để xử lý một tác vụ nào đó.
Event handling: hay được biết đến với pattern pub-sub.

Trước tiên cần hiểu commands và events là gì? Command là một hành động nào đó cần được thực hiện bời một hay nhiều services theo yêu cầu từ end-user hay một service. Event phản chiếu trạng thái của một hành động. Ví dụ, khi bạn thực hiện mua hàng online, thông thường bạn sẽ thêm sản phẩm vào giỏ hàng của bạn, sau đó tiến hành thanh toán.

Commands: thêm sản phẩm vào giỏ hàng, thanh toán, cập nhật số lượng sản phẩm còn lại
Events: sản phẩm được thêm vào giỏ hàng thành công, khách hàng bắt đầu thanh toán, khách hàng đã thanh toán thành công, số lượng hàng trong kho đã được cập nhật thành công. Chú ý, ở ví dụ trên chúng ta chỉ xem xét đến trường hợp thành công, nếu lỗi xảy ra thì event có thể bao gồm thanh toán thất bại hoặc cập nhật số lượng hàng thất bại.

Dưới đây liệt kê sự khác biệt cách chúng ta nên xử lý command và event:

Command có thể sửa đổi - event thì không: ở ví dụ trên, nếu quá trình thanh toán bị lỗi do sai thông tin, chúng ta có thể thực hiện lại việc thanh toán, tức chúng ta có thể thay đổi command. Tuy nhiên một khi event đã xảy ra thì nó sẽ ở đó mãi mãi do chúng ta không thể thay đổi một event đã xảy ra.
Command không theo thứ tự - event theo thứ tự: chúng ta có thể xử lý command theo bất kì thứ tự nào, tuy nhiên event phải được xử lý theo đúng thứ tự do tính chất bất biến của event.
Command có thể bị từ chối - event thì không thể: hệ thống có thể từ chối thực hiện một command bởi vì invalid data hoặc một lý do nào đó. Tuy nhiên một khi event đã xảy ra, service lắng nghe event đó bắt buộc phải xử lý theo một cách nào đó.
Command chỉ đích danh service nào xử lý hành động gì và phải trả về kết quả thành công hay thất bại. Event không chỉ đích danh service nào cần xử lý, hay nói cách khác, service tạo ra event không cần quan tâm service nào xử lý event do mình tạo ra và cũng không quan tâm thành công hay thất bại.

Nếu bạn quan tâm chi tiết hơn về command và event trong hệ thống phân tán, mời bạn đọc thêm bài viết này của tác giả Dave Taubler.

Góc Database

Google Spanner là một hệ quản trị cơ sở dữ liệu phân tán có quy mô lớn đang được sử dụng bởi nhiều dịch vụ quan trọng bên trong Google.

Khởi đầu được xây dựng như một kho dữ liệu dạng key-value có hỗ trợ một vài tính năng như transaction cập nhật nhiều dòng, external consistency, transparent failover. Sau 7 năm, dần dần Spanner đang được nâng cấp dần trở thành một hệ cơ sở dữ liệu quan hệ.

Nếu như bạn nào đã từng làm việc với các hệ cơ sở dữ liệu phân tán, đặc biệt là có cơ hội trải qua cả các hệ thống NoSQL và SQL thì hẳn sẽ cảm nhận được sự khó khăn trong việc hỗ trợ tăng tải của các cơ sở dữ liệu loại SQL, cũng như sự thiếu hụt các tính năng hỗ trợ truy vấn của các NoSQL. Rõ ràng, việc xây dựng và nâng cấp Spanner thành một hệ cơ sở dữ liệu phân tán sẽ giúp kết hợp ưu điểm của cả hai thế giới, nhưng đây cũng là một thử thách không dễ vượt qua.

Trong bài báo này, các tác giả chia sẻ lại những kỹ thuật mà họ đã vận dụng trong thiết kế spanner, đặc biệt là các kỹ thuật có liên quan đến phiên dịch và thực thi query:

Những kỹ thuật đã được sử dụng để xây dựng thực thi query theo mô hình phân tán (distributed query execution)
Kỹ thuật Range Extraction, giúp cho hệ thống quyết định được server nào nên xử lý câu query, cũng như làm sao để tối thiểu hoá phạm vi dòng cần quét trên các server.
Thảo luận về cách xử lý lỗi trong quá trình thực thi câu query. Cơ chế này giúp cho các lập trình viên sử dụng Spanner không cần quan tâm về lỗi xảy ra (về mặt hạ tầng) khi thực thi câu query.
Bên trong Google có nhiều hệ cơ sở dữ liệu cùng được xây dựng cho các mục đích khác nhau, nhưng cùng chia sẻ việc sử dụng SQL làm ngôn ngữ truy vấn. Và một trong các kỹ thuật được các tác giả của bài báo chia sẻ đó là việc làm sao để sử dụng cú pháp SQL một cách nhất quán giữa Spanner và các hệ thống khác.
SSTable, một thiết kế gắn liền với Big-table đã được thay thế bằng Ressi, một kho dữ liệu dạng blockwise -columnar được xem là sẽ tối ưu hơn cho việc hỗ trợ đồng thời 2 loại tải là OLTP và OLAP
Ngoài ra một vài bài học liên quan đến quá trình deploy cũng được chia sẻ trong bài báo.

Mời các bạn cùng tham khảo bài báo để hiểu thêm chi tiết: link

Code & Tools

Sponsor

We’ve built an engineering and AI powerhouse in bustling southern Vietnam, where we tackle AI’s biggest challenges in the public safety space. With cameras that depict truth, automated reporting and evidence management that will triple the amount of time officers can spend serving their communities, and Smart Weapons that protect life in the moment of conflict, Axon has revolutionized the world of public safety - and by working here, you can contribute every day to the mission to protect life.

LinkedIn: https://www.linkedin.com/company/axon-protect-life/life/c3dd0184-9540-4c1e-aaa5-34544ded8e59/

Link jobs:

https://jobs.lever.co/axon/593c20c7-1421-45e3-847c-33be2f646f76

https://jobs.lever.co/axon/fd318c3e-0a8e-4d13-af56-fdec7e049826

Quotes

Fix the cause, not the symptom

- Steve Maguire