体系结构 – 系统设计：处理对DB的大量写入的策略
|
从系统设计/可伸缩性的角度来看,在处理需要大量写入DB中特定表的系统时,有哪些行业标准策略.
为简单起见,假设该表是产品的库存表,并且具有“产品名称”列和“计数”列,每次将新产品购买到系统中时,它只会递增1.每秒有数百万用户购买不同的产品,我们必须跟踪每种产品的最新数量,但不一定要严格实时,也许可以接受5分钟的延迟. 我的选择是： 1)主从复制,其中主DB处理所有写入,而从属处理读取.但这并没有解决写得很重的问题 2)根据产品名称范围或其散列值对数据库进行分片.但是,如果某个特定产品(例如Apple)在短时间内收到大量更新,它仍然会遇到相同的数据库. 3)批量更新？使用某种缓存并每隔X秒写入表格,累计计算我们在X秒内收到的任何数据？这是一个有效的选项,我使用什么缓存机制？如果上次读取和下次写入之间出现崩溃怎么办？如何恢复丢失的计数？ 4)我忘记了任何其他明显的选择？ 任何见解都表示赞赏！ 解决方法
我会说解决方案将高度依赖于您需要做什么.每秒写入数千条记录的解决方案可能与您在提供的示例中递增计数器有很大不同.更重要的是,可能根本没有表来处理这样的负载.您的问题中也缺少一致性/可用性要求,并且取决于它们,整个架构可能会有很大差异.
无论如何,回到你特定的简单案例和你的选择 选项1(主从复制) 你将面临的问题是数据库锁定 – 每次增加都需要一个记录锁定来避免竞争条件,你很快就会让你的进程写入你的数据库,等待队列和系统关闭.即使在中等负荷下) 选项2(对数据库进行分片) 你的假设是正确的,与p.1没什么不同 选项3(批量更新) 很接近.由轻量级存储提供的缓存层,提供并发原子增量/减量,持久性不会丢失数据.我们已经将redis用于类似目的,尽管任何其他key-value database也可以这样做 – 实际上有几十个这样的数据库.
解决方案如下： incoming requests → your backend server -> kv_storage (atomic increment(product_id)) 并且你将有一个“刷新”脚本运行,即* / 5执行以下操作(简化)： >为kv_storage中的每个product_id读取其当前值 进一步扩展 >如果脚本失败,则不会发生任何不良事件 – 更新将在下次运行时到达>如果您的后端盒无法处理负载 – 您可以轻松添加更多盒子>如果单个键值db无法处理负载 – 大多数都支持在多个框上进行缩放,或者后端脚本中的简单分片策略可以正常工作>如果单个“刷新”脚本无法跟上增量 – 您可以将它们缩放到多个框并确定每个框处理的键范围 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |