热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

在超大规模(Citus)中使用基本层对Postgres进行分片,为什么以及何时

AzureDatabaseforPostgreSQL托管服务中的超大规模选项使您能够做的一大新事情是,除了能够横向扩展Postgres之外,您现在可以在单个超大规模上对Postgr

Azure Database for PostgreSQL 托管服务中的超大规模 (Citus) 选项使您能够做的一大新事情是,除了能够横向扩展 Postgres 之外,您现在可以在单个超大规模 (Citus) 上对 Postgres 进行分片。 ) 节点。借助预览版中称为“基本层”的新超大规模 (Citus) 功能,您可以从小处着手,经济高效地开始,同时随时准备横向扩展。

借助超大规模 (Citus) 中的新基本层功能(预览版),您现在可以:



  • 以更低的价格试用 Hyperscale (Citus),起价为 0.27 美元/小时[1]

  • 在单个超大规模 (Citus) 节点上对 Postgres 进行分片,以便您的应用程序“可横向扩展”

  • 以更具成本效益的方式配置您的开发和测试环境

使用基本层,您可以使用标准超大规模 (Citus) 服务器组中所期望的所有功能。换句话说,基本层不受任何限制:使用基本层,您不必牺牲任何超大规模 (Citus) 功能。

您可以在我最近发布的关于在单个 Citus 节点上分片 Postgres 的开源博客文章中阅读支持这个新的基本层功能的 Citus 功能的所有信息,我们首先在新的和壮观的 Citus 10 开源版本中推出了该功能。

在这篇文章中,我们将介绍如何在 Azure 门户中的超大规模 (Citus) 上预配基本层。然后,如何通过在门户中添加更多节点将超大规模 (Citus) 节点从基本层扩展到标准层。

你问的标准层是什么?标准层是多节点超大规模 (Citus) 集群的新名称,用于将多节点集群与仅具有单个超大规模 (Citus) 节点的基本层区分开来。

同样在这篇文章中,我们将向您展示使用新的基本层在单个超大规模 (Citus) 节点上对 Postgres 进行分片的一些有用方法。特别是,我喜欢高性价比的角度,因为每小时 0.27 美元,您可以试用 Hyperscale (Citus) 约 8 小时,而您只需支付 2-3 美元。

图片.png


在超大规模 (Citus) 中试用基本层的“操作方法”指南

要开始在 Azure Database for PostgreSQL 托管服务中的超大规模 (Citus) 中使用基本层,一如既往,一个不错的起点是 docs.microsoft.com:



  • 使用快速入门文档:按照这些快速入门说明在超大规模 (Citus) 中配置您的基本层。

您需要配置的所有说明都在快速入门文档(上面的链接)中,用于在超大规模 (Citus) 中配置基本层。 尽管如此,我还是想通过来自 Azure 门户的屏幕截图来强调此可视化指南中的一些步骤。 从…开始:



  • 启用预览功能:截至本博文发布之日,基本层是超大规模 (Citus) 中的预览功能,因此请务必单击启用预览功能。 如果你以后阅读这篇文章,你可能不需要这一步。

图片.png

图 1:截至本博文发布之日,基本层是一项预览功能,因此请务必单击启用预览功能。

启用预览功能并进入 Azure 门户的预配工作流中的计算 + 存储屏幕后,请记住选择基本层:



  • 选择基本层:您的选择是基本层和标准层。 在这篇文章中,我们将提供基本层,每月只需 200 美元或 0.27 美元/小时。 在本文后面,我们将添加工作节点并无缝横向扩展至标准层。

图片.png

图 2:选择基本层来配置单个超大规模 (Citus) 节点,从小处着手并做好横向扩展准备。稍后在帖子中,我们还将扩展到标准层。

当您按照基本层快速入门文档配置超大规模 (Citus) 时,请务必特别注意:



  • 设置防火墙规则:在网络选项卡中,按照文档中的说明设置防火墙规则,方法是允许允许访问数据库的客户端 IP 地址。

