苏小勇的blog

关于javascript和xhtml的资料

超全中文资料 http://w3school.com.cn/

api搜索(英文) http://www.gotapi.com/jsdomw3s

prototype扩展资源大全 http://www.scripteka.com/

IE下的js调试工具

IE下的css调试工具

• 几个linux集群节点的辅助管理工具
• tomcat性能监控工具 lambda probe
• 关于
• 几个不常用但很有用的javascript方法
• Groovy学习之资料篇
• PostgreSQL性能优化相关资料大全

几个不常用但很有用的javascript方法

1. javascript代码延迟执行。

我们经常可以看到这样的应用，鼠标放到tab上时切换tab内容为当前tab.但是这样就会有个问题，怎么样防止鼠标不经意划过tab时触发这个事件呢？可以通过延迟触发来避免这种情况,但是javascript中没有这样的函数。

javascript提供了一个函数 setTimeout(),可以延迟一个操作的执行，但是这个操作最终还是要执行的。我们需要的是鼠标放在tab上超过0.5s才执行某个操作，否则什么都不发生。

幸好，javascript还提供了另外一个函数，叫做clearTimeout(),于是这个问题就解决了。

 var tabId;
 var timeoutId;
 //鼠标放上时
 function tabOnMouseOver(tabid)
 {
 tabId=tabid;
 //延时500毫秒
 timeoutId=setTimeout(changeTab,500);
 }
 //鼠标移开时清除定时器
 function tabOnMouseOut()
 {
 clearTimeout(timeoutId);
 tabId=0;
 }

2. 设置下拉列表的默认值。

通常的做法是用jsp标签在页面上判断当前默认应该选中哪个value.这样不但繁琐，程序的可读性也很差。这个工作完全交给javascript去做。

// 设置下拉列表的默认值，用于设置表单初始值,表单加载结束时调用
 function setSelectDefaultValue(eleId,value)
 {
 var options=document.getElementById(eleId).options;
 for(i=0;i<options.length;i++)
 {
 if(options[i].value==value)
 {
 options[i].selected =true;
 }
 }
 }

这样，每次页面加载完之后调用这个方法set下拉列表的默认值就可以了。

3. 计算两个日期间隔。

这里要求日期的格式必须为”yyyy-MM-dd”格式。

//检查日期间隔不能大于interval天
 function checkInterval(date1,date2,interval)
 {
 //将天数转为毫秒数
 iseconds = 1000 * 3600 * 24 * interval;
 date1=Date.parse(new Date(date1.replace(/-/g,"/")));
 date2=Date.parse(new Date(date2.replace(/-/g,"/")));
 if(date2-date1)>iseconds)
 {
 alert("查询时间间隔不能超过" + interval + "天") ;
 return false;
 }
 if(date2-date1)<0)
 {
 alert("请设置正确的查询间隔，开始时间不能晚于结束时间");
 return false;
 }
 return true
 }

• 几篇有用的文章
• 关于javascript和xhtml的资料

Groovy WebSite Generator(Groovy 网站生成器)开源啦

用于生成bestunix 的程序发布在google code上，网址为 http://gwg.googlecode.com .

可以通过 svn checkout http://gwg.googlecode.com/svn/trunk/ gwg 取得最新代码。也可以在网站上下载打包好的代码。

经过两次比较大的重构(更新历史)，目前gwg的主要功能有：

1. 使用groovy根据rss生成网站首页，detail页面，分类页面，tag页面；
2. 使用google ajax api实现了站内搜索功能；
3. 页面内容中的tag链接替换为本地链接；
4. 实现了本地rss输出；
5. 实现了google sitemap；

gwg的价值在哪里：

1. 可以快速的生成自己的独立网站；
2. 只有一个配置文件需要修改；
3. 网页风格可以通过dreamweaver的模板快速更改；
4. gwg本身也是很好的groovy资料

快速启动：

1. 首先需要配置好groovy运行环境；
2. 进入gwg/src 目录，修改Config中的sourcePath和topFolder路径
3. 在命令行运行 groovy start.groovy

• 使用Groovy自动生成网站
• Groovy学习之资料篇
• 一些大型网站的架构信息
• PostgreSQL性能优化相关资料大全
• 关于javascript和xhtml的资料

sequoia中的日志

Sequoia 提供了基于log4j的日志服务。

