从每秒 6000 写请求谈起

发布于: 2020 年 09 月 05 日
从每秒6000写请求谈起





背景



每一个片子的幕后,都保留了你的观看记录,详细的记着你观看了几次,跳过了那些时长 ,据说根据这些数据可以分析出你喜欢哪个日本明星,以此来做定向推送......



虽然看起来很简单的一个功能,其实涉及到的数据量非常大,极限情况下为你的用户数*视频数的乘积。



那么在只有两个网站服务器,一台sqlserver的情况下,该如何面对这样不算大数据量的写请求呢?为什么说是写请求呢?因为用户观看视频的每一秒你都需要记录下来,例如:视频的第十秒用户观看了。要想把这个功能搞定,首先需要定义几个事情:



  1. 记录用户观看视频情况的数据定义

  2. 和客户端交互的数据协议

  3. 数据库中记录的数据格式

  4. 如何解决服务器写的压力(毕竟单台服务器请求数还是比较大)

解决方案

用户观看视频进度定义



对于一个视频来说,假如有1个小时的时长,这3600秒对应着3600个是否已经观看的状态,对于观看状态来说,只有观看和未观看两种状态,所以一个bit足以,一个字节(byte)有8个bit,所以一个byte可以表示8秒的观看状态,以此为基础,进制越高,同样数量的字符表示的状态就越多。



客户端每次上传新的数据,需要和服务端已经存在的数据做位运算,例如: 01000 表示第二秒观看了 ,客户端新上传:00011 表示第4,5秒都观看了,对于用户而言这个视频第2,4,5 秒都看过,虽然只是一个简单的运算,但是量大的时候,对cpu的消耗不容小觑。



第一字节 第二字节
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
bit: 1 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0
二进制: 0x88 0x40
字符串: 8840




和客户端交互协议



用户观看视频的进度实时信息,只有客户端知道,客户端需要上传用户的观看进度数据,和服务端交互的进制可以选择通用性比较强的16进制,当然你选择100进制也无所谓,只要双方能同时支持,并且能正常解析即可

数据库数据格式

每种数据库支持的数据类型有差异,所以这里不在过多叙述,当然无论什么格式,占用空间越少越好,但也要根据业务的计算量来综合考虑。

解决问题

cpu性能问题



毕竟要把用户每次最新的观看数据和老数据做合并工作,在用户量大的情况下不容小觑。在综合了各种条件之后,最终采用10进制来做合并工作,客户端上传上来16进制数据,然后转化为十进制,然后和观看记录(10进制)做合并运算,这部分cpu省略不了,具体转化程序为:



//需要新加的数据
ConcurrentQueue<UserVideoInfo> AddQueue = new ConcurrentQueue<UserVideoInfo>();

//把16进制的字符串按照两位 分割成十进制数组
protected List<int> ConvertToProgressArray(string progressString)
{
if (string.IsNullOrWhiteSpace(progressString))
{
return null;
}
//验证是否为2的倍数长度
if (progressString.Length % 2 != 0)
{
return null;
}
var proStrSpan = progressString.AsSpan();
List<int> ret = new List<int>();
int i = 0;
while (i < proStrSpan.Length)
{
ret.Add(int.Parse(proStrSpan.Slice(i, 2).ToString(), System.Globalization.NumberStyles.HexNumber)); ;
i = i + 2;
}
return ret;
}




客户端请求数量问题

如果同时一万用户在同时观看视频,上传数据时间间隔为2秒,意味着每秒有5000请求。由于这个业务只是一个用户log型业务,何为log型,就是说可以容忍一部分数据丢失,针对这个数据形态,客户端可以先在本地做缓冲记录,没有必要一秒上传一次记录,例如现在约定的客户端30秒上传一次记录,如果用户关掉客户端,下次启动的时候会重新上传未成功的记录。

数据库压力



如果每次请求都单独更新数据库,按照第二条的计算每秒高达5000次update请求。用户观看每次视频都加载内存中缓存,仔细分析这种业务,由于是log型数据,所以每次你请求没有必要都去更新数据库,而是先更新了缓存,然后定时去更新数据库。



由于数据量的问题,所有的更新操作都会发送到一个任务队列,队列的执行者会根据配置批量更新数据库,这样比单条更新数据库性能要高很多,其实这种方案在很多log型的业务中都有使用,批量更新对数据库的压力要小很多,代码类似以下



public async Task<int> AddUserVideoData(UserVideoInfo data, DBProcessEnum processType = DBProcessEnum.Update)
{
if(processType== DBProcessEnum.Add)
{
AddQueue.Enqueue(data);
}
return 1;
}

void MulProcessData()
{
//每次更新的条数
int maxNumber = 50;
List<UserVideoInfo> data = new List<UserVideoInfo>();
while (true)
{
if (data == null)
{
data = new List<UserVideoInfo>();
}
try
{
if (!AddQueue.Any() && !UpdateQueue.Any())
{
System.Threading.Thread.Sleep(500);
}
else
{
//先处理 需要更新的
data.Clear();
while (data.Count <= maxNumber && AddQueue.Any())
{
if (!AddQueue.TryDequeue(out UserVideoInfo value))
{
continue;
}
//判断是否有重复对象
if (data.Any(s => s.UserId == value.UserId && s.VideoId == value.VideoId))
{
var exsitItem = data.First(s => s.UserId == value.UserId && s.VideoId == value.VideoId);
exsitItem = value;
}
else
{
data.Add(value);
}

}
if (data != null && data.Any())
{
var ret = UserVideoProgressProxy.Add(data);
}
}
}
catch (Exception err)
{
}


}
}




写在最后



其实这种高IO的操作用sqlserver这种关系型数据库反而不好,Nosql在这种简单高IO的情境下要很多,改天可以改为redis试一试,估计会比sqlserver要好很多。

更多精彩文章





发布于: 2020 年 09 月 05 日 阅读数: 40
用户头像

一个坚持把架构做到极致的技术人 2014.10.19 加入

还未添加个人简介

评论

发布
暂无评论
从每秒6000写请求谈起