Đến với một sản phẩm đã phát triển hơn chục năm, không có gì đáng ngạc nhiên khi tìm thấy những công nghệ lạc hậu trong đó. Nhưng điều gì sẽ xảy ra nếu trong sáu tháng bạn phải giữ tải trọng cao hơn gấp 10 lần và chi phí cho những cú ngã sẽ tăng lên hàng trăm lần? Trong trường hợp này, bạn cần một Kỹ sư chịu tải cao. Nhưng vì không có người giúp việc nên họ giao cho tôi giải quyết vấn đề. Trong phần đầu tiên của bài viết, tôi sẽ cho bạn biết cách chúng tôi chuyển từ Redis sang Redis-cluster và trong phần thứ hai, tôi sẽ đưa ra lời khuyên về cách bắt đầu sử dụng cụm và những điều cần chú ý khi sử dụng nó.

Lựa chọn công nghệ

Nó có tệ đến vậy không? Redis riêng biệt (redis độc lập) trong cấu hình gồm 1 chủ và N nô lệ? Tại sao tôi gọi nó là công nghệ lạc hậu?

Không, Redis không tệ đến thế... Tuy nhiên, có một số khuyết điểm không thể bỏ qua.

• Đầu tiên, Redis không hỗ trợ các cơ chế khắc phục thảm họa sau lỗi chính. Để giải quyết vấn đề này, chúng tôi đã sử dụng cấu hình tự động chuyển VIP sang chủ mới, thay đổi vai trò của một trong những nô lệ và chuyển đổi những người còn lại. Cơ chế này hoạt động nhưng không thể gọi là giải pháp đáng tin cậy. Thứ nhất, đã xảy ra cảnh báo sai và thứ hai, nó chỉ dùng một lần và sau khi vận hành, cần phải thực hiện các thao tác thủ công để sạc lò xo.

• Thứ hai, chỉ có một chủ dẫn đến vấn đề sharding. Chúng tôi phải tạo một số cụm độc lập “1 chủ và N nô lệ”, sau đó phân phối cơ sở dữ liệu theo cách thủ công giữa các máy này và hy vọng rằng ngày mai một trong các cơ sở dữ liệu sẽ không bị phình to đến mức phải chuyển sang một phiên bản riêng.

Các tùy chọn là gì?

• Giải pháp đắt nhất và phong phú nhất là Redis-Enterprise. Đây là một giải pháp đóng hộp với sự hỗ trợ kỹ thuật đầy đủ. Mặc dù thực tế là nó trông lý tưởng từ góc độ kỹ thuật, nhưng nó không phù hợp với chúng tôi vì lý do ý thức hệ.
• Redis-cụm. Có sẵn sự hỗ trợ cho chuyển đổi dự phòng và phân mảnh chính. Giao diện gần như không có gì khác biệt so với phiên bản thông thường. Có vẻ đầy hứa hẹn, chúng ta sẽ nói về những cạm bẫy sau.
• Tarantool, Memcache, Aerospike và những người khác. Tất cả những công cụ này đều thực hiện khá giống nhau. Nhưng mỗi cái đều có những khuyết điểm riêng. Chúng tôi quyết định không bỏ tất cả trứng vào một giỏ. Chúng tôi sử dụng Memcache và Tarantool cho các nhiệm vụ khác và nhìn về phía trước, tôi sẽ nói rằng trong quá trình thực hành của chúng tôi có nhiều vấn đề hơn với chúng.

Cụ thể sử dụng

Hãy cùng xem những vấn đề trước đây chúng tôi đã giải quyết với Redis và chức năng nào chúng tôi đã sử dụng:

• Bộ nhớ đệm trước khi yêu cầu các dịch vụ từ xa như 2GIS | Golang
  

  NHẬN THIẾT LẬP MGET MSET "CHỌN DB"

• Bộ nhớ đệm trước MYSQL | PHP
  

  NHẬN THIẾT LẬP MGET MSET SCAN "KEY BY PATTERN" "CHỌN DB"

• Kho lưu trữ chính phục vụ làm việc với phiên và tọa độ lái xe | Golang
  

  NHẬN THIẾT LẬP MGET MSET "CHỌN DB" "THÊM KHÓA GEO" "NHẬN KHÓA GEO" QUÉT

