Giới thiệu
Redis cảm thấy vững chắc khi mọi thứ đều ổn. Thử nghiệm thực sự bắt đầu khi có thứ gì đó bị vỡ. Nút gặp sự cố, máy ảo khởi động lại, vùng chứa biến mất hoặc sự cố mạng khiến một phần hệ thống bị cô lập.
Điều gì xảy ra tiếp theo phụ thuộc hoàn toàn vào cách thiết kế sao chép và tính sẵn sàng cao. Nhiều nhóm cho rằng Redis tự động xử lý lỗi, nhưng thực tế không phải vậy. Redis cung cấp các khối xây dựng chứ không phải giải pháp hoàn chỉnh.
Nhân rộng và tính sẵn sàng cao giải quyết các vấn đề khác nhau. Redis hỗ trợ cả hai, nhưng hiểu được sự khác biệt là rất quan trọng để xây dựng hệ thống sản xuất linh hoạt.
Bản sao Redis thực sự làm gì
Về cốt lõi, sao chép Redis là sao chép dữ liệu từ nút này sang nút khác. Nút chính, thường được gọi là nút chính, xử lý tất cả các thao tác ghi. Một hoặc nhiều nút bản sao nhận được luồng thay đổi liên tục và giữ cho dữ liệu của chúng được đồng bộ hóa.
Việc sao chép tồn tại vì ba lý do chính:mở rộng quy mô đọc, sẵn sàng chuyển đổi dự phòng và dự phòng dữ liệu. Tuy nhiên, chỉ sao chép không đảm bảo tính sẵn sàng cao. Nó chỉ cung cấp những thành phần cần thiết để xây dựng nó.
Bản sao hoạt động như thế nào
Khi một bản sao kết nối với bản gốc, nó sẽ bắt đầu với quá trình đồng bộ hóa ban đầu. Bản gốc tạo ảnh chụp nhanh dữ liệu hiện tại của nó và gửi nó đến bản sao. Bản sao tải ảnh chụp nhanh này vào bộ nhớ.
Sau lần đồng bộ hóa đầu tiên, bản chính sẽ truyền tất cả các lệnh ghi tiếp theo vào bản sao. Bản sao áp dụng các lệnh này theo thứ tự giống nhau để luôn nhất quán.
Cách tiếp cận này hiệu quả và đơn giản, nhưng nó đưa ra những đánh đổi quan trọng. Bản sao mặc định không đồng bộ, có nghĩa là luôn có một cửa sổ nhỏ nơi dữ liệu tồn tại trên bản chính nhưng chưa có trên bản sao.
Rủi ro sao chép không đồng bộ và mất dữ liệu
Sao chép không đồng bộ cho phép Redis duy trì tốc độ nhanh và phản hồi nhanh, nhưng điều đó cũng có nghĩa là có thể mất một số dữ liệu nếu bản gốc bị lỗi.
Nếu bản gốc gặp sự cố trước khi bản sao nhận được lần ghi mới nhất thì những lần ghi đó sẽ bị mất. Redis không cố gắng che giấu thực tế này. Đối với dữ liệu bộ đệm, điều này thường được chấp nhận. Đối với trạng thái quan trọng thì có thể không.
Redis cung cấp các tùy chọn để thực hiện sao chép chặt chẽ hơn nhưng đảm bảo chặt chẽ hơn sẽ làm tăng độ trễ và giảm tính khả dụng. Quyết định mức độ mất dữ liệu có thể chấp nhận được là một quyết định quan trọng về mặt kiến trúc.
Sử dụng bản sao để chia tỷ lệ số lần đọc
Một lý do phổ biến để sử dụng bản sao Redis là để mở rộng lưu lượng đọc. Ứng dụng có thể hướng dẫn các thao tác ghi tới bản chính và phân phối các thao tác đọc trên các bản sao.
Điều này làm giảm tải cho bản gốc và cải thiện thông lượng tổng thể. Tuy nhiên, do quá trình sao chép không đồng bộ nên các bản sao có thể trả về dữ liệu hơi cũ.
Đối với các trường hợp sử dụng như cấu hình hoặc cấu hình bộ nhớ đệm, điều này thường ổn. Đối với những tình huống yêu cầu tính nhất quán cao, nó có thể không được chấp nhận. Các đội phải thực hiện sự đánh đổi này một cách có chủ đích.
Điều gì xảy ra khi bậc thầy thất bại
Bản sao một mình không xử lý được lỗi chính. Khi bản gốc ngừng hoạt động, các bản sao vẫn được đồng bộ hóa nhưng không được tự động nâng cấp nếu không có cơ chế chuyển đổi dự phòng bên ngoài.
Tính sẵn sàng cao đòi hỏi phải có thứ gì đó để phát hiện lỗi, điều phối các quyết định và thăng chức cho người chủ mới. Đây là lúc hệ thống chuyển đổi dự phòng phát huy tác dụng.
Redis Sentinel và tính sẵn sàng cao
Redis Sentinel là giải pháp truyền thống để tăng tính sẵn sàng cao cho Redis. Các quy trình Sentinel giám sát các phiên bản Redis, phát hiện lỗi và liên lạc với nhau để đạt được sự đồng thuận.
Khi Sentinels đồng ý rằng một chủ nhân đã ngừng hoạt động, một trong những bản sao sẽ được thăng chức trở thành chủ nhân mới. Sentinels cũng thông báo cho khách hàng để họ có thể kết nối lại với đúng nút.
Sentinel giới thiệu các thành phần bổ sung và độ phức tạp. Để có hiệu quả, nhiều nút Sentinel phải chạy. Một Sentinel duy nhất là không đủ để có tính sẵn sàng cao thực sự.
Sentinel quyết định thất bại như thế nào
Sentinel sử dụng thời gian chờ và số đại biểu để tránh chuyển đổi dự phòng sai. Nhiều Sentinels phải đồng ý rằng không thể liên lạc được với master trước khi được thăng hạng.
Thiết kế này cải thiện độ tin cậy nhưng có nghĩa là việc chuyển đổi dự phòng không diễn ra ngay lập tức. Luôn có một khoảng thời gian ngắn khi bản gốc không có sẵn và không có bản thay thế nào được kích hoạt.
Các ứng dụng phải được thiết kế để xử lý cửa sổ này một cách khéo léo. Việc thử lại, hết thời gian chờ và hành vi dự phòng là rất cần thiết.
Cụm Redis và tính sẵn sàng cao tích hợp sẵn
Redis Cluster tích hợp sao chép và chuyển đổi dự phòng trực tiếp vào hệ thống. Mỗi phân đoạn có một phân đoạn chính và các bản sao, đồng thời quá trình chuyển đổi dự phòng sẽ tự động diễn ra khi phân đoạn chính bị lỗi.
Điều này loại bỏ sự cần thiết của Sentinel nhưng lại đưa ra những hạn chế khác. Việc phân phối khóa, hành vi của khách hàng và hoạt động trên nhiều phân đoạn đòi hỏi phải có thiết kế cẩn thận.
Redis Cluster đơn giản hóa tính sẵn sàng cao đồng thời áp đặt các ranh giới kiến trúc chặt chẽ hơn.
Chuyển đổi dự phòng không có nghĩa là không có thời gian ngừng hoạt động
Một quan niệm sai lầm phổ biến là việc chuyển đổi dự phòng Redis đảm bảo không có thời gian ngừng hoạt động. Trên thực tế, quá trình chuyển đổi dự phòng diễn ra nhanh chóng nhưng không tức thời.
Trong quá trình chuyển đổi dự phòng, một số yêu cầu sẽ không thành công hoặc yêu cầu thử lại. Các hệ thống được thiết kế tốt mong đợi hành vi này và phục hồi một cách nhẹ nhàng. Hệ thống được thiết kế kém có thể gặp sự cố hoặc gây ra lỗi xếp tầng.
Tính sẵn sàng cao cải thiện khả năng phục hồi chứ không phải sự hoàn hảo.
Sự chia rẽ não bộ và những rủi ro của nó
Sự phân chia não xảy ra khi có nhiều hơn một nút tin rằng nó là nút chủ. Redis và Sentinel được thiết kế để ngăn chặn điều này, nhưng phân vùng mạng và cấu hình sai vẫn có thể gây ra điều đó.
Bộ não bị chia tách có thể dẫn đến việc ghi xung đột và hỏng dữ liệu. Để giảm thiểu rủi ro này, cần có số đại biểu Sentinel thích hợp, thiết lập mạng chính xác và thời gian chờ hợp lý.
Bỏ qua những chi tiết này là nguyên nhân phổ biến gây ra những sự cố hiếm gặp nhưng nghiêm trọng.
Độ trễ sao chép và tác động đến hiệu suất
Độ trễ sao chép thường nhỏ nhưng không bao giờ bằng không. Dưới tải trọng ghi lớn, các bản sao có thể tụt lại phía sau bản gốc.
Nếu chuyển đổi dự phòng xảy ra trong khoảng thời gian có độ trễ cao, tình trạng mất dữ liệu sẽ tăng lên. Việc giám sát độ trễ sao chép là điều cần thiết đối với những hệ thống quan trọng về tính toàn vẹn của dữ liệu.
Độ trễ tăng đột ngột thường báo hiệu các vấn đề về hiệu suất hoặc tài nguyên cơ bản.
Tại sao bản sao không phải là bản sao lưu
Bản sao không nên nhầm lẫn với bản sao lưu. Nếu dữ liệu bị xóa trên bản gốc thì việc xóa đó sẽ được sao chép ngay lập tức.
Sao lưu bảo vệ chống lại lỗi của con người và sai sót logic. Bản sao bảo vệ khỏi lỗi phần cứng hoặc quy trình. Cả hai đều được yêu cầu nếu Redis lưu trữ dữ liệu có giá trị.
Những lỗi thường gặp của Redis HA
Các nhóm thường xuyên mắc phải những lỗi tương tự khi thiết kế tính sẵn sàng cao của Redis. Chúng bao gồm giả định rằng sao chép có độ khả dụng cao, chỉ chạy một Sentinel, bỏ qua độ trễ sao chép, không kiểm tra chuyển đổi dự phòng và cho phép ứng dụng gặp sự cố do lỗi Redis.
Những lỗi này xuất hiện nhiều lần trong các báo cáo ngừng hoạt động thực tế.
Thử nghiệm thất bại như một phần của thiết kế
Tính sẵn sàng cao chưa bao giờ được thử nghiệm chỉ tồn tại trên giấy. Các nhóm nên thường xuyên mô phỏng các lỗi bằng cách dừng bản chính trong môi trường được kiểm soát.
Việc quan sát hành vi chuyển đổi dự phòng, đo lường thời gian khôi phục và tìm hiểu phản hồi của ứng dụng sẽ cung cấp những hiểu biết sâu sắc có giá trị mà không tài liệu nào có thể thay thế được.
Mô hình tinh thần thực tế cho Redis HA
Tính sẵn sàng cao của Redis là về sự xuống cấp nhẹ nhàng. Khi Redis khỏe mạnh, hệ thống sẽ hoạt động tốt. Khi Redis trở nên không lành mạnh, hiệu suất có thể giảm sút. Khi Redis không khả dụng, hệ thống vẫn tồn tại.
Nếu Redis ngừng hoạt động khiến toàn bộ hệ thống ngừng hoạt động thì tính sẵn sàng cao sẽ không đầy đủ.
Tóm tắt
Sao chép Redis và tính sẵn sàng cao định hình cách các hệ thống hoạt động khi bị căng thẳng. Bản sao cung cấp bản sao của dữ liệu, trong khi tính sẵn sàng cao mang lại tính liên tục của dịch vụ.
Cả hai đều yêu cầu thiết kế cẩn thận, kỳ vọng thực tế và thử nghiệm liên tục. Khi được triển khai đúng cách, lỗi của Redis sẽ trở thành sự kiện thường xuyên hơn là sự cố lớn. Đó là mục tiêu của tính sẵn sàng cao của Redis.