Nếu redis đã là một phần của ngăn xếp, tại sao Memcached vẫn được sử dụng cùng với Redis?


85

Redis có thể thực hiện mọi thứ mà Memcached cung cấp (bộ nhớ cache LRU, thời hạn sử dụng mặt hàng và hiện đang phân cụm trong phiên bản 3.x +, hiện đang ở phiên bản beta) hoặc bằng các công cụ như twemproxy. Hiệu suất cũng tương tự. Hơn nữa, Redis bổ sung tính bền bỉ do đó bạn không cần phải làm nóng bộ nhớ cache trong trường hợp máy chủ khởi động lại.

Tham khảo một số câu trả lời cũ so sánh Redis và Memcache, một số câu trả lời ủng hộ Redis thay thế cho Memcache (nếu đã có trong ngăn xếp):

Mặc dù vậy, khi nghiên cứu các công ty quy mô lớn như Instagram, Pinterest, Twitter, v.v., tôi thấy rằng họ sử dụng cả Memcached và Redis cho các mục đích khác nhau, không sử dụng Redis cho bộ nhớ đệm chính. Bộ nhớ đệm chính vẫn là Memcached và Redis được sử dụng cho bộ nhớ đệm logic dựa trên cấu trúc dữ liệu của nó.

Kể từ năm 2014, tại sao memcached vẫn đáng được thêm vào làm thành phần bổ sung vào ngăn xếp của bạn, khi bạn đã có một thành phần Redis có thể làm mọi thứ mà memcached có thể? Đâu là điểm thuận lợi khiến các kiến ​​trúc sư / kỹ sư vẫn đưa memcached vào bên ngoài Redis hiện có?

Cập nhật:

Đối với nền tảng của chúng tôi, chúng tôi đã loại bỏ hoàn toàn Memcached và sử dụng redis cho các yêu cầu bộ nhớ đệm đơn giản cũng như logic. Hiệu suất cao, linh hoạt và đáng tin cậy.

Một số tình huống ví dụ:

  • Liệt kê tất cả các khóa được lưu trong bộ nhớ cache theo một mẫu cụ thể và đọc hoặc xóa các giá trị của chúng. Rất dễ dàng trong redis, không làm được (dễ dàng) trong memcached.
  • Lưu trữ một tải trọng lớn hơn 1mb, dễ thực hiện trong redis, yêu cầu điều chỉnh kích thước phiến trong memcached, điều này có tác dụng phụ về hiệu suất của riêng nó.
  • Dễ dàng chụp nhanh nội dung bộ nhớ đệm hiện tại
  • Redis cluster cũng đã sẵn sàng sản xuất cùng với trình điều khiển ngôn ngữ, do đó việc triển khai theo cluster cũng dễ dàng.

Câu trả lời:


122

Lý do chính mà tôi thấy ngày nay là trường hợp sử dụng cho memcached trên Redis là hiệu quả bộ nhớ vượt trội mà bạn có thể nhận được với bộ nhớ đệm các đoạn HTML thuần túy (hoặc các ứng dụng tương tự). Nếu bạn cần lưu trữ các trường khác nhau của các đối tượng trong các khóa memcached khác nhau, thì hàm băm Redis sẽ hiệu quả hơn về bộ nhớ, nhưng khi bạn có một số lượng lớn các cặp key -> simple_string, memcached sẽ có thể cung cấp cho bạn nhiều mục hơn mỗi megabyte.

Những điều khác là điểm tốt về memcached:

  • Nó là một đoạn mã rất đơn giản, vì vậy nếu bạn chỉ cần chức năng mà nó cung cấp, tôi đoán nó là một sự thay thế hợp lý, nhưng tôi chưa bao giờ sử dụng nó trong sản xuất.
  • Nó là đa luồng, vì vậy nếu bạn cần mở rộng quy mô trong thiết lập một hộp, đó là một điều tốt và bạn chỉ cần nói chuyện với một phiên bản.

Tôi tin rằng Redis như một bộ nhớ cache ngày càng có ý nghĩa hơn khi mọi người hướng tới bộ nhớ đệm thông minh hoặc khi họ cố gắng bảo toàn cấu trúc của dữ liệu được lưu trong bộ nhớ cache thông qua cấu trúc dữ liệu Redis.

So sánh giữa Redis LRU và memcached LRU.

Cả memcached và Redis đều không thực hiện các thao tác đuổi LRU thực, mà chỉ là một phép gần đúng.

Loại bỏ Memcache là lớp theo kích thước và phụ thuộc vào chi tiết triển khai của trình cấp phát phiến của nó. Ví dụ: nếu bạn muốn thêm một mục phù hợp với một lớp kích thước nhất định, memcached sẽ cố gắng xóa các mục đã hết hạn / không được sử dụng gần đây trong lớp đó, thay vào đó, cố gắng toàn cục để hiểu đối tượng là gì, bất kể nó là gì kích thước, đó là ứng cử viên tốt nhất.