Như bạn có thể thấy, không có toán học cao hơn. Vậy thì khó khăn là gì? Chúng ta hãy xem xét từng phương pháp riêng biệt.

Phương thức
Описание
Các tính năng của Redis-cluster
phán quyết

ĐƯỢC THIẾT LẬP
Phím ghi/đọc

MSET MSET
Viết/đọc nhiều phím
Các phím sẽ ở trên các nút khác nhau. Các thư viện được tạo sẵn chỉ có thể thực hiện nhiều thao tác trong một nút
Thay thế MGET bằng một đường dẫn hoạt động N GET

CHỌN cơ sở dữ liệu
Chọn cơ sở chúng tôi sẽ làm việc cùng
Không hỗ trợ nhiều cơ sở dữ liệu
Đặt mọi thứ vào một cơ sở dữ liệu. Thêm tiền tố vào khóa

SCAN
Đi qua tất cả các khóa trong cơ sở dữ liệu
Vì chúng ta có một cơ sở dữ liệu nên việc xem qua tất cả các khóa trong cụm là quá tốn kém
Duy trì một bất biến trong một khóa và thực hiện HSCAN trên khóa này. Hoặc từ chối hoàn toàn

GEO
Hoạt động với geokey
Geokey không bị phân mảnh

TỪ KHÓA THEO MẪU
Tìm kiếm khóa theo mẫu
Vì chúng tôi có một cơ sở dữ liệu nên chúng tôi sẽ tìm kiếm trên tất cả các khóa trong cụm. Quá đắt
Từ chối hoặc duy trì tính bất biến, như trong trường hợp SCAN

Redis vs Redis-cụm

Chúng ta mất gì và được gì khi chuyển sang cụm?

• Nhược điểm: chúng tôi mất chức năng của một số cơ sở dữ liệu.
  • Nếu chúng ta muốn lưu trữ dữ liệu không liên quan về mặt logic trong một cụm, chúng ta sẽ phải tạo ra những chiếc nạng dưới dạng tiền tố.
  • Chúng tôi mất tất cả các hoạt động “cơ sở”, chẳng hạn như SCAN, DBSIZE, CLEAR DB, v.v.
  • Nhiều thao tác đã trở nên khó thực hiện hơn nhiều vì nó có thể yêu cầu quyền truy cập vào một số nút.
• Cộng thêm:
  • Khả năng chịu lỗi ở dạng chuyển đổi dự phòng chính.
  • Sharding về phía Redis.
  • Truyền dữ liệu giữa các nút nguyên tử và không có thời gian chết.
  • Thêm và phân phối lại công suất cũng như tải mà không có thời gian ngừng hoạt động.

Tôi kết luận rằng nếu bạn không cần cung cấp khả năng chịu lỗi ở mức độ cao thì việc chuyển sang một cụm là không đáng, vì đó có thể là một nhiệm vụ không hề nhỏ. Nhưng nếu ban đầu bạn chọn giữa phiên bản riêng và phiên bản cụm, thì bạn nên chọn cụm, vì nó không tệ hơn và hơn nữa, sẽ giúp bạn giảm bớt một số cơn đau đầu

Đang chuẩn bị di chuyển

Hãy bắt đầu với các yêu cầu để di chuyển:

• Nó phải liền mạch. Việc dừng hoàn toàn dịch vụ trong 5 phút là không phù hợp với chúng tôi.
• Nó phải an toàn và dần dần nhất có thể. Tôi muốn kiểm soát được tình hình. Chúng tôi không muốn bỏ mọi thứ cùng một lúc và cầu nguyện qua nút quay lại.
• Mất dữ liệu tối thiểu khi di chuyển. Chúng tôi hiểu rằng sẽ rất khó để di chuyển nguyên tử, vì vậy chúng tôi cho phép giải đồng bộ hóa một số dữ liệu trong Redis thông thường và theo cụm.

Bảo trì cụm

Ngay trước khi di chuyển, chúng ta nên suy nghĩ xem liệu chúng ta có thể hỗ trợ cụm hay không:

• Biểu đồ. Chúng tôi sử dụng Prometheus và Grafana để vẽ biểu đồ tải CPU, mức sử dụng bộ nhớ, số lượng máy khách, số lượng hoạt động GET, SET, AUTH, v.v.
• Chuyên môn. Hãy tưởng tượng rằng ngày mai bạn sẽ có một cụm lớn thuộc trách nhiệm của bạn. Nếu nó bị hỏng thì không ai có thể sửa được ngoài bạn. Nếu anh ta bắt đầu giảm tốc độ, mọi người sẽ chạy về phía bạn. Nếu bạn cần thêm tài nguyên hoặc phân phối lại tải, chúng tôi sẽ liên hệ lại với bạn. Để không chuyển sang màu xám ở tuổi 25, nên cung cấp cho những trường hợp này và kiểm tra trước xem công nghệ sẽ hoạt động như thế nào trong một số hành động nhất định. Hãy nói về vấn đề này chi tiết hơn trong phần “Chuyên môn”.
• Giám sát và cảnh báo. Khi một cụm bị hỏng, bạn muốn là người đầu tiên biết về nó. Ở đây, chúng tôi giới hạn ở một thông báo rằng tất cả các nút đều trả về cùng một thông tin về trạng thái của cụm (vâng, nó xảy ra khác nhau). Và các vấn đề khác có thể được phát hiện nhanh hơn nhờ cảnh báo từ dịch vụ khách hàng của Redis.

Di chuyển

Chúng ta sẽ di chuyển như thế nào:

• Trước hết bạn cần chuẩn bị một thư viện để làm việc với cluster. Chúng tôi lấy go-redis làm nền tảng cho phiên bản Go và thay đổi một chút để phù hợp với bản thân. Chúng tôi đã triển khai Đa phương thức thông qua quy trình và cũng sửa một chút các quy tắc lặp lại yêu cầu. Phiên bản PHP có nhiều vấn đề hơn nhưng cuối cùng chúng tôi đã giải quyết bằng php-redis. Gần đây họ đã giới thiệu hỗ trợ cụm và theo quan điểm của chúng tôi thì nó có vẻ tốt.
• Tiếp theo bạn cần triển khai chính cụm đó. Điều này được thực hiện theo nghĩa đen bằng hai lệnh dựa trên tệp cấu hình. Chúng ta sẽ thảo luận về cài đặt chi tiết hơn bên dưới.
• Để di chuyển dần dần, chúng tôi sử dụng chế độ khô. Vì chúng tôi có hai phiên bản của thư viện có cùng giao diện (một cho phiên bản thông thường, một cho cụm), nên không mất phí gì khi tạo một trình bao bọc hoạt động với một phiên bản riêng biệt và sao chép song song tất cả các yêu cầu vào cụm, so sánh các câu trả lời và ghi lại những khác biệt trong nhật ký (trong trường hợp của chúng tôi là NewRelic). Do đó, ngay cả khi phiên bản cụm bị hỏng trong quá trình triển khai, hoạt động sản xuất của chúng tôi sẽ không bị ảnh hưởng.
• Sau khi triển khai cụm ở chế độ khô, chúng ta có thể bình tĩnh nhìn vào biểu đồ chênh lệch phản hồi. Nếu tỷ lệ lỗi chậm nhưng chắc chắn tiến tới một hằng số nhỏ nào đó thì mọi thứ đều ổn. Vì sao vẫn có chênh lệch? Bởi vì việc ghi trong một phiên bản riêng biệt xảy ra sớm hơn một chút so với trong cụm và do microlag nên dữ liệu có thể khác nhau. Tất cả những gì còn lại là xem xét các bản ghi khác biệt và nếu tất cả chúng đều được giải thích là do tính phi nguyên tử của bản ghi, thì chúng ta có thể tiếp tục.
• Bây giờ bạn có thể chuyển chế độ khô theo hướng ngược lại. Chúng tôi sẽ viết và đọc từ cụm và sao chép nó thành một phiên bản riêng. Để làm gì? Trong tuần tới tôi muốn quan sát công việc của cụm. Nếu đột nhiên xảy ra sự cố khi tải tối đa hoặc chúng tôi không tính đến điều gì đó, chúng tôi luôn có sự khôi phục khẩn cấp về mã cũ và dữ liệu hiện tại nhờ chế độ khô.
• Tất cả những gì còn lại là tắt chế độ khô và tháo phiên bản riêng biệt.

