Redis sentinel vs clustering

Tôi hiểu redis sentinel là một cách định cấu hình HA (tính khả dụng cao) giữa nhiều trường hợp redis. Như tôi thấy, có một phiên bản redis đang tích cực phục vụ các yêu cầu của khách hàng vào bất kỳ thời điểm nào. Có hai máy chủ bổ sung đang ở chế độ chờ (chờ sự cố xảy ra, vì vậy một trong số chúng có thể hoạt động trở lại).

• Có lãng phí tài nguyên không?
• Có cách nào tốt hơn để sử dụng toàn bộ các tài nguyên có sẵn không?
• Redis phân cụm có phải là một sự thay thế cho Redis lính canh không?

Tôi đã tra cứu tài liệu redis cho sentinel và clustering , ai có kinh nghiệm có thể giải thích cho tôi.

CẬP NHẬT

ĐỒNG Ý. Trong kịch bản triển khai thực tế của tôi, tôi có hai máy chủ dành riêng cho redis. Tôi có một máy chủ khác Máy chủ Jboss của tôi đang chạy. Ứng dụng chạy trong Jboss được định cấu hình để kết nối với máy chủ redis master (M).

Kịch bản chuyển đổi dự phòng

Lý tưởng nhất, tôi nghĩ rằng khi máy chủ bộ đệm Master bị lỗi (quá trình Redis gặp sự cố hoặc lỗi máy) thì ứng dụng trong Jboss cần kết nối với máy chủ bộ đệm Slave. Tôi sẽ cấu hình các máy chủ redis như thế nào để đạt được điều này?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

Đầu tiên, hãy nói chuyện với lính canh.

Sentinel quản lý chuyển đổi dự phòng, nó không cấu hình Redis cho HA. Đó là một sự khác biệt quan trọng. Thứ hai, sơ đồ bạn đã đăng thực sự là một thiết lập tồi - bạn không muốn chạy Sentinel trên cùng một nút với các nút Redis mà nó đang quản lý. Khi bạn mất máy chủ đó, bạn sẽ mất cả hai.

Đối với "Có lãng phí tài nguyên không?" nó phụ thuộc vào trường hợp sử dụng của bạn. Bạn không cần ba nút Redis trong thiết lập đó, bạn chỉ cần hai. Ba tăng khả năng dự phòng của bạn, nhưng không bắt buộc. Nếu bạn cần bổ sung dự phòng thì không lãng phí tài nguyên. Nếu bạn không cần dự phòng thì bạn chỉ cần chạy một phiên bản Redis duy nhất và gọi nó là tốt - vì chạy nhiều hơn sẽ bị "lãng phí".

Một lý do khác để chạy hai nô lệ là phân chia lần đọc. Một lần nữa, nếu bạn cần thì sẽ không lãng phí.

Đối với "Có cách nào tốt hơn để sử dụng toàn bộ các tài nguyên có sẵn không?" chúng tôi không thể trả lời điều đó vì nó quá phụ thuộc vào kịch bản và mã cụ thể của bạn. Điều đó nói rằng nếu số lượng dữ liệu cần lưu trữ là "nhỏ" và tỷ lệ lệnh không quá cao, thì hãy nhớ rằng bạn không cần phải cung cấp máy chủ lưu trữ cho Redis.

Bây giờ cho "Redis clustering có phải là một thay thế cho Redis lính canh?". Nó thực sự phụ thuộc hoàn toàn vào trường hợp sử dụng của bạn. Redis Cluster không phải là một giải pháp HA - nó là một giải pháp nhiều bộ ghi / lớn hơn ram. Nếu mục tiêu của bạn chỉ là HA thì nó có thể sẽ không phù hợp với bạn. Redis Cluster đi kèm với những hạn chế, đặc biệt là về các hoạt động đa phím, vì vậy nó không nhất thiết phải là một hoạt động "chỉ sử dụng cụm" đơn giản.

