memcache--定义from wiki

Memcached的

维基百科,自由的百科全书
Memcached的
Memcached.svg
开发者(S) Danga Interactive公司
初始发行 5月22日,2003
 
稳定版本
1.5.1 / 2017年8月24日29天以前[1]
知识库 GitHub的.COM / memcached的/分布式缓存
写在 C
操作系统 跨平台
类型 分布式内存缓存系统
执照 订正BSD许可证[2]
网站 WWW .memcached .ORG

Memcached的(发音:MEM-现金DEE)是一个通用分布式内存缓存系统。它经常被用于加速动态数据库通过高速缓存数据和驱动的网站的对象RAM来减少次数的外部数据源(例如数据库或API)的数目必须被读出。Memcached是自由和开放源码软件,在许可修订BSD许可证[2]的Memcached运行在类似Unix的操作系统(至少的LinuxOS X)和微软视窗这取决于libevent的图书馆。

Memcached的的的API提供了一个非常大的哈希表在多台机器分布。当表满时,后续插入导致较旧的数据被清除在最近最少使用(LRU)的顺序。[3] [4]使用通常的Memcached回落上较慢的后备存储,例如数据库之前层请求和添加到RAM中的应用。

历史编辑]

Memcached的最早是由开发布拉德·菲兹派翠克为他的网站的LiveJournal,于2003年5月22日,[5] [6]它最初是写在Perl中,后来在改写Ç阿纳托利·沃罗贝,然后通过LiveJournal的使用。[7] Memcached是现在所使用的许多其他系统,包括YouTube的[8] 书签交易[9] 的Facebook[10] [11] 的Twitter[12]维基百科[13] 谷歌应用程序引擎微软AzureIBM Bluemix亚马逊网络服务还通过API提供了一个Memcached的服务。[14] [15] [16] [17]

软件架构编辑]

该系统采用了客户端-服务器架构。服务器保持一个键-值关联阵列 ; 客户端填充这个数组,并重点对其进行查询。键是高达250个字节长和值可以是在1 兆字节的大小。

客户端使用客户端库联系哪个默认情况下,在公开其服务的服务器端口 11211. TCP和UDP的支持。每个客户端都知道所有服务器; 服务器不互相通信。如果客户希望设置或读取对应于某个键的值,客户端的库首先计算一个哈希值的关键,以确定使用哪个服务器。这给出了一个简单的形式,分片和可扩展的无共享架构跨越服务器。服务器计算密钥的第二散列,以确定在哪里存储或读取的相应值。这些服务器保持RAM中的数据; 如果服务器用完的RAM,它放弃最旧的值。因此,客户端必须将Memcached的一个短暂缓存; 他们不能假设存储在Memcached中的数据仍然存在,当他们需要它。其它数据库,如MemcacheDBCouchbase服务器,提供永久存储,同时保持Memcached的协议兼容性。

如果所有的客户端库使用相同的哈希算法来确定服务器,然后客户端可以读取对方的缓存数据。

一个典型的部署有多个服务器和许多客户。但是,可以使用Memcached的一台计算机上,同时作为客户端和服务器。其哈希表的大小往往是非常大的。它的服务器在数据中心集群中被限制为可用的存储器跨所有服务器。当高容量,广受众Web发布需要它,这可能会延伸到数千兆字节。分布式缓存可以是用于情况同样有价值的,其中任一请求的内容的数目高时,或生成的特定内容的成本是高的。

安全编辑]

Memcached的大多数部署是信任的网络,在这里客户可以自由连接到任何服务器内。然而,有时Memcached是部署在不安全的网络上或者在管理员想要被连接客户端进行控制。为此Memcached的还可选配编译SASL认证支持。的SASL支持需要二进制协议。

在一个演示文稿的BlackHat USA 2010透露,一些大型公共网站已经离开Memcached的公开查阅,分析,检索,修改数据。[18]

即使在受信任的组织,分布式缓存的扁平信任模型可能存在安全隐患。为了有效地简化,所有的Memcached操作都一视同仁。客户端与该高速缓存获得进入内获得低安全性条目的有效需求在缓存中的条目,即使这些都是更高的安全性和客户对他们没有正当需要。如果缓存密钥可以预测,猜到或者通过详尽的检索发现,其高速缓存项可以被检索。

