Tổng quan về Distributed system
replication
1
Distributed System
8
White

MasBeeju viết ngày 07/08/2019

Chào anh em web developer!

Hiện nay để một hệ thống web application có thể thành công, nổi tiếng thì sẽ trải qua rất nhiều gian nan. Hệ thống của chúng ta cũng không ngoại lệ. Sprint nào ta cũng implement feature mới, fix bug để hoàn thiện business, logic của hệ thống. Nhưng cần phải biết, từng đó chưa đủ để hệ thống của chúng ta thành công. Lúc khách hàng sử dụng thì application của chúng ta nằm trong môi trường network, và trong môi trường network thì tồn tại một khái niệm là distributed system. Sớm muộn, hệ thống của chúng ta cũng là distributed system. Hôm nay mình sẽ đi vào tổng quan của distributed system và làm rõ tại sao nó lại cần thiết.

Thế giới quan web application trong mắt chúng ta

Hẳn là anh em đều biết fron-end, back-end, database. Và architecture lẫn flow sơ bộ thì anh em cũng đã biết, nó như hình bên dưới.
alt text
Khi build một dự án như trên, anh em nghĩ sẽ có chuyện gì xảy ra?
Dự án của chúng ta sẽ thành công vang dội. Không! Tất nhiên, mọi thứ không chỉ đơn giản như vậy.

Các vấn đề xảy ra và cách giải quyết

  • Nếu một ngày server bỗng gặp vấn đề (về network hay hardware, application có vấn đề gì đấy) thì sao?
    Toàn bộ khách hàng đang dùng hệ thống của mình sẽ không truy cập được. Có người đang lưu một thông tin quan trọng thì server chết, thông tin quan trọng đó bị mất luôn :grimacing:.

  • Nữa, tưởng tượng anh em có một dự án triển vọng (100 người dùng). OK, 100 người dùng:expressionless: Thấy ế ẩm quá, anh em thuê vài bà chị marketing xịn về, và không biết mấy bã làm cái gì đó (=)) :smiling_imp:) mà số người dùng hệ thống của anh em lên tới con số 500. Đúng ý quá rồi, như này mới gọi là "triển vọng" chứ!
    Lúc này, anh em sẽ nghĩ đến chuyện mở rộng bandwidth, nghĩ đến chuyện làm sao server chịu được nhiều request hơn. Yeah, mình đang nói đến Scalability đó người anh em. Có thể chia thành 2 kiểu là Horizontal scaling và Vertical scaling.
    Vertical scaling chắc chắn là suy nghĩ đầu tiên mà anh em nghĩ tới. Giờ hệ thống được yêu cầu là có thể tiếp nhận đồng thời nhiều request hơn lẫn xử lý đồng thời cho nhiều request hơn (2 điều này không giống nhau nha anh em), thì đương nhiên là nâng cấp con server của mình rồi. Nâng cấp hoặc thêm processor, RAM, memory storage, thậm chí, tậu hẳn một em server mới xịn hơn để thay thế em server cũ luôn.
    Rồi bẵng đi một thời gian, lượng người dùng của hệ thống đã lên tới 2000 (I love marketing girls :heart_eyes:) Nhưng lúc này, ta không thể nâng cấp server nổi nữa, giờ phải tìm cách khác thôi.

2 vấn đề trên đòi hỏi high availability và large request covering. Horizontal scaling chứ gì nữa! Single machine chịu không nổi thì chơi kiểu multi-machine vậy. Bằng cách này, dù hệ thống có mấy trăm ngàn người dùng thì ta vẫn triển được.

Horizontal scaling

Đại khái hệ thống của mình sẽ như này.
alt text
Khi 1 user send 1 cái request thì Load Balancer sẽ distribute request đó cho 1 trong những Web client( chính là thứ chúng ta hay gọi là front-end). Tuỳ vào request, nếu request yêu cầu thay đổi data(write) thì ta sẽ gọi đến Master, còn nếu chỉ yêu cầu read thì gọi đến Slave. Master và Slave ở đây đều được gọi chung là Replica.

Replication

Replication ở Distributed system có 2 loại:

o Passive Replication: hay còn gọi là primary-backup hoặc master-slave, một số tài liệu gọi là High-availability replication(cái tên nói lên lợi ích :stuck_out_tongue_closed_eyes:) . Hình phía trên thuộc dạng này đó anh em. Master handle việc write, có thể là read nữa ( nhưng phí lắm), còn Slave handle việc read. Loại này sẽ có 2 lợi ích chính: high availability và back-up, nữa là high performance. Nếu làm rõ ra thì: availability, request latency, read bandwidth, solve bottle neck-deadlock, backup, geographic location...

o Active Replication: hay còn gọi là multi-primary hoặc multi-master, master-master lẫn Enterprise Replication đều được. Mọi master đều handle việc write. Trường hợp hệ thống mình có nhiều client request yêu cầu write database quá, đến nỗi con master mình nâng cấp hết mức rồi mà vẫn chả handle nổi, thì đây là phương án giải quyết. Nhưng giải pháp này thì sẽ có data conflict, cần ta có những resolution tốt. Anh em nghĩ khi bị conflict data thì sẽ có giải pháp gì? Version? 2 master đều thay đổi 1 record đồng thời thì version không giúp ích được gì. Time stamp? Không được, vì trong distributed system không có global clock. Cách giải quyết đơn giản nhất là ignore, còn nếu tất cả các server cùng nằm trên 1 cluster có dùng global time thì sẽ dùng global time để check. Có rất nhiều rule, anh em có thể tìm hiểu thêm ở Data conflict resolution để nắm rõ hơn.

Distributed system

Distributed system là gì?

OK! Vòng vèo nãy giờ để đặt vấn đề và tìm cách giải quyết. Vậy thì liên quan gì tới distributed system?
Distributed system là một hệ thống có các thành phần được đặt trên các máy tính nối mạng khác nhau, giao tiếp và phối hợp hành động của chúng bằng cách pass message cho nhau.

Nói đến đây thì anh em đều phát hiện, mô hình trong phần Horizontal Scaling cũng là một dạng distributed system phải không? Nghĩa là, khi một system đủ lớn thì sẽ xuất hiện các vấn đề, và cách giải quyết là biến nó thành distributed system.

Liên hệ với parallel system

Parallel system khá gần với distributed system: mọi processor dùng chung 1 memory.
Bởi dùng chung nên chả cần phải pass message. Nhưng đã là dùng chung, thì sẽ có tranh chấp tài nguyên, dẫn tới tình trạng bottleneck, ảnh hưởng performance nên sẽ chậm hơn so với việc dùng tài nguyên riêng lẻ như trong distributed system.
Còn distributed system có hình thức kết hợp lỏng lẻo hơn (loosely coupled) parallel system, mỗi processor dùng riêng một memory, data đều giống nhau( chính xác là consistent với nhau), nên sẽ giải quyết được những vấn đề đó. Lúc này sẽ xuất hiện vấn đề là các memory không consistent. Ta phải làm sao? Cách 1, request đến tất cả các node, nếu fail thì fail tất cả, nhưng sẽ bị block 1 thời gian, performance sẽ giảm. Cách 2, dùng message passing - cách được nhiều anh em chọn trên toàn thế giới, tuy data sẽ không consistent tại một vài thời điểm nhưng đây là cách đánh đổi hợp lý.
alt text
(a), (b): a distributed system.
(c): a parallel system.
Wiki

Anh em xem hình trên để dễ tưởng tượng nghen.
Nếu là parallel system thì ta sẽ chia sẻ resource, memory..., ví dụ như hệ thống có nhiều server mà xài chung database, hoặc nhiều processor xài chung resource của computer vậy đó, nhưng kiểu này sẽ gặp vấn đề về locking, blocking. Còn distributed system thì không dùng chung resource, mỗi resource đều giống nhau( chính xác là consistent với nhau), nên sẽ giải quyết được những vấn đề đó. Như anh em hay nghe về CQRS đấy, nếu dự án nào tách việc write-read nhưng chẳng tách database ra thì vẫn là parallel system thôi, vẫn dính performance issue như thường, còn nếu tách database ra riêng thì sẽ là distributed system.

Microservices architecture

Microservices cũng là một dạng của distributed system. Ở microservices, người ta tách mỗi service ra riêng và thường thì không references với nhau, lúc deploy thì mỗi service sẽ đóng vai là 1 server, tách biệt với các service khác. Nhưng các service vẫn có data liên quan với nhau (nên mới xảy ra chuyện pass message đó, không liên quan thì pass message làm gì?), còn data được hiểu như thế nào, mô hình dữ liệu như thế nào thì tùy vào Bounded context (hình bên dưới).
alt text

