Memcached so với Redis?


1466

Chúng tôi đang sử dụng ứng dụng web Ruby với máy chủ Redis để lưu trữ. Có một điểm để kiểm tra Memcached thay thế?

Điều gì sẽ cho chúng ta hiệu suất tốt hơn? Bất kỳ ưu và nhược điểm giữa Redis và Memcached?

Những điểm cần xem xét:

  • Tốc độ đọc / ghi.
  • Sử dụng bộ nhớ.
  • Bán phá giá đĩa I / O.
  • Thu nhỏ.

38
Một phân tích khác ngoài các ý kiến ​​dưới đây: Google Xu hướng: redis vs. memcached
MarkHu

3
Một nhận xét không đảm bảo câu trả lời: nếu bạn đang xem các dịch vụ dựa trên đám mây cho hai hệ thống này (ví dụ: addoku heroku) Các dịch vụ Memcached đôi khi rẻ hơn một chút cho mỗi MB vì ​​bất kỳ lý do gì.
Ben Roberts

2
Đối với khả năng mở rộng: Imgur và Twitter sử dụng cả hai
the_red_baron

Câu trả lời:


2105

Tóm tắt (TL; DR)

Cập nhật ngày 3 tháng 6 năm 2017

Redis mạnh hơn, phổ biến hơn và được hỗ trợ tốt hơn so với memcached. Memcached chỉ có thể làm một phần nhỏ những việc mà Redis có thể làm. Redis là tốt hơn ngay cả khi các tính năng của họ chồng chéo.

Đối với bất cứ điều gì mới, sử dụng Redis.

Memcached vs Redis: So sánh trực tiếp

Cả hai công cụ này đều lưu trữ dữ liệu trong bộ nhớ mạnh mẽ, nhanh chóng, hữu ích như bộ đệm. Cả hai đều có thể giúp tăng tốc ứng dụng của bạn bằng cách lưu trữ kết quả cơ sở dữ liệu, các đoạn HTML hoặc bất kỳ thứ gì khác có thể tốn kém để tạo.

Những điểm cần xem xét

Khi được sử dụng cho cùng một điều, đây là cách họ so sánh bằng cách sử dụng "Điểm cần xem xét" của câu hỏi ban đầu:

  • Tốc độ đọc / ghi : Cả hai đều cực kỳ nhanh. Điểm chuẩn thay đổi theo khối lượng công việc, phiên bản và nhiều yếu tố khác nhưng thường cho thấy redis sẽ nhanh hoặc gần như nhanh như memcached. Tôi khuyên bạn nên redis, nhưng không phải vì memcached chậm. Nó không thể.
  • Sử dụng bộ nhớ : Redis là tốt hơn.
    • memcached: Bạn chỉ định kích thước bộ đệm và khi bạn chèn các mục, trình nền nhanh chóng tăng lên một chút so với kích thước này. Không bao giờ thực sự có một cách để lấy lại bất kỳ không gian nào, thiếu khởi động lại memcached. Tất cả các khóa của bạn có thể hết hạn, bạn có thể xóa cơ sở dữ liệu và nó vẫn sẽ sử dụng toàn bộ khối RAM mà bạn đã cấu hình.
    • redis: Đặt kích thước tối đa là tùy thuộc vào bạn. Redis sẽ không bao giờ sử dụng nhiều hơn nó phải và sẽ trả lại cho bạn bộ nhớ mà nó không còn sử dụng nữa.
    • Tôi đã lưu trữ 100.000 ~ 2KB chuỗi (~ 200MB) câu ngẫu nhiên vào cả hai. Sử dụng RAM Memcached tăng lên ~ 225MB. Sử dụng lại RAM đã tăng lên ~ 228 MB. Sau khi xả cả hai, redis giảm xuống ~ 29MB và memcached ở mức ~ 225MB. Chúng có hiệu quả tương tự trong cách chúng lưu trữ dữ liệu, nhưng chỉ có một người có khả năng lấy lại dữ liệu.
  • Bán phá giá đĩa I / O : Một chiến thắng rõ ràng cho redis vì nó làm điều này theo mặc định và có tính bền bỉ rất cấu hình. Memcached không có cơ chế để đổ vào đĩa mà không có công cụ của bên thứ 3.
  • Chia tỷ lệ : Cả hai cung cấp cho bạn hàng tấn khoảng không trước khi bạn cần nhiều hơn một thể hiện dưới dạng bộ đệm. Redis bao gồm các công cụ để giúp bạn vượt qua điều đó trong khi memcached thì không.

nhớ

Memcached là một máy chủ bộ đệm dễ bay hơi đơn giản. Nó cho phép bạn lưu trữ các cặp khóa / giá trị trong đó giá trị được giới hạn là một chuỗi lên tới 1MB.

Nó tốt ở đây, nhưng đó là tất cả những gì nó làm. Bạn có thể truy cập các giá trị đó bằng khóa của chúng ở tốc độ cực cao, thường bão hòa mạng có sẵn hoặc thậm chí băng thông bộ nhớ.

Khi bạn khởi động lại memcached, dữ liệu của bạn sẽ biến mất. Điều này là tốt cho một bộ đệm. Bạn không nên lưu trữ bất cứ điều gì quan trọng ở đó.

Nếu bạn cần hiệu suất cao hoặc tính sẵn sàng cao, có các công cụ, sản phẩm và dịch vụ của bên thứ 3.

làm lại

Redis có thể làm những công việc tương tự như memcached có thể, và có thể làm chúng tốt hơn.

Redis có thể hoạt động như một bộ đệm . Nó cũng có thể lưu trữ các cặp khóa / giá trị. Trong redis chúng thậm chí có thể lên tới 512MB.

Bạn có thể tắt tính bền bỉ và nó cũng sẽ mất dữ liệu khi khởi động lại. Nếu bạn muốn bộ nhớ cache của bạn tồn tại, nó cũng cho phép bạn làm điều đó. Trong thực tế, đó là mặc định.

Nó cũng siêu nhanh, thường bị giới hạn bởi băng thông mạng hoặc bộ nhớ.

