问题标签 [horizontal-scaling]

我最近被迫将我的应用程序转移到亚马逊并使用自动扩展，我偶然发现了一个与 cron 作业和自动扩展有关的问题。

我有一个每 15 分钟运行一次的 cron 作业，它检查是否应该对订阅收费，查询选择所有过期的订阅，并尝试对其收费。处理后会改变它们的状态，但是它们是分批提取的，这个过程需要 1-3 分钟。

如果我有多个具有相同 cron 作业的实例，它可能会同时触发并多次收取订阅费用。这实际上已经发生过一次。

这里最好的方法是什么？不知何故锁定表或？

我正在使用 Amazon elastic beanstalk 和 symfony3。

我们的数据库主要是读取，但我们想在我们的视频中添加“观看次数”和“点赞/点赞”。

当我们在 mysql 中对增量视图进行压力测试时，我们的数据库开始死锁。

我正在考虑通过拥有一个保存视图计数的 redis 数据库来处理这个问题，并且只有在密钥过期后才写入数据库。但是，我听说通知不一致，我不想丢失视图数据。

有没有更好的方法来解决这个问题？或者redis通知不一致的说法不是真的。

谢谢，

萨米

我正在创建博客应用程序，所有用户都可以在帖子下发表评论。

博客已经注册了可以评论的用户，并且评论将显示在他们的个人资料中定义的姓名，但客人也应该有评论的能力，唯一的区别是如果用户未登录，我会显示名字、姓氏和电子邮件的 3 个输入，这必须填写。

所以在 db 我有表users和comments. comments表具有表的外键，users以及 3 列firstname和。lastnameemail

当用户登录并写评论时，我正在保存用户的评论，其中包含来自他/她帐户的用户名、姓氏和电子邮件以及用户外键，但是当他/她是客人时，我正在横向保存他的名字、姓氏和电子邮件在comments表中。

我想知道，我应该只保存外键吗？或者将我已经在评论中水平放置的用户名、姓氏和电子邮件与我已经拥有的数据的用户 ID 一起保存是不错的方法？

根据Heroku 文档，当会话亲和性打开并且 Dynos（节点）的数量增加时，现有流量会均匀分布到新的 Dynos。

这会影响“旧” Dynos 的客户端被分配给他们之前未通信的 Dynos。这在缩小规模时是不可避免的，但在扩大规模时则不是必需的。

是否有可能阻止 Heroku 负载均衡器将现有会话分配给新的 Dynos，而不是将它们与原始会话保持一致？

我正在尝试在 Jelastic 中部署一个 Dockerized 的应用程序，并且我想要水平可扩展性，因为我需要一个负载均衡器并考虑过 nginx，但是如何通过 Jelastic 上的 docker 将 nginx 部署为负载均衡器？

我的具体疑问是因为到目前为止，当我部署负载均衡器时，它并没有自动配置，例如当您使用向导 GUI 中的 Java 选项卡将应用程序部署到 tomcat 时，我知道我可以在设置后为某些节点配置 nginx起来，问题是，如果它自动缩放，它将如何重新配置​​？

我们的数据库库是使用 EF-6 代码优先方法设计的。最初，我们设计了数据库，同时sharding architecture考虑到多租户。

然而，随着 Azure 上经济和专用数据库层的普及，这似乎不再是一个明智的架构，以便在应用程序级别处理 SQL Server 数据库的水平拆分。

由于已知 Guid.NewGuid() 会导致索引中的碎片，而整数主键则不会。Microsoft 支持建议使用顺序 Guid 而不是 Guid.NewGuid()。

有了这种架构背景，我越来越倾向于永远停止使用 Guid 作为主键。

对于现代应用程序架构师来说，合并和拆分 DB 似乎不再是一个明智的选择。

纠正我，如果需要，请！

在 SQL Server 中使用 Sequential Guid 而不是 Integer 主键有什么优势吗？

我很难将水平堆栈视图中的所有 5 个按钮拉伸到与我的设备宽度一样宽。我可以这样做吗？或者你们有什么解决办法吗？

期待您的回答。非常感谢您的关注。

我想根据请求的数量来扩展我的部署。每个 pod 一次只能处理一个请求。扩大规模是没有问题的，但是当我想缩小规模时，我想确保我没有杀死一个正在工作的 pod（例如编码一个大文件）。

我有以下豆荚：

• Pod 1（10 分钟前创建，有一个任务）
• Pod 2（5 分钟前创建，免费）
• Pod 3（1 分钟前创建，有一个任务）

如果我降低副本值，kubernetes 将杀死 pod 3。它不关心 pod 是否繁忙。我可以手动杀死 pod 2，所以 kubernetes 会启动一个新的：

• Pod 1（10 分钟前创建，有一个任务）
• Pod 3（1 分钟前创建，有一个任务）
• Pod 4（刚刚创建，免费）

在我知道 pod 2 被杀死后，我可以减少计数器的数量，因此 pod 4 将在获得任务之前被杀死。但是这个解决方案听起来很丑陋，因为必须有人告诉 pod 2 关闭。

所以 kubernetes 会杀死最后创建的那些，但是有没有可能告诉他，一个 pod 很忙，他必须等待它才会被杀死？

我们有一个包含 2 个 Web 服务器和 2 个 memcache 服务器的场景。Memcache 服务器节点在每个 Web 服务器上的配置文件中进行配置。

为了让我们能够自动水平扩展 Web 服务器，我们需要能够自动水平扩展 memcache 服务器。目前我们无法做到这一点，因为在 web 配置文件中定义了 memcache 节点。

在对系统影响最小的情况下，自动水平扩展 memcache 服务器的最佳方法是什么？

我有一个由三个节点组成的群：

然后我在那个 swarm 上运行 1 个 nginx 副本并将他的端口映射到 8080：

从那里，我可以通过http://node01:8080访问 nginx

接下来，我将 nginx 实例扩展到 6 个：

从那里，我仍然可以在http://node01:8080上访问 nginx 。

但是，如果 docker swarm 将多个节点公开为唯一的主机，那么在我所有的 nginx 服务都映射在同一个 8080 端口上的这种扩展操作期间，他如何管理该端口？swarm 在内部完成的所有服务实例之间是否存在循环负载平衡并在 8080 上返回答案？