0. 概览

0.1 简介

入坑水族几年，和年纪无关…
修生养性，培养一个兴趣爱好，毕竟生命在于折腾
下班回家，看着鱼儿在水中游，喂喂乌龟，也蛮有趣

最近几天在折腾过滤，
进一步了解了一下过滤系统，
也有朋友在问养鱼养龟方面的问题，
于是就想着写一篇博客简单的记录一下。

不懂的多百度，设备什么的购物平台搜搜。
有兴趣可以逛逛：南美水族论坛、乌龟吧(百度贴吧)，等水族相关内容。

0.2 预防针

需要有一定的金钱投入，更重要的是精力投入，长期维护。

0.3 我的水族

• 鱼缸
  • 动物：宝莲灯、孔雀鱼、苹果螺、杀手螺、黑壳虾
  • 植物：小水兰、珍珠草
  • 过滤：伊罕滤桶
  • 灯具：LED 水草灯
• 乌龟缸
  • 动物：鳄鱼龟(互动性不错)、苹果螺、黑壳虾
  • 植物：石菖蒲、水竹、紫芋
  • 过滤：侧滤 + 沼泽 + 滴滤
  • 灯具：LED 水草灯

0. 背景

现有的长城 100M 宽带太寒酸了
之前的住户说想升级光纤都没办法
于是乎咨询了下联通可否装光纤
答案是可以，换个套餐就行

桥接的好处就是，光猫只做光猫该做的事情。
其它事情由自己的路由器进行设置并且管理。
这样即使你搬家什么的，路由器搬走，
任何设备都不用动，包括固定内网 IP 等
我主要的点是固定内网 IP，因为我由 NAS

1. 操作

1.1 改为桥接

这一步是需要联系安装宽带的师傅
他们远程可以直接修改
如果改为桥接，那么原有网络无法使用

重点

• 联系师傅索要宽带账号密码
• 要安装师傅修改光猫为桥接
• 修改之后进光猫后台较麻烦(不过用不到，都在路由器操作了)

0. 背景

由于目前经常需要登录数据库查询相关数据
每次进行登录一系列操作，有点费劲
于是乎想着看看怎么自动化

限制：需要在堡垒机进行操作

1. 知识

1.1 expcet

expect是一个自动化交互套件，
主要应用于执行命令和程序时，
系统以交互形式要求输入指定字符串，实现交互通信。

1.2 awk

Awk是一种便于使用且表达能力强的程序设计语言，
可应用于各种计算和数据处理任务。
入门指南

2. 脚本

2.1 自动登录脚本

说明：基于 expect
文件：mysqlLogin.sh

1
2
3
4
5
6
7
8
9
10
11
12
13

#!/usr//bin/expect -f
set ip [lindex $argv 0]
set port [lindex $argv 1]
set user [lindex $argv 2]
set password [lindex $argv 3]

spawn mysql -h$ip -u$user -P$port -p
set timeout 1000
expect "Enter password:"
send "$password\r"
expect ">"
send "use xxx_database\r"
interact

0. 背景

某做科研的朋友
需要对一些地点的坐标
然后在 WGS-84 坐标系的底图上呈现相关内容

BD09 vs WGS84
北京韩美林艺术馆,BD09:116.68347847243588,39.88148624000483
北京韩美林艺术馆,WGS84:116.67097966259838,39.87446583754102

1. 准备

1.1 寻找成品

找了几个网址，反馈说之前用过坐标不准确

1.2 使用百度地图 API

1.2.1 注册百度地图开放平台

服务免费
需要实名认证
网址：lbsyun.baidu.com

零、背景

鉴于目前 Redis 使用广泛
虽然数据结构、API 比较简单
但是想使用好，还是有一定难度
建议了解下《Redis 开发与运维》
以达到知其然且知其所以然的境界

一、使用场景

大规模互联网在线应用
流量比较大，响应时间要求高
Redis 作为一款流行的高性能数据库

对于读多写少的场景，一般作为缓存使用
某大型电商订单系统读写比大概在 10:1
并且订单读取 90% 的流量都是创建订单当天查询