Nếu một phiên bản redis / memcached không đủ hiệu năng cho khối lượng công việc của bạn, thì redis là lựa chọn rõ ràng. Redis bao gồm hỗ trợ cụm và đi kèm với các công cụ có tính sẵn sàng cao ( redis-sentinel ) ngay "trong hộp". Trong vài năm qua, redis cũng đã nổi lên như một nhà lãnh đạo rõ ràng trong công cụ của bên thứ 3. Các công ty như Redis Labs, Amazon và các công ty khác cung cấp nhiều công cụ và dịch vụ hữu ích của redis. Hệ sinh thái xung quanh redis lớn hơn nhiều. Số lượng triển khai quy mô lớn hiện có khả năng lớn hơn so với memcached.

Superset Redis

Redis không chỉ là bộ đệm. Nó là một máy chủ cấu trúc dữ liệu trong bộ nhớ. Dưới đây bạn sẽ tìm thấy một cái nhìn tổng quan nhanh về những điều Redis có thể làm ngoài việc là một bộ đệm khóa / giá trị đơn giản như memcached. Hầu hết các tính năng của redis là những điều mà memcached không thể làm được.

Tài liệu

Redis là tài liệu tốt hơn so với memcached. Trong khi điều này có thể chủ quan, nó dường như ngày càng đúng hơn mọi lúc.

redis.io là một nguồn tài nguyên dễ dàng điều hướng tuyệt vời. Nó cho phép bạn thử redis trong trình duyệt và thậm chí cung cấp cho bạn các ví dụ tương tác trực tiếp với từng lệnh trong tài liệu.

Hiện tại có gấp 2 lần kết quả stackoverflow cho redis như memcached. Nhân đôi số kết quả của Google. Ví dụ dễ tiếp cận hơn trong nhiều ngôn ngữ. Phát triển tích cực hơn. Phát triển khách hàng tích cực hơn. Các phép đo này có thể không có ý nghĩa riêng lẻ nhiều, nhưng kết hợp lại, chúng vẽ ra một bức tranh rõ ràng rằng sự hỗ trợ và tài liệu cho redis là lớn hơn và cập nhật hơn nhiều.

Kiên trì

Theo mặc định, redis vẫn duy trì dữ liệu của bạn vào đĩa bằng cách sử dụng một cơ chế gọi là snapshOUND. Nếu bạn có đủ RAM, nó có thể ghi tất cả dữ liệu của bạn vào đĩa mà hầu như không bị suy giảm hiệu năng. Nó gần như miễn phí!

Trong chế độ chụp nhanh, có khả năng một sự cố bất ngờ có thể dẫn đến một lượng nhỏ dữ liệu bị mất. Nếu bạn thực sự cần phải đảm bảo không có dữ liệu nào bị mất, đừng lo lắng, bạn cũng sẽ quay lại với chế độ AOF (Append Only File). Trong chế độ kiên trì này, dữ liệu có thể được đồng bộ hóa vào đĩa khi được ghi. Điều này có thể giảm thông lượng ghi tối đa xuống tuy nhiên đĩa của bạn có thể ghi nhanh, nhưng vẫn khá nhanh.

Có nhiều tùy chọn cấu hình để tinh chỉnh sự bền bỉ nếu bạn cần, nhưng mặc định là rất hợp lý. Các tùy chọn này giúp bạn dễ dàng thiết lập redis như một nơi an toàn, dự phòng để lưu trữ dữ liệu. Nó là một cơ sở dữ liệu thực sự .

Nhiều kiểu dữ liệu

Memcached bị giới hạn ở các chuỗi, nhưng Redis là một máy chủ cấu trúc dữ liệu có thể phục vụ nhiều loại dữ liệu khác nhau. Nó cũng cung cấp các lệnh bạn cần để tận dụng tối đa các kiểu dữ liệu đó.

Chuỗi ( lệnh )

Văn bản đơn giản hoặc giá trị nhị phân có thể có kích thước lên tới 512MB. Đây là kiểu dữ liệu duy nhất được chia sẻ lại và chia sẻ memcached, mặc dù các chuỗi memcached được giới hạn ở 1MB.

Redis cung cấp cho bạn nhiều công cụ hơn để tận dụng kiểu dữ liệu này bằng cách cung cấp các lệnh cho các hoạt động theo bit, thao tác ở mức bit, hỗ trợ tăng / giảm điểm trôi nổi, truy vấn phạm vi và hoạt động đa khóa. Memcached không hỗ trợ bất kỳ điều đó.

Chuỗi rất hữu ích cho tất cả các loại trường hợp sử dụng, đó là lý do tại sao memcached khá hữu ích với riêng loại dữ liệu này.

Băm ( lệnh )

Băm là loại giống như một cửa hàng giá trị khóa trong kho lưu trữ giá trị khóa. Chúng ánh xạ giữa các trường chuỗi và giá trị chuỗi. Bản đồ trường-> giá trị sử dụng hàm băm có hiệu quả không gian hơn một chút so với bản đồ khóa-> giá trị sử dụng chuỗi thông thường.

Băm là hữu ích như một không gian tên hoặc khi bạn muốn nhóm hợp lý nhiều khóa. Với hàm băm, bạn có thể lấy tất cả các thành viên một cách hiệu quả, hết hạn các thành viên lại với nhau, xóa tất cả các thành viên cùng nhau, v.v ... Tuyệt vời cho mọi trường hợp sử dụng khi bạn có một vài cặp khóa / giá trị cần được nhóm.

Một ví dụ sử dụng hàm băm là để lưu trữ hồ sơ người dùng giữa các ứng dụng. Băm redis được lưu trữ với ID người dùng làm khóa sẽ cho phép bạn lưu trữ bao nhiêu bit dữ liệu về người dùng khi cần trong khi giữ chúng được lưu trữ dưới một khóa duy nhất. Ưu điểm của việc sử dụng hàm băm thay vì tuần tự hóa hồ sơ thành một chuỗi là bạn có thể có các ứng dụng khác nhau đọc / ghi các trường khác nhau trong hồ sơ người dùng mà không phải lo lắng về một ứng dụng ghi đè các thay đổi do người khác thực hiện (điều này có thể xảy ra nếu bạn tuần tự hóa cũ dữ liệu).

Danh sách ( lệnh )

