Trước hết, bạn có thể thay đổi cấu hình mặc định nếu bạn thực hiện ít thao tác trong
redis-Trib.rb
trong hàm def check_create_parameters . Bạn có thể đặt một bản sao chính và một bản sao nô lệ.
Mục đích của cấu hình này là để chịu lỗi. Các nô lệ cũng có thể được sử dụng để đọc (SN SÀNG). Trong ba bản chính, các hashslots được phân phối đồng đều và với thuật toán cân bằng tải, bạn có thể phân phối lại và các khóa thực tế. Các bước của một thuật toán có thể tách ra các khóa giữa các nút là (tôi đã thử nghiệm và nó hoạt động như mong đợi):
- Tìm đám đông các bậc thầy
- Nhận tổng số chìa khóa mà họ giữ
- Đối với mỗi nút chính, hãy lưu trữ tên máy chủ, cổng và số lượng khóa
- Tính toán các khóa mà mỗi cái chính phải giữ để sự phân bố các khóa được cân bằng (tổng số khóa của cụm / số khóa cái)
- Tìm các nút chính phải nhận hoặc cung cấp khóa và tổng số khóa mà chúng phải đưa / nhận
- Đặc điểm hóa các nút chính là nút nguồn hoặc nút đích tùy thuộc vào việc họ nhận hay cho đi khóa tương ứng
- Bắt đầu di chuyển từ nút nguồn sang nút đích, đầu tiên là khe cắm sau đó đến các khóa có liên quan và lặp lại cho đến khi tất cả các nhà quản lý chủ đề có cùng số lượng khóa
Thuật toán này sẽ giúp giảm thiểu thời gian phản hồi. Ý tôi là:
Với ba bản gốc, thời gian phản hồi có thể được giảm thiểu. Nếu bạn có cấu hình với một cái chính và cái cái này chứa 30000 #keys, ví dụ:thời gian phản hồi để nhận được 1000 khóa cùng lúc là> từ cấu hình có 2 cái chính chứa 15000 cái mỗi cái.
Nếu bạn tạo một khóa trong master1, thì nếu bạn cố truy cập (đọc) khóa đó từ master2, bạn sẽ gặp lỗi ĐÃ CHUYỂN ĐI. Vì vậy, giải pháp là tạo một ứng dụng khách thông minh ánh xạ các hashslots tới nút tương ứng. Do đó, bạn chỉ có thể xóa khóa khỏi master2 trong trường hợp master2 chuyển hướng yêu cầu của bạn đến đúng master.
Hy vọng điều đó sẽ hữu ích.