Nếu bạn nghĩ rằng có ba máy chủ đang chạy Redis (và ba máy chủ đang chạy) là lãng phí, bạn có thể sẽ giữ Cluster nhiều hơn vì nó đòi hỏi nhiều tài nguyên hơn.

Những câu hỏi bạn đã hỏi có lẽ quá rộng và dựa trên quan điểm để tồn tại như đã viết. Nếu bạn có một trường hợp / vấn đề cụ thể mà bạn đang giải quyết, vui lòng cập nhật vấn đề đó để chúng tôi có thể cung cấp hỗ trợ và thông tin cụ thể.

Cập nhật cho các chi tiết cụ thể:

Để quản lý chuyển đổi dự phòng thích hợp trong kịch bản của bạn, tôi sẽ đi với 3 lính canh, một đang chạy trên máy chủ JBoss của bạn. Nếu bạn có 3 nút JBoss thì hãy chọn một nút trên mỗi nút. Tôi muốn có một Redis pod (master + slave) trên các nút riêng biệt và để lính canh quản lý việc chuyển đổi dự phòng.

Từ đó, vấn đề là kết nối JBoss / Jedis để sử dụng Sentinel cho việc quản lý thông tin và kết nối. Vì tôi không sử dụng những tìm kiếm nhanh đó nên Jedis có hỗ trợ cho nó, bạn chỉ cần định cấu hình nó một cách chính xác. Một số ví dụ tôi đã tìm thấy là Tìm kiếm ví dụ về Jedis với Sentinel và https://github.com/xetorthio/jedis/issues/725 nói về việc JedisSentinelPooltrở thành lộ trình sử dụng pool.

Khi Sentinel thực hiện chuyển đổi dự phòng, các máy khách sẽ bị ngắt kết nối và Jedis sẽ (nên?) Xử lý việc kết nối lại bằng cách hỏi Sentinels chủ hiện tại là ai.

Khuyến nghị, ở mọi nơi, là bắt đầu với một số trường hợp lẻ, không sử dụng hai hoặc bội số của hai. Điều đó đã được sửa chữa, nhưng hãy sửa một số điểm khác.

Đầu tiên, nói rằng Sentinel cung cấp chuyển đổi dự phòng mà không có HA là sai. Khi bạn có chuyển đổi dự phòng, bạn có HA với lợi ích bổ sung là trạng thái ứng dụng được nhân rộng. Sự khác biệt là bạn có thể có HA trong một hệ thống mà không cần sao chép (đó là HA nhưng không có khả năng chịu lỗi).

Thứ hai, việc chạy một sentinel trên cùng một máy với phiên bản redis đích của nó không phải là một "thiết lập tồi": nếu bạn mất sentinel, hoặc redis instance của bạn hoặc toàn bộ máy, kết quả sẽ giống nhau. Đó có lẽ là lý do tại sao mọi ví dụ về cấu hình như vậy đều cho thấy cả hai đều chạy trên cùng một máy.

Đây không phải là câu trả lời trực tiếp cho câu hỏi của bạn, nhưng hãy nghĩ, đó là thông tin hữu ích cho những người mới của Redis, như tôi. Ngoài ra câu hỏi này xuất hiện dưới dạng liên kết đầu tiên trong google khi tìm kiếm "Redis cluster vs sentinel".

Redis Sentinel là tên của giải pháp có tính khả dụng cao của Redis ... Nó không liên quan gì đến Redis Cluster và được sử dụng bởi những người không cần Redis Cluster, mà chỉ đơn giản là một cách để thực hiện tự động fail over khi có chủ phiên bản không hoạt động chính xác.

Lấy từ bản thảo thiết kế Redis Sentinel 1.3

Đó không phải là lỗi khi bạn mới sử dụng Redis và triển khai giải pháp chuyển đổi dự phòng. Các tài liệu chính thức về sentinel và clustering không so sánh với nhau, vì vậy thật khó để chọn đúng cách mà không cần đọc rất nhiều tài liệu.

Đây là hiểu biết của tôi sau khi đập đầu vào tài liệu.