Lúc này nếu ta cho toàn bộ server kết nối với 1 database duy nhất thì hệ thống của ta là parallel system, nhưng như nãy mình nói đó, sẽ bị các vấn đề về locking, blocking data khi dùng chung tài nguyên.
Còn nếu ta tách hẳn database ra thành nhiều phần, mỗi database dùng cho mỗi service thì lúc này hệ thống của chúng ta sẽ là distributed system, sẽ không gặp vấn đề đó nữa. Nhưng sẽ nảy sinh ra vấn đề data trên các service bị lỏng lẻo, không consistent. Và đây cũng là vấn đề lớn nhất, nan giải nhất ở mô hình này, nếu không handle tốt thì sẽ có vấn đề lớn. Thường thì ta sẽ chấp nhận eventually consistency, cho phép có một khoảng thời gian nhỏ data trên toàn hệ thống không consistent, nhưng sau khoảng thời gian đó thì data trên mọi replica sẽ trở về trạng thái thống nhất với nhau.

Microservices distribute về:

  • Trách nhiệm, chức năng: application của ta distribute ra nhiều service riêng lẻ. Từ một business khổng lồ ta chia ra nhiều phần nhỏ, mỗi service lãnh một trách nhiệm chuyên biệt.
  • Code: theo đó, code được distribute ra trên nhiều service, và deploy trên nhiều server (mỗi service này có thể nằm trên 1 server riêng mà vẫn hoạt động tốt).
  • Data: mỗi service dùng mỗi database riêng của chúng. Trong monolithic ta dùng 1 database chung chứa tất cả data của application, nhưng trong microservice thì được distribute ra, mỗi service dùng 1 database sao cho database của mỗi service là vừa đủ để dùng. Nghĩa là service cần thông tin gì thì database của nó sẽ chứa thông tin đó, database của mỗi service không chứa những thông tin không cần thiết, anh em có thể nhìn hình ảnh phía trên để dễ tưởng tượng hơn.

Chính sách "chia để trị" này sẽ dễ dàng cho việc quản lý code, quản lý permission, giảm request latency, dễ dàng phát triển, maintain lẫn không phụ thuộc công nghệ lẫn nhau...

Kết bài

Qua bài viết cơ bản này, mình hi vọng anh em thấy được những vấn đề của hệ thống web application và có được cái nhìn tổng quan về distributed system hơn. Còn những anh em nào từ các bài viết khác của mình tới đây thì mình mong anh em sẽ hiểu được tất cả những gì mình viết:smile:. Và mình cũng mong anh em góp ý để bài viết được cải thiện hơn nhé! Chúc anh em luôn vui vẻ!

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

MasBeeju

4 bài viết.
51 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
23 0
Hẳn anh em ở đây không xa lạ gì với NoSQL DBMS lẫn thế mạnh của nó. Nhưng liệu chúng ta có thực sự hiểu nó? Trước tiên, ta cùng điểm qua những thế ...
MasBeeju viết 10 ngày trước
23 0
White
22 6
Chào những người anh em Trong thời đại công nghệ hiện nay, có rất nhiều hướng để giải quyết một bài toán. Database (chính xác là DBMS database mana...
MasBeeju viết 1 tháng trước
22 6
White
9 11
Chào anh em (Link) của Hiểu và chọn database trong NoSQL DBMS mình đã phân tích về các loại NoSQL DBMS, part 2 này mình sẽ đi đến CAP theorem(định ...
MasBeeju viết 28 ngày trước
9 11
Bài viết liên quan
White
19 1
Transaction và Distributed Transaction là các vấn đề phải đối mặt rất nhiều trong xây dựng các hệ thống lớn Enterprise Software. Nó ảnh hưởng rất l...
Nghia Minh Le viết gần 3 năm trước
19 1
White
6 0
Tranh chấp tài nguyên là vấn đề lớn cần phải giải quyết trong việc xây dựng hệ thống lớn. Việc tranh chấp tài nguyên ảnh hưởng lớn tới hiệu năng và...
Nghia Minh Le viết gần 3 năm trước
6 0
White
3 0
Khi xây dựng hệ thống xử lý bất đồng bộ dựa trên message thì việc monitor có tính chất cốt tử. Đó là một thách thức rất khó khăn, không có một hệ t...
Nghia Minh Le viết gần 3 năm trước
3 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
4 bài viết.
51 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!