Thay vào đó, Redis cố gắng chọn một đối tượng tốt làm ứng cử viên cho việc loại bỏ khi maxmemoryđạt đến giới hạn, xem xét tất cả các đối tượng, bất kể loại kích thước, nhưng chỉ có thể cung cấp một đối tượng xấp xỉ tốt, không phải đối tượng tốt nhất với thời gian nhàn rỗi lớn hơn thời gian.

Cách Redis thực hiện điều này là lấy mẫu một vài đối tượng, chọn đối tượng không hoạt động (không được truy cập) trong thời gian dài nhất. Kể từ khi Redis 3.0 (hiện đang trong giai đoạn thử nghiệm), thuật toán đã được cải thiện và cũng có một nhóm ứng cử viên tốt qua các lần trục xuất, vì vậy ước tính gần đúng đã được cải thiện. Trong tài liệu Redis, bạn có thể tìm thấy mô tả và biểu đồ với chi tiết về cách hoạt động của nó .

Tại sao memcached có dung lượng bộ nhớ tốt hơn Redis đối với bản đồ chuỗi -> chuỗi đơn giản.

Redis là một phần mềm phức tạp hơn, vì vậy các giá trị trong Redis được lưu trữ theo cách gần giống với các đối tượng trong ngôn ngữ lập trình cấp cao: chúng có kiểu liên kết, mã hóa, đếm tham chiếu để quản lý bộ nhớ. Điều này làm cho cấu trúc bên trong của Redis tốt và dễ quản lý, nhưng có chi phí cao hơn so với memcached chỉ xử lý các chuỗi.

Khi Redis bắt đầu sử dụng bộ nhớ hiệu quả hơn

Redis có thể lưu trữ các kiểu dữ liệu tổng hợp nhỏ theo cách tiết kiệm bộ nhớ đặc biệt. Ví dụ: một Redis Hash nhỏ đại diện cho một đối tượng, được lưu trữ bên trong không phải với bảng băm, mà là một đốm màu duy nhất nhị phân. Vì vậy, việc đặt nhiều trường cho mỗi đối tượng thành một hàm băm sẽ hiệu quả hơn việc lưu trữ N khóa tách biệt vào bộ nhớ đệm.

Trên thực tế, bạn có thể lưu trữ một đối tượng vào memcached dưới dạng một khối JSON (hoặc được mã hóa nhị phân), nhưng trái với Redis, điều này sẽ không cho phép bạn tìm nạp hoặc cập nhật các trường độc lập.

Lợi thế của Redis trong bối cảnh bộ nhớ đệm thông minh.

Do cấu trúc dữ liệu Redis, mẫu thông thường được sử dụng với memcached để hủy các đối tượng khi bộ đệm bị vô hiệu, để tạo lại nó từ DB sau này, là một cách nguyên thủy để sử dụng Redis.

Ví dụ: hãy tưởng tượng bạn cần lưu vào bộ nhớ cache N tin tức mới nhất được đăng vào Tin tức Hacker để đưa vào phần "Mới nhất" của trang web. Những gì bạn làm với Redis là lấy một danh sách (giới hạn ở M mục) với những tin tức mới nhất được chèn vào. Nếu bạn sử dụng một kho lưu trữ khác cho dữ liệu của mình và Redis làm bộ nhớ đệm, việc bạn làm là điền vào cả hai dạng xem (Redis và DB) khi một mục mới được đăng. Không có sự vô hiệu bộ nhớ cache.

Tuy nhiên, ứng dụng luôn có thể có logic để nếu danh sách Redis được tìm thấy là trống, ví dụ sau khi khởi động, chế độ xem ban đầu có thể được tạo lại từ DB.

Bằng cách sử dụng bộ nhớ đệm thông minh, có thể thực hiện bộ nhớ đệm với Redis theo cách hiệu quả hơn so với bộ nhớ đệm, nhưng không phải tất cả các vấn đề đều phù hợp với mẫu này. Ví dụ: bộ nhớ đệm các đoạn HTML có thể không được hưởng lợi từ kỹ thuật này.


Cảm ơn Antirez, người sáng tạo. Nhưng ** tại sao diện tích bộ nhớ Redis cho chuỗi đơn thuần lại nhiều hơn so với bộ nhớ memcached? ** Có phải nén là một yếu tố? Hoặc Redis lưu trữ một số dữ liệu bổ sung khác khi SET được sử dụng để lưu trữ một chuỗi thuần túy? Sẽ thật tuyệt nếu bạn có thể đưa thông tin này vào câu trả lời.
DhruvPathak