Danh sách Redis được sắp xếp các bộ sưu tập của chuỗi. Chúng được tối ưu hóa để chèn, đọc hoặc xóa các giá trị từ đầu hoặc cuối (còn gọi là: trái hoặc phải) của danh sách.

Redis cung cấp nhiều lệnh để tận dụng danh sách, bao gồm các lệnh để đẩy / bật các mục, đẩy / bật giữa các danh sách, danh sách cắt ngắn, thực hiện các truy vấn phạm vi, v.v.

Danh sách làm cho tuyệt vời bền, nguyên tử, hàng đợi. Chúng hoạt động tuyệt vời cho hàng đợi công việc, nhật ký, bộ đệm và nhiều trường hợp sử dụng khác.

Bộ ( lệnh )

Bộ là bộ sưu tập không có thứ tự của các giá trị duy nhất. Chúng được tối ưu hóa để cho phép bạn nhanh chóng kiểm tra xem một giá trị có trong tập hợp không, nhanh chóng thêm / xóa giá trị và để đo chồng chéo với các bộ khác.

Đây là những thứ tuyệt vời cho những thứ như danh sách kiểm soát truy cập, trình theo dõi khách truy cập duy nhất và nhiều thứ khác. Hầu hết các ngôn ngữ lập trình đều có một cái gì đó tương tự (thường được gọi là Bộ). Đây là như thế, chỉ phân phối.

Redis cung cấp một số lệnh để quản lý các bộ. Những thứ hiển nhiên như thêm, xóa và kiểm tra bộ có mặt. Vì vậy, các lệnh ít rõ ràng hơn như popping / đọc một mục ngẫu nhiên và các lệnh để thực hiện các hiệp và giao với các bộ khác.

Bộ sắp xếp ( lệnh )

Bộ sắp xếp cũng là bộ sưu tập các giá trị duy nhất. Những cái này, như tên của nó, được đặt hàng. Họ được sắp xếp theo một số điểm, sau đó từ vựng.

Kiểu dữ liệu này được tối ưu hóa để tra cứu nhanh theo điểm số. Lấy giá trị cao nhất, thấp nhất hoặc bất kỳ phạm vi giá trị nào ở giữa là cực kỳ nhanh.

Nếu bạn thêm người dùng vào một tập hợp được sắp xếp cùng với điểm số cao của họ, bạn có cho mình một bảng lãnh đạo hoàn hảo. Khi điểm số cao mới xuất hiện, chỉ cần thêm chúng vào nhóm một lần nữa với điểm số cao của chúng và nó sẽ sắp xếp lại bảng lãnh đạo của bạn. Cũng tuyệt vời để theo dõi lần cuối người dùng truy cập và những người đang hoạt động trong ứng dụng của bạn.

Lưu trữ các giá trị có cùng số điểm khiến chúng được sắp xếp theo thứ tự từ vựng (nghĩ theo bảng chữ cái). Điều này có thể hữu ích cho những thứ như tính năng tự động hoàn thành.

Nhiều lệnh được sắp xếp tương tự như lệnh cho các tập hợp, đôi khi có thêm tham số điểm. Cũng bao gồm các lệnh để quản lý điểm số và truy vấn theo điểm số.

Địa lý

Redis có một số lệnh để lưu trữ, truy xuất và đo dữ liệu địa lý. Điều này bao gồm các truy vấn bán kính và đo khoảng cách giữa các điểm.

Về mặt kỹ thuật, dữ liệu địa lý trong redis được lưu trữ trong các bộ được sắp xếp, vì vậy đây không phải là loại dữ liệu thực sự riêng biệt. Nó là một phần mở rộng trên đầu của các bộ được sắp xếp.

Bitmap và HyperLogLog

Giống như địa lý, đây không phải là loại dữ liệu hoàn toàn riêng biệt. Đây là các lệnh cho phép bạn xử lý dữ liệu chuỗi như thể đó là bitmap hoặc hyperloglog.

Bitmap là những gì mà các toán tử cấp bit mà tôi đã tham chiếu theo Strings. Kiểu dữ liệu này là khối xây dựng cơ bản cho dự án nghệ thuật hợp tác gần đây của reddit: r / Place .

HyperLogLog cho phép bạn sử dụng một lượng không gian cực kỳ nhỏ để đếm các giá trị duy nhất gần như không giới hạn với độ chính xác gây sốc. Chỉ sử dụng ~ 16KB, bạn có thể đếm số lượng khách truy cập duy nhất vào trang web của mình một cách hiệu quả, ngay cả khi con số đó là hàng triệu.

Giao dịch và nguyên tử

Các lệnh trong redis là nguyên tử, có nghĩa là bạn có thể chắc chắn rằng ngay khi bạn viết một giá trị cho redis, giá trị đó sẽ hiển thị cho tất cả các máy khách được kết nối với redis. Không có chờ đợi giá trị đó để tuyên truyền. Về mặt kỹ thuật memcached cũng là nguyên tử, nhưng với redis thêm tất cả chức năng này ngoài memcached, điều đáng chú ý và hơi ấn tượng là tất cả các loại dữ liệu và tính năng bổ sung này cũng là nguyên tử.

Mặc dù không hoàn toàn giống như các giao dịch trong cơ sở dữ liệu quan hệ, redis cũng có các giao dịch sử dụng "khóa tối ưu" ( WATCH / MULTI / EXEC ).

Đường ống

Redis cung cấp một tính năng gọi là " đường ống ". Nếu bạn có nhiều lệnh redis mà bạn muốn thực thi, bạn có thể sử dụng pipelining để gửi chúng để làm lại tất cả cùng một lúc thay vì một lần.

Thông thường khi bạn thực thi một lệnh để redis hoặc memcached, mỗi lệnh là một chu kỳ yêu cầu / phản hồi riêng biệt. Với pipelining, redis có thể đệm một số lệnh và thực hiện tất cả chúng cùng một lúc, đáp ứng với tất cả các phản hồi cho tất cả các lệnh của bạn trong một câu trả lời.

Điều này có thể cho phép bạn đạt được thông lượng lớn hơn nữa khi nhập hàng loạt hoặc các hành động khác liên quan đến nhiều lệnh.

