Memcached 與 Redis 的比較
source link: https://blog.gslin.org/archives/2021/10/13/10375/memcached-%e8%88%87-redis-%e7%9a%84%e6%af%94%e8%bc%83/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Memcached 與 Redis 的比較
在「Memcached vs Redis - More Different Than You Would Expect」這邊看到對 Memcached 與 Redis 的分析。
這兩套軟體都很常被拿來用作 cache 機制，所以一般來說比較時就是比兩邊都有的東西 (如果你要 pub-sub 之類的東西，在這兩套裡面只有 Redis 有)。
最前面還是先講了對使用者 (開發者) 的差異，很明顯的是 Redis 對各種不同的資聊結構都有支援，這點可以從 Redis 被官方被稱作 Data Structures Server 就可以知道 (在「An introduction to Redis data types and abstractions」這篇可以看到)，而 Memcached 只支援了 key-value 架構。
不過如果是以 cache 來說，的確 key-value 架構就還蠻好用的。
後面就開始比較硬的主題了，提到了 Memcached 與 Redis 內部是怎麼使用記憶體的。
Memcached 的部份先提了 page/slab/chunk 的架構以及產生的效能限制與浪費，接著有提到 2020 年 refactor 的部份 (太久沒有看 Memcached 的消息，去年沒跟到這個部份)，讓多 CPU 的支援度更好。
Redis 則是靠 jemalloc 來處理這個部份，另外加上 background thread 的機制降低 fragment。
然後是比較 cache expiration 的部份，可以看到兩者用的演算法在現實世界中都夠用 (尤其是當作 cache 來用)，這部份跟印象中的架構差不多，應該是沒有太大變化。
最後是比較 cluster 的部份，Memcached 是 share nothing，所以沒什麼好說的，主要是靠 client library 實做 consistent hash 之類的架構打散；而 Redis 的話看起來有實做新的機制出來 (也沒跟到)，之後有機會再看看可以做到什麼程度。
不過好像沒提到 proxy 之類的架構，基本上各大公司都有自己幹：
少了這塊對於 cluster 架構的完整性差蠻多的。
文章最後沒有下定論一定要用哪個比較好，兩者都有強項與弱項，還是得看情況來處理。不過我自己還是很喜歡用 Memcached 就是了...
Related
Distributed Key-Value Database
這篇是因為在 PIXNET 內講了 n 次，決定寫成文字，至少之後新人進來可以說「就看這篇」，避免整套系統都需要重新講一次。 對了，補充一下，PIXNET 還是有缺人，參考「缺人找人」這篇的內容，如果有想問的細節，可以寫信問我。 資料庫 在 RDBMS 提供了很多而且很豐富的操作方式，但當資料量愈來愈大時，會遇到單台機器的網路頻寬有限以及空間有限。這時候一定得走向多台的架構。 Replication 最容易解決的情況是「讀取的 query 比寫入的 query 多」，可以用 database replication 解決，這也是 Web 1.0 網站常見的解法之一 (另外一種常見的解法是使用靜態檔案，或是 reverse proxy cache)，同步將資料複製到多台。 Memcached 接下來會發現當 slave 過多時會造成每台記憶體內重複 cache 相同的元素，也就是說，有二十台 slave，每台都有 SELECT * FROM `user` WHERE `name` = 'gslin' 的結果其實很浪費資源。不過這個問題可以用 memcached 或是 hash selection 解決。 Sharding 在…
July 25, 2009In "Computer"
Facebook 的 mcrouter
這也不知道積了多久，九月 Facebook 的文章，最近被同事提起來才又仔細看：「Introducing mcrouter: A memcached protocol router for scaling memcached deployments」。 memcached 應該當作普通的 cache layer 來用，拿來放掉了也沒關係的資料。如果掉了會很痛的資料應該丟到 Redis 或是 MySQL 這類 persistent storage。 但有些資料介於兩者之間，掉了會讓使用者用起來不太爽，但也不會死人... 於是總是想要在這上面做些改善。 Facebook 開發的 mcrouter 就可以拿來解這類問題。其中一個 scenario 是「寫的不多，但讀德很多」，寫的時候寫到所有機器上，但讀取時只挑一台： 而這個架構其實可以配合用在 memcached 的 HA 機制上。當有機器爛掉重開機變成空的 cache server 回來時可以暖機： 不過程式看起來並不好編，要先搞定 Facebook 的兩個 C++ 的套件後才能編...
October 25, 2014In "Computer"
AWS 上的 Redis 服務支援 Global Replication
AWS 上的 Redis 服務 (Amazon ElastiCache) 推出了 Global Datastore，也就是跨區同步的功能：「Now Available: Amazon ElastiCache Global Datastore for Redis」。 技術上會分成 read endpoint 與 write endpoint (在最後面的操作可以看到 $US_WEST_1_CLUSTER_READWRITE 與 $US_WEST_2_CLUSTER_READONLY)，所以算是蠻常見的 primary-secondary 架構。 不過我基本上不太愛 Redis，能用 Memcached 解決的偏好用 Memcached 解。不過如果把 Redis 當作是一種雲端服務的話，倒是還可以接受...
March 18, 2020In "AWS"
Author Gea-Suan LinPosted on October 13, 2021Categories Computer, Database, Murmuring, Network, Service, SoftwareTags cache, cluster, data, jemallc, key, memcached, memory, redis, server, software, structure, value Leave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK