architecture - 系统设计 : Strategies for dealing with heavy writes to a DB

Question

从系统设计/可扩展性的角度来看，在处理需要大量写入数据库中特定表的系统时，有哪些行业标准策略。

为简单起见，假设该表是产品的库存表，有一个“产品名称”列和一个“计数”列，并且每次将新产品购买到系统中时它只会增加 +1。并且每 2 日就有数百万用户购买不同的产品，我们必须跟踪每个产品的最新计数，但不必严格实时，也许 5 分钟的滞后是可以接受的。

我的选择是:

1) 主从复制，其中主数据库处理所有写入，从属处理读取。但这并没有解决写重的问题

2) 根据产品名称范围或其散列值对数据库进行分片。但是，如果某个特定产品(例如 Apple)在短时间内收到大量更新，它仍然会访问同一个 DB。

3)批量更新？使用某种缓存并每隔 X 秒写入一次表，并使用我们在这 X 秒内收到的任何内容的累积计数？这是一个有效的选项，我使用什么缓存机制？如果上次读取和下一次写入之间发生崩溃怎么办？如何恢复丢失的计数？

4)我忘记了任何其他明显的选择吗？

任何见解表示赞赏!

Answer 1

我想说一个解决方案将高度依赖于你到底需要做什么。每秒写入数千条记录的解决方案可能与您提供的示例中增加计数器的方法大不相同。更何况，可能没有 tables完全可以处理这样的负载。 Consistency/availability您的问题中也缺少要求，并且取决于它们，整个架构可能会有很大不同。

无论如何，回到您特定的简单案例和您的选择

方案一(主从复制)

您将在这里面临的问题是数据库 locking - 每个增量都需要一个记录锁以避免竞争条件，并且您将很快让您的进程写入您的数据库并在队列中等待并且您的系统关闭。即使在中等负载下)

选项 2(分片 DB)

你的假设是正确的，与 p.1 没有太大区别

选项 3(批量更新)

很接近。由提供并发的轻量级存储提供的缓存层 原子 使用 递增/递减坚持以免丢失您的数据。我们用过 redis出于类似的目的，尽管任何其他 key-value database也可以——实际上有几十个这样的数据库。

A key-value database, or key-value store, is a data storage paradigm designed for storing, retrieving, and managing associative arrays, a data structure more commonly known today as a dictionary or hash table

解决方案如下所示:

incoming requests → your backend server -> kv_storage (atomic increment(product_id))

并且您将运行一个“刷新”脚本，即 */5执行以下操作(简化):

每 product_id在 kv_storage 阅读当前 value

更新您的数据库计数器 ( += value )

递减value在 kv_storage

进一步扩展

如果脚本失败，不会发生任何不好的事情 - 更新将在下次运行时到达

如果您的后端盒子无法处理负载 - 您可以轻松添加更多盒子

如果单个键值数据库无法处理负载 - 它们中的大多数支持扩展多个框或后端脚本中的简单分片策略可以正常工作

如果单个“刷新”脚本跟不上增量 - 您可以将它们缩放到多个框并决定每个框处理哪些键范围