它的日志系统允许你选择，比如：

• 哪个组件要记录日志
• 要创建哪些日志文件。
• 不同的日志级别决定日志记录的详细程度
• 不同的appender决定日志的输出形式。默认地，Sequoia 日志保存在日志文件里，同时提供屏幕输出。你可以选择其他的appender,比如发送日志到一个远程的日志服务器或者email.

你安装完之后，在Sequoia的安装目录会有一个名为log4j.properties 的配置文件。你可以在运行时通过修改这个配置文件来控制日志输出。

日志级别

你可以为每个组件指定具体的日志级别。如果日志级别为OFF ,那么这个Sequoia 组件的日志就被关掉了。

下面是5种可用的日志级别:

• DEBUG
• INFO
• WARN
• ERROR
• FATAL .

日志级别决定了记录事件的严重性级别。比如，如果日志级别为ERROR,那么只有ERROR 或 FATAL级别的事件才会被记录。

• sequoia负载均衡
• sequoia中添加和同步集群节点
• sequoia简介
• sequoia的架构
• sequoia部署模型
• sequoia中的自动故障处理
• 集群中几种session同步解决方案的比较
• 几个linux集群节点的辅助管理工具

sequoia中的自动故障处理

Sequoia 提供了完全透明的故障处理。这意味着只要保证至少有一个后端处于enable状态，客户端应用就感觉不到故障的发生。因此，客户端不需要针对集群的异常做任何处理。

下面将更详细地说明不同情况的故障处理：

处理控制器连接失败

如果一个控制器实例连接失败，Sequoia 连接器会根据预定义的规则透明地将客户端连接重新连接到另一个控制器。参考在控制器之间分配客户端连接。

如果是在一个事务内部发生故障，事务的上下文会在重新连接时自动保存。

处理控制器失败

如果一个控制器失败，这个控制器上的后端会被disable掉。现有的客户端连接也会自动的根据预定义的规则重新连接到另外一个控制器上。

正在执行的查询，按下面方法处理:

• 如果控制器在读写查询执行之前失败，那么这些读写查询会被自动恢复重新执行（甚至在事务内部也可以） 。
• 如果查询已经执行了但是尚未返回结果，这个时候控制器失败了，那么结果仍然可以得到。

当控制器无法从错误中恢复时，Sequoia 会在log目录自动生成一个名为sequoia.report的trace文件.

处理后端错误

如果后端失败了，它会从负载均衡器上自动去掉。失败操作的处理则取决于查询类型：

• 如果在读操作时后端失败，这个操作会在另外一个后端上重试。如果重试成功了，第一个后端会被disabled掉。如果在所有的后端上都失败了，那么这个查询可能有问题。.
• 如果在写操作的过程中后端失败，但是这个写操作在其他后端上执行成功，那么这个失败会被忽略。

这样，所有的失败都可以对客户端透明地处理。

• sequoia负载均衡
• sequoia中添加和同步集群节点
• sequoia简介
• sequoia中的日志
• sequoia的架构
• sequoia部署模型
• 使用Groovy自动生成网站
• 几个linux集群节点的辅助管理工具
• 集群中几种session同步解决方案的比较

sequoia中添加和同步集群节点

当一个新的后端添加到集群中时，它下面的数据库必须被初始化为跟其他活动节点下的数据库相同的状态。

在Sequoia中，当一个新的节点添加到集群中时，会用recovery log这个节点初始化为跟集群中其他节点相同的状态。这个进程不会影响到集群的其他操作，这使得Sequoia可以不停机的进行故障恢复。

Sequoia 的控制器为每个虚拟数据库保留一份recovery log,这个log记录了所有更新过虚拟数据库的查询和事务。recovery log包含下面内容：:

• 指向数据库dump的元数据，这个dump是某个时间点的数据库状态的快照 (这个数据库快照存放在文件系统中。)
• 数据库dump创建以后，所有的更新过数据库的查询和数据库的记录。

disable掉的节点自动记录recovery log

当你disable掉一个后端，比如，执行数据库维护，Sequoia 将会:

1. 自动在recovery log中插入一个checkpoint来记录它下面数据库的状态。
2. 继续记录来自客户端的请求.

当你重新enable这个后端时，系统将会播放recovery log中从指定checkpoint以后的所有来自客户端的update请求，同步它下面的数据库。

