多个网站对比表格怎么做,网站搭建者,蛋糕网站模板,工程公司名称大全简单大气很长时间以来 GitLab.com 使用了一个单个的 PostgreSQL 数据库服务器和一个用于灾难恢复的单个复制。在 GitLab.com 最初的几年#xff0c;它工作的还是很好的#xff0c;但是随着时间的推移#xff0c;我们看到这种设置的很多问题#xff0c;例如#xff0c;数据库长久处…很长时间以来 GitLab.com 使用了一个单个的 PostgreSQL 数据库服务器和一个用于灾难恢复的单个复制。在 GitLab.com 最初的几年它工作的还是很好的但是随着时间的推移我们看到这种设置的很多问题例如数据库长久处于重压之下 CPU 使用率几乎所有时间都处于 70% 左右。在我们使用 PostgreSQL 去跟踪这些问题时使用了以下的四种技术1、优化你的应用程序代码以使查询更加高效。2、使用一个连接池去减少必需的数据库连接数量及相关的资源。3、跨多个数据库服务器去平衡负载。4、分片数据库。连接池在 PostgreSQL 中一个连接是通过启动一个操作系统进程来处理的这反过来又需要大量的资源更多的连接(及这些进程)将使用你的数据库上的更多的资源。 PostgreSQL 也在 max_connections 设置中定义了一个强制的最大连接数量。一旦达到这个限制PostgreSQL 将拒绝新的连接 比如下面的图表示的设置这里我们的客户端直接连接到 PostgreSQL这样每个客户端请求一个连接。通过连接池我们可以有多个客户端侧的连接重复使用一个 PostgreSQL 连接。例如没有连接池时我们需要 100 个 PostgreSQL 连接去处理 100 个客户端连接使用连接池后我们仅需要 10 个或者依据我们配置的 PostgreSQL 连接。这意味着我们的连接图表将变成下面看到的那样这里我们展示了一个示例四个客户端连接到 pgbouncer但不是使用了四个 PostgreSQL 连接而是仅需要两个。对于 PostgreSQL 有两个最常用的连接池pgpool 有一点特殊因为它不仅仅是连接池它有一个内置的查询缓存机制可以跨多个数据库负载均衡、管理复制等等。另一个 pgbouncer 是很简单的它就是一个连接池。数据库负载均衡数据库级的负载均衡一般是使用 PostgreSQL 的 “热备机hot-standby” 特性来实现的。 热备机是允许你去运行只读 SQL 查询的 PostgreSQL 副本与不允许运行任何 SQL 查询的普通备用机standby相反。要使用负载均衡你需要设置一个或多个热备服务器并且以某些方式去平衡这些跨主机的只读查询同时将其它操作发送到主服务器上。扩展这样的一个设置是很容易的(如果需要的话)简单地增加多个热备机以增加只读流量。这种方法的另一个好处是拥有一个更具弹性的数据库集群。即使主服务器出现问题仅使用次级服务器也可以继续处理 Web 请求当然如果这些请求最终使用主服务器你可能仍然会遇到错误。然而这种方法很难实现。例如一旦它们包含写操作事务显然需要在主服务器上运行。此外在写操作完成之后我们希望继续使用主服务器一会儿因为在使用异步复制的时候热备机服务器上可能还没有这些更改。分片分片是水平分割你的数据的行为。这意味着数据保存在特定的服务器上并且使用一个分片键检索。例如你可以按项目分片数据并且使用项目 ID 做为分片键。当你的写负载很高时分片数据库是很有用的(除了一个多主设置外均衡写操作没有其它的简单方法)或者当你有大量的数据并且你不再使用传统方式保存它也是有用的(比如你不能把它简单地全部放进一个单个磁盘中)。不幸的是设置分片数据库是一个任务量很大的过程甚至在我们使用诸如 Citus 的软件时也是这样。你不仅需要设置基础设施 (不同的复杂程序取决于是你运行在你自己的数据中心还是托管主机的解决方案)你还得需要调整你的应用程序中很大的一部分去支持分片。GitLab 的连接池对于连接池我们有两个主要的诉求1、它必须工作的很好(很显然这是必需的)。2、它必须易于在我们的 Omnibus 包中运用以便于我们的用户也可以从连接池中得到好处。用下面两步去评估这两个解决方案(pgpool 和 pgbouncer)1、执行各种技术测试(是否有效配置是否容易等等)。2、找出使用这个解决方案的其它用户的经验他们遇到了什么问题怎么去解决的等等。pgpool 是我们考察的第一个解决方案主要是因为它提供的很多特性看起来很有吸引力。我们其中的一些测试数据可以在 这里 找到。最终基于多个因素我们决定不使用 pgpool 。例如 pgpool 不支持粘连接sticky connection。 当执行一个写入并(尝试)立即显示结果时它会出现问题。想像一下创建一个工单issue并立即重定向到这个页面 没有想到会出现 HTTP 404这是因为任何用于只读查询的服务器还没有收到数据。针对这种情况的一种解决办法是使用同步复制但这会给表带来更多的其它问题而我们希望避免这些问题。另一个问题是 pgpool 的负载均衡逻辑与你的应用程序是不相干的是通过解析 SQL 查询并将它们发送到正确的服务器。因为这发生在你的应用程序之外你几乎无法控制查询运行在哪里。这实际上对某些人也可能是有好处的 因为你不需要额外的应用程序逻辑。但是它也妨碍了你在需要的情况下调整路由逻辑。由于配置选项非常多配置 pgpool 也是很困难的。或许促使我们最终决定不使用它的原因是我们从过去使用过它的那些人中得到的反馈。即使是在大多数的案例都不是很详细的情况下我们收到的反馈对 pgpool 通常都持有负面的观点。虽然出现的报怨大多数都与早期版本的 pgpool 有关但仍然让我们怀疑使用它是否是个正确的选择。结合上面描述的问题和反馈最终我们决定不使用 pgpool 而是使用 pgbouncer 。我们用 pgbouncer 执行了一套类似的测试并且对它的结果是非常满意的。它非常容易配置(而且一开始不需要很多的配置)运用相对容易仅专注于连接池(而且它真的很好)而且没有明显的负载开销(如果有的话)。也许我唯一的报怨是pgbouncer 的网站有点难以导航。使用 pgbouncer 后通过使用事务池transaction pooling我们可以将活动的 PostgreSQL 连接数从几百个降到仅 10 - 20 个。我们选择事务池是因为 Rails 数据库连接是持久的。这个设置中使用会话池session pooling不能让我们降低 PostgreSQL 连接数从而受益(如果有的话)。通过使用事务池我们可以调低 PostgreSQL 的 max_connections 的设置值从 3000 (这个特定值的原因我们也不清楚) 到 300 。这样配置的 pgbouncer 即使在尖峰时我们也仅需要 200 个连接这为我们提供了一些额外连接的空间如 psql 控制台和维护任务。对于使用事务池的负面影响方面你不能使用预处理语句因为 PREPARE 和 EXECUTE 命令也许最终在不同的连接中运行从而产生错误的结果。 幸运的是当我们禁用了预处理语句时并没有测量到任何响应时间的增加但是我们 确定 测量到在我们的数据库服务器上内存使用减少了大约 20 GB。为确保我们的 web 请求和后台作业都有可用连接我们设置了两个独立的池 一个有 150 个连接的后台进程连接池和一个有 50 个连接的 web 请求连接池。对于 web 连接需要的请求我们很少超过 20 个但是对于后台进程由于在 GitLab.com 上后台运行着大量的进程我们的尖峰值可以很容易达到 100 个连接。今天我们提供 pgbouncer 作为 GitLab EE 高可用包的一部分。对于更多的信息你可以参考 “Omnibus GitLab PostgreSQL High Availability”。整合连接池和数据库负载均衡整合连接池和数据库负载均衡可以让我们去大幅减少运行数据库集群所需要的资源和在分发到热备机上的负载。例如以前我们的主服务器 CPU 使用率一直徘徊在 70%现在它一般在 10% 到 20% 之间而我们的两台热备机服务器则大部分时间在 20% 左右CPU Percentage在这里 db3.cluster.gitlab.com 是我们的主服务器而其它的两台是我们的次级服务器。其它的负载相关的因素如平均负载、磁盘使用、内存使用也大为改善。例如主服务器现在的平均负载几乎不会超过 10而不像以前它一直徘徊在 20 左右CPU Percentage在业务繁忙期间我们的次级服务器每秒事务数在 12000 左右(大约为每分钟 740000)而主服务器每秒事务数在 6000 左右(大约每分钟 340000)Transactions Per Second可惜的是在部署 pgbouncer 和我们的数据库负载均衡器之前我们没有关于事务速率的任何数据。我们的 PostgreSQL 的最新统计数据的摘要可以在我们的 public Grafana dashboard 上找到。我们的其中一些 pgbouncer 的设置如下设置值default_pool_size100reserve_pool_size5reserve_pool_timeout3max_client_conn2048pool_modetransactionserver_idle_timeout30除了前面所说的这些外还有一些工作要作比如 部署服务发现(#2042) 持续改善如何检查次级服务器是否可用(#2866)和忽略落后于主服务器太多的次级服务器 (#2197)。值得一提的是到目前为止我们还没有任何计划将我们的负载均衡解决方案独立打包成一个你可以在 GitLab 之外使用的库相反我们的重点是为 GitLab EE 提供一个可靠的负载均衡解决方案。如果你对它感兴趣并喜欢使用数据库、改善应用程序性能、给 GitLab上增加数据库相关的特性(比如 服务发现)你一定要去查看一下我们的 招聘职位 和 数据库专家手册 去获取更多信息。