Quán rượu / phụ

Redis có các lệnh dành riêng cho chức năng pub / sub , cho phép redis hoạt động như một đài phát tin nhắn tốc độ cao. Điều này cho phép một khách hàng xuất bản tin nhắn cho nhiều khách hàng khác được kết nối với một kênh.

Redis không pub / sub cũng như hầu hết mọi công cụ. Các nhà môi giới tin nhắn chuyên dụng như RabbitMQ có thể có lợi thế ở một số khu vực nhất định, nhưng thực tế là cùng một máy chủ cũng có thể cung cấp cho bạn hàng đợi bền bỉ và các cấu trúc dữ liệu khác mà khối lượng công việc / quán rượu của bạn có thể cần, Redis thường sẽ chứng minh là công cụ đơn giản và tốt nhất cho công việc.

Lua Scripting

Bạn có thể nghĩ về các tập lệnh lua như SQL hoặc các thủ tục được lưu trữ của redis. Nó nhiều hơn và ít hơn thế, nhưng sự tương tự chủ yếu hoạt động.

Có thể bạn có các tính toán phức tạp mà bạn muốn redis thực hiện. Có thể bạn không đủ khả năng để giao dịch của mình quay trở lại và cần đảm bảo mọi bước của một quy trình phức tạp sẽ diễn ra nguyên tử. Những vấn đề này và nhiều vấn đề khác có thể được giải quyết với kịch bản lua.

Toàn bộ tập lệnh được thực thi nguyên tử, vì vậy nếu bạn có thể điều chỉnh logic của mình thành tập lệnh lua, bạn thường có thể tránh gây rối với các giao dịch khóa lạc quan.

Thu nhỏ

Như đã đề cập ở trên, redis bao gồm hỗ trợ tích hợp để phân cụm và được đóng gói với công cụ sẵn sàng cao được gọi là của nó redis-sentinel.

Phần kết luận

Không do dự, tôi sẽ khuyên bạn nên làm lại trên memcached cho bất kỳ dự án mới nào, hoặc các dự án hiện tại chưa sử dụng memcached.

Ở trên có vẻ như tôi không thích memcached. Trái lại: nó là một công cụ mạnh mẽ, đơn giản, ổn định, trưởng thành và cứng. Thậm chí có một số trường hợp sử dụng mà nó nhanh hơn một chút so với redis. Tôi yêu memcached. Tôi chỉ không nghĩ rằng nó có ý nghĩa cho sự phát triển trong tương lai.

Redis làm mọi thứ memcached làm, thường tốt hơn. Bất kỳ lợi thế hiệu suất cho memcached là nhỏ và khối lượng công việc cụ thể. Ngoài ra còn có khối lượng công việc mà redis sẽ nhanh hơn và nhiều khối lượng công việc hơn mà redis có thể làm mà memcached đơn giản là không thể. Sự khác biệt hiệu năng nhỏ bé dường như rất nhỏ khi đối mặt với lỗ hổng lớn về chức năng và thực tế là cả hai công cụ này rất nhanh và hiệu quả, chúng rất có thể là phần cuối cùng của cơ sở hạ tầng của bạn mà bạn sẽ phải lo lắng về việc mở rộng quy mô.

Chỉ có một kịch bản mà memcached có ý nghĩa hơn: nơi memcached đã được sử dụng làm bộ đệm. Nếu bạn đã lưu vào bộ nhớ cache với memcached thì hãy tiếp tục sử dụng nó, nếu nó đáp ứng nhu cầu của bạn. Nó có thể không có giá trị nỗ lực để chuyển sang redis và nếu bạn sẽ sử dụng redis chỉ để lưu trữ, nó có thể không cung cấp đủ lợi ích xứng đáng với thời gian của bạn. Nếu memcached không đáp ứng nhu cầu của bạn, thì có lẽ bạn nên chuyển sang redis. Điều này đúng cho dù bạn cần mở rộng ra ngoài memcached hay bạn cần thêm chức năng.


11
Làm thế nào để Memcached cung cấp phân cụm theo cách tồn tại trong chính máy chủ? Tôi đã luôn sử dụng các thư viện phân phối cho nhóm máy chủ memcached bằng thuật toán băm hoặc mô đun. Điều tương tự cũng được nói cho Redis. Tôi chủ yếu sử dụng Python và dường như có khá nhiều mô-đun không dựa vào thư viện memcached để xử lý các nhóm kết nối.
whardier

2
"Giao dịch với khóa lạc quan (WATCH / MULTI / EXEC)" - Redis không có giao dịch đúng. Tức là nếu [multi, cmd1, cmd2, cmd3 (ngoại lệ), exec] thì cmd1 và cmd2 sẽ được thực thi.
Oleg

10
@Oleg đó không thực sự đúng. Nếu bạn sử dụng multi-exec, các lệnh được đệm (nghĩa là: không được thực thi) cho đến khi thực thi xảy ra, vì vậy nếu bạn có một ngoại lệ trước exec thì không có lệnh nào thực sự được thực thi. Nếu exec được gọi thì tất cả các lệnh đệm được thực thi nguyên tử, trừ khi, tất nhiên, trừ khi một biến đồng hồ đã được thay đổi kể từ khi đa được gọi lần đầu tiên. Cơ chế sau này là phần khóa lạc quan.
Carl Zulauf

3
@whardier Bạn đã đúng. Câu trả lời được cập nhật để phản ánh rằng "hỗ trợ" của cụm memcached được kích hoạt bằng các công cụ bổ sung. Nên đã nghiên cứu mà tốt hơn.
Carl Zulauf

3
Làm thế nào về phân cụm với máy chủ couchbase? (tương thích memcached)
Ken Liu

142

Sử dụng Redis nếu

  1. Bạn yêu cầu xóa có chọn lọc / hết hạn các mục trong bộ đệm. (Bạn cần cái này)

  2. Bạn yêu cầu khả năng truy vấn các khóa của một loại cụ thể. phương trình 'blog1: bài viết: *', 'blog2: chuyên mục: xyz: bài viết: *'. ồ đúng rồi cái này rất quan trọng. Sử dụng điều này để vô hiệu hóa một số loại mục lưu trữ được chọn lọc. Bạn cũng có thể sử dụng điều này để vô hiệu hóa bộ đệm phân đoạn, bộ đệm trang, chỉ các đối tượng AR thuộc loại đã cho, v.v.

  3. Kiên trì (Bạn cũng sẽ cần điều này, trừ khi bạn ổn với bộ đệm của mình phải khởi động sau mỗi lần khởi động lại. Rất cần thiết cho các đối tượng hiếm khi thay đổi)