从数据库dump中恢复数据库

如果你在正在使用的集群中添加一个新的后端，或者恢复一个失败的后端，你必须先考虑一下有没有可以用来自动同步数据的数据库快照。因此，数据库并不是简单地只用recovery log就可以同步的。

在这种情况下，你必须先从一个有效的数据库dump中恢复数据库。从有效的dump文件中恢复数据库也为你想用的后端增加了一个干净的checkpoint.

注意：

你应该定期备份你的数据库，以获得一个有效的数据库dump.

数据库备份

使用备份管理器，你可以备份一个数据库来创建一个dump;或者一个表结构和特定数据库的数据作为一个dump。你可以使用这个dump来：

• 为你准备添加到集群中的后端来恢复数据, 或者
• 恢复失败的后端.

备份操作的过程是这样的:

1. 如果后端处于enable状态，那么在备份时它将会被disable掉。它下面的数据库会继续运行。
2. 在数据库备份过程中，来自客户端的请求将被记录到 recovery log.
3. 如果一个正在备份的后端被切换到enable状态，它会在备份结束后自动使用recovery log同步数据库,然后enable它自己。

警告

如果只有一个enable的后端可用，你对它执行备份操作会导致它转入disable状态。因此，整个集群在备份期间将停止服务。

你应该定时进行数据库备份以避免需要停止整个集群来备份的情况发生。

• 几个linux集群节点的辅助管理工具
• sequoia负载均衡
• 集群中几种session同步解决方案的比较
• sequoia简介
• sequoia部署模型
• sequoia中的自动故障处理
• sequoia中的日志
• sequoia的架构

sequoia负载均衡

控制器之间客户端连接的分配

当客户端程序连接虚拟服务器的时候，Sequoia 连接器使用Sequoia URL连接到控制器。Sequoia URL包含了一个所有要用到的控制器的IP列表。默认的，Sequoia 控制器监听25322 端口。

如果当前选择的控制器失败了，将会自动从Sequoia URL定义的列表中重新取一个新的出来。

新的连接，根据预定义的负载均衡策略（随机，轮询，顺序），连接到一个控制器上。所有的属于这个连接的请求都会被发送到同一个控制器，但是这个控制器会把这些请求在它下面的后端之间进行的负载均衡。

一旦连接建立，一个针对某个虚拟数据库的用户名和密码的组合，会连同数据库的名字一起被发送到控制器的验证管理器中进行检查。

在后端之间分配只读请求

在后端之间进行负载均衡，有下面几种可选方案:

• least pending requests first - 请求被发送到等待执行请求的队列最短的那个后端去，也就是等待的请求数最小的将被执行。正在等待的请求队列是一个后端负载的准确估计，因此这种方法是一种有效的动态负载均衡机制。round robin - 简单轮询的负载均衡：第一个请求发送到第一个后端，第二个请求发送到第二个后端，依此类推。不断的循环，直到请求又从第一个后端开始。
• weighted round robin - 跟轮询方法相同，但是给每个后端分配了一个权重值。这个值决定了这个后端相对于其他后端接受负载的比例。比如，一个后端的权重值为2，那么它负载的请求数是权重为1的后端的两倍。

处理Sequoia中的客户端连接上下文

客户端连接可以分为下面两种:

• 非持久化连接(non-persistent connections) - 一个非持久化连接是一个到后端的连接，这个连接是在查询时（在AUTOCOMMIT模式）或者事件持续期间分配的，然后这个连接被放回后端连接池。
• 持久化连接(persistent connections) - 客户端持续连接每个后端期间，这个连接被分配为一个专用连接。当使用一个持久化连接时，这个连接的上下文和状态都被Sequoia保存。

这两种连接都是Sequoia 分配的：如果没有连接可用，控制器会等待连接池提供可用的连接。

使用持久化连接的典型例子

这里有一些持久化连接用法的典型例子:

• 为某个单独的连接设置一个可用的环境或连接属性（通常使用SET xxx commands）
• 创建并操作一个临时表
• 要得到这个连接中前一个操作的信息（在AUTOCOMMIT 中）, 比如在MySQL中SELECT LAST_INSERT_ID.

使用持久化连接的相关问题

因为下面的原因，不推荐使用Sequoia 的持久化连接。

减低系统性能；

打开和关闭持久化连接是在集群范围内执行的，因此会降低系统性能；

