外链论坛

 找回密码
 立即注册
搜索
查看: 27|回复: 2

每日上百万次调用的巨量拜访系统缓存数据丢失?看eBay的三种处理办法

[复制链接]

3039

主题

2万

回帖

9606万

积分

论坛元老

Rank: 8Rank: 8

积分
96065878
发表于 2024-9-27 10:01:32 | 显示全部楼层 |阅读模式

eBay 的员工 Venkatesh Ramaswamy 于 2017 年 1 月发布了一篇文案文案发布在 eBay 技术博客上,文案重点讲了针对购物车缓存数据丢失状况,eBay 思考的三种处理方法,以及最后采用的处理方法。背景

eBay 的购物车信息存储依赖于两个区别的数据存储介质,MongoDB 存储用户完整的购物车信息,Oracle 仅存储购物车的大致信息,然则能够经过关键信息查询所有的购物车信息。在 eBay 的这套系统里,MongoDB 更加多被用来充当“缓存”,Oracle 数据库做为存储副本。倘若数据在 MongoDB 里面找不到了,服务会从 Oracle 里面重新抽取(恢复)数据,而后重新计算用户的购物车。

所有的购物车数据都是 JSON 格式的,JSON 数据在 Oracle 里被存储在 BLOB 格式的字段里。这些 Oracle 里面的数据只能被用于 OLTP 交易。

这篇文案并不是讨论数据库技术的选取(Oracle vs MongoDB,其他数据),而是期盼能够让大众在巨量拜访系统(每日上百万次调用)中找到技术债,理解怎样处理问题。

问题描述

2016 年秋天起始,购物车服务显现了缓存层丢失数据的状况同期,运维团队报告 MongoDB 的备份机制多次显现失败(MongoDB 运行在主从模式)。eBay 的这个服务已然运行了 5 年时间,始终显现问题,做过任何架构调节和大规模代码改变,需要尽快找到原由和防治办法。针对实质问题进行反复检测发掘 MongoDB 的 oplog(实时性需求极高的写日志记录)正在达到网络 I/O 限制。每一次的数据丢失,都会触发守护办法(再次从 Oracle 读取数据后重复计算),并进一步加长用户的等待时间。

处理方法

咱们具体讨论特定的处理方法前,咱们期盼去尽可能多地讨论处理方法。例如,一旦备份机制启用,是不是能够经过隐匿有些副本方式让系统能够正常运行,而不要在系统尤其繁忙的时候去尝试重新备份。咱们能够尝试超机会制和周期性副本方式,然则这些方式并不会导致咱们本文说的问题出现

方法一:切片(MongoDB)

团队成员提出对 JSON 数据进行切分,即对原先存储在 MongoDB 里的原子化的购物车信息(一个 JSON 字符串),切分为多个字符串,这般做的好处是能够减少单一 MongoDB 中心节点的写入次数和网络开销。

针对数据切分后的相关方式,远比数据切分、负载平衡繁杂因此呢,第 1 种方法选取会引入其他技术难点,需要咱们自己能够寻找被切分后的数据的相关性,这便是为何 eBay 放弃了这个方法

方法二:有选取的写入

运用 MongoDB 的 set 命令,只针对当特定值出现更改后,才起步写入操作。这种方式理论上是可行的。

然则倘若你真正思虑一下,这种做法基本保证减少 oplogs 写入次数,然则它很有可能会导致全部文档的更新。

认识一下 MongoDB 的 Set 操作模式。Set 操作能够用于运用特定值替换字段值:

{$Set{:,…}}

假如你思虑一下描述制品的文档如下所示:

{

针对满足 _id 等于 100 的文档,执行 set 操作更新 quantity 字段、details 字段和 tags 字段的值。

db.products.update( {_id:100}, {$set:

以上这个操作替换 quantity 的值为 500,details 字段的值为一个新的嵌入式文档,tags 值为一个数组。

方法三:压缩传输数据

思虑到需要尽快处理问题,因此需要尽可能避免重写业务规律,压缩方式看起来是比较好的一中了。减少进入 MongoDB 的 Master 节点的数据量,这般能够减少写入 oplog 的数据规模。然则,这种方式会将 JSON 字符串转变为二进制文案,操作时需要解压缩。

常用的压缩算法重点有:deflate、gzip、bzip2、lzo、snappy 等。差别如下所示:

deflate、gzip 都是基于 LZ77 算法与哈夫曼编码的无损数据压缩算法,gzip 只是在 deflate 格式上增多了文件头和文件尾;

bzip2 是 Julian Seward 研发根据自由软件 / 开源软件协议发布的数据压缩算法,Apache 的 Commons-compress 库中进行了实现;

LZO 致力于解压速度,并且该算法是无损算法;

LZ4 是一种无损数据压缩算法,着重于压缩和解压缩速度;

Snappy 是 Google 基于 LZ77 的思路用 C++ 语言编写的快速数据压缩与解压程序库,2011 年开源。它的目的并非最大程度地压缩,而是针对最快速度和恰当的压缩率。

目的思虑

咱们起始做这一功能性测试之前,咱们需要知道几个目的

准许购物车被压缩并持久化到 MongoDB(数据不会有改变)。

准许压缩编码方式的选取,支持采用一种编码方式读取,另一种编码方式写入。

准许读到老的、新的、中间状态的购物车信息,新老前后能够互相兼容。

压缩和解压缩的操作能够同期进行。

保证针对 MongoDB 数据库的实时 JSON 数据检索查找请求。

JSON 字符串例子

这是老的 JSON 字符串:

{ "_id" : ObjectId("560ae017a054fc715524e27a"), "user" : "9999999999",

这是压缩之后的 JSON 字符串:

{ "_id" : ObjectId("560ae017a054fc715524e27a"), "user" : "9999999999",

测试结果

经过运用相同的购物车数据进行测试,观察 CPU I/O 状况,数据如图所示:

结论

oplog 的写入速率,从 150GB/ 小时下降为大约 11GB/ 小时,下降了 1300%!文档的平均对象体积从 32KB 下降为 5KB,600% 的下降。另外,服务的响应时间有所改善。数据如图所示:

下面这张图表示的是 MongoDB 的 Ops Manager UI 工具信息,尤其标注了压缩和解压缩数据的耗时,以及文档的平均对象体积的下降数据。

最后针对生产环境下的随机一小时数据压缩,eBay 团队收集了有些指标图,用于更加多的深入观察。

End.

源自:公众号“大数据杂谈”

运行人员:中国统计网博主微X号:itongjilove)

博客ID:中国统计网

中国统计网,是国内最早的大数据学习网站,公众号:中国统计网

http://www.itongji.cn





上一篇:我帮妈妈做家务的日记篇三(二小红)
下一篇:.NET 开源实时监控系统 - WatchDog 技术解析
回复

使用道具 举报

3037

主题

2万

回帖

9910万

积分

论坛元老

Rank: 8Rank: 8

积分
99109078
发表于 2024-10-4 03:06:29 | 显示全部楼层
说得好啊!我在外链论坛打滚这么多年,所谓阅人无数,就算没有见过猪走路,也总明白猪肉是啥味道的。
回复

使用道具 举报

2983

主题

2万

回帖

9910万

积分

论坛元老

Rank: 8Rank: 8

积分
99109240
发表于 2024-10-23 14:38:43 | 显示全部楼层
“BS”(鄙视的缩写)‌
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

站点统计|Archiver|手机版|小黑屋|外链论坛 ( 非经营性网站 )|网站地图

GMT+8, 2024-11-15 00:15 , Processed in 0.123954 second(s), 21 queries .

Powered by Discuz! X3.4

Copyright © 2001-2023, Tencent Cloud.