配置可能需要几分钟时间。为您的超大规模 (Citus) 服务器组配置基本层后,您将看到“您的部署已完成屏幕”。您可以单击蓝色的“转到资源”按钮转到刚刚在 Azure 门户中创建的基本层实例。现在您已准备好按照以下步骤连接到数据库。



  • 从 Azure 门户获取连接字符串:如下图 3 所示,您可以在 Azure 门户屏幕左侧的“设置”列中找到“连接字符串”选项卡。当您单击连接字符串时,您可以看到数据库连接字符串的不同选择,以连接到超大规模 (Citus) 中新配置的基本层。

图片.png

图 3:找到我们将用于连接到超大规模 (Citus) 服务器组的“连接字符串”。

在这篇文章中,我将使用 psql(PostgreSQL 的交互式终端前端)连接到超大规模(Citus)数据库并通过创建分布式表开始对 Postgres 进行分片。 (Azure 提示:您也可以将 psql 用作 Azure Cloud Shell 的一部分!)



  • 更新连接字符串中的密码:在上面的屏幕截图中,“your_password”是连接字符串中的占位符。 您将需要更新“your_password”,以在连接字符串中使用您的实际密码。

  • 使用psql:在命令行中执行psql命令,连接数据库。

  • 开始对 Postgres 表进行分片:接下来,您可以开始在 Hyperscale (Citus) 服务器组上创建分布式表。

-- Create a table with the usual PostgreSQL syntax
CREATE TABLE users_table (user_id bigserial primary key, age int);
-- Convert the table to a distributed table
SELECT create_distributed_table('users_table', 'user_id');

Hyperscale (Citus) create_distributed_table 函数将 Postgres 表划分为 32 个分片,但您仍然可以像所有数据都在一个表中一样查询 Postgres。因为分片是常规的 Postgres 表,所以您仍然可以依赖 Postgres 关系数据库的丰富功能,例如事务、索引、数据库约束、JOIN 等等。

正如您在上面看到的,只需单击几下,我们就能够使用基本层配置超大规模 (Citus) 数据库,然后在单个超大规模 (Citus) 节点上创建分布式表。

接下来,让我们探讨一下为什么你还是要使用这个新奇的基本层的东西?在单个节点上对 Postgres 进行分片对您有何帮助?


具有基本层的单个超大规模 (Citus) 节点上的分片 Postgres,“准备好横向扩展”

分片 Postgres 长期以来一直与大规模数据相关联。事实上,当大多数人想到 Citus 如何对 Postgres 进行分片时,您可能会想象一个具有 2 或 4 个工作节点,或者可能有 20 个或 50 个甚至 100 个工作节点的超大规模 (Citus) 集群。但是随着超大规模(Citus)上基本层的引入,我们都可以以不同的方式考虑分片。

即使数据量不大,在单个超大规模 (Citus) 节点上对 Postgres 进行分片也可以带来立竿见影的好处。通过使用分布式数据模型,您可以获得:



  • 多分片查询的查询并行化

  • 要创建/维护的较小索引

  • 较小的表自动清空(并行!)

  • 更快的批量数据加载

例如,在使用 create_distributed_table 函数对上面的 users_table 进行分片后,以下 SQL 命令现在将在 Hyperscale (Citus) 分片上并行运行,这可以显着减少执行次数:

-- load data, ingestion happens in parallel across shards
INSERT INTO users_table (age)
SELECT 20 + (random() * 70)::int
FROM generate_series(0, 100000);
-- this query runs in parallel across all shards
SELECT avg(age) FROM users_table;
-- index created in parallel across all shards
CREATE INDEX user_age ON users_table (age);

当您的数据不再适合内存时(或者如果数据库服务器受 CPU 限制),那么使用超大规模 (Citus) 中的基本层,您的数据将已经被分片,您将能够轻松地将更多节点添加到集群中以保持 您的数据库性能。

