Việc phát hành Redis 7.0 đang trên đúng đường (on track), và chúng tôi vừa phát hành ứng cử viên phát hành thứ hai (second release candidate). Ứng cử viên phát hành này là một cột mốc được lên kế hoạch nhằm hoàn thiện các tính năng của phiên bản, nhưng nó cũng là cơ hội cho chúng tôi trình bày thêm nội dung trong phiên bản mới. Ví dụ, Redis Functions đã tiến hóa từ sự hỗ trợ kịch bản (scripting) hiện có mà Redis có kể từ phiên bản 2.6. Tương tự, nhiều tính năng của Redis khác đã tiến hóa.
Trong tự nhiên, tiến hóa xảy ra dường như ngẫu nhiên và chọn lọc tự nhiên (natural selection) lo việc phân loại kết quả. Nói chung, trong phần mềm nói chung, và cụ thể với Redis, quy trình này diễn ra ngược lại: chúng tôi chọn đường dẫn mong muốn và tiến hóa dự án để tuân theo nó. Thay vì để ngẫu nhiên chi phối tương lai, việc lập kế hoạch và thực hiện lộ trình (roadmap) của chúng tôi chủ yếu được dẫn dắt bởi phản hồi của người dùng và các trường hợp sử dụng mới nơi Redis phù hợp.
Trong Redis 7.0, Danh sách Kiểm soát Truy cập (ACL) cũng đã bước lên cao thêm một bậc trên thang tiến hóa. Được giới thiệu trong Redis 6.0, ACL đã đảo ngược quan điểm lâu nay về bảo mật là ngoài phạm vi dự án bằng cách thêm các cơ chế để quản lý người dùng và quyền hạn của họ. Tuy nhiên, cộng đồng của chúng tôi nhanh chóng giáo dục chúng tôi rằng mặc dù đó là bước đi đúng hướng, tính năng này vẫn thiếu các khả năng cần thiết.
Một trong những khoảng trống trong ACL đã được giải quyết bởi Redis 6.2, cụ thể là kiểm soát các mẫu tên kênh Pub/Sub được phép. Nhưng đó chỉ là một biện pháp chạm chạm dứt điểm (partial stop-gap) và chúng tôi mất nhiều thời gian hơn để tìm ra một cách tiếp cận đơn giản và hiệu quả để giải quyết những cái còn lại.
Thiết kế ban đầu của ACL chỉ cung cấp cho các trường hợp sử dụng kiểm soát quyền cơ bản. Nó cho phép cấp hoặc từ chối truy cập chỉ đến một tập hợp đơn lẻ các lệnh, mẫu tên khóa (keys') và kênh (channels') cho mỗi người dùng. Ví dụ, không thể hạn chế lệnh `SET` cho một tập hợp con khóa, và cùng lúc cho phép `GET` cho một tập hợp con khóa khác cho một người dùng cho trước. Hiệu quả là, ACL không phải là một cơ chế hiệu quả để triển khai chính sách bảo mật.
Danh sách Kiểm soát Truy cập của Redis 7.0, hoặc ACLv2 cho ngắn, tương thích với bản gốc nhưng thêm hai cải tiến quan trọng. Thứ nhất, ACLv2 toàn bộ là về bộ chọn (selectors). Thứ hai, ACLv2 cho phép đặt quyền loại truy cập (access type permissions) cho các khóa cụ thể. Khả năng này làm cho việc hạn chế độc quyền người dùng chỉ đọc (read-only), chỉ ghi (write-only), hoặc đọc-ghi (read-write) đối với một tập hợp con khóa trở nên khả thi.
Thiết kế ACL ban đầu chỉ cung cấp một bộ chọn cho mỗi người dùng — bộ chọn mặc định (default selector). Bộ chọn mô tả các khóa và kênh mà người dùng có thể truy cập, các danh mục và lệnh. ACLv2 cho phép thêm bất kỳ số lượng bộ chọn nào trên đầu bộ chọn mặc định được áp dụng theo thứ tự. Cách tiếp cận này thỏa mãn yêu cầu của các chính sách bảo mật要求苛刻 (more demanding) và đưa ACL gần hơn đến sự hoàn chỉnh.
Khả năng tự quan sát (introspective abilities) của máy chủ là khía cạnh khác của Redis đã tiến bộ đáng kể trong phiên bản 7.0. Redis expose (tiết lộ) một API, từ điển lệnh của nó, thông qua đó nó tương tác. Khi dự án phát triển, số lượng các lệnh khác nhau (và các lệnh con của chúng) tăng lên, vượt quá 380 trong phiên bản 7.0. Bởi vì mỗi lệnh Redis được chuyên dụng cho các nhiệm vụ cho trước, ghi chép các đối số triệu hồi (invocation arguments) và hành vi của mỗi lệnh là nguyên tắc cốt lõi của dự án. Tài liệu này là hợp đồng duy nhất giữa máy chủ và các client của nó.
Lịch sử, các lệnh được ghi chép bên ngoài (externally) chính dự án trong một kho lưu trữ mã (code repository) riêng biệt. Chúng tôi giữ tất cả tài liệu ở định dạng (đa số) có thể đọc được bởi con người vì nó được dự định để được đọc bởi con người. Điều này đặt ra thách thức cho máy móc (hay đúng hơn, những người lập trình máy móc) vì dịch văn xuôi (prose) sang mã (code) là rối rắm và dễ vỡ (brittle). Cụ thể, tác giả của các client cho Redis chỉ có thể hy vọng giữ dự án của họ cập nhật bằng cách theo dõi các thay đổi tài liệu và đọc ghi chú phát hành (release notes).
Vì vậy, từ phiên bản 2.8, chúng tôi nhận ra rằng chúng tôi cũng cần một cách lập trình (programmatic way) cho phép máy chủ báo cáo các lệnh của nó. Lệnh `COMMAND` có tên phù hợp (nhưng cũng là rào cản lسان - tongue-twister) liệt kê trong thời gian chạy (runtime) các lệnh mà máy chủ hỗ trợ. Hơn nữa, lệnh con `COMMAND GETKEYS` cho phép client gửi một lệnh nguyên văn (verbatim command) và các đối số của nó để máy chủ trích xuất bất kỳ tên khóa nào từ nó. Trích xuất tên khóa từ một lệnh là cần thiết để client có thể hướng thao tác chính xác trong triển khai cụm (clustered deployment).
Một phần được thúc đẩy bởi nỗ lực liên quan đến ACLv2 nhưng cũng để làm cho danh sách lệnh runtime (runtime commands list) hữu ích hơn cho client, phiên bản 7.0 cải tổ (overhauls) nhiều cơ chế nội bộ của việc quản lý lệnh của máy chủ. Thêm vào đó, chúng tôi đã làm giàu siêu dữ liệu (metadata) mà máy chủ giữ về mỗi lệnh, làm cho việc xây dựng các client tinh vi (sophisticated clients) có (gần như) không cần kiến thức tiên quyết (a prior knowledge) về khả năng của máy chủ trở nên khả thi. Cuối cùng, bảng lệnh được cải tiến (revamped commands table) được xây dựng theo cách mà các mô-đun Redis có thể mở rộng nó với các lệnh tương ứng của chúng, để cung cấp cùng mức độ tự quan sát (introspection) như các lệnh cốt lõi.
Các thông số khóa lệnh mới (new command key specifications) cho phép client trích xuất khóa cục bộ (locally extract keys) từ các lệnh nguyên văn mà không cần liên quan đến máy chủ của cụm, do đó cải thiện độ trễ và giảm băng thông mạng. Siêu dữ liệu về đối số lệnh cho phép client khám phá và thích ứng với các thay đổi trong cú pháp lệnh giữa các phiên bản máy chủ. Client có thể thu được thêm thông tin về việc thực thi lệnh trong hoàn cảnh đặc biệt và các loại triển khai khác nhau từ các mẹo lệnh (command tips).
Nỗ lực này cũng bao gồm việc thăng cấp (promotion) các lệnh con (subcommands) thành công dân hạng nhất (first-class citizens) của bảng lệnh của máy chủ. Ban đầu, các lệnh con được giới thiệu vào Redis để chống lại cardinality (số lượng) ngày càng tăng của API. Lý do là thay vì thêm một lệnh mới cho mọi nhiệm vụ, các nhiệm vụ liên quan được gọi bằng cách chỉ gọi một lệnh "cha" (parent command). Lệnh "cha" chấp nhận làm đối số đầu tiên tên của lệnh con, mà lần lượt quy định hành động được thực hiện. Từ góc độ kỹ thuật, các lệnh con kế thừa tất cả các đặc điểm của lệnh cha của chúng (ví dụ: danh mục ACL, cờ đọc/ghi, thông số khóa, v.v.), làm cho không thể có được sự phân biệt mहीन (fine-grained distinction) giữa các hành vi khác nhau của chúng.
Ví dụ, lệnh `CLIENT` là một giỏ chứa tất cả (catch-all basket) cho các nhiệm vụ quản lý kết nối mà tự hào có không kém hơn 15 lệnh con khác nhau. Một số lệnh con của nó, như `CLIENT SETNAME`, thường xuyên được gọi bởi các kết nối client bình thường, trong khi những cái khác như `CLIENT KILL` có tiềm năng bị sử dụng sai và do đó nên bị hạn chế chỉ dành cho quản trị viên (admin use alone). Các phiên bản Redis trước đây thiếu các cơ chế nội bộ hỗ trợ việc tạo ra sự phân biệt như vậy, từ而 hướng dẫn nhà phát triển đến tài liệu và tạo ra sự nhầm lẫn. Trong Redis 7.0, tuy nhiên, mọi lệnh con đều có tập hợp đặc điểm riêng của nó, bất kể cha hoặc anh chị em của nó, cho phép mô tả chính xác của nó.
Bài đăng này đã trở thành một bức tường văn bản (wall of text) khá lớn, đi sâu vào quá nhiều chi tiết kỹ thuật về phía cuối của nó (nếu thậm chí có thứ gọi là quá nhiều chi tiết kỹ thuật). Chúng tôi hy vọng nó không quá nhàm chán, và chúng tôi đã làm sáng tỏ một chút về phiên bản mới và sự phù hợp của nó trong dự án. Chúng tôi đang làm việc trên ứng cử viên phát hành cuối cùng (final release candidate(s)) cho sự sẵn sàng tổng quát (general availability) của phiên bản, nhưng hãy tiếp tục theo dõi các bài đăng tiếp theo trong chuỗi sẽ tiếp tục chuyến tham quan phiên bản mới.