应用较为成熟的第三方解决方案最大的劣势就在于在节俭本身研发老本的同时，还可能在互联网下面找到较多的文档信息，帮忙咱们解决一些日常遇到的问题还是十分有帮忙的。
目前比拟风行的第三方 Cache 解决方案次要有基于对象的分布式内存 Cache 软件 Memcached 和 嵌入式数据库编程库 Berkeley DB 这两种。上面我将别离针对这两种解决方案做一个剖析和架构探讨。
一、分布式内存 Cache 软件 Memcached
置信对于很多读者敌人来说，Memcached 并不会太生疏了吧，他当初的风行水平曾经比 MySQL 并不会差太多了。Memcached 之所以如此的风行，次要是因为以下几个起因：
通信协议简略，API 接口清晰；
高效的 Cache 算法，基于 libevent 的事件处理机制，性能卓越；
面向对象的个性，对利用开发人员来说十分敌对；
所有数据都寄存于内存中，数据拜访高效；
软件开源，基于 BSD 开源协定；
对于 Memcached 自身细节，这里我就不波及太多了，毕竟这不是本文的重点。上面咱们重点看看如何通过 Memcached 来帮忙咱们你晋升数据服务（这里如果再应用数据库自身可能会不太适合了）的扩展性。
要将 Memcached 较好的整合到零碎架构中，首先要在利用零碎中让 Memcached 有一个精确的定位。是仅仅作为晋升数据服务性能的一个 Cache 工具，还是让他与 MySQL 数据库较好的交融在一起成为一个更为更为高效现实的数据服务层。
①作为晋升零碎性能的 Cache 工具
如果咱们仅仅只是零碎通过 Memcached 来晋升零碎性能，作为一个 Cache 软件，那么更多的是须要通过应用程序来保护 Memcached 中的数据与数据库中数据的同步更新。这时候的 Memcached 根本能够了解为比 MySQL 数据库更为前端的一个 Cache 层。
如果咱们将 Memcached 作为利用零碎的一个数据 Cache 服务，那么对于 MySQL 数据库来说基本上不必做任何革新，仅仅通过应用程序本人来对这个 Cache 进行保护更新。这样作最大的益处就在于能够做到齐全不必动数据库相干的架构，然而同时也会有一个弊病，那就是如果须要 Cache 的数据对象较多的时候，应用程序所须要减少的代码量就会减少很多，同时零碎复杂度以及保护老本也会直线回升。
上面是将 Memcached 用为简略的 Cache 服务层的时候的架构简图。
从图中咱们能够看到，所有数据都会写入 MySQL Master 中，包含数据第一次写入时候 的 INSERT，同时也包含对已有数据的 UPDATE 和 DELETE。不过，如果是对曾经存在的数据，则须要在 UPDATE 或者 DELETE MySQL 中数据的同时，删除 Memcached 中的数据，以此保障整体数据的一致性。而所有的读申请首先会发往 Memcached 中，如果读取到数据则间接返回，如果没有读取到数据，则再到 MySQL Slaves 中读取数据，并将读取失去的数据写入到 Memcached 中进行 Cache。
这种应用形式一般来说比拟实用于须要缓存对象类型少，而须要缓存的数据量又比拟大的环境，是一个疾速无效的齐全针对性能问题的解决方案。因为这种架构形式和 MySQL 数据库自身并没有太大关系，所以这里就不波及太多的技术细节了。
②和 MySQL 整合为数据服务层
除了将 Memcached 用作疾速晋升效率的工具之外，咱们其实还能够将之利用到进步数据服务层的扩展性方面，和咱们的数据库整合成一个整体，或者作为数据库的一个缓冲。
咱们首先看看如何将 Memcached 和 MySQL 数据库整合成一个整体来对外提供服务吧。一般来说，咱们有两种形式将 Memcached 和 MySQL 数据库整合成一个整体来对外提供数据服务。一种是间接利用 Memcached 的内存容量作为 MySQL 数据库的二级缓存，晋升 MySQL Server 的缓存大小，另一种是 通过 MySQL 的 UDF 来和 Memcached 进行数据通信，保护和更新 Memcached 中的数据，而利用端则间接通过 Memcached 来读取数据。
对于第一种形式，次要用于业务要求十分非凡，切实难以进行数据切分，而且有很难通过对应用程序进行革新利用上数据库之外的 Cache 的场景。
当然，在失常状况下是必定无奈做到这一点的，之少目前必须借助外界的力量，开源我的项目 Waffle Grid 就是咱们须要借助的内部力量。
Waffle Grid 是国外的几位 DBA 在工作之余突发奇想进去的一个点子：既然 PC Server 的低廉老本如此的吸引咱们，而其 Scale Up 的能力又很难有一个较大的冲破，何不利用上当初十分风行的 Memcached 作为冲破单台 PC Server 的内存下限呢？就在这个想法的推动下，几位小伙子启动了 Waffle Grid 这个开源我的项目，利用 MySQL 和 Memcached 双双开源的个性，联合 Memcached 通信协议简略的特点，将 Memcached 胜利实现成为 MySQL 主机的内部“二级缓存”，目前仅反对用于 Innodb 的 Buffer Pool。
Waffle Grid 的实现原理其实并不简单，他所做的事件就是当 Innodb 在本地的 Buffer Pool（咱们权且称其为 Local Buffer Pool 吧）的时候，在从磁盘数据文件读取数据之前，先通过 Memcached 的通信 API 接口尝试从 Memcached 中读取相应的缓存数据（咱们称之为 Remote Buffer 吧），只有在 Remote Buffer 中也不存在须要的数据的时候，Innodb 才会拜访磁盘文件来读取数据。而且，只有处于 Innodb Buffer pool 中的 LRU List 中的数据会被发送到 Remote Buffer Pool 中，而这些数据一旦被批改，就会 Innodb 就会将之移入 FLUSH List，Waffle Grid 同时会将进入 FLUSH List 的数据从 Remote Buffer Pool 中革除掉。所以能够说，Remote Buffer Pool 中永远不会存在 Dirty Pages，这也保障了当 Remote Buffer Pool 呈现故障的时候不会产生数据失落的问题。下图是应用 Waffle Grid 我的项目时候的架构简图：
如架构图上所示，咱们首先在 MySQL 数据库端利用 Waffle Grid Patch，通过他连与其余的 Memcached 服务器通信。为了保障网络通信的性能，MySQL 与 Memcached 之间尽可能用高带宽公有网络。
另外，这里的架构图中并没有再将数据库辨别 Master 和 Slave 了，并不是说肯定不能辨别，只是一个示意图。在理论利用过程中，大部分时候只须要在 Slave 下面利用 Waffle Grid 即可，Master 自身并不需要如此大的内存。
看了 Waffle Grid 的实现原理，可能有些读者敌人会有些疑难了。这样做不是所有须要产生物理读的 Query 的性能就会受到间接影响了吗？所有读取 Remote Buffer 的操作都须要通过网络来获取，其性能是否足够高呢？对此，我同样应用作者对 Waffle 的实测数据来接触大家的疑虑：
通过 DBT2 所失去的这组测试比照数据，在性能我想并不需要太多的担心了吧。至于 Waffle Grid 是否适宜您的利用场景，那就只能依附各位读者敌人本人进行评估了。
上面咱们再来介绍一下 Memcached 和 MySQL 的另外一种整合形式，也就是通过 MySQL 所提供的 UDF 性能，自行编写相应的程序来实现 MySQL 与 Memcached 的数据通信更新操作。
这种形式和 Waffle Grid 不一样的是 Memcached 中的数据并不齐全由 MySQL 来管制保护，而是由应用程序和 MySQL 一起来保护数据。每次应用程序从 Memcached 读取数据的时候，如果发现找不到本人须要的数据，则再转为从数据库中读取数据，而后将读取到的数据写入 Memcached 中。而 MySQL 则管制 Memcached 中数据的生效清理工作，每次数据库中有数据被更新或者被删除的时候，MySQL 则通过用户自行编写的 UDF 来调用 Memcached 的 API 来告诉 Memcached 某些数据曾经生效并删除该数据。
基于下面的实现原理，咱们能够设计出如下这样的一个数据服务层架构：
如图中所示，此架构和下面将 Memcached 齐全和 MySQL 读来到作为惯例的 Cache 服务器来比拟，最大的区别在于 Memcached 的数据变为由 MySQL 数据库来保护更新，而不是应用程序来更新。首先数据被应用程序写入 MySQL 数据库，这时候将会触发 MySQL 下面用户自行编写的相干 UDF，而后通过该 UDF 调用 Memcached 的相干通信接口，将数据写入 Memcached。而当 MySQL 中的数据被更新或者删除的时候，MySQL 中的相干 UDF 同样会更新或者删除 Memcached 中的数据。当然，咱们也能够让 MySQL 做更少一些的事件，仅仅只是遇到数据被更新或者删除的时候，通过 UDF 来删除 Memcached 中的数据，写入工作则像后面的架构一样由应用程序来作。
因为 Memcached 基于对象的数据存取，以及通过 Hash 进行数据检索的个性，所以所有存储在 Memcached 中的数据都须要咱们设定一个用于标识该数据的 Key，所有数据的存取操作都通过该 Key 来进行。也就是说，如果您并不能像 MySQL 的 Query 语句一样通过某一个（或者多个）关键字条件来读取蕴含多条数据的后果集，仅实用于通过某个惟一键来获取单条数据的数据读取形式。
二、嵌入式数据库编程库 Berkeley DB
说实话，数据库编程库这个叫法切实有些顺当，但我也切实找不到其余适合的名词来称说 Berkeley DB 了，那就权且应用网上较为通用的叫法吧。
Memcached 所实现的是内存式 Cache，如果咱们对性能的要求并没有如此之高，在估算方面也不是太富余的话，咱们还能够抉择 Berkeley DB 这样的数据库型 Cache 软件。可能很多读者敌人又会产生纳闷了，咱们应用的 MySQL 数据库，为什么还要再应用一个 Berkeley DB 这样的“数据库”呢？实际上 Berkeley DB 在之前也是 MySQL 的存储引擎之一，只不过前期不晓得是何原因（获取与商业竞争无关吧），被 MySQL 从反对的存储引擎中移除了。之所以在应用数据库的同时还应用 Berkeley DB 这样的数据库型 Cache，是因为咱们能够充分发挥出二者各自的劣势，在应用传统通用型数据库的同时，同时能够利用 Berkeley DB 高效的键值对存储形式作为高效数据检索的性能补充，以失去更好的数据服务层扩展性和更高的整体性能。
Berkeley DB 本身架构能够分为五个功能模块，五个模块的在整个零碎中绝对比拟独立，而且能够设置应用或者禁用某一个（或者几个）模块，所以可能称之为五个子系统会更为失当一些。这五个子系统及根本介绍别离如下：
数据存取
数据存取子系统次要负责最次要也是最根本的数据存与取的工作。而且 Berkeley DB 同时反对了以下四种数据的存储后果形式：Hash，B-Tree，Fixed Length 以及 Dynamic Length。实际上，这四种形式对应了四种数据文件存储的理论格局。数据存储子系统能够齐全独自应用，也是必须开启的一个子系统。
事务管理
事务管理子系统次要是针对有事务要求的数据处理服务，提供残缺的 ACID 事务属性。在开启事务管理子系统的时候，出了须要开启最根本的数据存取子系统外，还至多须要开启锁管理子系统和日志零碎来帮忙实现事务的一致性和完整性。
锁治理
锁管理系统次要就是为了保证数据的一致性而提供的共享数据管制性能。反对行级别和页级别的锁定机制，同时为事务管理子系统提供服务。
共享内存
共享内存子系统我想大家看到名称就应该根本晓得是做什么事件的了，就是用来治理保护共享 Cache 和 Buffer 的，为零碎晋升性能而提供数据缓存服务。
日志零碎
日志零碎次要服务于事务管理系统，为保障事务的一致性，Berkeley DB 也采纳先写日志再写数据的策略，个别也都是与事务管理系统同时应用同时敞开。
基于 Berkeley DB 的个性，咱们很难像应用 Memcached 那样将他和 MySQL 数据库联合的那么严密。数据的保护与更新操作次要还是须要通过应用程序来实现。www.diuxie.com 一般来说，在应用 MySQL 的同时还要应用 Berkeley DB 的次要起因就是为了晋升零碎的性能及扩展性。所以，大多数时候都次要是应用 Hash 和 B-Tree 这两种构造的数据存储格局，尤其是 Hash 格局，是应用最为宽泛的，因为这种形式也是存取效率最高的。
在应用程序中，每次手游数据申请，都先通过事后设定的 Key 到 Berkeley DB 中取查找一次，如果存在数据，则返回获得的数据，如果位检索到数据，则再次到数据库中读取。而后将读取到的数据依照事后设定的 Key，整条存入 Berkeley DB 中，再返回给客户端。而当产生数据批改的时候，应用程序在批改 MySQL 中的数据之后必须还要将 Berkeley DB 中的数据删除。当然，如果您违心，也能够间接批改 Berkeley DB 中的数据，然而这样就可能引入更多的数据一致性危险并进步零碎复杂度了。
从原理来看，应用 Berkeley DB 的形式和将 Memcached 作为纯 Cache 来应用差异不大嘛，为什么咱们不必 Memcached 来做呢？其实次要有两个起因，一个是 Memcached 是应用纯内存来存放数据的，而 Berkeley DB 则能够应用物理磁盘，两者在老本方面还是有较大差异的。另外一个起因就是 Berkeley DB 所能反对的数据存储形式除了 Memcached 所应用的 Hash 存储格局之外，同时还能够应用其余存储格局，如 B-Tree 等。
因为和 Memcached 的根本应用原理区别不大，所以这里就不再画图示意了。