换句话说,使用超大规模 (Citus) 中的基本层,您已经准备好进行横向扩展,或者我喜欢称之为“可横向扩展”。

图片.png

图 4:在具有超大规模 (Citus) 基本层的单个节点上对 Postgres 进行分片——从而从一开始就采用分布式数据模型——可以让您轻松地将 Postgres 数据库随时扩展到任何规模。我喜欢将其称为 Azure Database for PostgreSQL 中的超大规模 (Citus) 的“横向扩展就绪”。


当您需要将工作节点添加到超大规模 (Citus) 基本层时会发生什么?

当您准备好进行扩展时,可以轻松地将工作节点添加到您的超大规模 (Citus) 基础层。毕竟,您的数据模型已经是分布式的。而且您无需迁移、升级或经历任何麻烦。您只需在门户中添加更多工作节点并从基本层升级到标准层,我们将在下面一起做。

当您将工作节点添加到超大规模 (Citus) 集群时,它们上还没有数据。这是因为所有分片仍在旧节点上——在这种情况下,使用基本层,所有数据都在单个超大规模 (Citus) 节点上。因此,最初所有这些新的工作节点将什么都不做。

这就是超大规模 (Citus) 分片重新平衡功能发挥作用的地方。分片重新平衡可确保分片在集群中的所有节点上公平分布。 Citus 分片再平衡器通过将分片从一个节点移动到另一个节点来实现这一点。

在移动分片时,所有读取和写入查询都可以继续。换句话说,超大规模 (Citus) 实现了数据的在线再平衡——或者一些人称之为零停机时间的再平衡。

下面,我们将向超大规模 (Citus) 数据库集群添加新节点,并在整个集群中重新平衡分片。我们将只添加 2 个工作节点,但您可以将超大规模 (Citus) 服务器组扩展到您认为需要的任意数量的节点。



  • 转到 Azure 门户中的设置:在 Azure 门户屏幕左侧的“设置”列中查找“计算 + 存储”选项卡。

  • 选择标准层:选择标准层[2] 以配置多节点集群。

  • 添加工作节点:使用下面屏幕截图中的滑块,选择您需要的任意数量的工作节点。请记住,对于基本层,您只有一个协调器节点,而您没有任何工作节点。在这篇文章中,让我们在下面添加 2 个工作节点。

  • 这样做:单击门户屏幕底部的“保存”按钮。

图片.png

图 5:在 Azure 门户的计算 + 存储屏幕上的超大规模 (Citus) 中从基本层切换到标准层。

添加新的超大规模 (Citus) 工作节点并将基本层升级到标准层后,您就可以进行一些分片重新平衡了。



  • 您决定何时启动分片重新平衡操作:为了最大程度地控制,何时运行分片重新平衡器的选择由您决定。 添加新的工作节点时,超大规模 (Citus) 不会自动重新平衡。

  • 如果您忘记重新平衡分片怎么办? 如果您忘记重新平衡,您将有一些没有任何数据的空工作节点。 好消息是,根据下面的屏幕截图,您将在“分片重新平衡器”选项卡中看到重新平衡的建议。

图片.png

图 6:建议重新平衡时 Azure 门户的 Shard 重新平衡器屏幕截图。 在这种情况下,您可以看到 2 个新添加的工作节点(blogtest-w0 和 blogtest-w1)每个都有 0 MiB 的数据——它们是空的!

您可以使用之前使用的相同连接字符串通过 psql 连接回协调器。

正如我之前提到的,在重新平衡操作期间,所有读写查询都可以在超大规模(Citus)数据库上继续进行。 换句话说,您的生产工作负载不受分片重新平衡的影响。



  • 重新平衡分片:准备好后,使用单个命令 rebalance_table_shards 重新平衡数据。