Sentinel là một loại giải pháp chờ nóng, nơi các nô lệ được giữ lại và sẵn sàng thăng cấp bất cứ lúc nào. Tuy nhiên, nó sẽ không hỗ trợ bất kỳ ghi đa nút nào. Các nô lệ có thể được cấu hình cho các hoạt động đọc. KHÔNG đúng là Sentinel sẽ không cung cấp HA, nó có tất cả các tính năng của một cụm chủ động-thụ động điển hình (mặc dù đó không phải là thuật ngữ thích hợp để sử dụng ở đây).

Redis cluster ít nhiều là một giải pháp phân tán, hoạt động trên các phân đoạn. Mỗi phần dữ liệu đang được phân phối giữa các nút chủ và nút nô lệ. Hệ số sao chép tối thiểu là 2 đảm bảo rằng bạn có sẵn hai phân đoạn hoạt động trên master và slave. Nếu bạn biết sharding trong Mongo hoặc Elasticsearch, bạn sẽ dễ dàng bắt kịp.

Redis có thể hoạt động trong cụm phân vùng (với nhiều chủ và nô lệ của các chủ đó) hoặc một chế độ cá thể duy nhất (một chủ duy nhất với nô lệ bản sao).
Các liên kết ở đây cho biết:

Khi sử dụng Redis ở chế độ phiên bản duy nhất, trong đó một máy chủ Redis duy nhất quản lý toàn bộ cơ sở dữ liệu chưa được phân vùng, Redis Sentinel được sử dụng để quản lý tính khả dụng của nó

Nó cũng nói:

Một cụm Redis, trong đó dữ liệu được phân vùng giữa nhiều phiên bản chính, tự quản lý tính khả dụng và không yêu cầu thành phần bổ sung.

Vì vậy HA có thể được đảm bảo trong 2 kịch bản đã nêu. Hy vọng điều này xóa những nghi ngờ. Cụm redis và lính canh không thay thế cho nhau. Chúng chỉ được sử dụng để đảm bảo HA trong các trường hợp khác nhau của master được phân vùng hoặc không phân vùng.

Redis Sentinel thực hiện chuyển đổi dự phòng các bản sao quảng bá khi họ thấy bản chính bị lỗi. Bạn thường muốn có một số lẻ các nút canh gác. Đối với ví dụ về một bản chính và một bản sao, nên sử dụng 3 lính canh để có thể có sự đồng thuận về quyết định. Lý tưởng nhất là lính canh thứ 3 nằm trên máy chủ thứ 3 để quyết định không bị lệch (tùy thuộc vào sự thất bại). Sentinel đảm nhận việc thay đổi cài đặt cấu hình chính / bản sao trên các nút của bạn để quảng cáo và đồng bộ hóa diễn ra theo đúng thứ tự và bạn không ghi đè dữ liệu bằng cách sử dụng một bản chính cũ bị lỗi hiện chứa dữ liệu cũ hơn.

Khi bạn đã thiết lập các nút sentinel để thực hiện chuyển đổi dự phòng, bạn cần đảm bảo rằng bạn đang trỏ đến đúng phiên bản. Xem ví dụ về cấu hình HAProxy cho điều này . HAProxy thực hiện kiểm tra sức khỏe và sẽ trỏ đến cái chính mới nếu xảy ra lỗi.

Phân cụm sẽ cho phép bạn mở rộng quy mô theo chiều ngang và có thể giúp xử lý tải cao. Phải mất một chút công việc để thiết lập và cấu hình trước.

Có một nhánh mã nguồn mở của Redis, “KeyDB” đã loại bỏ nhu cầu về các nút giám sát với tùy chọn bản sao hoạt động. Điều này cho phép nút bản sao chấp nhận đọc và ghi. Khi xảy ra chuyển đổi dự phòng, HAProxy sẽ dừng đọc / ghi với nút bị lỗi và chỉ sử dụng nút hoạt động còn lại đã được đồng bộ hóa. Dấu thời gian cho phép các nút bị lỗi tự động tham gia lại và đồng bộ hóa lại mà không làm mất dữ liệu khi chúng trực tuyến trở lại. Thiết lập rất đơn giản và để có lưu lượng truy cập cao hơn, bạn không cần thiết lập trả trước đặc biệt để chuyển trực tiếp các lần đọc đến nút bản sao và đọc / ghi vào nút chính. Xem ví dụ về nhân rộng tích cực tại đây . KeyDB cũng đa luồng, đối với một số ứng dụng có thể là một giải pháp thay thế cho phân cụm, nhưng thực sự phụ thuộc vào nhu cầu của bạn.

