原文:http://blog.s135.com/post/329/
前言：dbcached 1.0 beta* 在 Memcached 1.2.4 的基础上编写而成，也是我的第一个开源C项目。编写 dbcached 的目的是为了最大限度的发挥 Memcached 内存缓存的优势，便捷地维护 Memcached 服务器节点哈希列表，智能地支持 Memcached 故障转移，同时保证数据的持久化存储。
dbcached
协议：New BSD License
作者：张宴
网址：http://code.google.com/p/dbcached/
dbcached 是什么?
● dbcached 是一款基于 Memcached 和 NMDB 的分布式 key-value 数据库内存缓存系统。
● dbcached = Memcached + 持久化存储管理器 + NMDB 客户端接口
● Memcached 是一款高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。
● NMDB 是一款多协议网络数据库(dbm类)管理器，它由内存缓存和磁盘存储两部分构成，使用 QDBM 或 Berkeley DB 作为后端数据库。
● QDBM 是一个管理数据库的例程库，它参照 GDBM 为了下述三点而被开发：更高的处理速度，更小的数据库文件大小，和更简单的API。QDBM 读写速度比 Berkeley DB 要快，详细速度比较见《Report of Benchmark Test》。
![[转贴]dbcached──“分布式 key-value 数据库内存缓存系统”](https://image.shishitao.com:8440/aHR0cHM6Ly93d3cuaXRkYWFuLmNvbS9nby9hSFIwY0RvdkwySnNiMmN1Y3pFek5TNWpiMjB2Y0c5emRDOHpNamt2WVhSMFlXTm9iV1Z1ZEM4eU1EQTRNREl2WkdKallXTm9aV1F1WjJsbQ%3D%3D.jpg?w=700 "[转贴]dbcached──“分布式 key-value 数据库内存缓存系统”")
Memcached 和 dbcached 在功能上一样吗?
● 兼容：Memcached 能做的，dbcached 都能做。除此之外，dbcached 还将“Memcached、持久化存储管理器、NMDB 客户端接口”在一个程序中结合起来，对任何原有 Memcached 客户端来讲，dbcached 仍旧是个 Memcached 内存对象缓存系统，但是，它的数据可以持久存储到本机或其它服务器上的 QDBM 或 Berkeley DB 数据库中。
● 性能：前端 dbcached 的并发处理能力跟 Memcached 相同；后端 NMDB 跟 Memcached 一样，采用了libevent 进行网络IO处理，拥有自己的内存缓存机制，性能不相上下。
● 写入：当“dbcached 的 Memcached 部分”接收到一个 set(add/replace/...) 请求并储存 key-value 数据到内存中后，“dbcached 持久化存储管理器”能够将 key-value 数据通过“NMDB 客户端接口”保存到 QDBM 或 Berkeley DB 数据库中。
● 速度：如果加上“-z”参数，采用 UDP 协议“只发送不接收”模式将 set(add/replace/...) 命令写入的数据传递给 NMDB 服务器端，对 Memcache 客户端写速度的影响几乎可以忽略不计。在千兆网卡、同一交换机下服务器之间的 UDP 传输丢包率微乎其微。在命中的情况下，读取数据的速度跟普通的 Memcached 无差别，速度一样快。
● 读取：当“dbcached 的 Memcached 部分”接收到一个 get(incr/decr/...) 请求后，如果“dbcached 的 Memcached 部分”查询自身的内存缓存未命中，则“dbcached 持久化存储管理器”会通过“NMDB 客户端接口”从 QDBM 或 Berkeley DB 数据库中取出数据，返回给用户，然后储存到 Memcached 内存中。如果有用户再次请求这个 key，则会直接从 Memcached 内存中返回 Value 值。
● 持久：使用 dbcached，不用担心 Memcached 服务器死机、重启而导致数据丢失。
● 变更：使用 dbcached，即使因为故障转移，添加、减少 Memcached 服务器节点而破坏了“key 信息”与对应“Memcached 服务器”的映射关系也不怕。
● 分布：dbcached 和 NMDB 既可以安装在同一台服务器上，也可以安装在不同的服务器上，多台 dbcached 服务器可以对应一台 NMDB 服务器。
● 特长：dbcached 对于“读”大于“写”的应用尤其适用。
1. dbcached
Installation (安装)
tar zxvf libevent-1.3e.tar.gz
cd libevent-1.3e/
./configure --prefix=/usr
make && make install
cd ../
wget http://dbcached.googlecode.com/files/dbcached-1.0.beta2.tar.gz
tar zxvf dbcached-1.0.beta2.tar.gz
cd dbcached-1.0.beta2/
./configure --prefix=/usr/local/dbcached --with-libevent=/usr
make && make install
cd ../
Run as a daemon (作为守护进程运行)
● -x
● -y <端口号> nmdb 服务器的TCP端口号 (默认: 26010) 支持 set/delete/... 等写命令 和 get 等读命令
● -z <端口号> nmdb 服务器的UDP端口号 (默认: 26010) 只支持 get 等都命令, 当使用 -z 参数时，将使用 UDP 协议代替 TCP 协议执行 set 操作，执行 get 操作时仍然使用 TCP 协议。强烈推荐加上 -z 参数。
● 其他参数跟 memcached 1.2.4 完全一样，就不再详细说明。
● 如果想让 dbcached 通过 NMDB 保存数据时采用 TCP 协议，去掉 -z 参数即可，例如：(除非因防火墙、NAT穿透等问题导致 UDP 协议不可用，否则不建议使用 TCP 协议)
● 如果想让 dbcached 作为普通的 Memcached 运行，去掉 -x、-y、-z 参数即可，例如：
2. QDBM & NMDB
QDBM 和 NMDB 均为原版，可以从它们的官方网站下载最新版本。
QDBM Installation (安装)
tar zxvf qdbm-1.8.77.tar.gz
cd qdbm-1.8.77/
./configure --prefix=/usr
make
make install
cd ../
NMDB Installation (安装)
tar zxvf libevent-1.3e.tar.gz
cd libevent-1.3e/
./configure --prefix=/usr
make && make install
cd ../
wget http://auriga.wearlab.de/~alb/nmdb/files/0.21/nmdb-0.21.tar.gz
tar zxvf nmdb-0.21.tar.gz
cd nmdb-0.21/
make BACKEND=qdbm ENABLE_TIPC=0 ENABLE_SCTP=0 install
cd ../
Run as a daemon (作为守护进程运行)
● -d
● -t
● -T
● -u
● -U
● -c
![[转贴]dbcached──“分布式 key-value 数据库内存缓存系统”](https://image.shishitao.com:8440/aHR0cHM6Ly93d3cuaXRkYWFuLmNvbS9pbWdzLzYvNi85LzcvNzYvZWVjZWY0NGMxODkzNTg4ODMwYjc3MWQ5OWNjZDYzMzcuanBl.jpe?w=700 "[转贴]dbcached──“分布式 key-value 数据库内存缓存系统”")
跟Memcachedb 项目有啥差异？
1、故障转移
先引用 memcached 官方网站和 PHP 手册中的两段话：
http://www.danga.com/memcached/
If a host goes down, the API re-maps that dead host's requests onto the servers that are available.
http://cn.php.net/manual/zh/function.Memcache-addServer.php
Failover may occur at any stage in any of the methods, as long as other servers are available the request the user won't notice. Any kind of socket or Memcached server level errors (except out-of-memory) may trigger the failover. Normal client errors such as adding an existing key will not trigger a failover.
再以一个例子来说明：
<?php
/* OO API */
$memcache = new Memcache;
$memcache->addServer('192.168.0.5', 11211);
$memcache->addServer('192.168.0.6', 11211);
$memcache->addServer('192.168.0.7', 11211);
$memcache->addServer('192.168.0.8', 11211);
?>
当 Memcache 客户端使用 addServer 服务器池时，是根据“crc32(key) % current_server_num”哈希算法将key哈希到不同的服务器的，PHP、C和python的客户端都是如此的算法。
Memcache 客户端的 addserver 具有故障转移机制，当 addserver 了4台 Memcached 服务器，而其中一台宕机了，那么 current_server_num 会由原先的4变成3，这时就会重新哈希了。
举个例子，假设在4台服务器都正常的情况下，key 值 aaa 被哈希到服务器 192.168.0.5 上，如果这时 192.168.0.7 宕机了，key 值 aaa 就可能就会被重新哈希到服务器 192.168.0.6 上，这时就找不到数据了。当然，假设 key 值 aaa 两次哈希的值是一样，它将仍被哈希到 192.168.0.5 上，但是不管怎样，都会导致一部分数据丢失。
Memcachedb 可以保证数据的持久化存储，但目前还没有解决 Memcache 服务器池故障转移导致的数据丢失。而 dbcached 可以，它在未命中时会请求后端的 NMDB 取回数据。在接下来的版本中，dbcached 后端的 NMDB 将设计为两台，进行互备，届时无论前端 dbcached 中的某几台挂了还是后端 NMDB 中的一台挂了，数据都不会丢失。
2、设计方向
dbcached 和 Memcachedb 的设计方向不同，dbcached 的设计方向是发挥 Memcached 的内存缓存性能优势，使之成为一个具有“故障转移”、“数据持久化存储”、“多服务器同时读写”的高并发内存缓存系统，它是围绕 Memcached 进行开发的。而 Memcachedb 只使用了 Memcached 的协议和网络层，抛弃了 Memcached 的内存管理部分，使用 Berkeley DB 数据库自身的缓存来实现，是围绕 Berkeley DB 进行开发的，目前支持类似 MySQL 主辅库同步的方式实现读写分离，支持“主服务器可读写、辅助服务器只读”模式。
QDBM 或 Berkeley DB 这样的数据库中
当客户端在Memcached 中没有知道到请求的的数据 然后到 QDBM 或 Berkeley DB 中查找
这样和直接从数据库中读取 区别很大吗
1、并发：千万级数据查询，MySQL的速度比较慢，如果并发连接达到300以上，MySQL基本上就崩溃了。就算是只有几万条数据的定长表，撑死也就能达到3000的并发连接。
2、速度：往QDBM中写入100万条记录，只需耗费1～4秒，Berkeley DB 只需3～11秒，取平均值5秒计算，每秒可以插入20万条记录，而读取速度还要稍快一点，对于千万级的数据处理性能没问题。而MySQL每秒只能插入50～1000条数据。
但是 QDBM 或 Berkeley DB 等嵌入式数据库不是关系型数据库，不能进行SQL语句查询、排序，只能根据key值写入或者读取其对应的Value信息。
master-slave模式就可以了
考虑到主从模式.写操作的时候从服务器的负载以及网络负载问题
可以在应用上做数据库的垂直分割.
memcache本来就是作为临时cache存在的.
如果修改成了持久性的数据cache层.
那么我个人还是觉得数据库用主从模式就可以解决了.
这样对应用层的要求也会比较小.
因为MEMCACHE对应用层的改动太大.要求的工作也很多.
至于千万级的数据查询.如果你把这么多数量的内容都作为key来做memcache
这个性能一样不会高到哪里去的.
memcache只有对于最最常用的东西做cache才有效的.
至于插入问题.memcache只是缓冲层
他的插入也只是临时性的
虽然memcache可以将操作速度大大提高
但是最终数据仍旧是要跑到主数据库保存的
由于木桶理论.你的这个操作再快,也无法解决整体结构中写操作的速度
如果用了事务那就更加慢了.
除非你把写操作也cache下来.然后后台再把memcache里面的内容写到mysql里面,而不是由应用层来做这个工作.否则memcache写性能在强也于事无补的.
一些拙见.大家探讨.
而QDBM、BDB是哈希数据库，BDB的最大容量支持256TB，比MySQL的SELECT要快的多。
对于“Memcache 客户端”而言，dbcached 的写操作是很快的。
普通 Memcached 接收到set请求，将数据写入内存。
dbcached 接收到set请求，将数据写入内存，并将数据通过UDP协议发送给NMDB。通过UDP协议发送给NMDB几乎不会花费多少时间，因为dbcached将数据发送出就结束会话了，它不会管NMDB是否接收到，也不会管NMDB的返回信息。NMDB接收到信息，会用队列去写QDBM数据库的，写数据库的速度慢了些也没关系，不影响用户服务。
MySQL专用于做复杂的关系查询，dbcached专用于做简单的高并发查询。
dbcached的目的就是为了避免Memcached挂掉重启后，从后端的MySQL大量读取数据。在我们的应用中，一台Memcached的并发连接最大跑到8000多，只要倒一台，这部分并发量去访问后端的MySQL服务器重新取回数据，都是无法承受的，因为我们没有这么多的MySQL服务器。
变成解决数据库的高可用性和负载均衡问题.
简言之就是数据库的虚拟化.
memcache本身只是作为cache存在
cache的目的纯粹是为了慢速设备和快速设备之间做缓冲
而持久性和可靠性并不计在内(所有的cache在掉电后都允许数据损失,而且即便cache数据不可靠.也没有关系.因为cache不是最终数据保存的地方,cache允许数据存在时差或者误差)
memcache之所以存在许多不足.
不是由于它没有持久数据或者它的可靠性不足
而是由于它并非是从数据库存取数据
需要靠应用层主动对缓冲数据进行操作.
memcache这种手动优化的方法
在程序小的时候不会有问题,一旦程序框架变大
就变成整个项目需要手动优化数据存取
解决数据库虚拟的方法在于
在应用层下面建立透明的代理层
mysqlproxy项目的概念是非常好的.
虚拟化了后端的数据库服务器之后
不论是HA,还是LB,都可以通过代理层进行透明的操作.
代理可以对执行的操作进行简单的分类,比如读,还是写,对哪个库,哪个表操作.
代理层通过分析后,可以将实际的操作交由不同的后端数据库来做.
这样不论是读写分离,还是数据库垂直,水平分割,或者高可用性.
都是通过一个透明层来进行虚拟化.
memcache只是在虚拟化途中的一个临时变通手段
如果张兄继续优化.最终可能会变成一个类似MySQL Proxy的东西
不论现在做的什么手段
最终大家需要的.应该是一个类似LVS的MYSQL虚拟机
和我猜想的用法很像.
memcache在这里其实类似于mysql的query cache
不过这样.可以完全抛弃memcache的固有做法
因为你的问题域减小了.不再是所有网页内容的cache.而是mysql select查询的cache.
而从应用层来自己做set.get.
我一直认为不是件很好的事情
分层就会逐渐模糊.
我建议dbcached做一个mysql-like的接口
将获取到的select query做hash,和hash table里面的比对
如果cache未命中,则发送到后端的mysql
cache命中,则直接返回内存中的内容
这样这个cache对于上层就是完全透明的.
感觉这个dbcached和sina的memcachedb作用差不多。
dbcached的设计的和实际的出发点有些别离，感觉有些南辕北辙
咋的不直接用QDBM了了？
dbcached 整个构架是：dbcached 这一层服务器只做缓存，后端 NMDB+QDBM 的一层为数据存储中心。这样就需要跨服务器读写QDBM，跨服务器就需要走网络协议，所以用了现成的开源工具 NMDB 去处理网络层。（其实后端用 Memcachedb 也是差不多的，以后可能会考虑支持）
目前前端的 dbcached 服务器倒了任何一台，都是没关系的，只要还有其他的 dbcached 服务器活着，在这段时间内用户的读写仍然正常，缓存中丢失的数据会请求后端的 NMDB 重新获取。
而后端的 NMDB + QDBM 目前只有一台，按照我的思路，在今后的 dbcached 版本，后端将增加到两台 NMDB + QDBM，dbcached 将接收到的set请求用UDP协议同时发送给两台 NMDB + QDBM（UDP只发送不接收，发出去就不等待了，多发一次也不影响效率），get请求未命中时先请求第一台 NMDB + QDBM，如果发现它挂了，会请求第二台 NMDB + QDBM，就有点类似本地DNS设置的主、辅服务器。
这样无论前端 dbcached 中的某几台挂了还是后端 NMDB 中的一台挂了，在这段时间内，用户的读写数据都不会受到影响。
举个例子,发一个文章,同时POST的 数据有很多,TITLE,CONTENT.DATE.等,.如果先进行DBCACHE,怎么进行保存,后端进行QDBM备份 时候,逻辑应该也会很复杂吧.
<?php
$memcache = new Memcache;
$memcache->addServer('127.0.0.1', 11211);
$title_id = "id_123";
$key['title'] = "this is title";
$key['content'] = "this is content";
$key['date'] = "2008-02-22 13:14:23";
$memcache->set($title_id, $key);
echo "<pre>";
print_r($memcache->get($title_id));
echo "</pre>";
?>
显示：
Array
(
[title] => this is title
[content] => this is content
[date] => 2008-02-22 13:14:23
)
还有一种方法就是存入多个key，取的时候可以取其中的一部分：
<?php
$memcache = new Memcache;
$memcache->addServer('127.0.0.1', 11211);
$title_id = "id_123";
$memcache->set('title_'.$title_id, 'this is title');
$memcache->set('content_'.$title_id, 'this is content');
$memcache->set('date_'.$title_id, '2008-02-22 13:14:23');
$keys = array();
$keys[]= 'title_'.$title_id;
$keys[]= 'content_'.$title_id;
echo "<pre>";
print_r($memcache->get($keys));
echo "</pre>";
?>
显示：
Array
(
[title_id_123] => this is title
[content_id_123] => this is content
)
再复杂的就要用关系型数据库了。
举个例子,发一个文章,同时POST的 数据有很多,TITLE,CONTENT.DATE.等,.如果先进行DBCACHE,怎么进行保存,后端进行QDBM备份 时候,逻辑应该也会很复杂吧.
呵呵.这个问题恰恰就是memcache的本质性的弊端了
因为他要求开发人员手动对缓冲内容进行处理.
开发人员需要预判缓冲可能发生的最高的情况.
如果实际状况和预判的不同
则命中率低下的开销会大过开发难度的提升.
而实际情况中,对于缓冲内容是会根据不同用户的不同时期的需求发生改变的.
而针对数据库的缓冲层(以下简称mysqlcache).我觉得和memcache的工作机理相同,但是还有很多本质区别.
其差别基本上等同于xcache这类的op cache和memcache这种内容cache
1.mysql缓冲层对于上层是透明的.程序员应该和操作mysql数据库一样去操作mysqlcache,而memcache则是由开发人员来决定哪些内容放入cache.上层是需要针对memcache来做操作的.
2.mysqlcache可以和其他的虚拟层一样,通过本身的策略来决定cache的保留与丢弃,这些用户只需要在配置文件内修改,同样保证了透明性,而memcache需要在应用层内决定保留哪些,丢弃哪些,如果不对已经缓冲资源进行丢弃.势必导致超出memcache服务器的内存容量,导致swap,引起性能下降.
3.mysqlcache是对整条mysql语句进行hash,而memcache是对某特定内容进行hash,memcache从某种程度来说(mysql使用过多如selecte *等未优化语句)占用内存更小
4.mysqlcache可以轻易加入负载均衡或者高可用性功能,由于其是代理层,可以对后端的mysql状态或者查询进行分发,memcache其实是和mysql平行的一个模块.是在应用层使用的缓冲技术,从理论上来说如果没有独立的mysql负载均衡或者HA措施,memcache对这两者是无能为力的.因为memcache的数据是由应用层取出并放入,而不是它本身直接去操作数据库的.
对mysql的透明代理应用感兴趣的.可以看看mysql proxy项目,不过目前还不是stable的.所以在性能以及稳定性方面还没有确切的保证.但是其可能的用途是非常好的.
1.mysql的HA.这点已经做到了
2.mysql的负载均衡.这点也完成了
3.mysql的读写分离.这点也完成了
4.mysql的数据表的纵向分割,这点我没有实验是否可行,但是理论上是可以的.我们可以通过分析获取到的查询所针对的表名,然后将不同表的查询分发至不同的mysql后端
5.mysql的数据横向分割,理论上也是可行的,但是难度很高.可以分析where子条件中来语句属于哪一段,从而分发到不同的后端.但是开销很大.我很怀疑这样做了以后.mysql proxy本身会变成瓶颈
我目前的情况是用memcache作session数据处理,后端用了mysql来做持久,如果改用dbcached有风险吗?
看了上面的讨论，又搜索了一下其他资料。希望大家能指正一下我的理解：
1，mysql proxy 并不会缓存数据，而只是分离数据，然后中转到mysql
2，dbcached 是通过用户端的请求数据临时存到比mysql更快的数据库，然后通过跨服务器读写QDBM，把数据转到mysql里面去。用户先在比mysql更快中的服务器中读缓存数据。
上面的理解是否错误？
另外问个问题。dbcached全挂掉的话，会导致数据丢失吗？
1.不支持git上的最新的nmdb,这个估计是nmdb的问题.
但是最新的nmdb已经支持tokyocabinet,如果dbcached能支持最新的nmdb,那就最好了
2.不支持memcache的过期.
不支持过期会极大的限制dbcached的应用范围
很期待支持双机的dbcached