本文介绍 OceanBase 在架构中各个部分请求分发的设计所起到的作用。
OceanBase 在使用架构上应该如何设计来保证正确的使用其高可用性？
在各类部署中，应用接入 OceanBase 在负载均衡、主备场景、JDBC URL、甚至用户名，都会影响到请求分发的方向和目标。这些影响在实际部署中应该怎么理解和使用，需要注意什么细节？
本文从一个复杂的模拟场景入手来进行说明：双应用部署、多 DNS 解析、多负载均衡、双机房、主备集群。
在这个模拟场景里从应用到数据库最终可以在四个层面实现数据的访问路由，他们分别是：
- 应用侧分发
- DNS 侧分发
- 负载均衡负载分发
- OBProxy 分发
在这个场景中，每条链路无论实线虚线都是可以独立的，也就是整个请求链路单一同一应用可以有 2 \times 2\times 2\times 2=16 条，而如果应用 A 和应用 B 实际上是同一应用的两个部署实例的话，则整个链路有 2 \times 2 \times 2 \times 2 \times 2=32 条可能性。
应用侧分发
应用侧分发主要通过 JDBC URL 中的参数配置来决定。
应用侧分发是通过 JDBC URL 进行控制，在 OceanBase 数据库 JDBC V2.2.9 之后提供相关支持。此方法称为 JDBC loadbalance 模式，使用方法是在 JDBC URL 中增加 jdbc:oceanbase:loadbalance 来启用，同时通过 URL 中不同的 IP (或域名)列表进行负载均衡。目前支持的 loadBalanceStrategy 分发策略有 random 默认、serverAffinity 加权随机，其中也可以通过 serverAffinityOrder 设置不同的加权随机分布。
示例如下：
jdbc:oceanbase:loadbalance//xxx.xxx.xxx.1:2883,xxx.xxx.xxx.2:2883/dbname?loadBalanceStrategy=serverAffinity&serverAffinityOrder=xxx.xxx.xxx.1:5,xxx.xxx.xxx.2:10
在这个配置中 IP 列表有两个，实际支持可以多个，JDBC 按照配置信息中的 IP 和端口进行请求分发，其中重要的部分拆分如下。
jdbc:oceanbase:loadbalanceloadbalance必须启用。IP_1:port,IP_2:port 这里是
xxx.xxx.xxx.1:2883,xxx.xxx.xxx.2:2883，IP 和端口的列表，也可以写成域名方式。loadBalanceStrategy 指定分发策略，这里使用的是 serverAffinity，也就是加权随机的模式，而具体分发的权重通过以下配置指定。
serverAffinityOrder 指定分发权重，只有在
loadBalanceStrategy=serverAffinity有效，权重设置在 IP 地址冒号后的数字上，数字越大分发几率越高xxx.xxx.xxx.1:5,xxx.xxx.xxx.2:10。
DNS 侧分发
DNS 侧分发控制主要取决于应用访问 OceanBase 入口的机器的 DNS 解析。主要阐述几个结论：
不同的应用在域名解析指向的 DNS 可以是相同的 DNS 服务器，也可以不同。
相同：比如，单应用或者多应用访问均为同一个 DNS 服务器。
不同：比如，云内可用区域的情况，各个可用区域拥有各自的 DNS 服务器。
DNS 解析本身也可以进行请求分发。
DNS 配置了多个 A 记录，每次域名解析请求都会根据对应的负载均衡算法计算出一个不同的 IP 地址并返回。
简单来说，无论何种方式。不同的域名，不同的 DNS 解析，DNS 自身的分发都可以最终实现 DNS 侧请求的分发。
负载均衡负载分发
负载均衡本身就是针对请求分发的技术，目前技术上软件、硬件实现均有。主要阐述几个方面的信息：
分发决定要素
首先，确保所选择的服务器列表能够对请求做出响应 （需要探测后端可用性）。
然后根据预先配置的规则从健康服务器池（healthy pool）中进行选择。
负载均衡算法
Round Robin（轮询）：为第一个请求选择列表中的第一个服务器，然后按顺序向下移动列表直到结尾，然后循环。
Least Connections（最小连接）：优先选择连接数最少的服务器，在普遍会话较长的情况下推荐使用。
Source：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。
负载均衡本身也有主备切换机制保护负载均衡的可用性。
OBProxy 分发
OBProxy 的分发有两种，RSlist 和 ConfigURL 方式。
RSlist：通过启动参数指定的 root server list 来确定可连接 OceanBase 集群。
ConfigURL：通过 config server 查询可连接 OceanBase 集群的 root server list。
OceanBase 在分布式设计上，已经将请求的分发考虑其中，无论何种方式，最终都是 OBProxy 会根据请求的信息决定分发的目标。这个分发的要素点就是数据库的用户名，用户名可以直接设置在 JDBC URL 中，通常单独指定，举例如下。
数据源：
username: username@tenant#clustername:xxxxxx
客户端连接
obclient -hhostname -P2883 -uroot@sys#obcluster:xxxxxx -p
在这个用户名字符串中，OBProxy 起到分发判断的内容在于井号后端的信息。如果直接连接 OceanBase 数据库而不需要 OBProxy 分发，实际上是不需要这串信息的，譬如如果只是连接某台 OBServer。
obclient -hhostname -P2881 -uroot@sys -p
默认情况下，OBProxy 实际将 2883 端口接受到的请求向后方 OceanBase 数据库的 2881 端口进行请求分发。
通过 OBProxy 分发时，如果添加了集群的 ID 信息，相当于指定后端的 OceanBase 集群，而如果未指定集群 ID 信息，实际上是将请求分发的控制权交于 OBProxy，OBProxy 会根据后端主备集群的正在运行信息将请求分发至主集群。在 OceanBase 集群做诸如 switchover 甚至 failover 的情况下，proxy 会根据相关配置获取到主集群的信息和 ID，将请求分发至新的主集群中。
总结
OceanBase 业务请求分发可以发生在各个阶段，在 OceanBase 本身可控中，主要在以下两点：
JDBC URL
URL 可以通过域名指向不同的分发链路。
URL 可以通过多 IP 多域名的方式指定不同的分发目标。
OBProxy UserName
UserName 中只指定 ClusterName，说明分发只指向集群中的主集群，并随着主集群切换而切换。
UserName 中指定了 ClusterID，则无论集群是否切换，请求都只指向对应 ID 的集群。
适用版本
OceanBase 数据库所有版本（部分信息要求 OceanBase JDBC >= V2.2.9）。
