The Mirages

最近借着西贝的事情，魔都绿捷的学校供餐终于给捅出来了。

一家为魔都市500多所中小学及幼儿园提供营养午餐服务的公司，当然它的一举一动都会被大家看在眼里。一有问题跟西贝一样被放大是很正常的。

下面是魔都市政府采购网里找到的，当然这里只有2025年的，之前的估计是被隐藏了。

https://www.zfcg.sh.gov.cn/site/search?k=%E4%B8%8A%E6%B5%B7%E7%BB%BF%E6%8D%B7%E5%AE%9E%E4%B8%9A&type=0

不过现在AI这么发达，这些东西都能帮你查出来。这里是120个学校的，覆盖整个魔都。

那天我们是要去G331的乌云河桥下挖玛瑙。这里也是从嘉荫去茅兰沟的必经之路

但是乌云河桥这段一直在维修，不过整个G331是一堆路段都在维修。

我们开着车一直在找这个桥怎么从桥面往桥下走的地方。看小红书上说是过了桥后300米有条土路，但是我们走了过去，发现根本就到不了河边。于是又回来了。看着桥旁边有施工队，于是车就停施工队入口附近，但是也没挡着入口。

整个这一段路都是来去各一条车道的，所以千万不能直接停路上。停好后我们就过马路准备下桥了。突然施工人员开始喊了，这里不能停车什么的，我本来还牵着球球的手，被人这么一喊，球球就甩开我的手准备回去了，然后就听见一阵急刹车，车子停在了球球2米远的地方，球球在路当中有点不知所措，也不知道往前走还是往后退，车上驾驶员就开始骂了，怎么看的孩子的。

我赶紧过去把球球给拉过来了，直跟司机道歉，还好这是大白天，而且这一段一直修路，大家都开的比较注意，车速也不会快，不然真是后果无法想象。

当然这种事情也没法跟媳妇说，只能是我跟球球2个人的秘密了。

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

充电

话说当天住的酒店是带充电桩的，这样定的好处就是可以方便充电。可晚上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]}]
}