-- move shards to new worker node(s)
SELECT rebalance_table_shards();
NOTICE: Moving shard 102008 from c.blogtest.postgres.database.azure.com:5432 to w1.blogtest.postgres.database.azure.com:5432 ...
NOTICE: Moving shard 102009 from c.blogtest.postgres.database.azure.com:5432 to w0.blogtest.postgres.database.azure.com:5432 ...
....
NOTICE: Moving shard 102028 from c.blogtest.postgres.database.azure.com:5432 to w1.blogtest.postgres.database.azure.com:5432 ...

在 Hyperscale (Citus) 中的分片重新平衡操作期间,您可以监控其进度。 为此,请按照以下步骤操作:



  • 监控分片重新平衡器:转到 Azure 门户。 在服务器组管理中打开 Shard rebalancer 页面。 您将看到正在重新平衡的消息。 您可以在此页面中关注重新平衡操作的进度。

图片.png

图 7:在重新平衡过程中,关注 Azure 门户的 Shard Rebalancer 屏幕上的重新平衡进度。

现在分片已分布在超大规模 (Citus) 集群中,您的应用程序可以使用工作节点和协调节点上的资源。但是,除了增加了应用程序可用的计算、内存和磁盘——从应用程序的角度来看,没有任何改变。

在向超大规模 (Citus) 数据库集群添加 2 个工作程序节点并在整个集群中重新平衡分片之后,您的应用程序仍在与同一个 Postgres 数据库通信。恭喜,您已经使用 Hyperscale (Citus) 无缝扩展了 Postgres 数据库!


如果您现在不需要横向扩展 Postgres,为什么要使用超大规模 (Citus) 中的基本层在单个节点上进行分片?

你可能想知道:

“如果我现在不需要横向扩展 Postgres,为什么要使用 Hyperscale (Citus)?”

好吧,如果您认为您的数据库在未来不会增长(并且您的数据库将保持小于 ~100GB),那么我们的 Azure Database for PostgreSQL 托管服务中的其他部署选项之一 - 例如单服务器或灵活的服务器——很可能很好地处理您的工作负载。但是,如果您希望您的应用程序(以及因此您的 Postgres 数据库)随着时间的推移而增长,那么答案就会与您相关。

如果您从 Hyperscale (Citus) 的小规模开始——通过在单个 Hyperscale (Citus) 节点基本层上对 Postgres 进行分片——那么随着应用程序的增长(就用户或活动或功能或数据库大小而言),您将能够轻松地添加节点并在 Hyperscale (Citus) 上使用零停机时间分片重新平衡器。向您的超大规模 (Citus) 服务器组添加更多节点将使您能够将更多数据放入内存中,拥有更高的 I/O 带宽,并为您的 Postgres 数据库提供更多的计算能力 (CPU)。换句话说,即使在应用程序增长时,您也将拥有所有方法来保持应用程序的数据库性能。


如何准备您的 Postgres 数据库以做好横向扩展准备?

您需要考虑一些事项,以使超大规模 (Citus) 可以使用新的基本层进行横向扩展。在横向扩展架构中,数据基于分片键(我们在 Citus 中称为分布列)进行分布。您选择的分片键不仅会影响数据的分布方式,还会影响您将获得什么样的查询性能得到。因此,对您的查询模式和数据模型进行一些前期思考可能会有很长的路要走。例如,对不包含分布键的 Postgres 列强制执行 UNIQUE 约束通常是不高效的(甚至是不可能的)。

如果在 Azure Database for PostgreSQL 中使用超大规模 (Citus) 中的基本层时遵循分布式数据库的数据建模最佳做法,则可以轻松横向扩展数据库。无缝扩展 Postgres 数据库的 Citus 最佳实践包括:



  • 选择正确的分配键

  • 了解超大规模 (Citus) 的不同表类型,包括参考表和分布式表

  • 调整主键/外键以包含分布键

  • 尽可能多地向查询添加分布键过滤器和连接

  • 请注意我们的 Citus 10 开源团队正在努力消除每个新的 Citus 版本中的几个跨分片 SQL 限制