Ngoài ra còn có một ví dụ về thiết lập phân cụm theo cách thủ công và bằng công cụ tạo cụm . Đây là các bước tương tự nếu bạn đang sử dụng Redis (thay thế 'keydb' bằng 'redis' trong hướng dẫn)

Thông tin bổ sung cho các câu trả lời ở trên

Cụm Redis

• Một mục đích chính của cụm Redis là phân phối đều / đồng nhất tải dữ liệu của bạn bằng cách sharding

• Redis Cluster không sử dụng hàm băm nhất quán, mà là một hình thức khác của sharding trong đó mỗi khóa là một phần khái niệm của cái được gọi là vùng băm

• Có 16384 vị trí băm trong Cụm Redis, Mỗi nút trong Cụm Redis chịu trách nhiệm về một tập con của các vị trí băm, vì vậy, ví dụ, bạn có thể có một cụm với 3 nút, trong đó:

  Nút A chứa các khe băm từ 0 đến 5500, Nút B chứa các khe băm từ 5501 đến 11000, Nút C chứa các khe băm từ 11001 đến 16383

Điều này cho phép chúng tôi thêm và loại bỏ các nút trong cụm một cách dễ dàng. Ví dụ, nếu chúng ta muốn thêm một nút D mới, chúng ta cần di chuyển một số vùng băm từ các nút A, B, C sang D

• Redis cluster hỗ trợ cấu trúc master-slave, bạn có thể tạo các nô lệ A1, B1, C2 cùng với master A, B, C khi tạo một cluster, vì vậy khi master B đi xuống, slave B1 được thăng cấp là master

Bạn không cần xử lý chuyển đổi dự phòng bổ sung khi sử dụng Redis Cluster và bạn chắc chắn không nên trỏ các phiên bản Sentinel tại bất kỳ nút Cluster nào.

Vậy về mặt thực tế, bạn nhận được gì với Redis Cluster?

1. Khả năng tự động phân chia tập dữ liệu của bạn giữa nhiều nút.

2. Khả năng tiếp tục hoạt động khi một tập hợp con của các nút gặp lỗi hoặc không thể giao tiếp với phần còn lại của cụm.

Redis Sentinel

• Redis hỗ trợ nhiều nô lệ sao chép dữ liệu từ một nút chính.
• Điều này cung cấp một bản sao lưu cho dữ liệu trong nút chính.
• Redis Sentinel là một hệ thống được thiết kế để quản lý chủ và nô lệ. Nó chạy như một chương trình riêng biệt. Số lượng lính canh tối thiểu cần có trong một hệ thống lý tưởng là 3. Họ liên lạc với nhau và đảm bảo rằng Chủ nhân còn sống, nếu không còn sống họ sẽ thăng cấp một trong những nô lệ làm chủ nhân, vì vậy sau này khi nút chết quay lên sẽ làm nô lệ cho chủ nhân mới
• Số lượng có thể định cấu hình. Về cơ bản, đó là số lượng lính canh cần phải đồng ý khi chủ xuống. N / 2 +1 nên đồng ý. N là số nút trong Nhóm (lưu ý thiết lập này được gọi là nhóm và không phải là một cụm)

Vậy về mặt thực tế, bạn nhận được gì với Redis Sentinel?

Nó sẽ đảm bảo rằng Chủ nhân luôn sẵn sàng (nếu chủ nhân đi xuống, nô lệ sẽ được thăng cấp thành chủ nhân)

Tài liệu tham khảo :

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial