Các hệ thống lớn scale-up như thế nào???

Nhân cơ hội tìm hiểu về các vấn đề khi phát triển các hệ thống lớn để chuẩn bị cho một công việc mới thì mình sẽ tổng hợp lại những gì mà mình tìm hiểu được từ nhiều nguồn trong bài viết này với mục đích chia sẽ đến các bạn cũng như để lưu lại những gì mình đã tìm hiểu😀.

Káº¿t quáº£ hÃ¬nh áº£nh cho how to scale large systems server

Những hệ thống lớn như Google, Facebook, Tiki, Lazada,.. hoạt động như thế nào khi hàng trăm, hàng nghìn người truy cập cùng một lúc mà hệ thống có thể chịu tải được. Đây là bài toán rất khó và phức tạp. Sao đây mình sẽ cùng nhau tìm hiểu xem hiện nay họ đã giải quyết bài toán đó như thế nào.

1. Vậy các hệ thống nhỏ hoạt động như thế nào?

Muốn biết các hệ thống lớn nó hoạt động như thế nào thì chúng ta phải biết các hệ thống nhỏ nó hoạt động như thế nào trước cái đã.

Thì hầu như các hệ thống nhỏ nào cũng phải có một database để chứa dữ liệu và một cái web server để đọc ghi dữ liệu từ database và nó hiện thị cho người dùng.

Ở hệ thống nhỏ thì con web server và con database server này là một, thường là người ta sẽ kiếm một con server thật, server thật là con máy CPU mạnh, ram nhiều, người ta cài database như mysql, postgresql,.. lên đây, sau đó người ta cài luôn golang, nodejs, java,... để nó chạy lên cái máy này và hai cái này nó nằm chung trên một con server.

Đây là một cách làm của các hệ thống nhỏ như các trang web tin tức,.. thì những con này nó chịu tải cũng tàm tạm. Thường thường trang của bạn có 100 người, ví dụ như hôm nay trang của bạn có đăng một tin hot như "Ngọc Trinh có bạn trai mới" chẳng hạn thì số lượng người truy cập lên 10.000 người, 100.000 người thì bạn có thể tăng con server này lên, ví dụ con server của các bạn có 2 core - 2GB ram thì các bạn nâng cấp lên 8 core - 32GB ram để nó chạy nhanh hơn, phục vụ được nhiều người dùng hơn. Tuy nhiên một hệ thống có lượng truy cập vài trăm nghìn, vài triệu thì không thể nào mà tăng con này lên vô hạn được, do vậy, bình thường người ta sẽ dùng các cách sau:

2. Phân tách Web Server và Database Server

Khi làm như cách trên thì ta thấy con Web Server và Database Server nằm chung một chổ, nhiều khi là con Database Server nó chạy nhiều quá dẫn đến ảnh hưởng tới web, khi đó người ta sẽ tách ra thêm một con server nữa, khi đó ta có hai server riêng, một là chạy web server còn lại là chạy database server.

Thường thì DB server có RAM nhiều để nó lưu trữ index và load cho nhanh, do vậy khi mà có truy cập nhiều thì cái database này nó nằm trong một con server riêng rồi do đó cái web server nó sẽ nhẹ nhàng hơn, nó chỉ việc đọc và ghi dữ liệu lên con database server thôi.

Cách này khi mà trang web của các bạn có lượng truy cập đông quá thì các bạn tách ra làm 2 con làm cho khối lượng công việc nó sẽ nhẹ nhàng hơn giữa 2 con server. Tuy nhiên, cách giải quyết như thế này chỉ áp dụng cho các hệ thống nhỏ nhỏ hay là tầm trung, vậy các hệ thống lớn nó sẽ làm việc như thế nào?

3. Sử dụng Load Balancer để scale

Ví dụ trong mấy cái nhà hàng có 1 đầu bếp và 1 nhân viên, nếu khi khách đông thì họ sẽ làm việc như thế nào???😋, thì họ sẽ thuê nhiều đầu bếp hơn😁. Thì với web họ cũng làm vậy.

Các trang web hầu như ban đầu họ cũng có một con database server và một con web server để đọc ghi từ database thôi. Nếu một con web server nó chỉ chịu được 1000 người truy cập vô thôi, vậy mình phải làm sao... thì chúng ta sẽ tăng lên 10 con, 20 con lên, 1 con chịu được 1000 người thì 10 con chịu được 10.000 người, cứ thế mà tăng lên thôi.