一些试图分离设置,并读取数据可能在情况下进行,如高体积网络发布。朝外的内容服务器的一个农场已经阅读访问包含发布的网页或页面组件的memcached,但没有写访问。当新的内容发布(且尚未在分布式缓存),请求将被发送到不公开访问创建内容单元和它添加到memcached的内容生成服务器。然后,内容服务器重试检索并向外服务于它。

示例代码编辑]

请注意,此页面上描述的所有功能都是伪代码而已。Memcached的调用和编程语言可能会因所使用的API。

转换数据库或对象创建查询使用Memcached是简单的。通常,使用直数据库查询时,示例代码将如下所示:

 功能 get_foo INT  用户ID 
     数据 =  db_select “SELECT * FROM用户其中userid =?”  用户ID 
     返回 数据

转换到Memcached的后,同样的通话可能看起来像以下

 功能 get_foo INT  用户ID 
     / *先试缓存* / 
     数据 =  memcached_fetch “userrow:”  +  用户ID 
     ,如果 没有 数据
         / *未找到:请求数据库* / 
         数据 =  db_select “SELECT * FROM用户其中userid =? “  用户ID 
         / *然后在高速缓存中保存,直到下一次获取* / 
         memcached_add ”userrow:“  +  用户ID  数据

     返回 数据

该客户端将首先检查与独特的键Memcached的值是否“userrow:用户ID”的存在,其中userid是一些数字。如果结果不存在,它会从数据库中像往常一样选择,并使用Memcached的API添加函数调用设置的唯一关键。

但是,如果只有这个API调用进行了修改,服务器会结束后的任何数据库更新操作获取不正确的数据:数据的Memcached的“意见”将成为过时。因此,除了创造一个“添加”号召,也将使用Memcached的设定功能需要更新电话。

 功能 update_foo INT  用户标识  dbUpdateString 
     / *第一更新数据库* / 
     结果 =  db_execute dbUpdateString 
     如果 结果
         / *数据库更新成功:取的数据被存储在高速缓存* / 
         数据 =  db_select “SELECT * FROM用户WHERE用户标识?=”  用户ID 
         / *上一行还可能看起来像数据= createDataFromDBString(dbUpdateString)* / 
         / *然后在高速缓存中保存,直到下一次获取* / 
         memcached_set “userrow:”  +  用户ID 数据

此调用将更新当前缓存的数据到数据库匹配新的数据,假设数据库查询成功。另一种方法是用无效Memcached的删除功能的高速缓存,从而使后续提取导致缓存未命中。类似的行动将需要采取当数据库记录被删除,维持无论是正确的或不完整的高速缓存。

另一种缓存失效策略是存储在一个商定的高速缓存条目的随机数,并把这个数字成用于存储特定类型条目的所有键。无效的,一旦所有这样的条目,修改随机数。现有条目(这是使用旧号码存储)将不再被引用,因此最终将过期或回收。

  功能 store_xyz_entry INT   字符串 
      / *检索随机数-如果还没有存在使用零。
      *此处使用的键名是任意的。* /  
      种子 =  memcached_fetch “:xyz_seed:” 
      ,如果 没有 种子
          种子 =  0 
      / *建立用于存储条目,并将其存储的关键。
      *此处使用的键名也是任意的。请注意,该“种子”和用户的“钥匙” 
      *被存储为所构造的hashKey串的独立的部分:“:xyz_data:(种子):(密钥)”。
      *这是不是强制性的,但建议。* /
       hashKey  =  sprintf的“:xyz_data数:%d:%d个”  种子 
      memcached_set hashKey  

  / *“fetch_entry,”未示出,如下相同逻辑于上述。* /

  功能 invalidate_xyz_cache ()
      existing_seed  =  memcached_fetch “:xyz_seed:” 
      / *硬币不同的随机种子* / 
      
          种子 =  兰特() 
      直到 种子 !=  existing_seed 
      / *现在将其存储在商定的地点。将来所有的请求都将使用这个号码。
      *因此,所有现有条目成为未提及,最终将到期。* / 
      memcached_set “:xyz_seed:”  种子

使用编辑]

另请参见编辑]

posted @ 2017-09-19 17:39  孙中明  阅读(174)  评论(0编辑  收藏  举报