The Mirages

在上个月在东北游记中，有一段旅程是在阿尔山，而阿尔山也是我们唯一一个连住两天的城市，其他城市我们基本都是就一天，或者当中隔一天什么的。

充电

话说当天住的酒店是带充电桩的，这样定的好处就是可以方便充电。可晚上6点多的时候去充，发现一辆小米和一辆tank在充，等吃完晚饭发现变成了一辆大众ID3了，而且已经充满了。

于是找了下酒店老板，问有电话不，老板说确实是酒店客人的，但是具体这车是谁的他也不知道。车挡风玻璃上也没有留电话。

在老板的见证下把充电拔了，我就停外面点接上快充了。大概一个小时候充完了，我就把车挪好了。

晚上11点半的时候突然接到当地兴安盟的一个手机号，接了说是酒店老板的，说警察在楼下了。得，还得穿好衣服下楼，还好是夏天穿的少点。

新工体从来没有去过，这次接着跟球球看球的机会算是进去了一次。也学习了下以后如何选择座位了。

下面这个是官方的座位安排。其中126,234,235,334,335 这些都是给客队球迷的。125,127,236,2336,333以及部分124,232,332,337,128,237都是隔离看台。主要是害怕球迷之间互相闹事。

剩下白色区域才是散客购买的。

这里要说的就是高层也就是3xx区域的选座，毕竟都是穷人，能买100多的就买100多的。

从下图中我们可以看到，这个3xx区域的第一排（也就是票上的11排）是有个4层的护栏，这个是非常影响第一和第二排视线的，第一排的可能还能站着，这第二排就没戏了，第三排刚好越过。

这是2025年的数据库大会，现在这种会基本没有人说oracle，db2, sql-server这些老东西了。大家全部都是信创，全部都是自主知识产权。比如磐维,openGauss,亦或是总经理刚被抓的达梦。

不过感觉这会现在怎么有点抠缩呢，3000元的票现在就是20元快餐了，而且也不每人送个包，送个本啥的。想想以前oreilly举办的velocity大会，这分享嘉宾很重量（当然当年国际形势也不同），中午自助餐也很给力。

云厂商们因为内部都是自有协议，所以还都基于自己内部网络做了存算分离，并且在这条路上越玩越花了。

传统的还有clickhouse来了，大概聊了下，原来他们在国内某云上的集群对应的对象存储还是某云单独给搭建的。就是为了防止把oss全部打挂了，据说历史上还真打挂过。不过clickhouse很多花的玩法之前都没有用过，后面可以都试试。

还有一些广告的，比如什么eloqkv，说是冷数据可以存放在对象存储上，结果这个功能是付费版，免费版跟tendis一样都是本地磁盘。不过后面我也可以测试这些区别，比如Dragonflydb这些都可以再搞搞，

这些都是可以支持集群版，也都支持ssd存储。但是细节肯定有很多区别的。不过这些先看看文档再说。

整体线路如下：

由于当时从漠河到满归的道路被大水给冲垮了，所以当时只能从加格达奇区绕一下，这样绕行大概200KM多吧，现在是已经通了。

而这次其实主要就是围绕这大兴安岭和小兴安岭地区。

第一天因为上午10点有个面试，一直面到11点半，所以从12点才出发，一直开到了辽宁阜新，到阜新也已经晚上8点多了。

注： 本文是学习《kubernetes in Action中文版》的学习笔记.

这里主要是了解kubernets如何做到服务的多副本高可用，一个是部署的时候，一个是发布更新的时候。

部署的时候我们最基础的是需要多个副本，然后最好是每个副本都在不同的物理机，rack，或者az里，这样可以最大限度的保证高可用。

所以我们这里就是朝着这个方向去努力。

后面我们再分析kubernetes里pod的资源限制和使用的问题。

ReplicationController

监控对于任何一个互联网产品是重中之重。无论你是ToB的产品，还是ToC的产品，监控永远是一个必须项。没有监控的产品那不就跟裸奔一样。

那我们如何来评估一个监控产品呢？以下是按照一个完整的监控系统去评估的，对于有些单机部署的产品，那我们完全可以舍弃其中一些指标，从来选择各适合自己产品线的监控系统。

在OOP里我们一般使用4个指标来度量。

1. 耦合性
2. 内聚性
3. 充分性
4. 完整性

那监控系统是否也可以按照这些指标呢？

1. 耦合性： 这个应该是衡量的一个指标，如果一个监控系统对于现有系统侵入性太高，那必然会增加集成难度，易用性也会大打折扣，带来的结果就是无法广泛使用。
2. 完整性：这个是任何一个监控系统的基本要求了。要是监控的内容都不完整，那这个监控系统也可以跳过不用了。但是现在随着各个系统越来越复杂，所以为了保证完整性，一般现在的监控系统都会有主动上报和接收上报的功能。
   1. 主动上报：这些就是跟硬件和操作系统相关的监控项的上报。还有一些标准中间件的上报。
   2. 接收上报：提供api接口或者其他方式来接收其他程序推送过来的监控内容。这里当然要支持不同的metric类型，比如Counter，Gauge等等这种类型
   3. 容器接收：是否能够接收容器内上报的相关指标
3. 充分性：针对监控系统来说，也就是可靠性。不能监控项已经宕机很久了，但是监控内容还是正常，或者明明已经宕机了，但是却无法展示出来。这个之前有碰到过有公司设计的数据报警就是这样的，都是从本机发起的监控，这种一旦自己网络有问题，要么自己没发现，要么自己发现了但是也无法推送出来。导致监控失效。
4. 内聚性：通俗的说就是只是包含监控，不包含其他的。那这个因为是产品级别了，所以大部分问题都不大。这里可能就涉及到监控系统内部各个服务的评估是否符合内聚性。

整体路程是这样的：

成都走高速到映秀镇，然后走G350（中国熊猫大道）到四姑娘山双桥沟，然后再从双桥沟出来继续走G350转G662（理小路）到理县，然后走高速到汶川和成都。

成都

不过我们也是从成都出发的，但是成都虽然以前来过，但是从来没有看过川剧，于是这次就补上了这个，我们就住在四川省川剧院旁边，于是就去了。

川剧也叫蜀剧，也是地方戏剧的一种。

一开始就来了段三英战吕布的桥段。然后是各种当地杂技什么的。不过川剧最有名的就是变脸。这次真的是看的太过瘾了。

近日要搞kafka集群降配，因此要检查一下这个kafka集群的所有topic是否副本数有等于1的。

1

./kafka-topics.sh --zookeeper timoq-zk1:2181 --describe | grep 'ReplicationFactor:1'

这样就能列出来，果然有几个topic还是1个副本的，那个就开始搞成2个副本。其实kafka可以给你生成的副本配置的json的。

1

./kafka-reassign-partitions.sh --zookeeper timo-zk1:2181 --topics-to-move-json-file topic-generate.json --broker-list "0,1,2,3,4,5,6" --generate

但是这种生成出来的json文件无法跟现有的对照起来，我是希望现在分区谁是leader，后面还是leader，于是就手动写了个json文件。

1
2
3
4
5

{"version":1, "partitions":[
{"topic":"timo_log","partition":0,"replicas":[3,4]},
{"topic":"timo_log","partition":1,"replicas":[5,6]},
{"topic":"timo_log","partition":2,"replicas":[6,7]}]
}

ffmpeg 是一个非常庞大的软件，而且依赖关系太多了，导致还是自己打包一下，把对应的依赖包都打进去，这样省的后面搞依赖了。

由于贵司现在还有centos7的服务器，而且还都运行的非常好，因此只能打包ffmpeg6的版本，7还有很多依赖的东西比较底层，不太好搞。

依赖包编译。由于我最终ffmpeg是安装到/usr/local/ffmpeg-6.1的，所以就需要把这些依赖包都安装到这个目录下。因此我的这些第三方依赖库的编译都会添加

1

--prefix=/usr/local/ffmpeg-6.1/third

这些第三方依赖就不单独说了。主要说说ffmpeg本身的编译，因为你的第三方依赖包都在 /usr/local/ffmpeg-6.1/third 目录下，因此编译的时候需要进行一些调整。

其实就是把third目录下的这些lib加进来

早上5点多被电话直接吵醒，说是aliyuncs.com这个域名无法解析了。需要赶紧处理。

可我们也没有收到对应报警啊。

整个事情的时间线

1. 02:57：监控发现 aliyuncs.com 域名解析异常，被劫持至安全组织Shadowserver的服务器（ sinkhole.shadowserver.org ）。
2. 04:04：工程师确认劫持原因为国际执法机构通过域名注册商威瑞信（ VeriSign ）强制修改解析。
3. 08:11：解析异常修复，但全球 DNS 缓存刷新延迟导致部分区域持续故障。
4. 09:00：受影响云服务（ OSS 对象存储、CDN等）基本恢复。

但是实际上一直到中午12点海外还是有很多地区没有恢复呢。

我们通过这个可以发现，在发现后的1个小时内阿里云的工程师才找到原因。这个是十分失职的。