会导致禁止后端或关闭数据库失败；

后端只有在所有的持久化连接都关闭后才能被disable。

每个连接的打开/关闭都会被记录到recovery log中。当一个checkpoint需要被添加到recovery log中时（比如在数据库库备份期间要disable掉后端），Sequoia 必须等当前打开的所有持久化连接都关闭完之后才能执行，因为连接的上下文不会被记录。

而且，虚拟数据库也只能在所有的后端都被disable掉之后才能关闭。所以，如果应用无限期的保持打开连接池中的连接的话，虚拟数据库将无法正常关闭。

那么在使用持久化连接时怎么防止这些情况发生呢。

上述失败可能发生如果我们这么使用Sequoia 的话：

• 在独立应用中，没有显式的使用close () 关闭连接。
• 像jboss那样的应用服务器，它们会代替应用去请求连接池。

确保你的应用显式的关闭了它们的连接。特别要检查连接池和连接重用计划。

如果你使用像Jboss那样的应用服务器。你必须配置连接池，因此没用的连接被续约并按照一定的规则关闭掉（idle-timeout 参数在虚拟数据库的配置文件中）。

注意：

使用Sequoia时，不推荐同时使用持久化连接和连接池。因此，如果你没用持久化连接，你应该把他们disable掉。

• sequoia中添加和同步集群节点
• sequoia简介
• 集群中几种session同步解决方案的比较
• sequoia的架构
• sequoia部署模型
• sequoia中的日志
• sequoia中的自动故障处理
• 几个linux集群节点的辅助管理工具

sequoia部署模型

这章讲解释你可以使用的不同的部署模型和配置。

1. 复制模型和数据分发 描述sequoia支持的不同的复制模型。
2. 控制器复制和水平扩展 解释怎么使用控制器的冗余来提高集群的高可用性和容错性。
3. 客户端如何连接sequoia, 解释不同的客户端应用如何通过sequoia中间件来访问数据库。

复制模型和数据分发

sequoia使用RAIDb的概念。

RAIDb的目标：

通过将多个廉价的数据库实例组合到一个数据库阵列，提供比单台数据库更好的性能和容错性。

隐藏分布式数据库的复杂性，提供给数据库客户端一个独立的数据库。

在RAIDb中，一个控制器在其他资源的前面。客户发送他们的请求到RAIDb控制器，这个控制器将他们分发给一组RDBMS后端。

有不同的RAIDb级别或数据分发方案可用，它提供不同的费用，性能，或者容错权衡。

全分割(RAIDb-0)

RAIDb-0 分割数据库表到一个数据库后端节点集。

• 一个表本身不能再分割了。但是不同的表可以分布在不同的后端节点上。
• RAIDb-0 需要至少两个数据库后端。
• RAIDb-0 当前只能和一个控制器配置一起使用。
• RAIDb-0 提供了一定的性能扩展，但不支持容错功能。

注意：

当前的实现不支持分布式join。也就是说如果你想在表t1和t2间进行join操作，你必须确保t1和t2在同一台机器上。

扩展性的提升取决于表的数目和各个表的负载情况：

• 如果你的数据库很大，没有单个节点有足够的容量存放整个数据库，那么RAIDb-0允许你把一个数据库分布存储到到一组节点上。
• 此外，每个数据库引擎处理一个小的数据集可以尽可能的提高缓存利用率，因为总是请求那几个表。
• RAIDb-0存储的使用率是最高的，因为没有重复的信息。
• RAIDb-0需要控制器知道那个表在哪台服务器上，以便把请求导向正确的节点。因为没有重复的表，一直一个后端会执行一个特定的请求。这些信息也可以静态配置到配置文件中，也可以从每个数据库中抓取其schema来动态构建。

全复制 (RAIDb-1)

• RAIDb-1 在一组后端上提供了一个数据库的全镜像。
• RAIDb-1 需要至少两个后端节点，但是理论上后端的数量没有上限的限制。每个后端必须有足够的空间运行整个数据库。
• RAIDb-1 允许在集群配置中使用几个控制器来为关键系统获得高可用性。

全复制

RAIDb-1的扩展能力取决于控制器广播更新所有节点的能力。如果有大量后端数据库，使用复合RAIDb可以获得更好的扩展性。