Sử dụng memcached nếu

  1. Memcached cung cấp cho bạn headached!
  2. umm ... co cụm? ồ nếu bạn đi xa đến đó, hãy sử dụng Varnish và Redis để lưu trữ các đoạn và các đối tượng AR.

Từ kinh nghiệm của tôi, tôi đã có sự ổn định tốt hơn với Redis so với Memcached


7
Tài liệu Redis nói rằng sử dụng các mẫu đòi hỏi phải quét bảng. blog1: bài viết: * có thể yêu cầu quét bảng O (N). Tất nhiên, nó vẫn nhanh trên các tập dữ liệu có kích thước hợp lý, vì Redis rất nhanh. Nó sẽ ổn để kiểm tra hoặc quản trị viên.
wisty

182
Headached là một trò đùa, phải không? :-) Tôi đã googled cho memcached headached nhưng không tìm thấy bất cứ điều gì hợp lý. (Tôi mới biết về Memcached và Redis)
KajMagnus

11
bình chọn xuống với cùng lý do hơn @pellucide. Redis có thể tốt hơn Memcached, nhưng Memcached không quan trọng để sử dụng. Tôi chưa bao giờ có vấn đề với nó và nó không quan trọng để cấu hình.
Diego Jancic

5
Cảm ơn bạn @KajMagnus đã làm cho ngày của tôi .. có thể là cả tuần của tôi
alex

@DiegoJancic Redis là một trong những công nghệ dễ sử dụng nhất. Không có kiến ​​thức về Redis trước đây, tôi chỉ mất 20 phút để cài đặt nó trên Ubuntu bằng trình quản lý gói trên đám mây và bắt đầu thực hiện các truy vấn đơn giản. 4 giờ sau tôi có thể POC các kịch bản phức tạp hơn bằng cách chèn hàng loạt bằng cách sử dụng tập lệnh Lua và chọn thư viện Java (NIO) phù hợp để cải thiện hiệu suất. Tôi không thể tưởng tượng bất cứ điều gì thân thiện và đơn giản để sử dụng hơn Redis.
Moose on the Loose

105

Memcached là đa luồng và nhanh chóng.

Redis có rất nhiều tính năng và rất nhanh, nhưng hoàn toàn giới hạn ở một lõi vì nó dựa trên một vòng lặp sự kiện.

Chúng tôi sử dụng cả hai. Memcached được sử dụng cho các đối tượng lưu trữ, chủ yếu là giảm tải đọc trên cơ sở dữ liệu. Redis được sử dụng cho những thứ như các bộ được sắp xếp thuận tiện cho việc cuộn dữ liệu chuỗi thời gian.


2
Các trang web có lưu lượng truy cập cao được đầu tư nhiều vào memcached và có các tắc nghẽn db trên dữ liệu không liên quan đến "hồ sơ người dùng" nên đánh giá couchbase song song với Mongo, Redis

2
@siliconrockstar - khá chắc chắn Redis 3 vẫn là lõi đơn; ít nhất AWS Redis (sử dụng 3.2.6 hoặc 3.2.10) cảnh báo sẽ tính đến điều đó khi xem xét, ví dụ: Số liệu
thống kê EngineCpuUtilization

1
Có vẻ như bạn đúng, tôi nghĩ khi tôi đưa ra nhận xét đó, tôi đã dựa trên những nguồn không đầy đủ. Đã xóa bình luận.
siliconrockstar

nhưng bạn vẫn có thể khởi chạy các phiên bản $ core_count của Redis
Imaskar

2
Redis cực kỳ tập trung vào hiệu quả - vì vậy bạn cần phải tự hỏi tại sao một loạt các nhà phát triển thông minh chọn giữ cho nó một chuỗi? Từ các tài liệu redis "Không thường xuyên lắm khi CPU trở thành nút cổ chai của bạn với Redis, vì thông thường Redis là bộ nhớ hoặc bị ràng buộc mạng". Nếu bạn đã sử dụng một máy chủ càu nhàu bị ràng buộc bởi CPU, thì có lẽ bạn có nhiều người dùng và dù sao cũng nên có nhiều máy chủ dự phòng. Nếu bạn muốn tối đa nhiều CPU trên một máy chủ, hãy sử dụng phân vùng. Đọc: redis.io/topics/...
robocat

91

Điều này quá dài để được đăng dưới dạng một nhận xét cho câu trả lời đã được chấp nhận, vì vậy tôi đặt nó như một câu trả lời riêng

Một điều cũng cần xem xét là liệu bạn có mong muốn có giới hạn bộ nhớ trên cứng trong trường hợp bộ nhớ cache hay không.

Vì redis là một cơ sở dữ liệu nosql với vô số tính năng và bộ nhớ đệm chỉ là một tùy chọn mà nó có thể được sử dụng, nên nó phân bổ bộ nhớ khi nó cần - bạn càng đặt nhiều đối tượng vào nó, càng sử dụng nhiều bộ nhớ. Các maxmemorytùy chọn không đúng thực thi trên việc sử dụng giới hạn bộ nhớ. Khi bạn làm việc với bộ đệm, các khóa bị đuổi và hết hạn; rất có thể các khóa của bạn không cùng kích thước, do đó xảy ra sự phân mảnh bộ nhớ trong.

Theo mặc định, redis sử dụng bộ cấp phát bộ nhớ jemalloc , nó cố gắng hết sức để vừa nhỏ gọn vừa nhanh, nhưng nó là bộ cấp phát bộ nhớ cho mục đích chung và nó không thể theo kịp nhiều phân bổ và thanh lọc đối tượng xảy ra với tốc độ cao. Bởi vì điều này, trên một số mẫu tải quá trình redis rõ ràng có thể rò rỉ bộ nhớ vì sự phân mảnh bên trong. Ví dụ: nếu bạn có máy chủ có RAM 7 Gb và bạn muốn sử dụng redis làm bộ đệm LRU không liên tục, bạn có thể thấy rằng quá trình redis với maxmemorycài đặt thành 5Gb theo thời gian sẽ sử dụng nhiều bộ nhớ hơn, cuối cùng đạt đến giới hạn RAM cho đến khi Kẻ giết người ngoài bộ nhớ can thiệp.

memcached phù hợp hơn với kịch bản được mô tả ở trên, vì nó quản lý bộ nhớ của nó theo một cách hoàn toàn khác. memcached phân bổ một khối lớn bộ nhớ - mọi thứ nó sẽ cần - và sau đó tự quản lý bộ nhớ này, bằng cách sử dụng bộ cấp phát bản đã triển khai của chính nó . Hơn nữa, memcached cố gắng hết sức để giữ phân mảnh bên trong ở mức thấp, vì nó thực sự sử dụng thuật toán LRU trên mỗi phiến , khi việc trục xuất LRU được thực hiện với kích thước đối tượng được xem xét.

Như đã nói, memcached vẫn có một vị trí vững chắc trong các môi trường, trong đó việc sử dụng bộ nhớ phải được thi hành và / hoặc có thể dự đoán được. Chúng tôi đã thử sử dụng redis ổn định mới nhất (2.8.19) như một sự thay thế memcached dựa trên LRU không liên tục trong khối lượng công việc 10-15k op / s, và nó bị rò rỉ bộ nhớ A RẤT; khối lượng công việc tương tự đã làm sập các trường hợp ElastiCache của Amazon trong một ngày hoặc lâu hơn vì những lý do tương tự.


2
Từ redis.io/topics/faq : Redis có các biện pháp bảo vệ tích hợp cho phép người dùng đặt giới hạn tối đa cho việc sử dụng bộ nhớ, sử dụng tùy chọn maxmemory trong tệp cấu hình để đặt giới hạn cho bộ nhớ mà Redis có thể sử dụng. Nếu đạt đến giới hạn này, Redis sẽ bắt đầu trả lời lỗi khi viết lệnh (nhưng sẽ tiếp tục chấp nhận các lệnh chỉ đọc) hoặc bạn có thể định cấu hình nó để đuổi các khóa khi đạt đến giới hạn bộ nhớ tối đa trong trường hợp bạn đang sử dụng Redis để lưu trữ. Chúng tôi có tài liệu nếu bạn dự định sử dụng Redis làm bộ đệm LRU. liên kết
StefanNch

8
maxmemoryTùy chọn @StefanNch redis ' không tính đến sự phân mảnh bộ nhớ trong. Vui lòng xem nhận xét của tôi ở trên để biết chi tiết - các vấn đề tôi đã mô tả đã được nhìn thấy trong kịch bản được mô tả trong trang "Redis as a LRU cache" với các tùy chọn giới hạn bộ nhớ được bật. mặt khác, memcached sử dụng các cách tiếp cận khác nhau để tránh vấn đề phân mảnh bộ nhớ, do đó giới hạn bộ nhớ của nó "cứng" hơn nhiều.
artyom

46

Memcached rất giỏi trong việc trở thành một kho lưu trữ khóa / giá trị đơn giản và giỏi làm key => STRING. Điều này làm cho nó thực sự tốt cho lưu trữ phiên.

Redis rất giỏi làm key => SOME_OB DỰ ÁN.

Nó thực sự phụ thuộc vào những gì bạn sẽ được đưa vào đó. Sự hiểu biết của tôi là về mặt hiệu suất, chúng thậm chí còn đẹp.

Cũng may mắn tìm thấy bất kỳ điểm chuẩn khách quan, nếu bạn tìm thấy một số vui lòng gửi cho họ theo cách của tôi.


2
IMO kiểu dữ liệu Redis Hash có ý nghĩa hơn trong việc lưu trữ các biến phiên hơn là tuần tự hóa chúng thành một chuỗi memcached.
Carl Zulauf

6
Nếu bạn quan tâm đến trải nghiệm người dùng, đừng đặt các phiên của bạn vào bộ đệm. dormando.livejournal.com/495593.html
sleblanc

4
@sebleblanc Về mặt lý thuyết, đây không phải là vấn đề với Redis vì có sự tồn tại của đĩa.
haknick

2
@sebleblanc memcache vẫn còn tốt trong việc lưu trữ phiên bạn có thực hiện nó kém hay không. vâng, vâng là một vấn đề nhưng không phải là không thể vượt qua, cũng không phải là vấn đề của memcache nếu bạn không lo lắng về việc trục xuất. Tôi tin rằng hầu hết các giải pháp phiên memcache sử dụng cookie như một bản sao lưu.
Erik Petersen

11
"Không đặt các phiên của bạn trong bộ nhớ cache" là sai lệch. Ý bạn là "Không chỉ lưu trữ các phiên của bạn trong bộ nhớ cache". Bất cứ ai lưu trữ dữ liệu quan trọng trong memcache chỉ nên bị sa thải ngay lập tức.
Jacob

37

Nếu bạn không quan tâm đến phong cách viết thô bỉ, Redis vs Memcached trên blog Systoilet đáng để đọc từ quan điểm về khả năng sử dụng, nhưng hãy chắc chắn đọc qua lại trong các bình luận trước khi đưa ra bất kỳ kết luận nào về hiệu suất; có một số vấn đề về phương pháp luận (các bài kiểm tra vòng lặp đơn luồng) và Redis đã thực hiện một số cải tiến kể từ khi bài viết được viết.

Và không có liên kết điểm chuẩn nào hoàn tất mà không gây nhầm lẫn một chút, do đó, hãy kiểm tra một số điểm chuẩn mâu thuẫn tại LiveJournal của DormondoAntirez Weblog .

Chỉnh sửa - như Antirez chỉ ra, phân tích Systoilet khá khó hiểu. Ngay cả ngoài sự thiếu hụt luồng đơn, phần lớn sự chênh lệch hiệu năng trong các điểm chuẩn đó có thể được quy cho các thư viện máy khách thay vì thông lượng máy chủ. Các điểm chuẩn tại Antirez Weblog thực sự đưa ra một so sánh táo hơn nhiều (với cùng một miệng).



28
Bạn không đùa về crass.
ocodo

1
Hơn năm 2010, blog lỗi thời
Siddharth

24

Tôi đã có cơ hội sử dụng cả memcached và redis cùng nhau trong proxy lưu trữ mà tôi đã làm việc, hãy để tôi chia sẻ cho bạn chính xác nơi tôi đã sử dụng những gì và lý do đằng sau cùng ....

Redis>

1) Được sử dụng để lập chỉ mục nội dung bộ đệm, trên cụm. Tôi có hơn một tỷ khóa trải đều trên các cụm redis, thời gian phản hồi của redis khá ít và ổn định.

2) Về cơ bản, đó là một kho lưu trữ khóa / giá trị, vì vậy, bất cứ khi nào trong ứng dụng của bạn, bạn có một cái gì đó tương tự, người ta có thể sử dụng redis với nhiều phiền phức.

3) Redis kiên trì, chuyển đổi dự phòng và sao lưu (AOF) sẽ giúp công việc của bạn dễ dàng hơn.

Memcache>

1) có, một bộ nhớ được tối ưu hóa có thể được sử dụng làm bộ đệm. Tôi đã sử dụng nó để lưu trữ nội dung bộ đệm được truy cập rất thường xuyên (với 50 lần truy cập / giây) với kích thước nhỏ hơn 1 MB.

2) Tôi chỉ phân bổ 2 GB trong số 16 GB cho memcached khi kích thước nội dung duy nhất của tôi> 1MB.

3) Khi nội dung phát triển gần các giới hạn, đôi khi tôi đã quan sát thời gian phản hồi cao hơn trong các số liệu thống kê (không phải trường hợp với redis).

Nếu bạn yêu cầu trải nghiệm tổng thể thì Redis có nhiều màu xanh vì nó dễ cấu hình, linh hoạt với nhiều tính năng mạnh mẽ ổn định.

Hơn nữa, có một kết quả điểm chuẩn có sẵn tại liên kết này , bên dưới là một vài điểm sáng từ cùng,

nhập mô tả hình ảnh ở đây

nhập mô tả hình ảnh ở đây

Hi vọng điêu nay co ich!!


14

Kiểm tra. Chạy một số điểm chuẩn đơn giản. Trong một thời gian dài, tôi coi mình là một con tê giác trường học cũ vì tôi đã sử dụng chủ yếu là memcached và coi Redis là đứa trẻ mới.

Với công ty hiện tại của tôi, Redis đã được sử dụng làm bộ đệm chính. Khi tôi đi sâu vào một số thống kê hiệu suất và chỉ đơn giản là bắt đầu thử nghiệm, Redis, về mặt hiệu suất, có thể so sánh hoặc chậm hơn tối thiểu so với MySQL.

Memcached, mặc dù đơn giản, đã thổi Redis ra khỏi nước hoàn toàn . Nó mở rộng tốt hơn nhiều:

  • cho các giá trị lớn hơn (yêu cầu thay đổi kích thước bản mỏng, nhưng đã hoạt động)
  • cho nhiều yêu cầu đồng thời

Ngoài ra, chính sách trục xuất memcached theo quan điểm của tôi, được thực hiện tốt hơn nhiều, dẫn đến thời gian phản hồi trung bình ổn định hơn trong khi xử lý nhiều dữ liệu hơn bộ đệm có thể xử lý.

Một số điểm chuẩn cho thấy Redis, trong trường hợp của chúng tôi, hoạt động rất kém. Điều này tôi tin là phải làm với nhiều biến:

  • loại phần cứng bạn chạy Redis trên
  • loại dữ liệu bạn lưu trữ
  • số lượng được và bộ
  • ứng dụng của bạn đồng thời như thế nào
  • bạn có cần lưu trữ cấu trúc dữ liệu

Cá nhân, tôi không chia sẻ quan điểm của các tác giả Redis về sự đồng thời và đa luồng.


vui lòng giải thích "tối thiểu chậm hơn MySQL."
Anirudha Gupta 18/03/18

Truty được nói rằng tôi không có dữ liệu điểm chuẩn này trong tay nhưng trường hợp cụ thể đó là rất nhiều ops đọc / ghi
mdomans 20/03/18

13

Một phần thưởng khác là có thể thấy rất rõ memcache sẽ hoạt động như thế nào trong một kịch bản lưu trữ, trong khi redis thường được sử dụng như một kho dữ liệu liên tục, mặc dù nó có thể được cấu hình để hoạt động giống như memcached hay đuổi theo các mục được sử dụng gần đây khi nó đạt đến mức tối đa sức chứa.

Một số ứng dụng tôi đã sử dụng cả hai chỉ để làm rõ cách chúng tôi dự định xử lý dữ liệu - nội dung trong memcache, chúng tôi viết mã để xử lý các trường hợp không có ở đó - công cụ trong redis, chúng tôi dựa vào đó .

Khác với điều đó Redis thường được coi là vượt trội đối với hầu hết các trường hợp sử dụng là giàu tính năng hơn và do đó linh hoạt.


10

Sẽ không sai, nếu chúng ta nói rằng redis là sự kết hợp của (cache + cấu trúc dữ liệu) trong khi memcached chỉ là một bộ đệm.


1
Đây là câu trả lời tốt - Laravel đang sử dụng redis làm bộ đệm và làm cơ chế lưu trữ dữ liệu
Miroslav Trninic

8

Một thử nghiệm rất đơn giản để đặt và nhận 100k khóa và giá trị duy nhất chống lại redis-2.2.2 và memcached. Cả hai đều chạy trên linux VM (CentOS) và mã máy khách của tôi (được dán bên dưới) chạy trên màn hình nền Windows.

Redis

  • Thời gian để lưu trữ 100000 giá trị là = 18954ms

  • Thời gian để tải 100000 giá trị là = 18328ms

Ghi nhớ

  • Thời gian để lưu trữ 100000 giá trị là = 797ms

  • Thời gian để lấy 100000 giá trị là = 38984ms


Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

