连接池
本主题介绍了连接池在 Bigtable 中的工作原理、连接池大小对使用 Bigtable 的应用的影响，以及何时可能需要更改默认连接池设置。
阅读本页面后，如果您确定应该更改连接池大小，请参阅配置连接池，了解如何确定最佳大小以及如何更改大小。只有在使用 Cloud Bigtable 的 Go、C++ 或 Java 客户端库时，您才可以在代码中配置每个池的连接数。
连接池的工作原理
连接池（也称为通道池）是可共享和重复使用的数据库连接的缓存，可用于改善连接延迟和性能。连接在轮循系统中使用。
使用 Bigtable 时，您需要为每个应用进程创建一个数据客户端。每个客户端都有一个连接池。每个连接池包含一定数量的 gRPC 连接，每个 gRPC 连接最多可以处理 100 个并发流。通过这些连接发送的请求会通过 Google 中间件，然后中间件将请求路由到您的表。中间件层由许多负载均衡实例组成，每个请求都通过具有最高可用性的中间件实例进行路由。
您可以将连接（或通道）视为一条高速公路，它最多可以有 100 条车道，每个车道（流）在任意给定时刻只能有一辆汽车（请求）。Google 的中间件层中强制执行每个 gRPC 连接 100个并发流的限制，您无法重新配置此数量。
连接每小时自动刷新一次。此外，如果连接在五分钟内没有看到请求，中间件会自动删除该连接，并且直到需要其他连接时才会重新创建该连接。
在后台，每个通道都有一个子通道。每个子通道都有一个 HTTP2 连接，该连接使用 TCP 将请求转换为字节，并通过中间件发送，最后发送到表。此过程由 Bigtable 服务无缝处理，您无需进行任何配置。
连接池如何影响性能
理想情况下，您应该具有足够的 gRPC 连接来处理请求，不进行任何缓冲。但是，连接数量也不应过多，否则连接会因缺少使用而被频繁删除。
连接数量不足
如果连接池没有足够的连接来处理流量，中间件会开始缓冲请求并将请求加入队列。由于请求进行备份，这种缓冲会降低每秒请求数并增加延迟，导致流量减速。
连接数量过多
如果池中连接过多（即某些连接处于空闲状态），中间件会断开空闲连接。然后，当新请求需要连接时，这些连接会重新建立。这意味着，当流量增加时，请求可能会遇到服务器端缓存未命中的情况，从而导致额外的工作和延迟。如果这种情况由于流量水平变化而频繁发生，则此活动可能表现为客户端延迟时间激增。
何时更改默认设置
默认连接池大小适用于大多数应用，在大多数情况下无需更改。根据您在应用中使用的客户端库，您可能无法更改连接池大小。只有在使用 Cloud Bigtable 的 Go、C++ 或 Java 客户端库时，您才可以在代码中配置每个池的连接数。
一般来说，理想的连接池连接数至少是达到最大饱和量所需连接数的两倍。这可以为流量波动留出余量。例如，假设您有 4 个连接，每个连接都处理最大请求数 (100)，并且您希望将每个连接的请求数都减少到介于 10 到 50 之间，那么理想的连接池大小至少为该连接数的两倍，即至少 8 个连接。
在以下情况下，您应该考虑更改池中的连接数量：
吞吐量低并且客户端尾延迟时间激增
如果您的典型吞吐量相当低（例如每个连接每秒少于一个请求），并且您观察到应用周期性地出现高尾延迟时间，那么可能您发送的流量过少，无法使连接保持活跃状态。在这种情况下，您可能需要减少池中的连接数。请参阅配置连接池，了解如何确定正确的数量。
请求被缓冲
如果您发现请求在客户端积压，则可能表示发送的并发请求数超过了连接池的处理能力。请计算最佳数量，然后根据需要更改代码。
如需确定请求是否积压，可以使用 OpenCensus 来查看 grpc.io/client/started_rpcs 和 grpc.io/client/completed_rpcs 指标之间的差异。
虚拟环境
在极少数情况下，Bigtable 客户端无法识别应用正在运行的 CPU 数量，并按照仅使用一个 CPU 的情况分配连接。例如，当您在 Kubernetes 或 Docker 中使用虚拟 CPU 实例时，可能会发生这种情况。如果此情况很明显，您应该根据应用的 QPS 和延迟时间，按照指南配置池数量。