RAIDb-1提供了对读查询的加速，因为他们可以被均衡到所有后端上。另一方面，它对写操作没有加速（update,insert,delete请求），因为他们必须广播到所有节点。写操作在所有的后端并行执行。所以，在写的角度来看，RAIDb-1可能比不上一个单独的节点，但是从读的角度来看，性能会随着后端节点的增加而线性增长。

RAIDb-1有很好的容错性，因为系统即使只有一个后端可用时也可以保持工作。

不像RAIDb-0，RAIDb-1控制器不需要知道数据库的结构，因为所有的节点都有能力处理任何请求。然后，RAIDb-1提供了一个缓存，它需要数据库结构来维护缓存的一致性。

部分复制 (RAIDb-2)

RAIDb-2可以看作是RAIDb-0 和 RAIDb-1权衡下的一个中庸的解决方案。它支持调整每个数据库表的部分复制程度，以获得一个做好的读写性能。

RAIDb-2:

• 要求至少三个数据库后端；
• 要求每个数据库表在至少两个后端上可用以解决单点故障问题。
• 不要求任何一个节点可以运行整个数据库。

下面是RAIDb-2的典型应用：

没有或者只有少数几个节点运行整个数据库，一组节点各自运行这数据库的一部分。

下图中的例子显示了RAIDb-2的部分复制，数据库包含3个表：x,y,和z.第一个后端包含整个数据库，但是其他节点都只包含一个或两个表。表x 和 y有3份拷贝,表z有两份拷贝。任一节点失败，仍然可以从其他的存活节点中找到数据。

RAIDb-2对于异构数据库非常有用。一个已有的企业数据库使用商业数据库，但是要建立一个全拷贝无论是从存储上还是从增加许可的费用上来说，都太贵了。有了RAIDb-2就好办了，你可以增加几个小型开源数据库来各自运行整个数据库中的某些部分来代替整个数据库，这样也可以获得更好的容错性。在下图这个使用RAIDb-2进行部分复制的案例中，第一个后端节点可以是商业数据库，其他4个节点是小型开源数据库。

RAIDb-2容错性没有RAIDb-1好，但是它有效的改善了写操作的效率。

跟RAIDb-0类似，RAIDb-2也要求控制器知道所有数据库的结构，以便将请求定向到适当的节点。

警告：

在Sequoia中使用RAIDb-2仍然有一些限制。

当前，备份器不支持部分导出：当你要备份一个后端时，你将dump所有的表。类似的，当你restore一个后端时，你也将恢复所有的表。比如节点1有表x,y和z,你把他们全部dump了，如果你想用这个dump恢复节点2时，节点2将得到全部的表（x,y,z）.

当节点在恢复过程中，这就成问题了：recovery log记录了所有的请求（对所有表的），并且尝试去把他们重新走一遍。如果在恢复过程需要的一个表不在当前这个节点上，那么这个节点就不能被重新同步了。因此，这是个需要修复的bug，应该允许只同步当前节点上有的那些表。

另外，RAIDb-2也不支持分布式的join,跟 RAIDb-0 相同。

控制器复制和水平伸缩性

除了数据复制以外，Sequoia 还支持控制器冗余。为了防止Sequoia 控制器成为单点故障，你不惜在Sequoia 的配置中包括两个活更多的控制器节点。

注意：

在单个数据库和RAIDb-0配置中，你只能使用一个单独的控制器：这些控制不支持控制器复制。

Sequoia 包含两个可选的配置来提供水平扩展：

• 搭配控制器配置（collocated controller configuration）-同一台及其既做控制器，又做后端数据库服务器。
• 专用控制器配置（dedicated controller configuration）-控制器和后端数据库服务器被装在专门的机器上。

注意：

每个控制器必须被分配给一组特定的后端：后端坚决不能在多个控制器间共享。

搭配控制器配置适用于高可用系统：

在一个搭配控制器配置中，Sequoia被安装成两个节点的配置，两个节点都作为控制器和后端/数据库服务器。

专用服务器适用于大型生产环境

在规模较大的环境中，Sequoia 控制器安装在专用的服务器上来提升性能。

在控制器后面增加更多的后端，可以让Sequoia为更多的客户端应用请求服务。请求被后端的数据库服务器以他们各自的速度执行，但是控制器后面的服务器越多，可用的资源也就越多。