6
Vì rõ ràng bạn đã sử dụng Java để đo lường .... bạn đã "làm nóng" các trường hợp thử nghiệm của mình chưa? Đây là điều cần thiết đo lường trong một thời gian ngắn như vậy ... mà JIT đã biên soạn các điểm nóng.
cljk

7

Một điểm khác biệt lớn chưa được chỉ ra ở đây là Memcache luôn có giới hạn bộ nhớ trên, trong khi Redis không mặc định (nhưng có thể được cấu hình thành). Nếu bạn luôn muốn lưu trữ khóa / giá trị trong một khoảng thời gian nhất định (và không bao giờ xóa nó vì bộ nhớ thấp), bạn muốn đi với Redis. Tất nhiên, bạn cũng có nguy cơ hết bộ nhớ ...


6

Lý do lớn nhất còn lại là chuyên môn hóa.

Redis có thể làm rất nhiều thứ khác nhau và một tác dụng phụ đó là các nhà phát triển có thể bắt đầu sử dụng rất nhiều các bộ tính năng khác nhau trên cùng một ví dụ. Nếu bạn đang sử dụng tính năng LRU của Redis cho bộ nhớ cache cùng với bộ lưu trữ dữ liệu cứng mà KHÔNG phải là LRU thì hoàn toàn có thể hết bộ nhớ.

Nếu bạn định thiết lập một cá thể Redis chuyên dụng CHỈ được sử dụng làm phiên bản LRU để tránh trường hợp cụ thể đó thì thực sự không có bất kỳ lý do thuyết phục nào để sử dụng Redis trên Memcached.

Nếu bạn cần một bộ đệm LRU "không bao giờ tắt" đáng tin cậy ... Memcached sẽ phù hợp với hóa đơn vì nó không thể hết bộ nhớ theo thiết kế và chức năng chuyên dụng ngăn các nhà phát triển cố gắng tạo ra thứ gì đó có thể gây nguy hiểm cho điều đó. Đơn giản tách mối quan tâm.


6

Memcached sẽ nhanh hơn nếu bạn quan tâm đến hiệu suất, ngay cả khi Redis liên quan đến kết nối mạng (các cuộc gọi TCP). Ngoài ra Memcache nội bộ là nhanh hơn.

Redis có nhiều tính năng hơn như được đề cập bởi các câu trả lời khác.


6

Chúng tôi đã nghĩ về Redis như một sự cất cánh cho dự án của chúng tôi tại nơi làm việc. Chúng tôi nghĩ rằng bằng cách sử dụng một mô-đun nginxđược gọi HttpRedis2Modulehoặc một cái gì đó tương tự, chúng tôi sẽ có tốc độ tuyệt vời nhưng khi thử nghiệm với AB-test, chúng tôi đã chứng minh là sai.

Có thể mô-đun là xấu hoặc bố cục của chúng tôi nhưng đó là một nhiệm vụ rất đơn giản và thậm chí còn nhanh hơn để lấy dữ liệu bằng php và sau đó nhét nó vào MongoDB. Chúng tôi đang sử dụng APC làm hệ thống lưu trữ và với php và MongoDB đó. Nó đã nhanh hơn nhiềunginx mô-đun Redis.

Mẹo của tôi là tự kiểm tra nó, thực hiện nó sẽ cho bạn thấy kết quả cho môi trường của bạn. Chúng tôi quyết định rằng sử dụng Redis là không cần thiết trong dự án của chúng tôi vì nó sẽ không có ý nghĩa gì.


Câu trả lời thú vị nhưng không chắc nó có giúp OP
Scott Schulthess

Chèn vào Redis và sử dụng nó làm bộ đệm chậm hơn so với sử dụng APC + PHP + MongoDB. Nhưng chỉ cần chèn vào Redis là chậm hơn so với chèn trực tiếp vào MongoDB. Không có APC tôi nghĩ họ khá ngang nhau.
Ms01

2
Thats vì Mongo không cung cấp cho bạn bất kỳ sự đảm bảo rằng những gì bạn đã chèn là bao giờ sẽ được ghi vào đĩa ...
Damian

21
nhưng nó là webscale, mongodb sẽ chạy xung quanh bạn trong vòng tròn trong khi bạn viết. Ngày nay tôi chỉ viết thư cho / dev / null vì đó là cách nhanh nhất.
Ms01

1

Redis là tốt hơn.

Ưu điểm của Redis,

  1. Nó có rất nhiều tùy chọn lưu trữ dữ liệu như chuỗi, bộ, bộ đã sắp xếp, giá trị băm, bitmap
  2. Độ bền của đĩa
  3. LUAHỗ trợ thủ tục lưu trữ ( kịch bản)
  4. Có thể hoạt động như một Nhà môi giới tin nhắn bằng PUB / SUB

Trong khi đó Memcachelà một hệ thống loại bộ đệm giá trị khóa trong bộ nhớ.

  1. Không hỗ trợ cho các kho lưu trữ loại dữ liệu khác nhau như danh sách, bộ như trong redis.
  2. Con lừa chính là Memcache không có đĩa.

0

Vâng, tôi chủ yếu sử dụng cả với các ứng dụng của mình, Memcache để lưu trữ các phiên và làm lại cho các đối tượng truy vấn học thuyết / orm. Về mặt hiệu suất cả hai gần như giống nhau.


0

Đây là bài viết / sự khác biệt thực sự tuyệt vời được cung cấp bởi Amazon

Redis là một người chiến thắng rõ ràng so với memcached.

Chỉ có một điểm cộng cho Memcached Nó là đa luồng và nhanh. Redis có rất nhiều tính năng tuyệt vời và rất nhanh, nhưng giới hạn ở một lõi.

Những điểm tuyệt vời về Redis, không được hỗ trợ trong Memcached

  • Ảnh chụp nhanh - Người dùng có thể chụp nhanh bộ nhớ cache Redis và lưu trữ trên bộ lưu trữ thứ cấp bất kỳ lúc nào.
  • Hỗ trợ sẵn có cho nhiều cấu trúc dữ liệu như Set, Map, Sortedset, List, BitMaps, v.v.
  • Hỗ trợ cho kịch bản Lua trong redis
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.