Video học lập trình mỗi ngày

Nếu thời gian của bạn quý báu hơn rất nhiều người ở đây thì vui lòng đọc điểm này Hệ thống nâng cấp 3000 lên 6000 req/s và cơn bão bắt đầu tới...

Khuyến nghị xem video có cách nhìn trực quan: Cuộc tấn công API giao diện lúc 23h đêm

Tóm tắt phần trước

Như thường lệ để bắt đầu một bài viết mới thuộc Series - Dự án bán vé với đồng thời cao với nhiều lập trình viên họ chưa có cơ hội tiếp xúc mới một hệ thống đống thời cao, có nghĩa là sẽ có ba yếu tố làm nên dự án này, và đây cũng chính là sự khó khăn với chúng ta. Đó là đặc điểm của "Anh chị hãy cho biết 3 đặc điểm của dự án đồng thời cao là gì?"() ở trong này chúng ta đã phân tích rất rõ. Nếu có thời gian tầm 3 phút thôi, hãy tìm hiểu xem 3 đặc điểm đó có trong dự án của mình không.

Ở phần trước khi chúng ta đã thực hiện được việc mở bán vé ngày thứ hai thành công với sự giúp sức của việc cải cách biến redis trở nên mạnh mẽ với cách triển khai của của Senior Backend, biến cache đơn thuần thành Distributed Cache. Có thể nói sự biến hoá này cho chúng ta thấy kiến thức 2 chiều, chiều rộng và chiều sâu của công nghệ giúp các lập trình viên có thể tự tin thêm trong việc hanlder big requests...

Khuyến nghị hãy xem: Chiều sâu và rộng của công nghệ khi triển khai Distributed Cache của Senior

Còn bầy giờ hãy tận hưởng những ngày binh yên trước cơn giông bão chuẩn bị kéo đến.

Distributed Cache và một vụ tai nạn trực tuyến.

Để mô tả một vụ tai nạn trực tuyến một cách sát nhất thì tôi sẽ kể lại một cách chân thật kèm theo đó là một số nói quá lên một chút.

Chuyện kể rằng, trước khi chúng tôi triển khai Chiều sâu và rộng của công nghệ khi triển khai Distributed Cache của Senior thì hệ thống đơn giản một server, một redis thì có thể chạy tới 500 req/s nhưng nó đã xâm nhập vào mysql của hệ thống rất nhiều. Đây là hệ thống và chúng tôi đã ghi lại thực tế.

Khuyến nghị: Hệ thống đông thời CAO được bố trí giám sát như thế này

Như các đồng chí thấy thì với lượng như vậy thì ăn thua gì đúng không? Chính vì vậy team đẫ thay đổi và sử dụng công nghệ khi triển khai Distributed Cache và kết quả cho thấy từ 500 -> 3000 req/s và vẫn đảm bảo được chỉ một request và query mysql mà thôi. Quả thực rất tốt, và chúng tôi đã thư nghiệm trước khi thông báo với Sếp là chúng ta có thê yên tâm vào ngày mở bán thứ hai. Hãy xem hình ảnh sau đây.

Kể từ khi chúng tôi mở bán vé ngày thứ hai vào ngày 11/11 thì thống kê cho thấy thông số rất tuyệt vời, ngoài ra chúng tôi còn theo dõi nhờ vào 4 công nghệ giám sát đỉnh cao của hệ thống backend. Sếp tôi xem xong vào thông báo rằng, mọi thứ rất tốt, chúng ta có thể đi về và ngủ ngon. Chúng tôi bắt đầu trở về vơi tinh thần nhẹ nhõm

Đếm hôm đó chúng tôi về căn hộ dành riêng cho các lập trình viên. Sau một ngày mệt mỏi thì một giấc ngủ ngon là điều quý giá cho mỗi người. Tắm xong chúng tôi không hẹn mà gặp, mỗi thằng cầm một lon bia lên cụng nhau và nhấp vài ngụm bia. Sau đó ai về phòng nấy, và ai đi ngủ thì ngủ, ai nhắn tin với bồ thì nhắn... Ngoài cửa sổ mọi chuyện vẫn bình thường và bên này 8h tối nhưng trời vẫn sáng...

Hệ thống nâng cấp 3000 lên 6000 req/s

10h đêm sau khi đã ăn uống vui vẻ, no say thì vân như thường lệ tôi có thói quen xem lại monitoring trước khi đi ngủ... Và vẫn hy vọng mọi chuyện vẫn tốt đẹp...

Lúc này hệ thống đã lên tới 6000 request/second, điều đó có nghĩa là hệ thống bán vé tàu của chúng tôi phát huy sức mạnh với nhiều người quan tâm. Ngáp một hơi lấy tinh thân đi ngủ thôi...

Cuộc đời lập trình viên đẹp đến thế là cùng... NHƯNG

