Đầu tiên, Sentinel không phải là trình cân bằng tải hoặc proxy cho Redis.
Thứ hai, không phải tất cả các thất bại đều là cái chết của vật chủ. Đôi khi máy chủ bị treo trong thời gian ngắn, đôi khi cáp mạng không được cắm, v.v. Vì điều này, việc chạy Sentinel trên các máy chủ giống như phiên bản Redis của bạn là không tốt. Nếu bạn đang sử dụng Sentinel để quản lý chuyển đổi dự phòng, bất kỳ thứ gì ít hơn ba vệ tinh đang chạy trên các nút không phải là chủ Redis và (các) nô lệ của bạn sẽ gặp rắc rối.
Sentinel sử dụng cơ chế túc số để bỏ phiếu cho một chuyển đổi dự phòng và nô lệ. Với ít hơn hai lính canh, bạn có nguy cơ bị phân tách não nơi hai hoặc nhiều máy chủ Redis nghĩ rằng chúng là chủ.
Hãy tưởng tượng tình huống bạn chạy hai máy chủ và chạy sentinel trên mỗi máy chủ. Nếu bạn mất một cái, bạn sẽ mất khả năng chuyển đổi dự phòng đáng tin cậy.
Khách hàng chỉ kết nối với Sentinel để tìm hiểu thông tin kết nối chính hiện tại. Bất cứ lúc nào khách hàng mất kết nối, họ lặp lại quá trình này. Sentinel không phải là proxy cho Redis - các lệnh dành cho Redis được gửi trực tiếp đến Redis.
Lý do đáng tin cậy duy nhất để chạy Sentinel với ít hơn ba lính canh là để khám phá dịch vụ, có nghĩa là không sử dụng nó để quản lý chuyển đổi dự phòng.
Hãy xem xét kịch bản hai máy chủ:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Nếu Máy chủ B tạm thời mất kết nối mạng với Máy chủ A trong trường hợp này, HostB sẽ tự thăng cấp thành chủ. Bây giờ bạn có:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Bất kỳ máy khách nào kết nối với Sentinel 2 sẽ được cho biết Máy chủ B là chính, trong khi các máy khách kết nối với Sentinel 1 sẽ được thông báo cho Máy chủ A là máy chủ (nếu bạn có Sentinels của mình đứng sau bộ cân bằng tải, nghĩa là một nửa số khách hàng của bạn).
Vì vậy, những gì bạn cần chạy để có được quản lý chuyển đổi dự phòng đáng tin cậy tối thiểu có thể chấp nhận được là:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Khách hàng của bạn kết nối với các vệ tinh và lấy bản chính hiện tại cho cá thể Redis (theo tên), sau đó kết nối với nó. Nếu máy chủ chết, máy khách sẽ ngắt kết nối, sau đó máy khách sẽ / nên kết nối lại với Sentinel và nhận thông tin mới.
Mỗi thư viện khách xử lý điều này tốt như thế nào là tùy thuộc vào thư viện.
Lý tưởng nhất là Máy chủ C, D và E nằm trên cùng một máy chủ mà bạn kết nối với Redis từ đó (tức là máy khách). hoặc đại diện cho một mẫu tốt đã nhận được chúng. Lực đẩy chính ở đây là để đảm bảo bạn đang kiểm tra xem bạn cần kết nối với Redis từ đâu. Không đặt chúng ở cùng DC / Rack / Region với khách hàng.
Nếu bạn muốn khách hàng của mình nói chuyện với bộ cân bằng tải, hãy thử để các Sentinel của bạn trên các nút LB đó nếu có thể, thêm các máy chủ khác không phải LB nếu cần để có được số lượng lính canh lẻ> 2. Một ngoại lệ cho điều này là nếu máy chủ khách hàng năng động ở chỗ số lượng máy chủ không nhất quán (ví dụ:chúng mở rộng quy mô cho lưu lượng truy cập, giảm trong khoảng thời gian chậm). Trong trường hợp này, bạn phải chạy Sentinels của mình trên các máy chủ không phải client và không phải redis-server.
Lưu ý rằng nếu bạn làm điều này, sau đó bạn sẽ cần phải viết một daemon giám sát kênh Sentinel PUBSUB cho sự kiện chuyển đổi chính để cập nhật LB - trong đó bạn phải định cấu hình để chỉ nói chuyện với chính hiện tại (không bao giờ cố gắng nói chuyện với cả hai). Còn nhiều việc hơn để làm điều đó nhưng sử dụng Sentinel trong suốt đối với máy khách - vốn chỉ biết nói chuyện với IP / Cổng LB.