如果您按照上述最佳实践构建数据库,超大规模 (Citus) 的承诺是您将能够将 Postgres 数据库扩展到一些相当大的数据库集群大小。这里的关键点是,一旦您习惯了横向扩展系统的思维方式,您就会意识到遵循数据建模最佳实践是多么容易。

图片.png

图 8:使用新的超大规模 (Citus)“基本层”功能(预览版)从小处着手,经济高效,然后如果需要,您可以通过添加更多超大规模(Citus)轻松升级到“标准层” ) 节点。


为您的开发和测试环境使用基本层

在超大规模 (Citus) 中使用基本层的另一个有趣场景是在您的开发和测试环境中。正如我之前提到的,与标准层相比,基本层没有任何限制。因此,对于许多用户而言,基本层可能是一种实用且经济高效的配置开发和测试数据库的方式。


Hyperscale (Citus) 中提供了更多预览功能

正如我之前在博客中提到的,基本层目前处于预览状态。事实上,预览中有几个超级有用的超大规模(Citus)功能,包括:



  • 基本层:仅使用协调节点而不使用工作节点运行服务器组。一种进行初始测试和开发以及处理小型生产工作负载的经济方式。

  • PostgreSQL 12 和 13:您现在可以为您的超大规模 (Citus) 服务器组选择最新的 Postgres 版本。

  • Citus 10:自动安装在运行这些预览版功能和 PostgreSQL 13 的服务器组上。

  • 列式存储:将选定表的列(而不是行)连续存储在磁盘上。支持磁盘压缩。适用于分析和数据仓库工作负载。 (您可能还会发现我们关于 Citus 10 柱状压缩的开源博客文章很有用。)

  • 只读副本(当前仅限同一区域):主服务器组发生的任何更改都会反映在其副本中,并且针对副本的查询不会对原始服务器组造成额外负载。副本是提高只读工作负载性能的有用工具。

  • Managed PgBouncer:一个连接池,允许多个客户端一次连接到服务器组,同时限制活动连接的数量。拥有入站 PgBouncer 可以满足连接请求,同时保持协调器节点平稳运行。


超大规模 (Citus) 中的基本层为新的可能性打开了大门

我们很高兴为您带来 Azure Database for PostgreSQL 上超大规模 (Citus) 中新的基本层功能(预览版!)的预览。

虽然“打开通往新可能性的大门”可能听起来很崇高,但这是真的。超大规模 (Citus) 中的基本层为您提供了一种在云中的第 0 天“准备好向外扩展”的方法。如果您的应用程序已经在单节点 Postgres 上运行,那么您现在可以采用分片数据模型,该模型允许您在未来尽可能多地扩展 Postgres 数据库。从本质上讲,随着您的应用程序增长并且您需要向外扩展,您将不会面临任何类型的数据库迁移挑战。

当您准备好试用 Citus 时,一些有用的链接和资源:



  • 入门:此入门页面由我的一位队友创建,无论您喜欢哪种学习方式:阅读、观看或做事,都有有用的资源。对于开始使用 Citus 开源以及 Azure Database for PostgreSQL 托管服务中的超大规模 (Citus) 来说,这是一个 +1。

  • Hyperscale (Citus) 的快速入门文档:这些用于在 Hyperscale (Citus) 中配置基本层的快速入门文档很有帮助。 (如果您还没有 Azure 订阅,只需先创建一个免费的 Azure 帐户。)

  • Citus 开源:查看 GitHub 上的 Citus 开源存储库以报告问题、查看源代码并了解更多信息。要试用 Citus 开源,您可以按照 GitHub README 上的安装说明进行操作,也可以下载 Citus 包在本地试用 Citus。您也可以在我的开源博客文章中找到有关在单个 Citus 节点上分片 Postgres 的所有详细信息。

  • 深入了解 Citus 内部结构:如果您想了解 Citus 如何将 Postgres 分片作为扩展的内部结构,这篇最近的博客文章是关于我的队友在卡内基梅隆大学的一次 Citus 演讲(由 CMU 团队录制)是一个很好的地方开始。