Chuyên môn

Đầu tiên, nói ngắn gọn về thiết kế cụm.

Trước hết, Redis là một kho lưu trữ khóa-giá trị. Các chuỗi tùy ý được sử dụng làm khóa. Số, chuỗi và toàn bộ cấu trúc có thể được sử dụng làm giá trị. Có rất nhiều cái sau, nhưng để hiểu cấu trúc chung thì điều này không quan trọng đối với chúng tôi.
Mức độ trừu tượng tiếp theo sau khóa là các khe (SLOTS). Mỗi khóa thuộc về một trong 16 vị trí. Có thể có bất kỳ số lượng phím nào bên trong mỗi khe. Do đó, tất cả các khóa được chia thành 383 bộ rời rạc.

Tiếp theo, phải có N nút chính trong cụm. Mỗi nút có thể được coi là một phiên bản Redis riêng biệt biết mọi thứ về các nút khác trong cụm. Mỗi nút chính chứa một số vị trí. Mỗi vị trí chỉ thuộc về một nút chính. Tất cả các vị trí cần được phân phối giữa các nút. Nếu một số vị trí không được phân bổ thì các khóa được lưu trữ trong đó sẽ không thể truy cập được. Sẽ rất hợp lý khi chạy từng nút chính trên một máy vật lý hoặc logic riêng biệt. Cũng cần nhớ rằng mỗi nút chỉ chạy trên một lõi và nếu bạn muốn chạy nhiều phiên bản Redis trên cùng một máy logic, hãy đảm bảo chúng chạy trên các lõi khác nhau (chúng tôi chưa thử cách này, nhưng về lý thuyết thì nó sẽ hoạt động) . Về cơ bản, các nút chính cung cấp khả năng phân chia thường xuyên và nhiều nút chính hơn cho phép ghi và đọc các yêu cầu theo tỷ lệ.

Sau khi tất cả các khóa được phân phối giữa các vị trí và các vị trí nằm rải rác giữa các nút chính, một số lượng nút phụ tùy ý có thể được thêm vào mỗi nút chính. Trong mỗi liên kết chủ-nô lệ như vậy, việc sao chép bình thường sẽ hoạt động. Cần có các nô lệ để mở rộng các yêu cầu đọc và chuyển đổi dự phòng trong trường hợp lỗi chính.

Bây giờ hãy nói về các hoạt động mà sẽ tốt hơn nếu có thể thực hiện.

Chúng ta sẽ truy cập vào hệ thống thông qua Redis-CLI. Vì Redis không có một điểm vào duy nhất nên bạn có thể thực hiện các thao tác sau trên bất kỳ nút nào. Tại mỗi điểm, tôi chú ý riêng đến khả năng thực hiện thao tác có tải.