Khi các bạn vào một trang web nổi tiếng như là của Lazada chẳng hạn, thì các bạn sẽ không vào thẳng cái web server của nó mà phải thông qua một con gọi là Load Balancer có thể hiểu đó là cân bằng tải, nó có thể viết bằng phần mềm hoặc cũng có thể là phần cứng luôn.

Vậy con load balancer này nó làm gì? Khi chúng ta truy cập vào lazada.vn thì nó sẽ chia sẽ tải qua nhiều con server, vì vậy khi có số lượng người truy cập nhiều thì chúng ta chỉ cần thêm những con server thôi để phục vụ cho vô hạn người dùng, còn mội chuyện điều phối thì có load balancer lo😛.

Thật ra nó có một cách khác đó là DNS load balancer nữa nha.

4. Sử dụng DNS Load Balancer

Ví dụ các bạn vào trang google.com, thì nó sẽ nói chuyện với DNS, khi các bạn ở Việt Nam thì nó sẽ trỏ đến con web server ở Việt Nam, các bạn ở Lào thì nó sẽ trỏ đến con web server ở Lào để cho khoảng cách từ server đến máy bạn nó gần hơn, truy cập sẽ nhanh hơn.

Tuy nhiên có một vấn đề là cái web server chúng ta có thể tăng bao nhiêu cũng được, mỗi con hoạt động riêng. Nhưng cái database không thể tăng vô hạn như vậy được, bởi vì tất cả các web server phải xài chung một database, khi sử dụng nhiều database sẽ gập vấn đề là đồng bộ dữ liệu giữa các database rất là khó và phức tạp, nên cái con database này nó có thể scale một cách là phình bự lên

bằng cách lắp một con server mạnh hơn, nhưng mình đã nói rồi á, không có một con server nào có thể nâng cấp được lên vô hạn hết, thì họ sẽ làm cách như sau:

5. Scale Database với cơ chế master/slave

Chúng ta sẽ có một con database chính là master và 3 - 4 con database slave. Như vậy toàn bộ những cái ghi sẽ được ghi trên cái con database master và nó sẽ tự đồng bộ qua mấy con đệ tử của nó là slave, còn việc đọc thì có thể đọc qua con master hoặc slave giúp cho cái database chính không bị quá tải.

Cách này áp dụng cho các hệ thống đọc nhiều ghi ít. Nhưng có những hệ thống là đọc nhiều mà ghi cũng nhiều luôn như là facebook, zalo, ... thì sẽ sẽ sữ dụng cách khác

6. Scale Database với Sharding

Nếu bạn có một database có thể cho người dùng ở Anh, Mỹ, Việt Nam đều có thể truy cập được, khi hệ thống có lượng đọc ghi nhiều thì chúng ta có thể áp dụng cách sharding, chia database thành các mẫu shard nhỏ (theo IP, vị trí địa lý,...), như vậy chúng ta sẽ tách thành 3 database riêng là cái ở Anh, cái ở Mỹ, cái ở Việt Nam, và khi người ở Việt Nam thì chỉ truy cập được database ở Việt Nam thôi.

7. Dùng cache để tăng performance

Có những dữ liệu ít thay đổi, khi mỗi lần mà người dùng truy cập, chúng ta đều vào database lấy, như vậy rất tốn thời gian , người ta có một cách khác gọi là cache server thường là dùng Redis hoặc là Memcached, thay vì các bạn gọi vào database và mất vài giây để tính toán thì các bạn chỉ gọi lần đầu thôi, kết quả sẽ được lưu vào cache server, khi người dùng tới các bạn chỉ cần lấy trong cache server này ra, như vậy sẽ giảm đi lượng đọc ghi vào trong database.

Túm lại

Những kĩ thuật mình nhắc đến trong bài chỉ mang tính chất “cưỡi máy bay xem hoa”. Thấy có vẻ đơn giản, nhưng nếu đi sâu vào một trong các kĩ thuật (load balancer, master/slave, sharding) cũng sẽ mất nhiều thời gian để hiểu rõ chúng. Do vậy, mình chỉ liệt kê sơ để bạn đọc có hướng để tìm hiểu thêm.

Thành Công

%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22%22%20style%3D%22endArrow%3Dclassic%3Bhtml%3D1%3BstrokeWidth%3D3%3B%22%20edge%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2250%22%20height%3D%2250%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22190%22%20y%3D%22262%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22250%22%20y%3D%22262%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22%22%20style%3D%22endArrow%3Dclassic%3Bhtml%3D1%3BstrokeWidth%3D3%3B%22%20edge%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2250%22%20height%3D%2250%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22245%22%20y%3D%22280%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22185%22%20y%3D%22280%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E

Tìm kiếm Blog này

ThanhCong Technology