对于可容忍丢数据，但是对性能有极致要求，
比如优惠券发放，流量高，这种情况下当做 DB 用也挺好。

二、问题与建议

2.1 常见问题

• 网络抖动导致 redis 操作失败
• 定时任务清理过期 key 导致 IOPS 高
  • redis 做了二次开发，更激进的惰性删除( 针对大面积过期场景 )
• 热 key 导致流量倾斜
  • 考虑 Server 端旁路监听，做统计，然后推送到客户端做内存缓存
  • 京东有开源热 Key 方案
• redis slot 分配不均匀，导致某节点提前内存告警
  • 建议分配内存按 slot 分配，而不是节点

2.2 建议

• 缓存时间动态可配

零、背景

最近在做重构的项目
进入阶段性收尾阶段
总结记录下相关的内容
方便大家遇到类似问题可以想起有某个地方可以参考

一、初识 AOP

目前的 AOP 应用，由于公司生态体系不够完善
利用 AOP + ThreadLocal(transmittable-thread-local，ttl)
做一部分链路追踪的事情( 耗时打印，traceId 处理 )
这部分倒是很简单，只是之前用的很少

PS：链路追踪蛮重要，针对排查问题，性能监控等大有帮助，多关注开源协议/实现( 如 CNCF )

二、初识 BeanPostProcess

2.1 应用场景

目前做的项目当中，有一个 IDC 负载均衡的工具
有设置当前机器所属机房的方法，但是没有提供从配置文件读取的能力
因为 IDC 路由不生效，会造成跨机房访问，导致访问延迟偏高( 回头再写性能优化相关内容 )

零、背景

最近在做数据迁移
为了加速迁移速度
其中就需要把查询到的数据( max 100 条)
拆分成 5 份，然后执行 5 个子任务，加速处理

一、代码

1.1 常规做法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public static <T> List<List<T>> split2(List<T> lists, int subCount) {
    if (CollectionUtils.isEmpty(lists) || subCount < 1) {
        return null;
    }

    List<List<T>> result = new ArrayList<>();

    int size = lists.size();
    int count = (size + subCount - 1) / subCount;

    for (int i = 0; i < count; i++) {
        List<T> subList = lists.subList(i * subCount, (Math.min((i + 1) * subCount, size)));
        result.add(subList);
    }
    return result;
}

1.2 新颖做法

零、背景

过年期间，看到 github 关注的人的动态当中
有人 star 了这个项目 Rust语言圣经
这些年也听说过 Rust，一直没有特意去了解
当我看到大佬也关注了这个课程的时候
感觉应该是一个不错的学习资料

前面介绍学习的好处让我心动了
就跟着学习了前面 4 节课
目前感觉良好
有空继续学

不得不说，环境搭建特别方便！

一、实践

零、摘要

回顾 2021

1. 【完成】换了一份不错的工作;
2. 【完成】坚持阅读，追求质量;
3. 【待办】运动量不够，锻炼偏少;

展望 2022

1. 体重控制在 65Kg 以内，学会自由泳;
2. 持续阅读，技术与非技术书籍交替看，5 本基础书;
3. 深入理解公司内部技术栈、深入了解 2-3 条业务线;
4. 重新学习 Dubbo，学习设计理念，以及分布式系统架构;

一、成长

技术方面今年感觉成长不是太明显
有所改变的是会深入洞察需求
逐步完善设计之后开始 coding，而不是着急开始。

对于技术底层也有一定地涉猎，更多地可能是在钻电商业务。

零、背景

同事分享《Effective Java》
其中第十章，并发部分例子有争议
变量是否需要(代码如下) static？
几个大佬说需要加，我众目睽睽下反驳不需要，略尴尬

// 是否需要加 static？才能保证单例正确
private volatile Singleton singleton;

一、程序关键代码

1.1 原程序(错误)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Singleton {
   private volatile Singleton singleton;

   public Singleton() {
   }

   private Singleton getInstance() {
      if (singleton == null) {
         synchronized (Singleton.class) {
            if (singleton == null) {
               singleton = new Singleton();
            }
         }
      }
      return singleton;
   }
}

1.2 正确程序