11h đêm có lẽ ai cũng chìm trong giấc ngủ và kèm theo đó là những giấc mơ. Có lẽ trong giấc ngủ của tôi hầu hết là đang viết code (khà khà.. nói thật). Bỗng nhiên có tiếng notification thật là quen thuộc, nó dồn dập, dồn dập mỗi lúc một nhanh, đó là alermanagement một hệ thống cảnh báo có một dịch vụ nào đang breaker và nó cố gắng retry. Giấc ngủ đã bị phá vỡ ngay khi nó chỉ mới bắt đầu. Chưa dừng lại ở đó, điện thoại vang lên. Sếp tôi, không ai khác là Sếp rồi. Giờ này mà Sếp gọi chỉ có một việc đó GẤP và LỚN.

Đúng như dự đoán của hệ thống giám sát và hệ thống cảnh báo và hệ thống chạy bằng CƠM (Sếp) hệ thống của chúng tôi đã bị gãy liên tục. Lúc này, lúc này... Tôi dụi mắt và tay run khi mở giám sát lên, khi nhìn vào monitoring thì không dám tin vào mắt mình nữa, hay là ngủ chưa tỉnh, tôi lấy tay dụi mắt lần nữa với hy vọng monitoring cũng sẽ vì tôi mà thay đổi, thế nhưng nó vần vậy...

Trời đất... Hệ thống đã ngừng đột ngột tất cả mọi thông số (trong phần member đều nói đến) đều chống lại chúng tôi.. Đây là hình ảnh tiếp theo và nó cũng bắt đầu một cơn giông bão..

Hãy nhìn kỹ vào các thông số trong hình giám sát... Trong member chúng ta sẽ phân tích kỹ hơn. Quay trở lại hiện trường, ai cũng hoang mang, lo lắng, hay tay chúng tôi không đặt vào bàn phím như những lần quen thuộc, mà thay vào đó chúng tôi đặt nó trên đầu, biểu hiện của sự ngỡ ngàng và tội lỗi. Nào anh em, tôi nói: "Chúng ta lại bắt đầu thôi, con đường nào cũng đến thành ROME"...

Cách truy vết ERROR ở hệ thống đồng thời CAO

Lúc này đã 12h đêm, tôi liếc qua skype và thấy status của Sếp tôi vẫn sáng, tôi hiểu Ông ấy đang rất lo lắng hơn chúng tôi nhiều vì đơn giản anh ấy là SẾP... Định hình lại một chút, chúng tôi bắt đầu xử lý tình huống theo những cách trước đây mà team tôi đã làm.

Việc đầu tiên, và điều duy nhất cần làm lúc này là sự BÌNH TĨNH, TỈNH TÁO và không có suy nghĩ đổ lỗi cho bộ phận nào, vì nó đã xảy ra, quá khứ không thể thay đổi, và tương lai không biết sẽ tốt hơn không, nhưng ngày mai sẽ là một ngày chúng tôi sẽ tốt hơn...

Việc thứ hai, truy lùng thông qua Hệ thống đông thời CAO được bố trí giám sát như thế này. Chúng tôi mở email lên: "Ồ, nó đến từ Redis Exporter" wow có lẽ nào là, là, là Distributed Cache của Redisson không thể nào... Chúng tôi đã kiểm tra và nó rất tốt mà. Tiếp đến chúng tôi kiếm tra thêm giám sát LOG phân tán.

Tay run khi tôi bật log và tìm kiếm status -> ERROR chết mẹ rồi: "Hải -> quay xe" thấy count ERROR > 10K thì tôi hoảng hốt, sau đó định thần lại và tôi đột nhiên nghĩ đến query thêm chi tiết ERROR là gì? Và tôi đã thấy nó, cảm ơn hệ thống LOG phân tán, và chi tiết này giúp chúng tôi lần theo manh mối...

Bắt đầu thôi anh em...

Cách khắc phục sự cố hệ thống đồng thời CAO

Sau khi chúng tôi tìm thấy một điều khá đặc biệt ở Distributed Cache của Redisson thì chúng tôi đã nắm rõ sự việc, trước tiên hãy để cho hệ thống được chạy lại thì tôi sửa lại tuyến phòng thủ thứ hai trong hệ thống đống thời cao bằng cách hạ cấp và hạ request, xem lại nếu bạn chưa biết. Còn việc tiếp theo là bắt đầu, tôi gọi vào GROUP SKYPE nơi đó là những anh em thân thuộc.

Dậy thôi, chúng ta có chuyện gấp...

Ngoài trời mưa bắt đầu kéo đến, báo hiệu một đêm không ngủ của TEAM chúng tôi... Gió, bão nó đến không... Hãy chờ bài sau

Chú ý đọc

Những link redirect về home or playlist...