本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/key-value-stores/

早上看到博客Anti-RDBMS: A list of distributed key-value stores（抵制关系型数据库：分布式key-value存储列表），最近的项目中也有用到类似Key-Value的存储。

memcached是最典型的key-value型存储，估计也是使用最广泛，但是由于memcached数据存放在内存中，服务重启或者系统down机之后就会丢失，只能用来缓存非关键数据（丟了没关系，重建就可以），或者考虑memcached的持久化方案：memcachedb，不过还是建议缓存次关键数据，比如文章点击数，写入失败或者丢了数据也不是太要命。

有时候我们的数据本身就是key-value型的，比如字典数据，就两列：单词->释义，这样的数据存mysql之类的关系型数据库就有点太”重”了，大可采用key-value型的存储方案，Berkeley DB就足够用了。

一直在关注CouchDB，已经是Apache的顶极项目了，系统稳定和版本更新自然有保障一些，居于Erlang语言开发，高并发也不是问题，relication也集成在里面，分布式也很容易做到，提供HTTP Restful接口，方便调用。个人觉得最适合股票类的网站，需要实时更新股票价格，用这个简直就是就像是定制的，不知道新浪财经的同事有没有关注。

Anti-RDBMS: A list of distributed key-value stores还提到HyperTable，百度居然赞助了这个项目，实在难得，说明项目确实不错，希望百度也分配一些工程师进去，完善开发HyperTable，到那个时候平民百姓也能用到BigTable了。

今年的也准备写个key-value的项目，计划中，关键字：Python,stackless,UDP,BDB ,memcached protocol,Low mem use.

本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/10/another-way-of-sync-distributed-data-center/

通过Google Reader好友共享看到这篇文章：横向扩展（Facebook），之前看过英文原文，不过仅粗读了一下未求甚解，感谢译者的辛勤劳动。

看完全文，大意是Facebook为了解决跨地域的网络延迟问题，在东海岸新建了一个数据中心，可新的问题随之而来，MySQL数据库复制延迟、memcache缓存不同步，Facebook的工程师通过改进MySQL复制机制，在传递binlog的同时传递memcache更新指令。这样数据库同步了，memcache也更新了。

• 我将我的名字从”Jason”改为”Monkey”。
• 我将”Monkey”写入加利福尼亚的主数据库并从加利福尼亚的memcache中删除我的名字，但不包括弗吉尼亚的memcache。
• 某个人在弗吉尼亚访问了我信息。在memcache中找到了我的名字，并返回”Jason”。（注意这里，其他用户看到了过时的信息）
• 同步复制到了之后，将从数据库中我的名字更新为”Monkey”。还需要从弗吉尼亚的memcache中删除我的名字因为缓存对象出现在同步复制流中了。
• 另一个人在弗吉尼亚访问了我的信息，没有在memcache中找到我的名字，所以从从数据库读出名字，得到了”Monkey”。

关键的地方就在这里，Facebook有能力对MySQL进行改造，相信一般的公司是不敢的。其实也还有另外一种方式来实现，MySQL引入了一种叫做MySQL UDF(user defined function)的机制，有人也写了个Memcached Functions for MySQL的东东（基于libmemcached，我想应该是稳定高效吧），我们大可以在从服务器上创建触发器，这样一旦有数据更新，调用Memcached Functions for MySQL更新memcached缓存(如果写操作频繁的话，估计触发器也是瓶颈)。

文章的另一个核心是“页面路径选择”，Facebook约定了更新只在主服务器上（西海岸数据中心），东海岸的数据中心数据库服务器全部以slave形式工作，Facebook在最前端有一组负载均衡服务器，更加用户访问的URL来判断是否有写操作，如果有的话直接连接到主服务器上，如果只是页面显示则导向到从服务器上（也许是西海岸服务器），为了解决数据延迟而造成混乱的问题，Facebook在有更新的用户cookie里面加入一个标记，该标记创建后20秒内，都连主服务器（20秒足够对付延迟了吧）。

这是很有意思的一个设计，利用cookie标记用户是否更新过。但问题就是只是自己看到自己最新的数据，其他人有个20秒看到的是过时的数据。

其实是不是可以试试把标记信息放服务器端（如DNS解析部分），比如A用户更新了某些数据，在服务器端做下标记，20秒内请求到这些资源的时候走主服务器。标记大可以用bdb存储，效率就不是问题了。下面是流程：

• 我将我的名字从”Jason”改为”Monkey”。
• 我将”Monkey”写入加利福尼亚的主数据库并从加利福尼亚的memcache中删除我的名字，但不包括弗吉尼亚的memcache。
• 在服务器端标记我的名字改变了。
• 某个人访问了我信息，查出我的信息更改过，走主服务器。
• 同步复制到了之后，将从数据库中我的名字更新为”Monkey”，触发器工作，删除相应memcache缓存。
• 20秒后，负载均衡端标记失效，另一个人在弗吉尼亚访问了我的信息，没有在memcache中找到我的名字，所以从从数据库读出名字，得到了”Monkey”。

