1 FE高可用实践
对于 EMR Serverless StarRocks实例，可以在创建的时候选择高可用
创建完成后，直接访问对应的内网地址，即可直接访问到开启负载均衡的PLB。此时loadbalancer会根据后面的FE情况，进行轮询连接并实现高可用。
1.1 通过代码均衡负载
您可以在应用层代码进行重试和负载均衡 (Load Balance)。当特定连接宕机，代码应控制系统自动在其他连接上进行重试。使用该方式，您需要配置多个 StarRocks 前端节点地址。
1.2 通过 JDBC Connector 均衡负载
如果您使用 MySQL JDBC Connector 连接 StarRocks，可以通过 JDBC 的自动重试机制进行重试和负载均衡。
jdbc:mysql:loadbalance://[host1][:port],[host2][:port][,[host3][:port]]...[/[database]][?propertyName1=propertyValue1[&propertyName2=propertyValue2]...]
2 BE高可用实践
2.1 存算一体的高可用实践
默认情况下的Starrocks集群，已经具备高可用能力。高可用通过3节点的BE进行实现。StarRocks 支持 Tablet 多副本存储（默认三个），多副本能够保证数据存储的高可靠以及服务的高可用。在三副本下，一个节点的异常不会影响服务的可用性，集群的读写服务仍然能够正常进行。增加副本数还有助于提高系统的高并发查询能力。
在 BE 节点数量发生变化时 （比如扩缩容时），StarRocks 可以自动完成节点的增减，无需停止服务。节点变化会触发 Tablet 的自动迁移。当节点增加时，一部分 Tablet 会自动均衡到新增的节点，保证数据能够在集群内分布的更加均衡；当节点减少时，待下线机器上的 Tablet 会被自动均衡到其他节点，从而自动保证数据的副本数不变。管理员能够非常容易的实现弹性伸缩，无需手工进行数据的重分布。
存算一体架构的优势在于极速的查询性能，但也存在一些局限性：
成本高：需要使用三副本保证数据可靠性；随着用户存储数据量的增加，需要不断扩容存储资源，导致计算资源浪费。
架构复杂：存算一体架构需要维护多数据副本的一致性，增加了系统的复杂度。
弹性不够：存算一体模式下，扩缩容会触发数据重新平衡，弹性体验不佳。
2.2 存算分离的高可用实践
存算分离的集群同样具备3个BE（CN）节点并进一步实现了存储层面的高可用保障。StarRocks 存算分离技术在现有存算一体架构的基础上，将计算和存储进行解耦。在存算分离新架构中，数据持久化存储在更为可靠和廉价的远程对象存储（比如 TOS）或 HDFS 上。CN 本地磁盘只用于缓存热数据来加速查询。在本地缓存命中的情况下，存算分离可以获得与存算一体架构相同的查询性能。存算分离架构下，用户可以动态增删计算节点，实现秒级的扩缩容。存算分离大大降低了数据存储成本和扩容成本，有助于实现资源隔离和计算资源的弹性伸缩。与存算一体架构类似，存算分离版本拥有同样简洁的架构，整个系统依然只有 FE 和 CN 两种服务进程，用户唯一需要额外提供的是后端对象存储。
在 v3.1 版本及更高版本中，StarRocks 存算分离集群由 FE 和 CN 组成。CN 取代了存算一体集群中的 BE。
相对存算一体架构，StarRocks 的存储计算分离架构提供以下优势：
廉价且可无缝扩展的存储。
弹性可扩展的计算能力。由于数据不存储在 CN 节点中，因此集群无需进行跨节点数据迁移或 Shuffle 即可完成扩缩容。
热数据的本地磁盘缓存，用以提高查询性能。
可选异步导入数据至对象存储，提高导入效率。