3
Tôi đã cố gắng cải thiện câu trả lời. Cảm ơn vì những phản hồi.
antirez

3
Một khía cạnh khác của "trí thông minh" được đề cập ở trên, hoặc tận dụng các loại dữ liệu của Redis và logic phía máy chủ thông qua các hoạt động và / hoặc tập lệnh, là bạn tiết kiệm cả về độ phức tạp của ứng dụng và mạng (như đã được thảo luận bởi @antirez tại antirez. com / news / 73 và Yiftach tại redislabs.com/blog/the-proven-redis-performance ).
Itamar Haber

1
Antirez cảm ơn vì câu trả lời. Một lý do khác có thể là memcached nhanh hơn một chút. Cũng là phần mềm cũ và nhiều khuôn khổ hỗ trợ nó làm mặc định
Nick

3
Câu trả lời tuyệt vời, tôi phải yêu cha của Redis đã tận tâm như thế nào với cộng đồng.
Mahn

13

Thói quen khó phá bỏ :)

Nghiêm túc mà nói, có hai lý do chính - theo sự hiểu biết của tôi - tại sao Memcached vẫn được sử dụng:

  1. Legacy - có các nhà phát triển cảm thấy thoải mái và quen thuộc với Memcached, cũng như các ứng dụng hỗ trợ nó. Điều này cũng có nghĩa rằng nó là một công nghệ đã trưởng thành và đã được thử nghiệm kỹ lưỡng.
  2. Chia tỷ lệ - Memcached tiêu chuẩn có thể dễ dàng mở rộng theo chiều ngang, trong khi Redis (cho đến khi và không bao gồm phiên bản v3 sắp được phát hành) đòi hỏi nhiều công việc hơn để kết thúc (tức là sharding).

Tuy nhiên:

  1. Re. kế thừa - với sự mạnh mẽ của Redis (cấu trúc dữ liệu, lệnh, tính bền bỉ ...), nó đang được phát triển tích cực và ứng dụng khách trong mọi ngôn ngữ có thể hình dung - các ứng dụng mới thường được phát triển với nó.
  2. Mở rộng quy mô lại - bên cạnh phiên bản v3 sắp ra mắt, có những giải pháp có thể giúp mở rộng quy mô dễ dàng hơn nhiều. Ví dụ: Redis Cloud cung cấp khả năng mở rộng quy mô liền mạch mà không mất dữ liệu hoặc gián đoạn dịch vụ. Một cách tiếp cận phổ biến khác để chia tỷ lệ / sharding Redis là twemproxy .

1
Chỉ cần lưu ý: như đã được xác nhận bởi nhà bảo trì hiện tại trên Twitter, Memcached vẫn đang được phát triển / bảo trì tích cực. Tôi đoán thực tế là nó không thường xuyên thêm nội dung mới là do dự án đã đạt đến độ chín và không sẵn sàng thêm nội dung mới, vì vậy những phát triển mới tập trung vào tối ưu hóa / sửa chữa.
antirez

1
TIL rằng Memcached vẫn còn sống và đang hoạt động - đã chỉnh sửa câu trả lời của tôi / ty antirez & dormando
Itamar Haber

1
Băm nhất quán vẫn là một mô hình mạnh mẽ hơn cho sự thất bại duyên dáng hơn là Sharding Redis cho một kịch bản bộ nhớ cache thuần túy. Khi các nút rơi, các khóa bộ nhớ đệm sẽ tự động di chuyển đến các máy chủ khác. Miễn là bạn có một máy chủ duy nhất, bộ nhớ cache của bạn vẫn hoạt động, trái ngược với redis nơi nếu bạn mất master và slave cho bất kỳ nhóm băm nào thì cụm của bạn không thành công.
Usman Ismail

1
RedisLabs là tuyệt vời. Đó là một công nghệ quan trọng đằng sau Userify Cloud.
Fat_error,

1
Tôi cũng cực kỳ nghi ngờ về bất kỳ triển khai nào không dựa trên đa luồng và vòng lặp sự kiện. ... OK, bây giờ mọi người xin lỗi về màn trình diễn hiện tại đang ở đâu, tôi đã chuẩn bị bữa tối cho họ. Bây giờ redis có thể làm được điều đó, và tôi sẽ ủng hộ hơn nhiều từ phía hệ thống. Tuy nhiên, tại thời điểm này, trừ khi nhóm nhà phát triển có khả năng bất thường trong việc lưu vào bộ nhớ đệm, memcached là một cách triển khai đơn giản và hiệu quả hơn .... các tính năng KHÔNG BAO GIỜ miễn phí, đừng để những người xin lỗi nói với bạn rằng họ đang có, hoặc chi phí của bạn là không đáng kể.
JM Becker
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.