【问题标题】:MySQL - multiple concurrent updatesMySQL - 多个并发更新
【发布时间】:2020-02-07 19:10:10
【问题描述】:

我已经为 Android-IOS 创建了一个基于位置的应用程序,并且我使用 NodeJS 作为我的后端。我的用户的位置每隔 X 秒就会通过对 NodeJS 服务器的 HTTP 请求进行更新。假设我将有 10.000 个并发请求/秒来更新不同用户的位置数据,MySQL 可以处理这个量吗?还是会崩溃?

【问题讨论】:

  • 时间范围是多少?
  • @TheImpaler 你所说的时间框架是什么意思? 10.000 并发资源/秒。
  • "每秒" -- 请将其添加到问题中。
  • @Ashkan 不,我使用 MySQL

标签: mysql sql node.js concurrency


【解决方案1】:

大概你会使用类似这样的 MySQL 特定的 SQL:

 INSERT INTO location (user_id,long, lat) VALUES (?, ?, ?)
 ON DUPLICATE KEY UPDATE long=?, lat=?;

在具有如下定义的表上:

CREATE TABLE location (
 user_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
 long  FLOAT NOT NULL DEFAULT 0,
 lat   FLOAT NOT NULL DEFAULT 0,
 PRIMARY KEY (user_id)
);

这可能是您可以为此目的使用的最简单的表格。如果您需要根据位置搜索表格,您可能还需要此索引来进行边界框搜索。

 INDEX location_lat_long_user_id (lat, long, user_id)

因此,MySql 至少每次更新都需要访问user_id 键,并且可能还需要更新其他索引。

如果您在该表中放入更多信息或更多索引,则您的插入和更新将变得更加复杂,MySql 无法处理。

每秒 10K 的事务对于单个 MySQL 服务器来说是一个非常高的数字。如果您正确配置节点连接池,您的 MySQL 服务器将不会崩溃。但是您的节点服务器可能会慢下来,甚至内存不足。

如果您的应用扩展到 10K/秒,您可能需要考虑设置MySQL cluster。但是,YAGNI,在您的应用扩大规模之前不要这样做。获得成千上万的用户需要一段时间。与此同时,您的时间和金钱花在功能上比花在基础设施上要好得多。 (当你有一两个小时的空闲时,问我怎么知道的。)

但是,还有更多的方法可以优雅地处理这种工作负载。

  1. 使用 nodejs 内置的固有队列机制。对于这些位置更新,使用相当小的 MySQL 连接池。当池中的所有连接都处于活动状态时,节点将或多或少地自动将您传入的位置报告 API 请求排队。这将允许您的服务器在获得短暂的位置更新时优雅地放慢速度。

  2. 不要太频繁地记录位置数据。普通的 GPS 数据最多只能精确到几米。如果您的拍摄对象正在行走,则他们至少需要几秒钟才能移动一米。

  3. 仅当您知道受试者的手机已移动超过一定距离时才更新数据库。最好的方法是在您的应用程序中。使其仅在主体移动一定距离时报告新位置。这样,您将避免来自固定主题的重复更新。这将为手机节省大量电量。

  4. 您的更新还以度/秒为单位发送了时间戳和运动矢量。并且,仅在位置或运动矢量发生显着变化时发送它。您的更新可能如下所示:

     time        long       lat           dlong      dlat
    1581106542  -73.98508   40.74780    -0.0004     -0.0005
    

然后,如果您需要猜测您的主题的当前位置,您可以将向量乘以时间差并将其添加到该位置。如果您的对象快速移动(飞机、火车和汽车)并且您需要在后端准确猜测它们的位置,这将很有帮助。

【讨论】:

  • 感谢您的回复。首先在 MQ 中处理这些请求(我想到的是 RabbitMQ)然后一个一个(通过 MQ)发送到 MySQL 是否是个好主意?你怎么看?
  • 是的,如果您有权访问这些位置更新,绝对使用消息队列进行这些位置更新。这是一个很好的解决方案,因为您可以在一天中的繁忙时间监控您的积压工作。您还可以考虑使用内存中的键/值存储(如 redis)代替 MySql。这些都没有改变我的观点,即每秒一次位置更新对于可扩展的系统设计来说更新太多了。
  • 我使用 Redis 来更快地获取例如产品详细信息页面。在不断更新位置用户数据的情况下,Redis 如何发挥作用?你能解释一下你使用 Redis 而不是 MySQL 的逻辑吗?
  • 很难说哪种地理数据存储替代方案是最好的,因为您还没有解释要如何处理您的地理数据。 Redis 有一些地理搜索功能。
猜你喜欢
  • 1970-01-01
  • 2019-08-02
  • 1970-01-01
  • 2017-03-31
  • 1970-01-01
  • 1970-01-01
  • 2014-03-30
  • 2017-07-29
  • 1970-01-01
相关资源
最近更新 更多