Nội dung bài viết
Video học lập trình mỗi ngày
Bài viết này được đưa vào Series - DDD Project: Từ INTERN đánh bại SENIOR (Highly Concurrent Applications)
Series này là một câu chuyện xây dựng từ hình ảnh của một intern mới ra trường và còn nhiều bỡ ngỡ. Chúng ta hãy xem hành trình của cậu ta như thế nào, khi bắt đầu một hệ thống chưa có gì trong tay chỉ là một node đơn, ngôn ngữ được cung cấp trong ứng dụng chính Nodejs, Go và Java được tham khảo tại Tips JavaScript.
Đây là một phần trong khu du lịch sinh thái của hồ Trị An - Nó bình yên đến lạ thường đúng không? Ước gì anh em mình cũng có thể tự lập trình của cuộc đời mình thì ...
...
Chắc chắn chúng ta sẽ phải thêm một tuyến phòng thủ tiếp theo để bảo về redis, tôi nói. Vậy cái gì có performance tốt hơn Redis cache nữa... Bỗng thằng em INTERN cất tiếng nói, Anh em thấy thế này, giọng nó khá trong trẻo..
Hãy để ý mặc dù Redis là cache nhưng nó là cache phân tán, điều đáng chú ý là nó có tính IO network, chúng ta có thể phân tích nó từ liên kết hoàn chỉnh của một request. Giả sử rằng ba bộ đệm phân tán được sử dụng trong liên kết hiện tại, tức là 1 triệu yêu cầu sẽ tạo ra 3 triệu IO từ xa. Đây là một rủi ro không thể bỏ qua đối với hệ thống. gánh nặng. Do đó, trong các tình huống có tính tương tranh cao, cần đặc biệt chú ý đến hiệu ứng khuếch đại này và có thể chúng ta đã gặp trở lại lớn.
Ồ, em có thể vẽ nó được không? Giọng tôi khàn khàn chứ không trong trẻo như nó.` Nó đáp, chờ em một chút... Và kết quả như sau
Tóm tắt phần 04
Ở phần DDD - Project: vetautet.com 04: Một tai nạn trực tuyến xảy ra lúc 11h đêm, một cuộc điện thoại và nhiều notifications đã cho thấy nhiều bài học cho anh em chúng tôi. Rất may mắn là hệ thống đã được trang bị những warning system để đưa ra những lời cảnh báo đúng lúc, và quan trọng là chúng tôi nhờ vào đó tiết kiệm được nhiều thời gian để truy vết và khoanh vùng tại thời điểm dữ liệu đồng thời lên cao 6.000 - 10.000 request/second. Bạn có thể xem lại cách setup hệ thống cảnh báo ở bài ddd - project 04.
Sau khi khoanh vùng lại thì chúng tôi bắt đầu chuẩn bị kỹ việc fix bug lần này một cách kỹ hơn. Nhưng TEAM vẫn vậy chưa bổ sung thêm nhân lực cũng như chi phí server. Trời lại mưa...
Tôi lần đầu đến với Series - DDD Project JAVA
Phần này là dành cho những lập trình viên lần đầu ghé qua Series này. Hãy để tôi tóm tắt một chút về các phần trước, nói chung là từ một dev intern thì chúng ta phải đi từ đâu, và điều kiện là gì? công nghệ, ngôn ngữ, kỹ năng nào được hình thành thông qua các phần thực hành sau đây.
01 - SpringBoot 3: CÁCH xây dựng dự án triển khai về DDD bán VÉ TÀU, MUSIC với kiến trúc đồng thời CAO!
02 - Chúng tôi xây dựng Structure DDD Project như thế nào đạt chuẩn?
03 - Không tranh cãi, chúng tôi thống nhất hoàn thành kiến trúc DDD này
04 - Khi publish API chúng tôi gặp lượng request rất nhiều, áp dụng Circuit Breaker vs RateLimiter
05 - Sếp bảo tăng tốc từ 1000 lên 10.000 req/s, chúng tôi quyết định thêm Distributed Cached
06 - Sếp - Tại sao chúng ta không sử dụng LUA Redis mà chọn Redisson cho chức năng Lock
08 - Chúng tôi đã thiết lập giám sát Database thông qua Prometheus vs Grafana, giờ ngủ ngon rồi
09 - Thiết lập giám sát Redis thông qua Prometheus vs Grafana và chuẩn bị thiết lập 20.000 req/s
10 - Chuẩn bị có việc tăng tốc từ 10.000 lên 20.000 req/s không tăng chi phí
12 ..
Còn nếu như bạn đã có kinh nghiệm và không cần chuyện thực hành thì có thể đọc câu chuyện này tại blog anonystick.com, hàng tuần tôi sẽ có bài viết về nhiều thể loại, cũng mong các bạn ủng hộ series lần này.
01 - DDD - Project: vetautet.com 02: Tuyến phỏng thủ đầu tiên được thiếp lập
01 - DDD - Project: vetautet.com 03: Tuyến phỏng thủ thứ hai của lập trình viên nhiều kinh nghiệm
05 - DDD - Project: vetautet.com 05: Hệ thống chúng tôi cảm ơn thằng em INTERN và đây có lẽ là định mệnh - Bài viết này...
Đây là phần tiếp theo...
Tìm lý do vì sao hệ thống chịu tải cao lại sụp đổ thêm lần nữa
Sau khi chúng tôi xác định được nguyên nhân và khoanh vùng nó lại, bắt đầu khâu khám sức khoẻ ở redis.
> root@c32ef744fd62:/data# redis-cli info
Hình ảnh sau đây thể hiện rõ là rejected_connections khá nhiều, tiếp theo kéo xuống chút nữa tôi lại thấy error stat_ERR:count=3112 ý nghĩa của thông số này rất quan trọng đó là lỗi thường xảy ra khi Redis nhận một lệnh không hợp lệ, hoặc lệnh không được xử lý đúng cách. Ví dụ: Gửi lệnh sai cú pháp hoặc yêu cầu một thao tác không được hỗ trợ. Với count=3112 thì đây là số lần lỗi này đã xảy ra kể từ khi Redis bắt đầu chạy.
Vậy thì nguyên nhân gì lại xảy ra lỗi chúng tôi tiếp tục kiểm tra
root@c32ef744fd62:/data# redis-cli info clients
# Clients
connected_clients:9454
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:24
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0
Oà... Dừng lại một chút kiểm tra trong hệ thống giám sát grafana mà chúng tôi đã setup nhằm theo dõi sức khở của Redis. Và chúng tôi đã thấy hình như nó đã vượt quá maxclients cho phép mới một node đơn. 90% khà năng lỗi này. Tiếp tục khoanh vùng lại.
Chúng tôi sẽ dựng kịch bản này lại để xem nó xuất hiện lỗi tương tự hay không lần này chúng tôi sẽ set maxclients = 50 và thử nghiệm với một số request lớn để xem lỗi mà ở phần trước có xuất hiện lại hay không?
Quả nhiên đúng như nhận định chính là Distributed Cached là nguyên nhân gián tiếp, trực tiếp chính là Redisson. Ok, xác đinh được nguyên nhân.
Lời khuyên của vị Sếp cho hệ thống chịu tải cao
Bây giờ chúng tôi tự tin hẳn lên vì phát hiện được một lỗi nhưng nó nghiêng về infrastructure gọi là phía hạ tầng. Chúng tôi vội viết một ticket và gửi cho Sếp tôi. Nội dung được tóm lược như sau;
Thưa Sếp! Về vấn đề sụp đổ vào đêm 11/11 chúng tôi đã tìm ra nguyên nhân chính đó là phía Redis chịu tải không đủ mạnh để làm tuyến phòng thù, mặc dù chúng ta đã có một cơ chế lock vửa triển khai với hệ thống Distributed Cached thế nhưng với một Node đơn thì khó có thể chống chọi được một lượng request như vậy thưa Sếp. Cụ thể với một Node đơn chúng ta đã kiểm tra chỉ có
maxclients=10000vì thế chịu tải không đủ. Cách khắc phục chúng ta phải setup một một cluster để tăng tốc chịu tải lên. Ví dụ 3 node thì sẽ cómaxclients= 3* 10000. Lúc đó chúng ta sẽ tự tin hơn ...
Sau đó chúng tôi quay lại chuẩn bị một số config cho việc triển khai Cluster Redis. Cái này thật ra không khó với chúng tôi, vì anh em cũng đã quent huộc với những hệ thống như thế này. Đang làm say sưa, bồng tôi nhận được Email của vị Sếp đáng kính của tôi.
Gửi Anh Tips và Đồng Bọn!!! Trước hết cảm ơn anh em đã không ngủ để tìm ra nguyên nhân sụp đổ hệ thống gây thất thoát hàng tỷ đồng chỉ trong một đêm. Đó là một bài học của sự chủ quan, hệ thống phòng thủ thứ hai hay thứ ba hay thứ N cũng có thể vượt qua bởi một hay nhiều lý do. Quan trọng chúng ta phải cải thiện tốt nhất cho một version tốt hơn version cũ. Tôi đã đọc những lý do và cụ thể là cách khắc phục của TEAM. NHƯNG ở đây tôi có một lời góp ý cho anh em. Thứ nhất hay nhìn vào tổng thể công ty, một công ty còn yêu về tài chính nhưng chúng ta tự hào về có những thành viên có nhiều kinh nghiệm cũng như thực chiến, chính vì vậy cố gắng hãy ưu tiên các làm giảm chi phí nhất nhưng hiệu quả cao nhất, lúc đó với kinh nghiệm của các anh sẽ được phát huy mạnh nhất. Hãy để tôi giải thích thêm, nếu như chúng ta setup một môi trường cluster thì chi phí của Redis sẽ là x3 so với lúc ban đầu. Hãy thử nghĩ, vì sao một con đường sử dụng 24h mỗi ngày, nhưng chỉ 30 phút giờ cao điểm mới bị kẹt, còn lại 23h30 còn lại đường thông thoáng mỗi ngày. Còn số thời gian cao điểm rất ngắn và ít, tôi nghĩ hà cớ gì chúng ta phải xây dựng lại con đường đó, chi phí giải phóng mặt bằng cao, và biết đâu nó lại kẹt như ban đầu. Có thể nói không cần phải sử dụng con dao mổ TRÂU để giết một CON GÀ. Vì vậy phương án thêm Cluster Redis server chúng ta nên bỏ qua, vì công ty còn quá ít với kinh phí. Thiết nghĩ 80% kinh phí duy trì cho công ty là cho TEAM của các bạn hàng tháng, hàng quý, hàng năm, hãy tận dụng và xem có cách nào tôt hơn hay không. Đôi lời với TEAM ...
Chúng tôi đọc nó xong, trong lòng cảm thấy chúng tôi đã quá vội vàng khi làm một việc mà thông thường các lập trình viên nghĩ tới là mở rộng theo chiêu ngang, chiều dọc, thêm server A, B, C... Nhưng điều ở đây, chúng ta không suy nghĩ rằng chiều sâu của chính chúng ta quá nông.. Chính vì vậy một lời cảm ơn tới vị Sếp đáng quý này. Và, anh em, chúng ta cẫn suy nghĩ lại...
Hệ thống đồng thời CAO luôn phải có Local Cache
Ngoài trời vẫn mưa, mưa không nặng hạt vì nhìn qua tâm kính của cửa sổ chúng tôi vẫn nhìn thấy rõ khung cảnh hiện lên, nhưng tâm trạng của anh em tôi lại nặng trĩu. 2h sáng SGP... 
Chắc chắn chúng ta sẽ phải thêm một tuyến phòng thủ tiếp theo để bảo về redis, tôi nói. Vậy cái gì có performance tốt hơn Redis cache nữa... Bỗng thằng em INTERN cất tiếng nói, Anh em thấy thế này, giọng nó khá trong trẻo..
Hãy để ý mặc dù Redis là cache nhưng nó là cache phân tán, điều đáng chú ý là nó có tính IO network, chúng ta có thể phân tích nó từ liên kết hoàn chỉnh của một request. Giả sử rằng ba bộ đệm phân tán được sử dụng trong liên kết hiện tại, tức là 1 triệu yêu cầu sẽ tạo ra 3 triệu IO từ xa. Đây là một rủi ro không thể bỏ qua đối với hệ thống. gánh nặng. Do đó, trong các tình huống có tính tương tranh cao, cần đặc biệt chú ý đến hiệu ứng khuếch đại này và có thể chúng ta đã gặp trở lại lớn.
Ồ, em có thể vẽ nó được không? Giọng tôi khàn khàn chứ không trong trẻo như nó.` Nó đáp, chờ em một chút... Và kết quả như sau
Nó quá rõ ràng, tại sao nó lại đơn giản đến mức một thằng SENIOR như tôi lại không nghĩ ra cơ chứ. Đúng chính xác là IO Network là một điểm trừ ở hệ thống vừa rồi. Cảm ơn thằng em, có lẽ định mệnh mang thằng INTERN này đến cho tôi.
Nhấp một ngụm coffee, nhưng hớp này ngon đến lạ thường, nó kích thích tôi đến sảng khoái trong cơ thể. Tôi cất giọng, hay thật hoá ra tôi đang xài loại coffee trong đó có caffeine nó kích thích trí óc, và làm tăng sự hiệu quả mỗi khi làm việc.
Bỗng caffeine, caffeine oà, tôi đã tìm thấy nó... Chính là nó rồi caffeine trong java sẽ là cứu cánh chúng ta. Anh em, tôi đã thấy cách triển khai đó là caffeine java hay guava java.
Vậy làm sao chọn 1 trong 2 để phát triển local cache, chúng ta cần chọn những tiêu chí gì để có thể nâng cấp từ 10.000 lên 20.000 req/s đây.
Nếu như bạn đang nôn nóng xem chúng tôi đã chọn những tiêu chí gì thì có thể xem nó tại đây: Họp TEAM chọn vũ khí cho việc tăng tốc 20.000 req/s phải đạt 5 tiêu chí sau
Đến giờ đi ngủ thôi, ngày mai lại là một ngày tươi sáng, chả phải ngày hôm nay tốt hơn ngày hôm qua sao. Tôi nói như vậy, ku em đáp, em thấy hôm nay chúng ta cười nhiều hơn hôm qua..
Cuộc đời vốn ngắn ngủi, nếu vui nhiều hơn buồn thì nó đáng sống hay sao?
Hẹn dịp cuối tuần.
