背景每一部电影的幕后都保存着你的观看记录，详细记住你看了多少次，跳过了多少次。据说根据这些数据，可以分析出你喜欢哪位日本明星，并以此作为定向推送……虽然看起来是一个简单的功能，但实际上涉及的数据量非常大。在极端情况下，它是您的用户数*视频数的乘积。那么当只有两台web服务器和一台sqlserver时，如何处理这样一个数据量不是很大的写请求呢？为什么说是写请求呢？因为你需要记录用户观看视频的每一秒，例如：用户观看视频的第10秒。要完成这个功能，首先需要定义几个东西：如何记录用户观看视频的数据定义和记录在客户端交互数据协议数据库中的数据格式，以解决服务端写入压力（毕竟,单台服务器的请求量比较大)解决方案用户观看视频进度定义对于一个视频,如果是1小时,这3600秒对应的是3600状态是否已经观看或不。对于观看状态，只有观看和未观看状态，所以一位就够了，一个字节（byte）有8位，所以一个字节可以代表8秒的观看状态，基于此，数字越大，数字相同字符更多状态。客户端每次上传新的数据，都需要和服务器上已有的数据进行位计算，例如：01000表示第2秒观看，客户端新上传：00011表示第1秒观看第4秒和第5秒。对于用户来说，这个视频的第2、4、5秒都看过了。虽然只是简单的计算，但在量大的情况下，CPU的消耗也不容小觑。第一个字节第二个字节0123456701234567位：1000100001000000二进制：0x880x40字符串：8840与客户端的交互协议用户观看视频进度的实时信息只有客户端知道。客户端需要上传用户的观看进度数据，与服务端交互的十六进制可以选择更通用的十六进制。当然，你选择100个基础系统无所谓，只要双方能同时支持，能正常解析即可。数据库数据格式每个数据库支持的数据类型不同，这里就不过多描述了。当然不管是什么格式，占用的空间越少越好，但是也要根据业务的计算量综合考虑。解决cpu性能的问题，毕竟每次都要合并用户的最新观看数据和旧数据，在用户量大的情况下不可小觑。综合各种条件后，最终采用十进制进行合并工作。客户端上传十六进制数据，然后转成十进制，再与查看记录（十进制）进行合并操作。CPU的这部分不能省略，具体转换过程为：//新增数据ConcurrentQueue