• Điều đầu tiên và quan trọng nhất chúng ta cần là hoạt động của các nút cụm. Nó trả về trạng thái của cụm, hiển thị danh sách các nút, vai trò của chúng, phân bổ vị trí, v.v. Có thể lấy thêm thông tin bằng cách sử dụng thông tin cụm và vị trí cụm.
• Sẽ thật tuyệt nếu có thể thêm và xóa các nút. Với mục đích này, có các hoạt động gặp cụm và quên cụm. Xin lưu ý rằng tính năng quên cụm phải được áp dụng cho MỌI nút, cả nút chính và bản sao. Và cluster Meet chỉ cần được gọi trên một nút. Sự khác biệt này có thể gây bối rối, vì vậy tốt nhất bạn nên tìm hiểu về nó trước khi đưa vào hoạt động với cụm của mình. Việc thêm một nút được thực hiện một cách an toàn trong trận chiến và không ảnh hưởng đến hoạt động của cụm theo bất kỳ cách nào (điều này hợp lý). Nếu bạn định xóa một nút khỏi cụm, bạn nên đảm bảo rằng không còn chỗ trống nào trên nút đó (nếu không bạn có nguy cơ mất quyền truy cập vào tất cả các khóa trên nút này). Ngoài ra, không xóa chủ có nô lệ, nếu không việc bỏ phiếu không cần thiết cho chủ mới sẽ được thực hiện. Nếu các nút không còn chỗ trống thì đây chỉ là một vấn đề nhỏ, nhưng tại sao chúng ta lại cần thêm lựa chọn nếu có thể xóa các nút phụ trước.
• Nếu bạn cần hoán đổi mạnh mẽ vị trí chính và vị trí phụ thì lệnh chuyển đổi dự phòng cụm sẽ thực hiện. Khi gọi nó trong trận chiến, bạn cần hiểu rằng chủ sẽ không có mặt trong quá trình hoạt động. Thông thường, quá trình chuyển đổi diễn ra trong chưa đầy một giây nhưng không phải là chuyển đổi nguyên tử. Bạn có thể mong đợi rằng một số yêu cầu gửi tới máy chủ sẽ không thành công trong thời gian này.
• Trước khi loại bỏ một nút khỏi cụm, không được còn chỗ trống nào trên đó. Tốt hơn là phân phối lại chúng bằng lệnh chia sẻ lại cụm. Slots sẽ được chuyển từ chủ này sang chủ khác. Toàn bộ hoạt động có thể mất vài phút, tùy thuộc vào khối lượng dữ liệu được truyền, nhưng quá trình truyền diễn ra an toàn và không ảnh hưởng đến hoạt động của cụm dưới bất kỳ hình thức nào. Do đó, tất cả dữ liệu có thể được truyền trực tiếp từ nút này sang nút khác mà không cần lo lắng về tính khả dụng của nó. Tuy nhiên, cũng có sự tinh tế. Thứ nhất, việc truyền dữ liệu có liên quan đến một tải nhất định trên nút người nhận và người gửi. Nếu nút người nhận đã được tải nặng trên bộ xử lý thì bạn không nên tải nó khi nhận dữ liệu mới. Thứ hai, ngay khi không còn một khe nào trên máy chủ gửi, tất cả các nô lệ của nó sẽ ngay lập tức chuyển đến máy chủ mà các khe này đã được chuyển đến. Và vấn đề là tất cả những nô lệ này sẽ muốn đồng bộ hóa dữ liệu cùng một lúc. Và bạn sẽ may mắn nếu đó là đồng bộ hóa một phần chứ không phải hoàn toàn. Hãy tính đến điều này và kết hợp các hoạt động chuyển vị trí và vô hiệu hóa/chuyển giao nô lệ. Hoặc hy vọng rằng bạn có đủ mức độ an toàn.
• Bạn nên làm gì nếu trong quá trình chuyển tiền, bạn phát hiện mình đã mất slot ở đâu đó? Tôi hy vọng sự cố này không ảnh hưởng đến bạn, nhưng nếu có thì cần có thao tác sửa lỗi cụm. Ít nhất, cô ấy sẽ phân tán các ô trên các nút theo thứ tự ngẫu nhiên. Tôi khuyên bạn nên kiểm tra hoạt động của nó bằng cách trước tiên hãy xóa nút có các vị trí được phân phối khỏi cụm. Vì dữ liệu trong các vị trí chưa được phân bổ đã không còn khả dụng nên đã quá muộn để lo lắng về các vấn đề liên quan đến tính khả dụng của các vị trí này. Đổi lại, hoạt động sẽ không ảnh hưởng đến các vị trí được phân phối.
• Một hoạt động hữu ích khác là giám sát. Nó cho phép bạn xem trong thời gian thực toàn bộ danh sách các yêu cầu đi tới nút. Hơn nữa, bạn có thể grep nó và tìm hiểu xem có lưu lượng truy cập cần thiết hay không.