如果您对我们的 Azure Database for PostgreSQL 托管服务中的超大规模 (Citus) 选项有任何疑问,我的产品团队成员很乐意听取您的意见。您可以随时通过 AskAzureDBforPostgreSQL 的电子邮件与我们联系。或在 Twitter @AzureDBPostgres 上关注我们。我们很想知道您的想法。

脚注



  1. 在 Azure 上的美国东部区域,在协调节点上具有 2 个 vCore、8 GiB 总内存和 128 GiB 存储的超大规模 (Citus) 基本层的成本为 0.27 美元/小时或约 200 美元/月。 ↩

  2. 标准层的最小超大规模 (Citus) 协调器大小为 4 个 vCore,具有 16 GiB 内存和 512 GiB 磁盘。 因此,如果您拥有最小的基本层配置,那么切换到标准层会将您的协调器节点大小从 2 个 vCore 增加到 4 个 vCore(或者更多,如果您选择),并且从 128 GiB 存储增加到 512 GiB 存储(或者更多,如果您选择。) 如果您的协调器节点在从基本层移动到标准层时需要更改大小,则您的协调器将需要重新启动。 重新启动协调器需要短暂的停机时间。 在重新启动之前,您会看到一条警告,因此您可以确认此时停机时间正常。 如果您的基本层已经有 4 个 vCore(或 8 个 vCore)和 512 GiB 存储,您将避免重新启动。 ↩


原文标题:Sharding Postgres with Basic tier in Hyperscale (Citus), how why & when

原文作者:Onder Kalaci

原文地址:https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/sharding-postgres-with-basic-tier-in-hyperscale-citus-how-why/ba-p/2275672




推荐阅读
  • 云原生边缘计算之KubeEdge简介及功能特点
    本文介绍了云原生边缘计算中的KubeEdge系统,该系统是一个开源系统,用于将容器化应用程序编排功能扩展到Edge的主机。它基于Kubernetes构建,并为网络应用程序提供基础架构支持。同时,KubeEdge具有离线模式、基于Kubernetes的节点、群集、应用程序和设备管理、资源优化等特点。此外,KubeEdge还支持跨平台工作,在私有、公共和混合云中都可以运行。同时,KubeEdge还提供数据管理和数据分析管道引擎的支持。最后,本文还介绍了KubeEdge系统生成证书的方法。 ... [详细]
  • Linux服务器密码过期策略、登录次数限制、私钥登录等配置方法
    本文介绍了在Linux服务器上进行密码过期策略、登录次数限制、私钥登录等配置的方法。通过修改配置文件中的参数,可以设置密码的有效期、最小间隔时间、最小长度,并在密码过期前进行提示。同时还介绍了如何进行公钥登录和修改默认账户用户名的操作。详细步骤和注意事项可参考本文内容。 ... [详细]
  • 生成式对抗网络模型综述摘要生成式对抗网络模型(GAN)是基于深度学习的一种强大的生成模型,可以应用于计算机视觉、自然语言处理、半监督学习等重要领域。生成式对抗网络 ... [详细]
  • 本文介绍了Linux系统中正则表达式的基础知识,包括正则表达式的简介、字符分类、普通字符和元字符的区别,以及在学习过程中需要注意的事项。同时提醒读者要注意正则表达式与通配符的区别,并给出了使用正则表达式时的一些建议。本文适合初学者了解Linux系统中的正则表达式,并提供了学习的参考资料。 ... [详细]
  • 深度学习中的Vision Transformer (ViT)详解
    本文详细介绍了深度学习中的Vision Transformer (ViT)方法。首先介绍了相关工作和ViT的基本原理,包括图像块嵌入、可学习的嵌入、位置嵌入和Transformer编码器等。接着讨论了ViT的张量维度变化、归纳偏置与混合架构、微调及更高分辨率等方面。最后给出了实验结果和相关代码的链接。本文的研究表明,对于CV任务,直接应用纯Transformer架构于图像块序列是可行的,无需依赖于卷积网络。 ... [详细]
  • 统一知识图谱学习和建议:更好地理解用户偏好
    本文介绍了一种将知识图谱纳入推荐系统的方法,以提高推荐的准确性和可解释性。与现有方法不同的是,本方法考虑了知识图谱的不完整性,并在知识图谱中传输关系信息,以更好地理解用户的偏好。通过大量实验,验证了本方法在推荐任务和知识图谱完成任务上的优势。 ... [详细]
  • Android自定义控件绘图篇之Paint函数大汇总
    本文介绍了Android自定义控件绘图篇中的Paint函数大汇总,包括重置画笔、设置颜色、设置透明度、设置样式、设置宽度、设置抗锯齿等功能。通过学习这些函数,可以更好地掌握Paint的用法。 ... [详细]
  • 十大经典排序算法动图演示+Python实现
    本文介绍了十大经典排序算法的原理、演示和Python实现。排序算法分为内部排序和外部排序,常见的内部排序算法有插入排序、希尔排序、选择排序、冒泡排序、归并排序、快速排序、堆排序、基数排序等。文章还解释了时间复杂度和稳定性的概念,并提供了相关的名词解释。 ... [详细]
  • 深入理解Java虚拟机的并发编程与性能优化
    本文主要介绍了Java内存模型与线程的相关概念,探讨了并发编程在服务端应用中的重要性。同时,介绍了Java语言和虚拟机提供的工具,帮助开发人员处理并发方面的问题,提高程序的并发能力和性能优化。文章指出,充分利用计算机处理器的能力和协调线程之间的并发操作是提高服务端程序性能的关键。 ... [详细]
  • OpenMap教程4 – 图层概述
    本文介绍了OpenMap教程4中关于地图图层的内容,包括将ShapeLayer添加到MapBean中的方法,OpenMap支持的图层类型以及使用BufferedLayer创建图像的MapBean。此外,还介绍了Layer背景标志的作用和OMGraphicHandlerLayer的基础层类。 ... [详细]
  • Sleuth+zipkin链路追踪SpringCloud微服务的解决方案
    在庞大的微服务群中,随着业务扩展,微服务个数增多,系统调用链路复杂化。Sleuth+zipkin是解决SpringCloud微服务定位和追踪的方案。通过TraceId将不同服务调用的日志串联起来,实现请求链路跟踪。通过Feign调用和Request传递TraceId,将整个调用链路的服务日志归组合并,提供定位和追踪的功能。 ... [详细]
  • Python教学练习二Python1-12练习二一、判断季节用户输入月份,判断这个月是哪个季节?3,4,5月----春 ... [详细]
  • 颜色迁移(reinhard VS welsh)
    不要谈什么天分,运气,你需要的是一个截稿日,以及一个不交稿就能打爆你狗头的人,然后你就会被自己的才华吓到。------ ... [详细]
  • 本文讨论了在openwrt-17.01版本中,mt7628设备上初始化启动时eth0的mac地址总是随机生成的问题。每次随机生成的eth0的mac地址都会写到/sys/class/net/eth0/address目录下,而openwrt-17.01原版的SDK会根据随机生成的eth0的mac地址再生成eth0.1、eth0.2等,生成后的mac地址会保存在/etc/config/network下。 ... [详细]
  • 上图是InnoDB存储引擎的结构。1、缓冲池InnoDB存储引擎是基于磁盘存储的,并将其中的记录按照页的方式进行管理。因此可以看作是基于磁盘的数据库系统。在数据库系统中,由于CPU速度 ... [详细]
author-avatar
刘丹小宝0
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有