dockerfile 是一种可以被 docker 程序解释的脚本，由一条条指令组成。通过编写 dockerfile 可以做到：
- 定制化 docker 镜像。
- 整合下载镜像、启动容器、编辑可写层等等操作，可重复构建，提升效率。
- 随时维护、修改、分享 dockerfile。
Dockerfile 详解
2022-10-27 10:09:50Docker常用命令
2022-10-27 09:48:32Docker环境信息 info、version
镜像仓库命令 login、logout、pull、push、search
镜像管理 build、images、import、load、rmi、save、tag、commit
容器生命周期管理 create、exec、kill、pause、restart、rm、run、start、stop、unpause
容器运维操作 attach、export、inspect、port、ps、rename、stats、top、wait、cp、diff、update
容器资源管理 volume、network
系统信息日志 events、history、logs
编译运行Milvus
2022-09-27 11:40:01Milvus 是什么
Milvus 是一款开源的向量数据库，支持针对 TB 级向量的增删改操作和近实时查询，具有高度灵活、稳定可靠以及高速查询等特点。Milvus 集成了 Faiss、NMSLIB、Annoy 等广泛应用的向量索引库，提供了一整套简单直观的 API，让你可以针对不同场景选择不同的索引类型。此外，Milvus 还可以对标量数据进行过滤，进一步提高了召回率，增强了搜索的灵活性。
Milvus主要是在Ubuntu环境下进行开发的，我们推荐的编译环境首选是Ubuntu 18.04。在0.6.0之前的版本都是使用GPU加速的版本，但很多使用者反映他们希望在无GPU的机器上运行Milvus。于是我们在0.6.0上通过编译选项提供了CPU和GPU两种版本，但在CPU版本的Docker镜像没有发布前，很多使用者不得不自己去编译CPU版本，由于各人的机器环境千差万别而遇到了各种各样的编译问题。因此我们上传了两个Docker镜像，分别提供了Milvus CPU和GPU版本所需要的编译环境。
MinIO 快速入门
2022-09-21 10:12:50什么是 MinIO？
Minio 是个基于 Golang 编写的开源对象存储套件，基于Apache License v2.0开源协议，虽然轻量，却拥有着不错的性能。它兼容亚马逊S3云存储服务接口。可以很简单的和其他应用结合使用，例如 NodeJS、Redis、MySQL等。
Prometheus监控报警系统搭建
2022-09-21 10:10:17什么是Prometheus?
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。
2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。
Prometheus目前在开源社区相当活跃。
Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。
Prometheus的特点
多维度数据模型。
灵活的查询语言。
不依赖分布式存储，单个服务器节点是自主的。
通过基于HTTP的pull方式采集时序数据。
可以通过中间网关进行时序列数据推送。
通过服务发现或者静态配置来发现目标服务对象。
支持多种多样的图表和界面展示，比如Grafana等。
go语言JSON字典模拟
2022-09-16 03:18:27有关 golang 里JSON 使用的用法整理
go语言的sql解析器
2022-09-02 13:36:58https://github.com/xwb1989/sqlparser
来自Vitess的SQL词法解析器, 被单独抽出来做为一个独立库,可以用来实现很多好玩的东西
Vitess使用SQL的词法解析来实现像数据自动分片这类功能.
sql := "SELECT * FROM test_table WHERE a = 'abc'"
stmt, err := sqlparser.Parse(sql)
if err != nil {
// Do something with the err
}
// Otherwise do something with stmt
switch stmt := stmt.(type) {
case *sqlparser.Select:
_ = stmt
case *sqlparser.Insert:
}
Grafana配置数据源，自定义查询语法
2022-08-28 06:21:131.概述--美观、强大的可视化监控指标展示工具
grafana 是一款采用 go 语言编写的开源应用，主要用于大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具，目前已经支持绝大部分常用的时序数据库。最好的参考资料就是官网（http://docs.grafana.org/），虽然是英文，但是看多了就会啦。
1.1基本概念
Grafana支持许多不同的数据源。每个数据源都有一个特定的查询编辑器,该编辑器定制的特性和功能是公开的特定数据来源。 官方支持以下数据源:Graphite，Elasticsearch，InfluxDB，Prometheus，Cloudwatch，MySQL和OpenTSDB等。
每个数据源的查询语言和能力都是不同的。你可以把来自多个数据源的数据组合到一个仪表板，但每一个面板被绑定到一个特定的数据源,它就属于一个特定的组织。
TDengine + Telegraf + Grafana
2022-08-28 06:20:00
gRPC-Gateway 返回JSON数据int64类型被转为string类型问题
2022-08-28 06:17:010x01 问题由来
最近使用gRPC-Gateway实现一个GRPC的服务HTTP网关时,遇到一个数据类型转换的问题。
在PB中定义的类型为uint64字段，在通过http接口访问返回JSON结果到本地之后却是一个string类型.
0x02 原因分析
为什么gRPC-Gateway要把int64转为string类型呢，他们的回答是遵循proto3的序列化规则，proto3的json-mapping中规定了int64/uint64/fixed64类型映射的json类型为string。
文档 里的有的话是这样说的:
LLAMA模型试玩
2022-08-28 05:47:50最近 ChatGPT 着实火了一把，据说 GTP4 也即将发布。现在Large Language Model（LLM ）也受到了类似图像生成的 Stable Diffusion 那种高光时刻。
在之前我一直有一个错误的观念，认为谁掌握着计算能力，谁才能得到最好的AI模型。直到 Facebook 2023 年二月 24 号发布了论文“LLaMA: Open and Efficient Foundation Language Models”。粗略阅读之后，我才知道原来在一个限定的预算下，大参数模型并不如小参数模型用更多的数据进行训练。
当前，许多 AI 模型都依赖 CUDA，比如 nanoGPT，这也就意味着必须有 NVIDIA 的 GPU来训练和运行。有这样的硬件限制，对于我这种只是想初步了解一下 LLMs 的一些基本概念的业余爱好者变成了一个比较高的门槛。
语音识别的一些开源项目整理
2022-08-27 16:10:19（1）ESPNET
推荐指数：★★★★★
star数量：4.4k
工具特点：支持多个语音任务，支持多个ASR端到端系统，当前最活跃的语音开源社区，是第三代端到端ASR系统的典型代表。
链接：https://github.com/espnet/espnet
（2）kaldi
推荐指数：★★★★☆
start数量：11k
工具特点：基于C++开发，工具丰富，2012-2018年最活跃的开源社区，是第二代神经网络ASR系统的典型代表。
使用MYSQL8进行统计分析
2022-08-27 15:50:06使用MYSQL8对 California Housing 加利福尼亚的房价数据集，进行统计分析
记录FFmpeg抽帧、合流、转码、加水印等操作
2022-08-27 15:45:53解协议：
URLContext主要存储视音频使用的协议的类型以及状态。
URLProtocol存储输入视音频使用的封装格式。
每种协议都对应一个URLProtocol结构
解封装：
AVFormatContext主要存储视音频封装格式中包含的信息；
AVInputFormat存储输入视音频使用的封装格式。
每种视音频封装格式都对应一个AVInputFormat 结构
解码：
每个AVStream存储一个视频/音频流的相关数据；
每个AVStream对应一个AVCodecContext，存储该视频/音频流使用解码方式的相关数据；
每个AVCodecContext中对应一个AVCodec，包含该视频/音频对应的解码器。
每种解码器都对应一个AVCodec结构
存数据：
视频的话，每个结构一般是存一帧；音频可能有好几帧
解码前数据：AVPacket
解码后数据：AVFrame
移动网络弱网处理研究
2022-07-09 08:15:24这里编辑文章摘要...
翻译：使用 Semgrep 进行热点代码评审
2022-05-18 00:40:32共享内存并发路线图
2022-03-15 14:02:51Shared Memory Concurrency Roadmap
过去很多年, 单核处理器性能基本沿摩尔定律的预测不断提速. 然而, 设计上越来越复杂, 也越来越接近物理极限, 引起了生产成本和功耗的增大, 性价比降低. 2005年前后, CPU制造商, 开始从原来提升单核处理器的ILP(instruction-level parallelism), 转向在单个芯片上增加核数, 挖掘multicore processor的性能[1].
目前, 市面上, 商用廉价或高端服务器, 一般都采用shared memory multicore multiprocessor. 高端服务器有几十~几百core, 几百GB甚至上TB的内存. 例如: Intel® Xeon® Processor E7-8894 v4支持8 socket * 24 core, 3.07TB内存[2]. 服务器提供了强大处理的能力, 可将系统dataset(比如in-memory database)可以全驻于内存, 采用multi-threaded编程, 共享地址空间, 提升计算性能[3][4].
shared memory concurrency涉及三个方面: parallelism, performance和correctnesss.
优化 QUIC 的 ACK 机制
2022-01-27 13:22:18对频繁确认 (ACK) 的依赖是当前传输协议设计的产物，而不是基本要求。本文分析了WLAN中数据包和ACK在无线介质上的争用和冲突引起的问题，提出了一种ACK机制，可以最小化QUIC中ACK帧的强度，提高传输层连接的性能。
QUIC 上的 RTP
2022-01-27 13:00:59本文档指定了在 QUIC 中封装 RTP 和 RTCP 数据包的最小映射。它还讨论了如何利用端点中 QUIC 实现的状态来减少 RTCP 数据包的交换。
QUIC 协议相关源码收集
2022-01-18 13:43:21这里编辑文章摘要...
[译] [论文] BBR：基于拥塞（而非丢包）的拥塞控制（ACM, 2017）
2022-01-15 13:43:25本文翻译自 Google 2017 的论文：
Cardwell N, Cheng Y, Gunn CS, Yeganeh SH, Jacobson V. BBR: congestion-based congestion control. Communications of the ACM. 2017 Jan 23;60(2):58-66.
论文副标题：Measuring Bottleneck Bandwidth and Round-trip propagation time（测量瓶颈带宽和往返传输时间）。
BBR 之前，主流的 TCP 拥塞控制算法都是基于丢包（loss-based）设计的， 这一假设最早可追溯到上世纪八九十年代，那时的链路带宽和内存容量分别以 Mbps 和 KB 计，链路质量（以今天的标准来说）也很差。
三十年多后，这两个物理容量都已经增长了至少六个数量级，链路质量也不可同日而语。特别地，在现代基础设施中， 丢包和延迟不一定表示网络发生了拥塞，因此原来的假设已经不再成立。 Google 的网络团队从这一根本问题出发，（在前人工作的基础上） 设计并实现了一个基于拥塞本身而非基于丢包或延迟的拥塞控制新算法，缩写为 BBR。
简单来说，BBR 通过应答包（ACK）中的 RTT 信息和已发送字节数来计算 真实传输速率（delivery rate），然后根据后者来调节客户端接下来的 发送速率（sending rate），通过保持合理的 inflight 数据量来使 传输带宽最大、传输延迟最低。另外，它完全运行在发送端，无需协议、 接收端或网络的改动，因此落地相对容易。
Google 的全球广域网（B4）在 2016 年就已经将全部 TCP 流量从 CUBIC 切换到 BBR， 吞吐提升了 2~25 倍；在做了一些配置调优之后，甚至进一步提升到了 133 倍（文中有详细介绍）。
BBR拥塞控制算法
2022-01-15 13:40:26互联网曾广泛使用基于丢包的拥塞控制算法，例如Reno（[Jac88], [Jac90], [WS95] [RFC5681]）和 CUBIC（HRX08, draft-ietf-tcpm-cubic），这类算法认为丢包和拥塞是等效的。长久以来这类算法都运作的很好，但这并不能说明他们是绝对正确的。这种良好的表现是由于网络交换机和路由器的缓冲区都十分适配当时的网络带宽。而一旦发送者的发送速率足够快，缓冲区便会被快速填满，进而引发丢包。
实际上丢包并不等效于拥塞。拥塞可以被看作是一种在网络路径中，传输中的数据量始终大于带宽-时延积的场景。随着互联网的不断发展，丢包现象在非拥塞场景下也频繁发生。而基于丢包的拥塞控制策略给网络带来了源源不断的问题：
- 浅缓存：在浅缓存场景下，丢包往往发生在拥塞之前。高速、长距离的现代网络，搭配上消费级的浅缓存交换机，基于丢包的拥塞控制算法可能会导致极其糟糕的吞吐量，而这种现象则归咎于这类算法对于丢包的过激反应。流量突发引起的丢包会使发送速率乘性递减（这种丢包现象在空闲网络中也会频繁发生）。这种动态特性，使得基于丢包的拥塞控制算法在实际应用中很难对网络带宽进行充分利用：维持10Gbps/100ms RTT的网络，必须要求其丢包率在0.000003%以下。而更为实际的1%的丢包率，则会导致其只能维持在3Mbps/100ms（无论是瓶颈带宽的性能如何）。
- 深缓存：在有着深缓存的瓶颈链路中，拥塞往往发送在丢包之前。在现今的的边缘网络中，基于丢包的拥塞控制算法对众多最后几英里的设备，进行了深缓存的反复填充，引发了不必要的数秒级的排队延时，也就是“缓冲膨胀”的问题。
BBR拥塞控制算法使用了另类的方式：不用丢包去衡量拥塞是否发生，而是直接对网络建模来避免以及应对真实的拥塞。
BBR算法已经在之前的论文中大致描述过 [CCGHJ16] [CCGHJ17]，活跃性的社区工作也在持续进行中。该文档将对现有的BBR算法进行详细解释。
该文档将以下列形式进行组织：第二节将会给出多种术语定义。第三节是对BBR算法的设计概述。第四节将对BBR算法进行细节分析，包括BBR的网络路径模型，控制参数以及状态机。
congestion_controller、 remote bitrate estimator、pacing模块浅析
2022-01-15 13:30:301.概述
2.congestion_controller模块
2.1 congestion_controller模块组成
2.2 远端带宽探测
2.3 loss_based_bandwidth_estimation基于丢包的带宽评估
2.4 delay_based_bwe基于延迟的带宽评估
2.5 receive_side_congestion_controller接收端拥塞控制
3.remote_bitrate_estimator模块
4.pacing模块
实战|QUIC协议在蚂蚁集团落地
2022-01-15 12:41:55自 2015 年以来，QUIC 协议开始在 IETF 进行标准化并被国内外各大厂商相继落地。鉴于 QUIC 具备“0RTT 建联”、“支持连接迁移”等诸多优势，并将成为下一代互联网协议：HTTP3.0 的底层传输协议，蚂蚁集团支付宝客户端团队与接入网关团队于 2018 年下半年开始在移动支付、海外加速等场景落地 QUIC。
本文是综述篇，介绍 QUIC 在蚂蚁的整体落地情况。之所以是综述，是因为 QUIC 协议过于复杂，如果对标已有的协议，QUIC 近似等于 HTTP + TLS +TCP，无法详细的毕其功于一役，因此我们通过综述的方式将落地的重点呈现给读者，主要介绍如下几个部分：
-
QUIC背景：简单全面的介绍下 QUIC 相关的背景知识
-
方案选型设计：详细介绍蚂蚁的落地方案如何另辟蹊径、优雅的支撑 QUIC 的诸多特性，包括连接迁移等
-
落地场景：介绍 QUIC 在蚂蚁的两个落地场景，包括：支付宝客户端链路以及海外加速链路
-
几项关键技术：介绍落地 QUIC 过程中核心需要解决的问题，以及我们使用的方案，包括：“支持连接迁移”、“提升 0RTT 比例"， "支持 UDP 无损升级”以及“客户端智能选路” 等
-
几项关键的技术专利
阿里XQUIC：标准QUIC实现自研之路
2022-01-08 03:20:39为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。
为什么越来越多的团队投入QUIC协议自研实现？来自阿里巴巴淘系技术的刘彦梅的投稿很好的解释了背后的原因——提供更好的灵活性。同时，遵守标准的IETF QUIC也让研发投入能产生长期回报。刘彦梅介绍了XQUIC的前生今世，以及未来的开源计划。
XQUIC是阿里巴巴淘系架构团队自研的IETF QUIC标准化协议库实现，在手机淘宝上进行了广泛的应用，并在多个不同类型的业务场景下取得明显的效果提升，为手机淘宝APP的用户带来丝般顺滑的网络体验：
-
在RPC请求场景，网络耗时降低15%
-
在直播高峰期场景，卡顿率降低30%、秒开率提升2%
-
在短视频场景，卡顿率降低20%
从以上提升效果可以看出，对QUIC的一个常见认知谬误：“QUIC只对弱网场景有优化提升”是不准确的。实际上QUIC对于整体网络体验有普遍提升，弱网场景由于基线较低、提升空间更显著。此外，在5G推广初期，基站部署不够密集的情况下，如何保证稳定有效带宽速率，是未来2-3年内手机视频应用将面临的重大挑战，而我们研发的MPQUIC将为这些挑战提供有效的解决方案。
本文将会重点介绍XQUIC的设计原理，面向业务场景的网络传输优化，以及面向5G的Multipath QUIC技术（多路径QUIC）。
弱网不弱-TQUIC助力业务提速30%
2021-11-26 11:41:19腾讯核心业务用户登录耗时降低30%，下载场景500ms内请求成功率从HTTPS的60%提升到90%，腾讯的移动端APP在弱网、跨网场景下取得媲美正常网络的用户体验。这是腾讯网关sTGW团队打造的TQUIC网络协议栈在实时通信、音视频、在线游戏、在线广告等多个腾讯业务落地取得的成果。
TQUIC基于下一代互联网传输协议HTTP3/QUIC深度优化，日均请求量级突破千亿次，在腾讯云CLB、CDN开放云客户使用。本文重点分享了sTGW团队在协议栈基础能力、私有协议、明文传输等功能研发经验，并且针对弱网场景，分享腾讯如何基于0-RTT握手、连接迁移、实时传输等能力帮助业务用户体验提升。
程序员眼中最有价值的10条开发经验
2021-08-22 10:33:44到现在，我已经做了超过 21 年开发，可以说，我生命中超过一半的时间都在编程，那既是我的职业，也成了我的习惯。
下面是我在开发过程中学到的 10 条最有价值的经验。
1 你永远不可能什么都知道
尤其是在开始的时候，我以为我什么都能学会，在开发生涯的大部分时间里，我都是这样想的。但是，每次我学了什么新东西，就打开了一个全新的世界，里面有不同的概念和技术。
那似乎很有吸引力，你很愿意尝试，希望把什么都学会，但这是一个没有终点的旅程。如果要学的话，总是有其他的库、框架以及其他很酷的东西可以学。
因为似乎永远无法达成自己的目标，所以最终你的热情会慢慢冷却。最好是立足于你最擅长的东西，然后因需而学，即在真正需要的时候才学习新东西。这可以让你保持清醒，维持学习的动力。
你还可以把这一点应用在任何其他的领域。不是什么都知道才能达成预期的结果。利用这一点来打造自己的优势，在需要的时候学习。