最近在做流媒体相关的一些服务，它通过 k3s 部署在盒子上，我们的服务偶尔会出现拉流资源被拉爆的情况，需要定位一下是否存在资源泄漏的情况。由于基本流媒体服务是端口复用的，我们则选择 lsof -i : 来做这样的事情，但是在宿主机上看不到相关的信息，一定得进容器去看，但是部署的容器一般不带 lsof 等网络工具，每次定位问题需要 apt update && apt install，还是挺麻烦的。于是深入了解了一下，应该如何做？

文件系统有很多种，是广义的一个概念，例如 HDFS、GFS 这种分布式文件系统，以及 ZFS、ext4 这种只专注于宿主机上管理的文件系统。这里我们讨论的是兼容 posix 接口的文件系统。这样的文件系统可以直接使用 linux 的 mount umount 进行挂载，挂载点内是树状的结构，可以使用我们常见的 open，write 等接口进行交互，接口内部的实现则由文件系统自己定义，也就是说文件系统内部有可能是基于 block device、内存、web service 等等来实现的。

最近在涉猎存储相关的一些知识，要补习的东西还是比较多，网络、存储、IO。其中之前没接触过的东西还蛮多，正好听分享的时候，有听到对象存储相关的东西，说是借鉴了一些 Haystack 的设计，那也顺便学习一下。

最近沉迷了数独一段时间，有一些感受，记录一下下。

首先，数独是一个游戏，每当找到一个新的数字的时候，带来的都是爽感，反馈特别强，而且我也很享受这种简单的逻辑游戏。

其次，越难的数独，越有意思。我喜欢去尝试困难，这个困难能带给我学习的动力。

再次，数独的游戏需要循序渐进，效率较低的部分，是直接去挑战高难度的数独，但没有去复盘每一局数独，很多可以提高的地方就放过了。

最后，很多东西都是可以通过刻意训练来获得提升的，也要找对方法，最后有幸在微信阅读上，看到了适合我的教材，稍微学习了一下，基本最高难度的数独，20分钟能做完了，不会像之前卡住，解不出来。而且还只是随意看了，没有完整的看。

希望能从数独这个游戏上积累到的东西，扩善到生活当中去。

1. 先挑战难的
2. 失败后去针对性训练

如此反复，高效率的针对性学习。不过这种适合有固定解的问题，能够很快的找到答案，但如果是开放题，这个时候是没有标准答案了，就不适用这种方法。目前能够想到的还是多试，多尝试总没有错。

早在学校里就学习了数据库相关的东西，但是具体到细节的实现，了解得还是比较少，仅以这篇文章来回顾一下 InnoDB 中使用的一些锁，最后会和事务一块联系起来，做完整的一个介绍，彻底的理解 InnoDB 的锁与事务实现。

在做数据分析的时候，相对于传统关系型数据库，我们更倾向于计算列之间的关系。在使用传统关系型数据库时，基于此的设计，我们会扫描很多我们并不关心的列，这导致了查询效率的低下，大部分数据库 io 比较低效。因此目前出现了列式存储。Apache Parquet 是一个列式存储的文件格式。从这里入手，提升对列存的理解。当我还没看的时候，我还是很疑惑的，跟大家一样，向 hdfs 还是 lsmt 的设计，为了提升写入性能，都是使用 append 进行操作，而 append 如何将行式的数据转换成列式的数据呢？

最近学习了一些数据预测相关的知识，随着预测服务的上线，开始做一轮记录，总结一下最近学习到的与数据预测相关的知识， 也介绍一下做预测目前用到的一些工具。前面也说一下，我处理的数据是时序数据。

最近在做数据相关的事情。把我们线上的一个指标拉了下来。因为我们用到的都是第三方的服务，数据都维护在第三方。一个一个三方去看，还是比较麻烦的，也不好进行比对所以我们就全拉了回来，方便一起统计观看，同时也可以对这些数据利用起来，包括调度。

对这些数据的利用，最基本的是监控，其次需要针对这些数据做预测，其中一个点是需要做成本管理，预估之类的工作，第二点是要做异常检测。

最近都是在写 cms 后端，跟之前写容器调度系统，区别还是超级大的，面向的东西不一样了。发现 cms 后端，也就是 web 后端，还是蛮考察人的抽象能力的，可能比不上系统应用那样的性能以及效率。但是为了开发效率，以及抽象，还是很考察人的代码功底的。但是也没说意味着要牺牲性能。

Golang 的 interface(接口) 是一个很神奇的东西，定义为：

• 接口类型是由一组方法定义的集合
• 接口类型的值可以存放实现这些方法的任何值

Bazel 的细节就不在这里说了，上方链接可以去看看，google 开源的强大的 build 工具。现在团队在使用 Bazel 来 build 项目。我也算小小体验了一下下。应该算摸清楚了在 golang 项目中的玩法。

在 Golang 上，可以使用这个 rules_go。它提供了一些 golang 编译相关的方法，类似 go_library, go_test。 通过这些方法，可以非常容易的组合我们的包，把一个包所有的文件放到一个 go_library 中，就能够通过 bazel 来编译这个包了。而且还可以通过指定，name 来表明编译出来的包，这个方式就过于自由了， 按照用法，你可以任意组合 .go 源代码文件，然后打成一个 package 。如果这样做的话，会打破 golang 的package 规则，变得比较奇怪, go build 等工具就不能使用了， 所以推荐还是不要随意去指定名字，用 go_default_library 就可以了。

当然，golang 的话，还有 vendor 机制，我们能保证自己的每个包都写了 BUILD 文件，但是开源项目的话，不是每个人都使用 bazel 的。这样也是可能会阻碍，因为你的 BUILD 里的 deps 没法写。 这样的话，可以使用工具 gazelle 来自动生成 BUILD 文件。不过值得注意的是，要看好自己的 bazel 版本以及 rules_go 的版本，因为有可能 gazzle 编译出来的文件中会包含一些低版本中不具有的函数方法。

总结一下写 k8s TPR 遇到的坑，以及如何写一个 TPR。

TPR = ThirdPartyResource 虽然马上就会被 deprecated 了，但是整个过程还是能有一些借鉴意义的。

使用 TPR，可以在 k8s apiserver 里面注册一个资源，用户可以使用 yaml 描述这种资源。TPR 维护者可以通过 apiserver 感知到资源的创建、更新和删除。

Systemtap 允许开发者写一些简单的脚本来观察活动着的 linux 系统。能够检查一些复杂的系统以及函数问题。

linux 内核时间系统基于一个在每个时钟中断产生的时候增加的值。这个值是 jiffies。 jiffies 是时间中断发生的次数，每次发生时间中断，这个值就会被加 1。每秒中增加 HZ 的数量。 HZ，发生时间中断的频率，可以通过这样的方式查看grep 'CONFIG_HZ=' /boot/config-$(uname -r)。 比如在我的系统上，返回的是 CONFIG_HZ=250。也就是说，我的系统，每秒产生 250 次的时间中断，那么 jiffies 每秒就增加 250。 HZ这个值是可以配置的，配置得高的话，带来的好处是时间相关的调用会变得更精确，坏处就是，中断程序调用得更频繁，带来的消耗更大。

通过 /proc/timer_list我们可以看到一些时间相关的信息，可以看到 now以及目前 jiffies的值。

最近一件严重的事情 使用低版本的 go 程序，导致 sql 爆掉，api无法响应用户请求，引发血案。

其实我一直都还没仔细的学习过进程和线程，虽然资料很多，大多数教程都写了很详细的描述，还有一大堆相同点，不同点。可是看了还是云里雾里，理解不深刻，大概知道是什么个东西，但是真要谈起来还是有点问题。 这次就仔细深入的学习一下好了。