那么你系统后端需要多少台后端才合适呢？这依赖于你的应用类型：

如果你有一个读操作非常频繁的应用，那么最好在每个控制器后面都放几个后端。

另一方面，如果你的应用写操作非常频繁，那么控制器后面的后端最好稍微少一些。

注意：

写操作不能和读操作用相同的方法来衡量：

写操作需要在每个节点上按照相同的顺序同步执行。

默认的，当所有的后端都执行完这次请求后，写操作的结果会返回给客户端。（这个行为也可以在虚拟数据库的配置文件中配置：你也可以当一台后端执行完这次查询后就马上返回结果，或者当多数后端完成这次请求后返回。）所以，对于写操作来说，这意味着控制器后面增加几个后端，就要多维护几份数据库的拷贝，但它也会增加查询的处理能力。

客户端怎么连接到sequoia

你客户端应用通过Sequoia访问数据库的配置方式，取决于你所使用的客户端应用。

• Java 使用Sequoia提供的JDBC驱动直接访问
• Perl 通过DBD::JDBC Perl module 和 Sequoia JDBC驱动，或者使用Carob项目提供的ibmysequoia MySQL C API。
• C/C++ 使用Carob项目提供的ODBSequoia 驱动或者直接使用 Carob提供的C++ API
• PHP 使用Carob项目提供的ODBSequoia ODBC驱动或者MySQLi扩展和ibmysequoia MySQL C API
• .Net 使用Carob项目提供的ODBSequoia驱动

在配置你的客户端应用时，你必须提供基本的配置信息。这些信息对于所有不同的客户端应用都是一样的。这些必需的信息包括：

你的Sequoia的URL或IP，虚拟数据库的名字；

访问虚拟数据库的用户名密码。

• sequoia中添加和同步集群节点
• 集群中几种session同步解决方案的比较
• 几个linux集群节点的辅助管理工具
• sequoia负载均衡
• sequoia中的自动故障处理
• sequoia中的日志
• sequoia简介
• sequoia的架构

sequoia的架构

下面讲讲Sequoia的组件和他们各自的功能。

下面这些术语在我们下面讨论和描述Sequoia的架构时将会用到：

虚拟数据库(virtual database) 是指在该集群中载入的不同的数据库服务器上数据库实例的分发视图。

节点(node) 是指一台物理机器，它可以是一个控制器(controller)，也可以是一个数据库服务器，或者两者都是。

数据库服务器 是一个在虚拟数据库(virtual database)中运行的数据库引擎的实例。

后端(backend) 是一个Sequoia对象，用来管理一台受管的数据库服务器。

控制器(controller) 是运行在JVM中的一个Sequoia控制器(controller)实例。
Sequoia connector 连接着客户端应用和控制器(controller)。Sequoia的基本安装只包含一个用于java客户端的jdbc驱动，但是Carob项目提供了用于其他客户端应用的连接器。

Sequoia jdbc驱动

Sequoia JDBC驱动是一个type 4 JDBC驱动,它转发所有的数据库请求到Sequoia控制器(controller).

如果你正在使用Sequoia和Java客户端,那么你要用Sequoia驱动替换掉客户端原来使用的特定数据库的驱动,使客户端应用通过Sequoia驱动连接到集群.Perl客户端也可以通过DBD::JDBC Perl模块和Sequoia驱动来访问Sequoia.

Sequoia控制器(controller)

Sequoia控制器(controller)是一个Java程序,它实际上是Sequoia connector和后端(backend)之间的一个代理.控制器(controller)enable受管的一组数据库暴露给客户端应用作为一个虚拟数据库(virtual database).Sequoia控制器(controller)使用原生的数据库JDBC驱动访问数据库.

后端(backend)

后端(backend)是用来管理它下面数据库服务器的一个Sequoia对象:

后端(backend)是指一个数据库服务器实例的Sequoia视图
后端(backend)对象可以使用集群管理应用来管理.
当后端(backend)被disable时,它下面的数据库服务器的实例仍然是可操作的.比如要执行一次数据库备份操作,为了防止在备份过程中执行请求,确保数据库的一致性,这个时候就要把后端(backend)disable掉.

每个控制器(controller)对应专门的一组后端(backend):为了确保数据库的一致性,数据库在不同的控制器(controller)间不能共享.

控制器(controller)通讯协议

