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掉。