Điều đáng nói là thủ tục chuyển đổi dự phòng chính. Nói tóm lại, nó tồn tại và theo tôi, nó hoạt động rất tốt. Tuy nhiên, đừng nghĩ rằng nếu bạn rút dây nguồn trên máy có nút chính, Redis sẽ chuyển ngay lập tức và khách hàng sẽ không nhận thấy sự mất mát. Trong thực tế của tôi, việc chuyển đổi diễn ra trong vài giây. Trong thời gian này, một số dữ liệu sẽ không khả dụng: phát hiện thấy tính không khả dụng của dữ liệu chính, các nút bỏ phiếu cho dữ liệu mới, các phụ thuộc được chuyển đổi, dữ liệu được đồng bộ hóa. Cách tốt nhất để đảm bảo rằng chương trình đang hoạt động là tiến hành các cuộc diễn tập tại địa phương. Nâng cụm trên máy tính xách tay của bạn lên, tải ở mức tối thiểu, mô phỏng sự cố (ví dụ: bằng cách chặn các cổng) và đánh giá tốc độ chuyển đổi. Theo tôi, chỉ sau khi chơi theo cách này một hoặc hai ngày thì bạn mới có thể tự tin vào khả năng vận hành của công nghệ. Chà, hoặc hy vọng rằng phần mềm mà một nửa số Internet sử dụng có thể hoạt động.

Cấu hình

Thông thường, cấu hình là điều đầu tiên bạn cần để bắt đầu làm việc với công cụ và khi mọi thứ hoạt động tốt, bạn thậm chí không muốn chạm vào cấu hình. Phải mất một chút nỗ lực để buộc bản thân quay lại cài đặt và xem xét chúng một cách cẩn thận. Trong trí nhớ của tôi, chúng tôi đã gặp ít nhất hai lần hỏng hóc nghiêm trọng do không chú ý đến cấu hình. Đặc biệt chú ý đến những điểm sau:

• timeout 0
  Thời gian sau đó các kết nối không hoạt động được đóng lại (tính bằng giây). 0 - không đóng
  Không phải mọi thư viện của chúng tôi đều có thể đóng kết nối chính xác. Bằng cách tắt cài đặt này, chúng tôi có nguy cơ đạt đến giới hạn về số lượng khách hàng. Mặt khác, nếu xảy ra sự cố như vậy thì việc tự động chấm dứt các kết nối bị mất sẽ che giấu sự cố đó và chúng tôi có thể không nhận thấy. Ngoài ra, bạn không nên bật cài đặt này khi sử dụng kết nối liên tục.
• Lưu xy & chỉ thêm vào có
  Đang lưu ảnh chụp nhanh RDB.
  Chúng tôi sẽ thảo luận chi tiết về các vấn đề RDB/AOF bên dưới.
• dừng ghi trên bgsave-lỗi không & dữ liệu phục vụ nô lệ cũ có
  Nếu được bật, nếu ảnh chụp nhanh RDB bị hỏng, bản gốc sẽ ngừng chấp nhận các yêu cầu thay đổi. Nếu kết nối với master bị mất, Slave có thể tiếp tục đáp ứng các yêu cầu (có). Hoặc sẽ ngừng phản hồi (không)
  Chúng tôi không hài lòng với tình huống Redis biến thành quả bí ngô.
• thay thế-ping-slave-giai đoạn 5
  Sau khoảng thời gian này, chúng ta sẽ bắt đầu lo lắng rằng bản gốc đã bị hỏng và đã đến lúc thực hiện quy trình chuyển đổi dự phòng.
  Bạn sẽ phải tự tìm sự cân bằng giữa các kết quả dương tính giả và kích hoạt chuyển đổi dự phòng. Trong thực tế của chúng tôi, đây là 5 giây.
• thay thế-backlog-kích thước 1024mb & epl-backlog-ttl 0
  Chúng tôi có thể lưu trữ chính xác lượng dữ liệu này vào bộ đệm cho một bản sao bị lỗi. Nếu hết bộ đệm, bạn sẽ phải đồng bộ hóa hoàn toàn.
  Thực tế cho thấy rằng tốt hơn nên đặt giá trị cao hơn. Có rất nhiều lý do khiến một bản sao có thể bắt đầu bị lag. Nếu nó bị chậm, thì rất có thể chủ của bạn đang phải vật lộn để đối phó và việc đồng bộ hóa hoàn toàn sẽ là giọt nước cuối cùng.