控制器(controller)使用一个组播协议来交换信息,维护相互之间状态信息的一致性.这种控制器(controller)之间的数据复制防止了单点故障的发生.

只有数据库update和commit/rollback命令用组播协议广播给所有节点,所有其他的命令都在控制器(controller)内本地执行.

默认的,Sequoia控制器(controller)通讯是使用Appia实现的.

虚拟数据库(virtual database)

一个虚拟数据库(virtual database)虚拟了一个独立的数据库,但是Sequoia控制器(controller)虚拟了一个关系式数据库管理系统(RDBMS).换句话来说,一个RDBMS可以支持多个数据库，那么一个控制器(controller)也就可以提供多个虚拟数据库(virtual database)。

一个虚拟数据库(virtual database)由下面几部分组成

验证管理器(authentication manager)- 在建立连接时，验证虚拟数据库(virtual database)的用户名密码和真实数据库服务器的用户名密码的映射是否正确。关于这个更多的信息，请看Sequoia 3.0安装配置指南中配置Sequoia用户名和密码一节。

请求管理器(request manager)-处理Sequoia connector转发来的客户端请求。
备份管理器(backup manager)-执行数据库备份还原操作，在控制器(controller)之间传送备份文件。
后端(backend)-后端(backend)用来管理它下面的数据库服务器。

一个虚拟数据库(virtual database)和它的组件被配置在一个特定控制器(controller)的虚拟数据库(virtual database)配置文件中。换句话说，要配置一个虚拟数据库(virtual database)，你必须有两个对应这个虚拟数据库(virtual database)特有的特定控制器(controller)的配置文件。

请求管理器(request manager)

请求管理器(request manager)包含了控制器(controller)的核心功能。当一个请求从Sequoia connector进来时，它首先被传递到这个虚拟服务器相关的请求管理器(request manager)中。

请求管理器(request manager)由下面几部分组成，在后面我们会对它们进行详细说明：

请求调度器(request scheduler)
负载均衡器(load balancer)(load balancer)
recovery log

缓存 三个可选的请求缓存：

• 元数据缓存，缓存结果集的元数据（比如列名，类型等），它通常在创建结果集时用到。
• 解析缓存，它缓存解析的结果。这种缓存尤其是对于prepared statements非常有用。
• 查询结果缓存，它缓存了只读查询的结果：这个很容易理解，如果一个查询要执行多次，那么使用这种缓存时，只会请求数据库一次，然后一直从缓存中读取。

请求调度器(request scheduler)

请求调度器(request scheduler)调度请求并确保查询精确一致。

Sequoia使用一个传递调度方法，它给每个查询分配一个唯一的标识，然后转发到负载均衡器(load balancer。这个标识在后面被用来确保写操作被以相同的顺序发送到所有的后端(backend)。

每个数据库服务器最终执行这个计划并锁定。锁定的时间依赖于数据库引擎。

负载均衡器(load balancer)(load balancer)

从请求调度器(request scheduler)出来，客户端请求就到达了负载均衡器(load balancer)。

Sequoia的负载均衡机制提高了数据库集群的整体性能。它在后端(backend)之间根据预先定义好的负载均衡方式来分配请求：用户可以选择一个最适合他们系统的方式。关于负载均衡方式的更多信息，请看 Sequoia的负载均衡 一章。

Recovery log

Recovery log是一个事件日志，它记录了那些更新虚拟数据库(virtual database)的所有请求和事件，可以用来进行数据库的恢复和同步。

备份管理器(backup manager)

备份管理器(backup manager)和recover log一起，允许动态地向虚拟数据库(virtual database)中添加新的后端(backend)而不用重启整个系统。类似的，当一个后端(backend)恢复要进行错误恢复时,你可以使用备份管理器(backup manager)和recovery log很容易的重新enable它，

Sequoia安装包含了一个通用的和几个特定的关系数据库管理系统的备份器。你也可以使用你自己的备份管理器(backup manager)代码。更详细的可以看Sequoia 3.0 安装配置指南中如何配置备份管理器(backup manager)。

• sequoia负载均衡
• sequoia中添加和同步集群节点
• 集群中几种session同步解决方案的比较
• 一些大型网站的架构信息
• 几个linux集群节点的辅助管理工具
• sequoia部署模型
• sequoia中的自动故障处理
• sequoia中的日志
• sequoia简介