Loading...

2022年11月第二周周报

这周又拖了一天周报,下次不能继续了(肯定要拖的

  1. 本周早睡一周,感觉元气满满
  2. 肠胃又在闹肚子。。
  3. 本周的娱乐时间
    1. 德凯没有更新不开心
    2. 间谍过家家 EP 19 ,说实话有点过于无厘头了
    3. 登山少女继续,不愧是和摇曳并列的神
    4. COD19 最近在练连狙刷墙,EBR-14 手感其实挺不错的
    5. 这周 Links 又出新的视频了,啊啊啊,我想去欧洲玩!
  4. 本周和妹子的纪念日!一起美滋滋的吃了西塔老太婆的烤肉,以及 saka 钦点蛋糕供应商廿一客!好吃!
  5. 家里的缅因又有点小毛病,头疼
  6. 给老妈买的两个首饰到了,被她傲娇的说浪费钱(嘿嘿嘿

蛋糕

烤肉

生病的大猫猫

首饰

技术

这周的我 be like:我的内存条怎么上不了 5600 Mhz 的频率啊

  1. 本周在折腾台式机
    1. 我的台式机用了 DDR5 5600 32G * 4,不过默频一直只能4800Mhz
    2. 尝试了反复调整电压,从 1.25 到 1.35 都试过,就是上不了 5600Mhz
    3. 后面默频 4800Mhz 跑 memtest86 test7 反复 failure
    4. 最后经过多方查证,应该是 D5 四通道兼容性的锅,估计要四通道超频的话,只能去 D4 了
  2. 本周把 NAS 的硬盘插满了,现在整体的配置就 16T 2 组 RAID 1,存放重要资料,16T 6 RAID0 放娱乐(,然后硬盘统一的都是 EXOS 企业盘系列,这下可以不折腾了,再折腾我是狗
  3. 看了下 40Gbps + RDMA 的资料,为明年家里走全光 40Gbps 改造打基础(汪汪汪
  4. 本周再基于 PEP517 的实现 PEP517 写一个静态版本分析的工具,主要场景是在推动业务升级框架的时候发现潜在的版本冲突。举个例子,我们现在 Celery 是 4.x,依赖 Kombu 4.x,如果要升级 Celery 5.x 需要升级 Kombu 5.x,但是 Kombu 5.x 锁了 redis client version > 3,而我们另外一个库锁了 redis client version < 3。这种版本冲突就需要提前的进行分析,不能无脑升级
  5. 这周在做 Redis 从主从模式迁移到集群模式的操作,感觉可以作为一个经典的面试题(SRE/研发通用),这不比八股文舒服多了,简单聊下我的思路
    1. 核心还是在于说避免关键实例迁移导致的缓存雪崩,所以缓存内容需要迁移,这里有两种方案
      1. 离线脚本导入
        1. 优点,实现简单,业务改动小
        2. 缺点:
          1. 离线扫 Key 可能会影响原本实例的读写
          2. 业务代码还是会有改动,在离线脚本跑完到业务上线这段 time gap 里,缓存淘汰数量不可预测
      2. 业务双写
        1. 优点:
          1. 双写可以比较好的控制缓存的淘汰数量
          2. 对原本库的负担小
        2. 缺点:
          1. 业务代码改动大
          2. 会略微增大一些请求延时
    2. 如果采用方案2进行迁移,那么怎么样确定切换时机
      1. 经验法,在 time = 10 * min(1h, maxTTL) 后进行迁移,这个时间可以根据实际情况调整,确保缓存都被 warm up 了
      2. 在2的基础上增加双读,先读新库,fallback 老库,输出缓存命中率 metric,当新老 metric 趋于一致时,可以切换
    3. 需要注意 Key 冲突的问题
  6. 这周给公益群的小伙伴做了一个简单的分享,简单聊了聊家用网络规划和存储方案设计,科普向的一些东西,反馈还不错
  7. 这周 KubernetesPR107531 几个 PR 终于合并了,Liggitt 好人!
  8. 书的进展还不错,Chap 2 翻译完了,差不多一周多一章吧,后面可能还有提速的空间
  9. 看完 It’s Time to Replace TCP in the Datacenter 这篇论文了,好玩。作者上来一个 “Everything about TCP is wrong” 以及 “TCP is beyond repair” 笑死我了,但是仔细想想,一些场景下又很难不确实。作者主要还是讨论在大型 datacenter 的场景下,高速设备里(10Gbps or more),tcp 的一些局限性
    1. 面向流式的设计,导致在 datacenter 的场景下,大量的 rpc 小包会吞吐很差,应用需要频繁 check boundary, 容易造成 hot spot
    2. 面向链接的设计,让负载均衡变得很难。要做链接共享有额外的 overhead。
    3. 拥塞控制是由发送方来做的,这导致在网络环境变化的时候,发送方很难及时的感知到变化(比如交换机队列阻塞了,此时发送方并不能第一时间进行调整)
    4. 不支持乱序的特性导致 Load Balancing 很难做,很容易 Hot Spot,比如你在做负载均衡的时候,你必须保证同一个五元组的 target 是一致的,不管它负载如何(实际上也是流式设计的副作用)(Google 那篇 Maglev 的论文讨论了具体的实现方案)

差不多就这样吧,这段时间摆烂有点严重,要好好思考下明年个人的 OKR 了

群内分享

爽

爽

总结

最近疫情太反复不定了,大家一定要多保重,有机会一起约饭呀!

晚安~


Comment