• khách hàng tối đa 10000
  Số lượng khách hàng một lần tối đa.
  Theo kinh nghiệm của chúng tôi, tốt hơn là đặt giá trị cao hơn. Redis xử lý tốt các kết nối 10k. Chỉ cần đảm bảo có đủ ổ cắm trên hệ thống.
• chính sách bộ nhớ tối đa dễ bay hơi-ttl
  Quy tắc xóa các phím khi đạt đến giới hạn bộ nhớ khả dụng.
  Điều quan trọng ở đây không phải là bản thân quy tắc mà là sự hiểu biết về cách thức điều này sẽ xảy ra. Redis có thể được khen ngợi vì khả năng hoạt động bình thường khi đạt đến giới hạn bộ nhớ.

Các vấn đề về RDB và AOF

Mặc dù bản thân Redis lưu trữ tất cả thông tin trong RAM nhưng cũng có cơ chế lưu dữ liệu vào đĩa. Chính xác hơn, ba cơ chế:

• Ảnh chụp nhanh RDB - ảnh chụp nhanh hoàn chỉnh của tất cả dữ liệu. Đặt bằng cách sử dụng cấu hình SAVE XY và có nội dung “Lưu ảnh chụp nhanh đầy đủ của tất cả dữ liệu mỗi X giây nếu có ít nhất phím Y đã thay đổi”.
• Tệp chỉ nối thêm - danh sách các thao tác theo thứ tự chúng được thực hiện. Thêm các thao tác mới đến vào tệp cứ sau X giây hoặc mỗi thao tác Y.
• RDB và AOF là sự kết hợp của hai phần trước.

Tất cả các phương pháp đều có ưu điểm và nhược điểm, tôi sẽ không liệt kê tất cả, tôi sẽ chỉ chú ý đến những điểm mà theo tôi là chưa rõ ràng.

Đầu tiên, việc lưu ảnh chụp nhanh RDB yêu cầu gọi FORK. Nếu có nhiều dữ liệu, điều này có thể làm treo toàn bộ Redis trong khoảng thời gian từ vài mili giây đến một giây. Ngoài ra, hệ thống cần phân bổ bộ nhớ cho ảnh chụp nhanh như vậy, dẫn đến cần phải cung cấp gấp đôi RAM trên máy logic: nếu 8 GB được phân bổ cho Redis, thì 16 GB sẽ có sẵn trên máy ảo với Nó.

Thứ hai, có vấn đề với việc đồng bộ hóa một phần. Ở chế độ AOF, khi nô lệ được kết nối lại, thay vì đồng bộ hóa một phần, có thể thực hiện đồng bộ hóa toàn bộ. Tại sao điều này xảy ra, tôi không thể hiểu được. Nhưng thật đáng để ghi nhớ điều này.

Hai điểm này đã khiến chúng tôi phải suy nghĩ xem liệu chúng tôi có thực sự cần dữ liệu này trên đĩa hay không nếu mọi thứ đã bị nô lệ sao chép. Dữ liệu chỉ có thể bị mất nếu tất cả các máy phụ bị lỗi và đây là sự cố cấp độ "cháy ở DC". Như một sự thỏa hiệp, bạn có thể đề xuất chỉ lưu dữ liệu trên các nô lệ, nhưng trong trường hợp này, bạn cần đảm bảo rằng những nô lệ này sẽ không bao giờ trở thành chủ trong quá trình khắc phục thảm họa (vì điều này có cài đặt ưu tiên nô lệ trong cấu hình của chúng). Đối với bản thân chúng tôi, trong từng trường hợp cụ thể, chúng tôi nghĩ xem có cần thiết phải lưu dữ liệu vào đĩa hay không và câu trả lời thường là “không”.

Kết luận

Tóm lại, tôi hy vọng rằng tôi có thể đưa ra ý tưởng chung về cách hoạt động của redis-cluster cho những người chưa từng nghe đến nó và cũng thu hút sự chú ý đến một số điểm không rõ ràng đối với những người đã và đang sử dụng nó trong một khoảng thời gian dài.
Cảm ơn bạn đã dành thời gian và như mọi khi, chúng tôi luôn hoan nghênh những nhận xét về chủ đề này.

Nguồn: www.habr.com