也是很折腾的一种方案，我这里没有那样的环境，所以也只是理论上的思考，有条件的可以试试看效果如何。

本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/memcached_work_with_mysql

　　这次是Fotolog的经验，传说中比Flickr更大的网站，Fotolog在21台服务器上部署了51个memcached实例，总计有254G缓存空间可用，缓存了多达175G的内容，这个数量比很多网站的数据库都要大的多，原文是A Bunch of Great Strategies for Using Memcached and MySQL Better Together，我这里还是选择性的翻译以及按照我的理解补充，感谢Todd Hoff，总能给我们一些学习的案例，从这里也能看出国外技术的开放态度，不似我们，其实就那么点小九九还藏着掖着，好了，进入正题。

一、关于memcached

　　还不知道这个？那你去面试的时候要吃亏了，赶紧去官方网站看一下http://www.danga.com/memcached/，另外google一下用法，硬盘总是太慢，把数据存在内存里面吧，如果你只有一台服务器，推荐用一下APC(Facebook在用)或者eaccelerator或者Xcache(国人开发的)，这些产品单机效果更好，如果你需要分布式的缓存方案，那么用memcached吧。

二、memcached如何与mysql并肩作战？

• 通过数据库分片来解决数据库写扩展的问题把数据库分片，部署到不同的服务器上，免得只有一个主服务器，写操作成为瓶颈以及可能有的“单点故障”，一般的数据库分片主要是按照业务来分，尽可能的拆分业务，不相干的都独立起来做成服务也好
• 前端mysql和一堆memcached服务器来应付读的问题应用程序首先从memcached中获取数据，获取不到再从数据库中获得并保存在memcached中，以前看过一篇文章说好的应用95％的数据从memcache的中获得，3％的数据从mysql的query cache中获得，剩下2％才去查表，对比一下你的应用，差距有多远？
• 通过mysql复制（master-slave）来解决读的问题
  首先mysql数据库通过master-slave读写分离，多个slave来应对应用程序读的操作。

三、为什么不用mysql的query cache？

　　我们都知道mysql有个query cache，可以缓存上次查询的结果，可实际上帮不上太多的忙，下面是mysql quety cache的不足：

• 只能有一个实例
  意味着你能存储内容的上限就是你服务器的可用内存，一台服务器能有多少内存？你又能存多少呢？
• 只要有写操作，mysql的query cache就失效
  只要数据库内容稍有改变，那怕改变的是其他行，mysql的query cache也会失效
• mysql的query cache只能缓存数据库数据行
  意味着其他内容都不行，比如数组，比如对象，而memcached理论上可以缓存任何内容，甚至文件^_^

四、Fotolog的缓存技术

• 非确定性缓存你不确定你要的数据缓存中有没有，你也不知道是不是过期了，于是你就试探性的问memcached，我要的什么什么数据你那有吗？我可不要过期的数据啊，memcached告诉你说有并且给你，你就开心了，如果没有呢，你就要从数据库或者别的地方去获取了，这是memcached典型的应用。主要应用在：

  1.复杂的数据需要多次读取，你的数据库做了分片处理，从多个数据库中获取数据并组合起来是一个非常大的开销，你大可以把这些数据取出来之后存到memcached中

  2.mysql query cache的一个好的替代方案，这样数据库其他部门改变了，只要自己没改变就没问题（注意数据库更新的问题，后面会提到）

  3.把关系或者列表缓存起来，比如某个栏目下的多篇文章列表

  4.被多个页面调用并且获取起来很慢的数据，或者是更新很慢的数据，比如文章浏览排行榜

  5.如果cache的开销超过重新获取的开销，那么不要缓存它吧

  6.标签云和自动建议(类似google sugest)

  例如：当一个用户上传一个图片，这个用户的好友页面上都要列出这张图片来，那么把它缓存起来吧。

  潜在问题：

  memcached消耗的主要是服务器内存，对CPU消耗很小，所以Fotolog把memcached部署在他们的应用服务器上（貌似我们也是这样），他们遇到了CPU搞到90％的使用率（怎么会那么高？哪出问题了吧）、内存回收（这是个大问题）等等问题。

• 状态缓存把应用服务的当前状态存在memcached中主要应用在：

  1.“昂贵”的操作，开销大的操作

  2.sessions会话，Flickr把session存在数据库中，个人感觉还是存memcached比较“便宜”些，如果memecached服务器down掉了，那么重新登录吧。

  3.记录用户在线信息(我们也是这样做的)

• 确定性缓存对于某些特定数据库的全部内容，都缓存到memcached，有一个专门的应用服务来保障你要的数据都在memcached中，其他应用服务直接从memcached中获取数据而不去取数据库，因为数据库已经全部保存到memcached中并保持同步。主要应用在：

  1.读取伸展，所有的读取都从memcached中获得，数据库没有负载

  2.”永不过期“(相对的)的数据，比如行政规划数据，变动很小吧

  3.经常调用的内容

  4.用户的认证信息

  5.用户的概要信息

  6.用户的参数设置

  7.用户当前常用的媒体文件列表，比如用户的图片

  8.用户登录，不走数据库，只走memcached（个人觉得这个不太好，登录信息还是需要持久化的，用类似BDB这样效果也不错）

  使用方式：

  1.多个专门的缓存池而不是一个大的缓存服务器，多个缓存池保障了高可用性，一个缓存实例挂掉了走其他的缓存实例，所有的缓存实例挂掉了，走数据库（估计数据库抗不住^_^）

  2.所有的缓存池都用程序来维护，比如数据库有更新时，程序自动把更新后的内容同步到多个缓存实例中

  3.服务器重启之后，缓存要比网站先启动，这就意味着当网站已经启动了，所有的缓存都可用

  4.读取的请求可以负载均衡到多个缓存实例中去，高性能，高可靠性

  潜在的问题：

  1.你需要足够多的内存来存储那么多的数据

  2.数据以行记录数据，而memcached以对象来存储数据，你的逻辑要把行列的数据转换成缓存对象

  3.要维护多个缓存实例非常麻烦,Fotolog用Java/Hibernate，他们自己写了个客户端来轮询

  4.管理多个缓存实例会增加应用程序的许多开销，但这些开销相对于多个缓存得到的好处来说算不了什么

• 主动缓存数据魔法般的出现在缓存中，当数据库中有更新的时候，缓存立马填充，更新的数据被调用的可能性更高（比如一篇新文章，看的的人当然多），是非确定性缓存的一种变形(原文是It’s non-deterministic caching with a twist.我觉得这样翻译怪怪的)。主要应用在：

  1.预填充缓存：让memcached尽可能的少调用mysql如果内容不展现的话。

  2.“预热”缓存：当你需要跨数据中心复制的时候

  使用步骤：

  1.解析数据库更新的二进制日志，发现数据库更新时对memcached也进行同样的更新

  2.执行用户自定义函数，设置触发器调用UDF更新，具体参考http://tangent.org/586/Memcached_Functions_for_MySQL.html

  3.使用BLACKHOLE策略，传说中Facebook也用mysql的Blackhole存储引擎来填充缓存，写到Blackhole的数据复制到缓存中，Facebook用这来设置数据作废以及跨国界的复制，好处是数据库的复制不走mysql，这就意味着没有二进制日志以及对CPU使用不那么多（啊？难道通过memcached存储二进制日志，然后复制到不同的数据库？有经验的同志在这个话题上可以补充。）

• 文件系统缓存把文件直接缓存在memcached中，哇，够BT的，减轻NFS的负担，估计只缓存那些过于热门的图片吧。
• 部分页面内容缓存如果页面的某些部分获取起来非常费劲，以其缓存页面的原始数据还不如把页面的部分内容直接缓存起来直接调用
• 应用程序级别的复制通过API来更新缓存，API的执行细节如下：1.一个应用把数据写到某个缓存实例，这个缓存实例把内容复制到其他缓存实例（memcached同步）

  2.自动获得缓存池地址以及实例个数

  3.同时对多个缓存实例更新

  4.如果某个缓存实例down掉了，跳到下一个实例，直到更新成功

  整个过程非常高效以及低开销

• 其他技巧1.多节点以应对”单点故障”2.使用热备技术，当某个节点down掉了，另外一台服务自动替换成它的IP，这样客户端不用更新memcached的IP地址

  3.memcached可以通过TCP/UDP访问，持续连接可以减轻负载，系统设计成可同时承受1000个连接

  4.不同的应用服务，不同的缓存服务器群

  5.检查一下你的数据大小是否匹配你分配的缓存，更多请参考http://download.tangent.org/talks/Memcached%20Study.pdf

  6.不要考虑数据行缓存，缓存复杂的对象

  7.不要在你的数据库服务器上跑memcached，两个都是吃内存的怪兽

  8.不要被TCP延迟困扰，本地的TCP/IP对内存复制是做了优化的

  9.尽可能的并行处理数据

  10.并不是所有的memcached的客户端都是一样的，仔细研究你用的语言所对应的（好像php和memcached配合的不错）

  11.尽可能的是数据过期而不是使数据无效，memcached可以设定过期时间

  12.选择一个好的缓存标识key，比如更新的时候加上版本号

  13.把版本号存储在memcached中

　　作者最后的感言我就不翻译了，貌似mysql proxy正在做一个项目，自动同步mysql以及memcached，更多参考http://jan.kneschke.de/2008/5/18/mysql-proxy-replicating-into-memcache

　　后记：前几天，把Flickr架构(一)这篇文章发在PHPChina那的原创板块，居然被管理员当成软文给删掉了，难道就因为我保留了版权信息？匪夷所思。