database - redis 可以在单个键值对上每秒执行数百个事务吗

Question

我有一个应用程序，用于 API 调用。在每次 API 调用时，我都会执行一些任务并为此收费(可以是发送邮件或短信或任何类似的东西)。

目前我在 MYSQL 表中以下列形式保存我的用户余额/信用数据:

|user|balance|
|a   |1200   |
|b   |1200   |
|c   |1300   |
|d   |1400   |
|e   |1212   |
|f   |9000   |
|g   |8000   |
|h   |7000   |

但是当单个用户每分钟访问数千个 API 时，这会产生问题。在每个 API 上，我都会更新用户的余额，如果余额不足，我会返回一些错误。
当没有 API 命中很小时，没有问题，但当它很大时，更新余额会在该行上创建一个锁，其他 API 必须等待处理。

我正在考虑将此表移动到某个缓存或内存数据库中，以便我可以加快此过程。

早些时候我想到了 Memcache，但它是不稳定的，所以在搜索时，我读到了 Redis。
但是我很困惑，我的问题会不会被这个解决？对于不同的键，从 Redis 获取数据可能很快，因为它仅保存在内存/RAM 中，但如果对同一/单个键有数千个更新和搜索查询，它将如何工作。

如果您对此有任何知识或经验，请分享，或者如果有人有比 Redis 更好的解决方案来解决我的问题，请提供帮助。

Answer 1

简而言之，是的，Redis 会完成您想要做的事情。它可以handle very high throughput , can be configured to be persistent , 你可以 set it up in an HA manner with Sentinel .让它在一分钟内处理数千次 API 调用应该完全没有问题。

也就是说，这也不是绝对必要的。如果您可以在用户用完信用时向用户声明几秒钟的延迟，我还建议缓存每个框的 API 调用次数，并每隔几秒刷新一次数据库(Redis 或 MySQL)在此期间每个盒子使用/添加的信用总量。添加/减去这些数字应该是幂等的，每隔几秒刷新一次应该可以解决您无法随机处理意外大量 MySQL 命中的主要问题。

所以，您在这里有一些不错的选择。选择最适合您的用例的那个。