Kể từ khi được thành lập vào năm 2009, Redis OSS đã có một cộng đồng mã nguồn mở rất sôi động. Nhiều công cụ và tiện ích đã được phát triển xung quanh nó và Dynomite, một lớp phân phối địa lý ngang hàng cho các kho dữ liệu không phân tán, là một trong số đó.
Dynomite được phát triển bởi một nhóm kỹ sư tại Netflix và được phát hành dưới dạng mã nguồn mở. Mặc dù nó đã cung cấp các giải pháp tốt cho các nhu cầu cụ thể, nhưng nó đã không được duy trì hiệu quả trong vài năm qua. Hơn nữa, một số chức năng, lệnh và kiểu dữ liệu của Redis OSS (ví dụ:Pub / Sub hoặc Streams) không có sẵn hoặc bị giới hạn bởi mô hình phân phối các phiên bản Redis OSS của Dynomite.
Vì lý do này, chúng tôi đã và đang giúp các tổ chức di chuyển cơ sở dữ liệu Dynomite của họ sang một cụm Redis Enterprise.
So sánh kiến trúc Dynomite và Redis Enterprise
Hãy bắt đầu phần so sánh của chúng tôi với mô tả nhanh về cả kiến trúc của Dynomite và Redis Enterprise.
Dynomite
Một cụm Dynomite điển hình có thể được mô tả như sau:
- Nó trải dài trên nhiều trung tâm dữ liệu
- Một trung tâm dữ liệu duy nhất là một nhóm các giá đỡ
- Rack là một nhóm các nút:mỗi rack chứa toàn bộ tập dữ liệu, được phân vùng trên nhiều nút trong rack đó
Dynomite là một lớp phân phối ngang hàng, do đó một máy khách có thể gửi lưu lượng ghi tới bất kỳ nút nào trong một cụm Dynomite. Nếu nút là nút chịu trách nhiệm về dữ liệu, thì dữ liệu được ghi vào quy trình máy chủ Redis OSS cục bộ của nó, sau đó được sao chép không đồng bộ sang các giá đỡ khác trong cụm trên tất cả các trung tâm dữ liệu. Nếu nút không sở hữu dữ liệu, nó hoạt động như một bộ điều phối và gửi ghi tới nút sở hữu dữ liệu trong cùng một giá đỡ. Nó cũng sao chép các ghi tới các nút tương ứng trong các giá đỡ và DC khác.
Redis Enterprise
Một cụm Redis Enterprise cũng phân phối dữ liệu trên các phiên bản hoặc phân đoạn Redis khác nhau, nhưng có hai điểm khác biệt chính:
- Có thể có nhiều phân đoạn trên một nút - nhưng một phân đoạn chính và một bản sao không thể sống trên cùng một nút, vì mục đích có tính khả dụng cao.
- Chỉ có một bản sao cho mỗi phân đoạn chính. Khách hàng thực hiện các thao tác dữ liệu trên các phân đoạn chính. Các bản sao tương ứng của chúng tồn tại để có tính khả dụng cao trong trường hợp hỏng các phân đoạn chính.
Một phần quan trọng khác của cụm Redis Enterprise là cái được gọi là “đường dẫn quản lý”; nó bao gồm Trình quản lý cụm, Proxy và REST API / UI. Trình quản lý cụm chịu trách nhiệm sắp xếp cụm, đặt các phân đoạn cơ sở dữ liệu vào các nút có khả năng cao và phát hiện lỗi. Proxy ẩn cấu trúc liên kết cụm của Redis Enterprise khỏi các ứng dụng bằng cách cung cấp một điểm cuối duy nhất, không bao giờ thay đổi, cho mỗi cơ sở dữ liệu trong một cụm. Nó cũng giúp mở rộng các kết nối máy khách bằng cách ghép kênh và các lệnh ghép nối thành các phân đoạn.
Dưới đây là minh họa về Cụm doanh nghiệp Redis điển hình:
Với tính năng Active-Active của Redis Enterprise, bạn có thể tạo cơ sở dữ liệu toàn cầu trải dài trên nhiều cụm. Các cụm đó thường nằm trong các trung tâm dữ liệu khác nhau trên thế giới. Một ứng dụng ghi vào cơ sở dữ liệu Active-Active kết nối với điểm cuối phiên bản cục bộ. Tất cả các lần ghi bởi ứng dụng vào một phiên bản cục bộ sẽ được sao chép sang tất cả các phiên bản khác với tính nhất quán cuối cùng mạnh mẽ.
Nhân rộng Chủ động-Hoạt động cung cấp nhiều lợi thế như một giải pháp phân phối theo địa lý, một trong số đó là giải quyết xung đột liền mạch cho các loại dữ liệu Redis Enterprise đơn giản và phức tạp, mà chúng ta sẽ thảo luận bên dưới.
Bây giờ chúng tôi đã có ý tưởng về cấu trúc liên kết của Dynomite và Redis Enterprise, hãy xem những gì chúng đòi hỏi đối với các nhà phát triển và DevOps trong một tổ chức.
Dynomite hoặc Redis Enterprise:Nó tạo ra sự khác biệt nào cho các nhà phát triển?
Ngoài việc Dynomite không được duy trì tích cực, có ba lý do chính khiến một tổ chức muốn chuyển sang Redis Enterprise theo quan điểm của nhà phát triển:
- Các chức năng của Redis bị hạn chế và phức tạp hơn khi sử dụng Dynomite
- Dynomite không có cách hiệu quả để giải quyết các xung đột ghi phân tán theo địa lý
- Hỗ trợ bạn có thể nhận được từ Redis
Hãy xem chi tiết hơn hai phần đầu tiên.
Redis OSS phức tạp và hạn chế
Như bạn có thể đã biết, Redis OSS không phải là một kho lưu trữ khóa-giá trị thuần túy, theo nghĩa là nó không chỉ cho phép bạn liên kết các khóa chuỗi với các giá trị chuỗi. Redis OSS là một máy chủ cấu trúc dữ liệu hỗ trợ các loại giá trị khác nhau như danh sách, tập hợp, băm hoặc luồng. Chúng tôi gọi đó là “loại dữ liệu cốt lõi” của Redis OSS.
Redis OSS cũng có thể mở rộng thông qua các thư viện động được gọi là “mô-đun”. Các mô-đun cho phép bạn nhanh chóng triển khai các lệnh Redis mới với các tính năng tương tự như những gì có thể được thực hiện bên trong chính lõi. Trong số các mô-đun phổ biến nhất là RediSearch, cung cấp khả năng truy vấn, lập chỉ mục thứ cấp và tìm kiếm toàn văn và RedisJSON, biến Redis OSS thành một kho lưu trữ tài liệu mạnh mẽ.
Như đã thảo luận trong phần giới thiệu, một số lệnh và kiểu dữ liệu của Redis OSS không có sẵn hoặc bị giới hạn bởi Dynomite. Đây là một so sánh không đầy đủ:
Bạn có thể tìm thấy danh sách đầy đủ các lệnh được hỗ trợ và không được hỗ trợ với Dynomite tại đây.
Mặt khác, Redis Enterprise, được duy trì cùng với Redis OSS, cho phép các hoạt động đa mô hình bằng cách sử dụng các mô-đun và cấu trúc dữ liệu Redis OSS cốt lõi được thực thi theo cách hoàn toàn có thể lập trình và phân tán.
Sự vắng mặt của Giải pháp Xung đột
Dynomite là một hệ thống AP và cung cấp cho bạn ba tùy chọn về tính nhất quán. Cho dù bạn chọn tùy chọn nào, điều quan trọng cần lưu ý là Dynomite giải quyết xung đột ghi không đồng bộ bằng cách áp dụng chiến lược Last Write Wins. Điều này có thể dẫn đến việc cập nhật bị mất do dấu thời gian không liên quan, đặc biệt là trong bối cảnh ghi theo phân phối theo địa lý.
Mặt khác, kiến trúc Active-Active của Redis Enterprise dựa trên việc triển khai thay thế các lệnh Redis OSS và các kiểu dữ liệu được gọi là Xung đột-Miễn phí-Tái tạo-Loại dữ liệu hoặc CRDT. CRDT sử dụng đồng hồ vectơ để sắp xếp sự kiện. Họ đảm bảo rằng khi bất kỳ hai bản sao nào nhận được cùng một tập hợp các bản cập nhật, chúng sẽ đạt đến cùng một trạng thái, về mặt xác định, bằng cách áp dụng các quy tắc toán học hợp lý để đảm bảo sự hội tụ của trạng thái. Ngoài ra, người ta cũng có thể kích hoạt tính nhất quán nhân quả.
Do đó với Redis Enterprise:
- Kết quả của việc ghi đồng thời có thể dự đoán được và dựa trên một bộ quy tắc
- Các ứng dụng không cần bận tâm đến việc ghi đồng thời và giải quyết xung đột ghi
- Tập dữ liệu cuối cùng sẽ hội tụ về một trạng thái nhất quán, duy nhất
Nếu bạn thích, bạn có thể tìm thấy các quy tắc được triển khai cũng như các ví dụ về giải quyết xung đột bằng cách nhấp vào liên kết này.
Dynomite hoặc Redis Enterprise:Sự khác biệt của nó đối với DevOps là gì?
Bây giờ, hãy so sánh Dynomite và Redis Enterprise theo quan điểm DevOps, bằng cách thảo luận về các chủ đề sau:
- Tính khả dụng cao
- Khả năng mở rộng
- Khả năng triển khai
Tính khả dụng cao
Khi một nút bị lỗi trong giá đỡ Dynomite, việc ghi và đọc vào giá đỡ trở nên không thể. Điều này có nghĩa là một ứng dụng đang viết cục bộ cần tự xử lý việc chuyển đổi dự phòng sang một giá đỡ khác. Lưu ý rằng, nếu ứng dụng của bạn được phát triển bằng Java, ứng dụng Dyno của Netflix có thể xử lý chuyển đổi dự phòng đến các giá đỡ từ xa khi một nút Dynomite cục bộ bị lỗi.
Hơn nữa, khi nút hoạt động trở lại, bất kỳ dữ liệu nào đã được ghi trên giá đỡ từ xa trong quá trình lỗi sẽ bị thiếu từ nút bị lỗi. Nếu bạn triển khai trong các nhóm tự động chia tỷ lệ AWS, bạn có thể sử dụng Trình quản lý Dynomite của Netflix, công cụ này thực hiện thay thế nút và khởi động nút trong nhóm tự động chia tỷ lệ AWS.
Còn về tính khả dụng cao của Redis Enterprise thì sao?
Khi một nút bị lỗi, quá trình chuyển đổi dự phòng một chữ số giây sẽ xảy ra cho tất cả các phân đoạn chính sống trên nút đó và các bản sao của chúng được thăng cấp thành các phân đoạn chính. Cơ chế tự động chuyển đổi dự phòng này đảm bảo rằng dữ liệu được cung cấp với mức gián đoạn tối thiểu.
Dựa trên điều này:
- Redis Enterprise Proxy đảm bảo rằng điểm cuối duy nhất của cơ sở dữ liệu của bạn, sẽ không thay đổi trong trường hợp chuyển đổi dự phòng, vì vậy bạn không cần phải cấu hình lại ứng dụng của mình.
- Có tùy chọn “replica_ha” đảm bảo khi bản sao được thăng cấp thành bản sao chính, phân đoạn bản sao được đồng bộ hóa mới sẽ được tạo tự động trên bất kỳ nút nào khác có sẵn.
Các cơ chế này cho phép Redis Enterprise đảm bảo 99,99% thời gian hoạt động và 99,999% thời gian hoạt động cho các triển khai Active-Active.
Khả năng mở rộng
Dynomite cho phép bạn mở rộng Redis OSS trong khi vẫn duy trì hiệu suất tốt về độ trễ. Bạn có thể kiểm tra các điểm chuẩn nhưng nếu bạn đang sử dụng Dynomite, bạn có thể đã biết điều đó.
Khi nói đến khả năng mở rộng, sự khác biệt chính giữa Dynomite và Redis Enterprise là:
- Khả năng quản lý
- Quản lý kết nối độc lập
- Tối ưu hoá tài nguyên
Khả năng quản lý
Nếu bạn không sử dụng Trình quản lý Dynomite trong nhóm tự động định tỷ lệ AWS, thì việc thêm máy chủ vào giá đỡ Dynomite đang chạy thường yêu cầu:
- Tận dụng kỹ thuật “ghi kép” bằng cách sử dụng máy khách Java Dyno; ứng dụng của bạn ghi vào cụm cũ / nhỏ cũng như cụm mới / được chia tỷ lệ. Sau một vài ngày, bạn chỉ định tuyến lưu lượng truy cập đến cụm mới và biến nó trở thành cụm hoạt động.
- Di chuyển cơ sở dữ liệu của bạn từ cụm cũ / nhỏ sang nhóm mới / được chia tỷ lệ
Mặt khác, Redis Enterprise cho phép bạn:
- Mở rộng quy mô bằng cách thêm các phân đoạn vào cơ sở dữ liệu của bạn mà không thêm các nút vào cụm của bạn:Trường hợp này hữu ích khi có đủ công suất chưa được sử dụng trong cụm. Hãy nhớ rằng:một nút không bằng một phiên bản Redis. Việc sạc lại cơ sở dữ liệu của bạn có thể được thực hiện bằng một vài cú nhấp chuột thông qua giao diện người dùng Redis Enterprise hoặc bằng cách tận dụng API REST của Redis Enterprise. Nó được thực hiện mà không có thời gian chết hoặc gián đoạn dịch vụ. Nó cũng minh bạch với ứng dụng vì điểm cuối của cơ sở dữ liệu không thay đổi.
- Mở rộng quy mô bằng cách thêm (các) nút vào cụm. Kịch bản này hữu ích nếu cần nhiều tài nguyên vật lý hơn để thêm các phân đoạn vào cơ sở dữ liệu của bạn. Lưu ý rằng với Redis Enterprise Cloud, là sản phẩm cung cấp DBaaS được quản lý hoàn toàn của chúng tôi, các tổ chức không cần phải lo lắng về bước này. Redis sẽ cung cấp và quản lý cơ sở hạ tầng và tài nguyên cho họ. Xem thêm thông tin trong phần Triển khai của bài viết này.
Đây là điểm chuẩn mà Redis đã thực hiện cách đây vài năm, trong đó Redis Enterprise đã phân phối hơn 200 triệu ops / giây, với độ trễ dưới mili giây, trên 40 phiên bản AWS.
Quản lý kết nối
Khi chúng ta nói về quản lý kết nối với Redis, điều đầu tiên xuất hiện trong tâm trí là cách các ứng dụng khách của Redis, như Jedis hoặc Diếp, xử lý việc gộp kết nối và pipelining. Netflix cũng không ngoại lệ và đã triển khai các tính năng này cho ứng dụng Dyno của họ.
Redis Enterprise cung cấp các tính năng độc lập như vậy. Bản thân Proxy thiết lập các kết nối liên tục đến các phân đoạn trong cụm và các kết nối đó được chia sẻ bởi các máy khách. Nó cũng áp dụng tối ưu hóa hiệu suất bằng cách lập lịch yêu cầu trên một số kết nối liên tục đến các phân đoạn, thực hiện ghép kênh và ghép nối ở phía Redis.
Ngoài ra, proxy là đa luồng và sẽ tự động mở rộng quy mô để xử lý các sự cố trong kết nối máy khách.
Tối ưu hóa tài nguyên
Đầu tiên, hãy nhớ rằng trong cụm Redis Enterprise, một máy không bằng một phiên bản Redis và mỗi phân đoạn chính chỉ có thể có tối đa một bản sao.
Thứ hai, Redis Enterprise có nhiều người thuê. Điều đó có nghĩa là một cụm Redis Enterprise duy nhất có thể phục vụ hàng trăm cơ sở dữ liệu hoàn toàn biệt lập. Điều này sẽ không còn là chuyện nhỏ khi sử dụng Dynomite. Điều đáng chú ý là dịch vụ cho thuê nhiều lần của Redis Enterprise rất phù hợp với khả năng đa mô hình của nó. Trong bối cảnh của microservices, người ta có thể tưởng tượng việc chạy các cơ sở dữ liệu phù hợp với mục đích khác nhau trong một tập hợp các nút duy nhất, mỗi nút có cấu hình mô-đun sao chép, mở rộng, độ bền và khả năng sao chép riêng của chúng.
Cuối cùng, Redis Enterprise có một tính năng gọi là Redis On Flash (RoF). RoF cho phép cơ sở dữ liệu của bạn sử dụng cả RAM và bộ nhớ flash chuyên dụng (SSD / NVMe) để xử lý các tập dữ liệu lớn hơn nhiều với độ trễ và hiệu suất giống như RAM, nhưng với chi phí thấp hơn> 70% so với cơ sở dữ liệu toàn RAM.
Tùy chọn triển khai
Dynomite có thể được triển khai trong các thùng chứa hoặc máy chạy Ubuntu, RHEL và CentOS. Việc triển khai luôn được tự quản lý, theo nghĩa là bạn cần cung cấp cơ sở hạ tầng và tài nguyên để quản lý cụm của mình. Hơn nữa, như đã thảo luận trước đây, nếu bạn muốn tận dụng các tính năng của Trình quản lý Dynomite, bạn cần triển khai Dynomite trong nhóm tự động phân hạng AWS.
Mặt khác, Redis Enterprise có nhiều tùy chọn triển khai, có thể được chia thành hai nhóm:
- Các giải pháp tự quản lý, nhờ đó bạn tự tải xuống, cài đặt và triển khai Phần mềm Redis Enterprise. Có rất nhiều tùy chọn bao gồm trình cài đặt Linux (nhiều bản phân phối), Amazon Machine Image (AMI), Docker Containers, Kubernetes, RedHat OpenShift, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) hoặc Amazon Elastic Kubernetes Service (EKS) ).
- Các giải pháp được quản lý:Redis Enterprise Cloud được cung cấp dưới dạng dịch vụ đám mây được quản lý hoàn toàn (DBaaS) trên cả ba nền tảng đám mây công cộng chính (Google Cloud, AWS và Azure). Redis sẽ tổ chức một môi trường dành riêng cho bạn, với các tài nguyên cần thiết, trong đó bạn có thể tạo cơ sở dữ liệu với các điểm cuối riêng tư và công khai để các ứng dụng của bạn sử dụng.