Thrift 是 Facebook 开源的一个高性能，轻量级 RPC 服务框架，是一套全栈式的 RPC 解决方案，包含序列化与服务通信能力，并支持跨平台/跨语言。

近日，第五届深度学习图像压缩挑战赛（以下将简称“ CLIC 大赛”）比赛结果公布，首次参赛的火山引擎视频云多媒体实验室夺得视频压缩赛道第一名。压缩技术对于图像、视频应用十分重要。在保证同样的质量前提下，如何将图像压缩到更小的体积便于互联网信息传输，火山引擎视频云团队不断突破压缩技术“天花板”。

当前字节跳动高峰期每秒需处理近百万张图片，基于今日头条、抖音等亿级 DAU 的实践打磨，与国际领先的压缩技术，火山引擎视频云打造图像一站式解决方案 veImageX ，覆盖上传、存储、处理、分发、展示、质量监控全链路，涵盖图像生产、图像消费、云平台三大应用场景。

性能测试是 SDK 发版的重要依据，VolcRTC 的业务方对于性能指标都比较重视，对于 RTC 准入有明确的准入标准。因此我们建立了线下的性能自动化测试系统，测试过程中我们发现 VolcRTC 的内存占用较高存在较大的优化空间。

JavaScirpt30 是 Wes Bos 推出的一个 30 天挑战。项目免费提供了 30 个视频教程、30 个挑战的起始文档和 30 个挑战解决方案源代码。目的是帮助人们用纯 JavaScript 来写东西，不借助框架和库，也不使用编译器和引用。

直播 OOM 问题比较棘手难以定位，主要体现在涉及的业务很多，从定位到解决花费时间比较久。为了提前触达问题，提高定位的效率，也是对现有工具的补充，提出直播内存抖动解决方案- MemoryThrashing。

Java 多线程开发中为了保证数据的一致性，引入了同步锁(synchronized)。但是，对锁的过度使用，可能导致卡顿问题，甚至 ANR。

• 为了效率(efficiency)，协调各个客户端避免做重复的工作。即使锁偶尔失效了，只是可能把某些操作多做一遍而已，不会产生其它的不良后果。比如重复发送了一封同样的 email（当然这取决于业务应用的容忍度）。
• 为了正确性(correctness)。在任何情况下都不允许锁失效的情况发生，因为一旦发生，就可能意味着数据不一致(inconsistency)，数据丢失，文件损坏，订单重复，超卖或者其它严重的问题。

从系统设计角度看，一个系统从设计搭建到数据逐步增长，SQL 执行效率可能会出现劣化，为继续支撑业务发展，我们需要对慢 SQL 进行分析和优化，严峻的情况下甚至需要对整个系统进行重构。所以我们往往需要在系统设计前对业务进行充分调研、遵守系统设计规范，在系统运行时定期结合当前业务发展情况进行系统瓶颈的分析。

从数据库角度看，每个 SQL 执行都需要消耗一定 I/O 资源，SQL 执行的快慢，决定了资源被占用时间的长短。假如有一条慢 SQL 占用了 30%的资源共计 1 分钟。那么在这 1 分钟时间内，其他 SQL 能够分配的资源总量就是 70%，如此循环，当资源分配完的时候，所有新的 SQL 执行将会排队等待。所以往往一条慢 SQL 会影响到整个业务。

在反作弊场景中，黑产必须通过文本进行信息传递或触达受害者，而文本由于其生产成本低廉、传递信息能力强的特点成为了黑产与我们进行对抗的主要战场。文本理解算法为应对各类强对抗提供了文本检索、文本风险标签、风险信息提取的能力，以及一个文本模型训练平台。这些能力的组合使用可有效打击文本内容维度的作弊行为，现已在反作弊的各业务场景中得到应用。

Semi Design 是由抖音前端团队，MED 产品设计团队设计、开发并维护的桌面端设计系统。它从字节跳动各业务的复杂场景提炼而来，支撑包括客服、建站、项目管理、创作者与音乐人服务在内的，多元品类下近千计平台产品，服务内、外部 10 万+ 用户。

本篇文章介绍了字节跳动在 Flink 状态查询方面所进行的优化，解决了查询 Flink 任务状态时开发成本高及无法查询状态元信息等问题，提出了 State Query on Flink SQL 的解决方案，让用户使用 Flink Batch SQL 就可以快速查询 Flink 任务状态。

2022 年 3 月 15 日，Google 发布了万众瞩目的 Golang 1.18，带来了好几个重大的新特性，包括：

1. 解决本地同时开发多个仓库带来的一些问题的工作区（Workspace）
2. 能够自动探测代码分支，随机生成输入，并且检查代码是否会 panic 的模糊测试（Fuzzing Test）
3. 众多开发者盼星星盼月亮终于等到的泛型支持。

本文将简单讲述这三个特性的相关内容。

数据探查上线之前，数据验证都是通过写 SQL 方式进行查询的，从编写 SQL，到解析运行出结果，不仅时间长，还会反复消耗计算资源，探查上线后，只需要一次探查，就可以得到整张表的探查报告，但后续我们还发现了一些问题，主要有三点：

1. 无法看到探查的数据明细以及关联的行详情，无法对数据进行预处理操作。
2. 探查还是需要资源调度，等待时长平均分钟级。
3. 与质量监控没有打通，探查数据的后续走向不明确。

针对这些问题，我们进一步开发了动态探查需求，解决的问题如下：

1. 基于大数据预览的探查，支持对数据进行函数级别的预处理。
2. 探查结果秒级更新，实时响应。
3. 与数据监控打通，探索 SQL 的生成模式。

能抵抗剪切、拼接和编辑等攻击的隐藏水印了解一下？

以抖音直播为例，直播链路各环节延迟贡献如下：

• 推流端——网络延迟平均 20 ～ 30ms，编码延迟依赖编码参数设置而定
• 流媒体服务——在拉流转码的场景下，会额外引入 300ms ～ 2s 的转码延迟(大小与转码参数相关)，如果直接播放源流，则不存在转码延迟
• 播放端——网络延迟 100ms ～ 200ms 左右，主要是链路分发节点之间的传输延迟；防抖 buffer——5 ～ 8s

从各环节延迟贡献看，容易得出一个直观的结论：端到端延迟过大主要是播放器的防抖 buffer 造成，这个表面现象也经常会导致很多同学，认为降低播放器的 buffer，就能降低延迟。这个说法的对错，取决于从什么角度解释。

在实现实现任何功能前，一般都需要有数据统计支撑，作为收益验证的手段以及测试 Case 收集的手段。因此，在尝试实现 HEVC 硬解前，首先需要统计有多少视频是 HEVC 视频，并拿到视频的解码参数。

很不幸，浏览器层面并未给我们暴露出视频的解码信息，比如分辨率，编码，Profile，色彩空间。这些一系列的视频参数，对于前端都是无感知且无法感知的。

因此，在往常，如果需要获取视频信息做数据统计，首先需要拿到视频的二进制数据，在前端解析视频的元数据（比如 HEVC VPS、SPS、PPS），来提取视频参数。这样做，缺点是显而易见的，这种方式并不支持原生的 Video 标签播放的内容，且需要额外二次发起请求，且需要针对每种编码均实现一遍。

因此，如果能从 Renderer 层，以浏览器视角，监听视频的解码信息，那或许我们则不需要做任何 Trick 的操作？我在这个过程尝试探索了一下，并成功实现了这个诉求。