Công nghệ lưu trữ cache từ xa mới của Microsoft Research: 'Garnet'
(github.com/microsoft)- Garnet là kho lưu trữ cache từ xa do Microsoft Research tạo ra, dựa trên giao thức dây RESP nên có thể dùng các client Redis hiện có mà không cần chỉnh sửa
- Với nhiều kết nối client và batch nhỏ, Garnet có thông lượng và khả năng mở rộng cao hơn các kho cache mã nguồn mở tương đương; trên Azure VM khi bật Accelerated Networking, độ trễ percentile 99,9 thường dưới 300 micro giây
- Dựa trên .NET hiện đại, chạy trên Linux và Windows; có thể tạo các phép toán tùy chỉnh, stored procedure và module bằng C#, đồng thời hỗ trợ Lua script
- Tầng lưu trữ Tsavorite hỗ trợ phân tầng bộ nhớ·SSD·lưu trữ đám mây, checkpoint không chặn, phục hồi, log thao tác để bảo đảm độ bền, giao dịch nhiều khóa, cũng như sharding·replication·di chuyển khóa động trong chế độ cluster
- Các tính năng mới Vector Sets Preview và Range Index Preview đã được bổ sung, và bài báo về Garnet dự kiến sẽ xuất hiện tại VLDB 2026
Kho lưu trữ cache từ xa mà Garnet cung cấp
- Garnet là kho lưu trữ cache từ xa mới của Microsoft Research
- Garnet chọn giao thức dây RESP làm điểm khởi đầu, nên có thể dùng các client Redis hiện có bằng nhiều ngôn ngữ lập trình mà không cần chỉnh sửa
- Ví dụ có thể dùng StackExchange.Redis của C#
- Với nhiều kết nối client và batch nhỏ, Garnet cung cấp thông lượng và khả năng mở rộng tốt hơn các kho cache mã nguồn mở tương đương, có thể giúp giảm chi phí cho các ứng dụng và dịch vụ quy mô lớn
- Trên các Azure VM thông thường khi bật Accelerated Networking, độ trễ phía client ở percentile 99,9 thường ở mức dưới 300 micro giây
- Garnet dựa trên công nghệ .NET hiện đại, hướng tới kiến trúc đa nền tảng, có khả năng mở rộng và hiện đại
- Được thiết kế để dễ phát triển và tiến hóa mà không hy sinh hiệu năng trong các trường hợp thông thường
- Tận dụng hệ sinh thái thư viện .NET để mở rộng bề mặt API, đồng thời vẫn để lại không gian tối ưu hóa
- Đạt hiệu năng hiện đại trên cả Linux và Windows
- Nếu cần dịch vụ được quản lý hoàn toàn, Azure Cosmos DB Garnet Cache cung cấp Garnet dưới dạng giải pháp caching doanh nghiệp có tính sẵn sàng cao, bảo đảm hiệu năng và không cần quản lý hạ tầng
Tính năng mới bổ sung gần đây và bài báo
- Vector Sets Preview cung cấp tìm kiếm láng giềng gần nhất xấp xỉ
- Dựa trên thuật toán DiskANN và engine lưu trữ Tsavorite của Garnet
- Trong kết quả ban đầu, Garnet cho thấy kết quả vượt trội về QPS, độ trễ p99 và recall
- Range Index Preview cung cấp chỉ mục phụ dạng phạm vi và bằng nhau trên các khóa Garnet
- Dựa trên Bf-Tree
- Bài báo về Garnet dự kiến sẽ được đăng tại VLDB 2026
- Tên bài báo là Garnet: A Next-Generation Cache-Store for Accelerating Applications and Services
- Có cung cấp bản PDF
API và mô hình mở rộng
- Garnet triển khai nhiều API khác nhau
- Chuỗi thô: get, set, hết hạn khóa
- Phép toán phân tích: HyperLogLog, Bitmap
- Phép toán đối tượng: sorted set, list, v.v.
- Hỗ trợ giao dịch nhiều khóa
- Giao dịch RESP phía client
- Stored procedure và module phía server dựa trên C#
- Người dùng có thể tạo phép toán tùy chỉnh cho cả chuỗi thô và kiểu đối tượng do người dùng định nghĩa
- Tận dụng sự tiện lợi và an toàn của C# để hạ thấp rào cản phát triển phần mở rộng tùy chỉnh
- Cũng hỗ trợ Lua script
Tầng mạng, bảo mật và lưu trữ
- Garnet sử dụng tầng mạng nhanh và có thể cắm thay thế
- Cho phép các mở rộng trong tương lai như tận dụng stack kernel bypass
- Giao tiếp bảo mật hỗ trợ TLS bằng thư viện SslStream của .NET
- Cung cấp kiểm soát truy cập cơ bản
- Tsavorite, tầng lưu trữ của Garnet, được thiết kế cho hiệu năng cao và bao gồm nhiều chức năng cơ sở dữ liệu
- Khả năng mở rộng theo luồng
- Lưu trữ phân tầng bao gồm bộ nhớ, SSD và lưu trữ đám mây
- Checkpoint nhanh không chặn
- Phục hồi
- Log thao tác để bảo đảm độ bền
- Giao dịch nhiều khóa
- Quản lý và tái sử dụng bộ nhớ tốt hơn
Kiến trúc thiết kế
- Thiết kế của Garnet thiết kế lại toàn bộ stack cache store, từ nhận gói mạng đến phân tích cú pháp và xử lý phép toán cơ sở dữ liệu, rồi tương tác với lưu trữ
- Tầng mạng dựa trên thiết kế bộ nhớ chia sẻ
- Xử lý TLS và tương tác lưu trữ được thực hiện trên luồng hoàn tất IO mạng
- Tránh overhead chuyển luồng trong các trường hợp thông thường
- Thay vì di chuyển dữ liệu tới shard thích hợp của server như thiết kế mạng dựa trên shuffle truyền thống, Garnet để tính nhất quán cache CPU đưa dữ liệu về phía logic xử lý
- Thiết kế lưu trữ gồm hai kho key-value Tsavorite được liên kết bằng một log thao tác hợp nhất
- main store được tối ưu cho các phép toán chuỗi thô và quản lý bộ nhớ cẩn thận để tránh garbage collection
- object store tùy chọn được tối ưu cho đối tượng phức tạp và kiểu dữ liệu do người dùng định nghĩa
- object store bao gồm các kiểu như Sorted Set, Set, Hash, List, Geo
- Các kiểu dữ liệu của object store trong bản triển khai hiện tại tận dụng hệ sinh thái thư viện .NET
- Đối tượng được lưu trên heap bộ nhớ ở dạng cập nhật hiệu quả, còn trên đĩa ở dạng đã tuần tự hóa
- Để dễ bảo trì trong tương lai, nhóm dự định xem xét việc dùng chỉ mục và log hợp nhất
- Điểm khác biệt của Garnet là API lưu trữ Tsavorite dạng “eo hẹp”
- Trên API này, Garnet triển khai bề mặt RESP API lớn, phong phú và có thể mở rộng
- Gồm đọc, upsert, xóa và phép toán read-modify-write nguyên tử
- Thông qua callback bất đồng bộ, logic Garnet có thể can thiệp tại nhiều điểm trong mỗi phép toán
- Tách biệt các mối quan tâm về phân tích cú pháp và xử lý truy vấn khỏi các chi tiết lưu trữ như đồng thời, phân tầng lưu trữ và checkpoint
- Giao dịch nhiều khóa sử dụng khóa hai pha
Chế độ cluster và ràng buộc vận hành
- Ngoài chạy trên một node đơn, Garnet hỗ trợ chế độ cluster
- Có thể tạo và quản lý triển khai có sharding và replication
- Hỗ trợ phương thức di chuyển khóa hiệu quả và động để tái cân bằng shard
- Người dùng có thể tạo và quản lý cluster Garnet bằng các lệnh Redis cluster tiêu chuẩn
- Các node thực hiện gossip để chia sẻ và phát triển trạng thái cluster
- Thiết kế chế độ cluster của Garnet hiện là passive
- Không triển khai bầu chọn leader
- Phản hồi các lệnh cluster do control plane do người dùng cung cấp phát hành
- Nội dung liên quan nằm trong tài liệu control plane
Tài liệu và giấy phép
- Có thể xem thêm thông tin chi tiết và tài liệu tại trang tài liệu Garnet
- Để bắt đầu, có thể xem tài liệu getting started
- Ghi chú phát hành nằm trong mục releases
- Dự án được cung cấp theo MIT License
1 bình luận
Ý kiến trên Hacker News
Nhìn vào biểu đồ hiệu năng benchmark (https://microsoft.github.io/garnet/docs/benchmarking/results...), thông lượng GET cao hơn Dragonfly hơn 10 lần
Độ trễ 50% hơi cao hơn Dragonfly, nhưng phân vị thứ 99 thì hơi thấp hơn
Cả Garnet và Dragonfly đều có thông lượng và độ trễ tốt hơn Redis rất nhiều, nên có vẻ Redis cần tối ưu hiệu năng đáng kể
Không rõ có nhất thiết cần tối ưu hay không, và ở đây đã có 3 lựa chọn thay thế rồi
Tuy vậy, Garnet gây ấn tượng vì là lựa chọn thay thế đầu tiên vượt Redis ở cả mức đồng thời thấp lẫn cao, và tôi rất muốn sớm dùng thử
Dragonfly viết bằng C++, Redis viết bằng C
Tsavorite, tầng lưu trữ của Garnet, được tách ra từ FASTER mã nguồn mở, và bao gồm các tính năng cơ sở dữ liệu mạnh như khả năng mở rộng theo luồng, lưu trữ phân tầng (bộ nhớ, SSD, lưu trữ đám mây), checkpoint nhanh không chặn, phục hồi, log thao tác để đảm bảo độ bền, giao dịch đa khóa, cùng quản lý và tái sử dụng bộ nhớ tốt hơn
https://www.microsoft.com/en-us/research/blog/introducing-ga...
Khi đó, trong một dự án proof-of-concept có yêu cầu hiệu năng cao mà tôi đang làm, tôi thấy nó khá hứa hẹn như một thư viện lưu bền vững
Nhân tiện, có vẻ cả hai dự án đều do cùng một người dẫn dắt [1]
[1]: https://github.com/badrishc
Những dự án mà Microsoft và đội .NET tự tay làm kiểu “hack” hạ tầng khá ấn tượng
Yarp là công cụ làm reverse proxy/API gateway/hoặc bất cứ thứ gì cần thiết khác, còn giờ Garnet dành cho cache trong bộ nhớ
Có vẻ nhu cầu nội bộ rất lớn, và họ cũng sẵn sàng chia sẻ nó
Ước gì Azure App Service có thứ như thế này tích hợp sẵn
Để không nhất thiết phải dùng dịch vụ từ xa chỉ vì caching
Trước đây, trong IIS, cách phổ biến là đặt kho lưu trạng thái phiên ngoài tiến trình cho ứng dụng ASP.NET
Mục đích là để khi tiến trình web app khởi động lại, người dùng không mất phiên và phải đăng nhập lại từ đầu
Tất nhiên cũng có thể đặt trong kho trung tâm như SQL Server, nhưng khi đó mọi request trang web đều phải đợi tải trạng thái phiên trước khi xử lý
Trạng thái phiên thường bị khóa theo cách nào đó, nên cũng gây nhiều vấn đề hiệu năng
Cách giải phổ biến hiện nay là dùng Redis cho cache và trạng thái phiên, nhìn chung hoạt động tạm ổn
Thông lượng cao, nhưng Redis là một tài nguyên riêng trên Azure và đắt một cách vô lý
Tôi không muốn trả giá kiểu Oracle DB cho thứ đơn giản như vậy, và cấu hình kết nối cũng khá phiền
Bài viết này nói thời gian phản hồi 300 micro giây, nhưng với thiết kế dự phòng theo vùng thì điều đó gần như vô nghĩa, vì mọi bộ cân bằng tải Azure đều chọn vùng ngẫu nhiên
Một web server ở vùng ngẫu nhiên được chọn, rồi nó lại kết nối tới cache server ở một vùng ngẫu nhiên
Nếu server đó không có key, có thể lại phải sang một vùng ngẫu nhiên khác để lấy dữ liệu cache
Lưu lượng ping-pong giữa các datacenter, gây độ trễ 1–3ms và chậm hơn tối đa 10 lần so với con số Garnet quảng bá
Kịch bản lý tưởng là thứ như reliable collections[1] của Microsoft Service Fabric
Chạy cục bộ trên từng host node và sao chép sang hai node khác
Web app luôn có thể đọc giá trị cache từ cùng một host vật lý
Trong một số trường hợp, độ trễ có thể xuống mức micro giây một chữ số; bất kỳ dịch vụ bên ngoài nào dù tối ưu tốt đến đâu, nếu dùng cân bằng tải đơn giản, cũng chậm hơn hàng nghìn lần
Tôi muốn thứ không phải nhanh hơn Redis 30%, mà là nhanh hơn 3.000 lần
[1] https://learn.microsoft.com/en-us/azure/service-fabric/servi...
Có thể cấu hình để service luôn đi tới service cục bộ, hoặc theo các topology định tuyến khác
Rất phù hợp cho DNS hoặc cache ứng dụng
Đây là một sản phẩm thay thế Redis có các con số benchmark về độ trễ và thông lượng khá ấn tượng
Tò mò không biết khi chạy production thực tế trên stack không phải Azure thì sẽ ra sao
Tôi không thấy dấu hiệu hỗ trợ xstream
Garnet being multi-threaded, MSET is not atomic. For an atomic version of MSET, you would need to express it as a transaction (stored procedure).Tôi không hiểu rõ đoạn này
Tại sao không bọc nó trong transaction ở bên trong để biến lệnh thành nguyên tử
Và cũng tò mò còn những bẫy về tính nguyên tử nào khác
MSETcũng phải chịu chi phí hiệu năng, và sẽ không có cách tắt transaction đóNgược lại, nếu mục tiêu là thay thế Redis theo kiểu drop-in, thì Redis đảm bảo tính nguyên tử nên đây lại là vấn đề
Ít nhất, nếu drop-in replacement là mục tiêu thiết kế, có lẽ nên có tùy chọn cấu hình để chọn giữa tương thích và hiệu năng
Thật sự ấn tượng
Microsoft Research thỉnh thoảng đưa ra những dự án rất đỉnh; chắc được trả tiền để làm R&D sẽ thú vị lắm
Mong các tập đoàn lớn làm nhiều dự án mang tính R&D có ích cho cả ngành hơn
Nếu Hashicorp đang được rao bán, hy vọng một công ty tốt sẽ mua lại
Đây là tin rất tốt cho những ai cần chạy trực tiếp server tương thích Redis trên Microsoft Windows Server mà không phụ thuộc vào WSL2
Trước đây từng có bản port Redis [1], nhưng giờ đã bị lưu trữ, từng có vấn đề về mức dùng bộ nhớ (theo tôi biết chủ yếu do file ánh xạ bộ nhớ), và không còn được hỗ trợ
Việc nó được viết bằng C# cũng khá thú vị với cá nhân tôi
C# là ngôn ngữ chính của tôi, nên tôi muốn dành thời gian đào sâu vào code
[1]: https://github.com/microsoftarchive/redis
Tôi muốn xem họ đang dùng thứ này ở đâu trong môi trường production thực tế
Có đoạn nói: “Sau hàng nghìn unit test và vài năm triển khai vận hành Garnet với các đội 1st-party của Microsoft, chúng tôi cảm thấy đã đến lúc công khai nó”
https://microsoft.github.io/garnet/blog
Nhìn các bình luận ở đây, có vẻ giờ không còn ai dùng memcached nữa
Tôi muốn một cache LRU, nhưng có nhiều tùy chọn và phần mô tả không rõ, nên không hiểu vì sao nó cứ liên tục đẩy các mục ra
Chuyển sang Redis thì cấu hình dễ hơn và hoạt động đúng như mong đợi