关于知识付费关于知识付费，几年前知识付费这个词就已经流行开了。我也体会过为知识付费带来的眼界和认知的开阔。但是后续并没有积极主动地为付费性知识买单，反而热衷于在开源和免费中提升自己。我思考过为什么会这样，也许和从小到大的教育环境、生活环境有关。 从小被教育：好好学习，上大学才能找好工作，才能衣食勉强无忧（二十年后发现住行未必）。 在这种意识影响下长大，会形成一种因果观：因为要有钱生活，所以要学习知识。 所以，在我后来的人生中，因为我身上还穿着五年前的衣服，所以我没报名这个课程；因为我还在纠结哪个店的外卖优惠大，所以没买那本书；因为我刚刚买了房要还房贷，所以我不能够再考深造；因为我得几年内买个车接送孩子，所以我不去关注各种行业内峰会。 这是对的么？这是不得不。 我做不到穷其一生节衣缩食追求精神世界的提升，而阶段性的提升完全可以从非付费的知识中获取，所以这就是我自身的情况。 正常以我的性格，这段文字是不会公布于众的。但是看到现如今的互联网评论圈风气，又不由得杞人忧天，大概率会有两极分化，一方面是怒斥白嫖党的，一方面是感同身受的。 我只想说：其实都对，做好你自己。

jasypt 配置文件加密接入记录新来的同事接手项目，第一件事是看 application.yml，然后过来问我：”数据库密码直接写在这里没问题吗？” 他说得对。项目跑了一年多，数据库密码、Redis 密码、第三方 API Key 全是明文，所有有仓库权限的人都能看到。内网项目风险暂时小，但这是隐患，审计时也会被标出来。于是接入了 jasypt 解决这个问题。 一、问题背景为什么选 jasypt 而不是其他方案： Spring Cloud Config + Vault：太重，为了加密几个密码引入一套配置中心不划算 自己实现解密 Bean：重复造轮子，且团队间不统一 jasypt-spring-boot-starter：一个依赖搞定，ENC() 包裹密文，对业务代码零侵入，接入成本极低 适用场景：Spring Boot 项目，application.yml 里有需要保护的敏感信息（密码、API Key、Token）。 二、接入步骤引入依赖<dependency> <groupId>com.github.ulisesbocchio</groupI ...

MySQL 主从复制搭建记录团队项目到了一定规模，读写压力开始明显，需要做读写分离。搭主从是前提，这里记录用 Docker 搭建 MySQL 主从复制的完整过程。 1、基于 Docker 部署 MySQL# 启动 MySQL 容器，命令行参数直接开启 binlog 并设置 server-id，免得改配置文件docker run -p 3306:3306 --name mysql \ -v /home/mydata/mysql/db:/var/lib/mysql \ -v /home/mydata/mysql/conf:/etc/mysql/conf.d \ -v /home/mydata/mysql/log:/var/log/mysql \ -e MYSQL_ROOT_PASSWORD=123456 \ --restart=always \ -d mysql:8.0.27 \ --lower_case_table_names=1 \ --server-id=3306 同一服务器部署多实例时，映射到不同的主机端口，server-id 各不相同。 2、主从配置说明主从 ...

Docker 存储驱动（Storage Driver）差异对比把一台旧服务器上的 Docker 服务迁到新机器时，发现两台机器的 docker info 输出不一样——旧机器是 devicemapper，新机器是 overlay2。当时觉得「反正都能跑」就没管，直到旧机器上某个容器内大量小文件写入变得极慢，才认真研究了这个话题。 一、为什么要关心 Storage DriverStorage Driver 决定了 Docker 镜像层和容器可写层的存储与管理方式。选错了： 性能问题：大量小文件写入场景，不同 Driver 的吞吐差距可以达到 3-5 倍 稳定性问题：旧版 devicemapper 的 loop-lvm 模式在生产环境经常出现 IO 等待飙高 兼容性问题：旧内核不支持 overlay2，迁移到新机器后行为不一致 大多数时候，现代系统装好 Docker 默认就是 overlay2，不需要手动干预。但遇到旧机器或高 IO 场景，值得花 5 分钟确认一下。 二、三种主流 Driver 原理简述overlay2基于 Linux 内核的 OverlayFS，采用联合挂载（Un ...

RabbitMQ 使用记录项目里有订单超时取消的需求，用定时任务轮询太暴力，就引入了 RabbitMQ 的延迟消息来做。记录安装和接入过程，重点是延迟队列（死信队列）这块的配置。 RabbitMQ 是一个轻量级且易于部署的开源消息队列，支持多种消息协议，可部署在分布式和联合配置中，满足高规模、高可用性需求。 核心概念： Exchange（交换器）：direct（单播）、fanout（广播）、topic（组播，# 匹配多单词，* 匹配一单词） Queue（队列）：消息暂存的地方，消费者从这里取消息 安装Linux（Docker）docker run -d --name rabbitmq \ --publish 5671:5671 \ --publish 5672:5672 \ --publish 4369:4369 \ --publish 25672:25672 \ --publish 15671:15671 \ --publish 15672:15672 \ rabbitmq:3.7.15-management 开启管理界面插件（如果用的不是 manageme ...

带了四年团队，我才搞清楚什么叫技术管理一、2017 年，我以为技术管理就是……2017 年我第一次主导一个项目，那时候的项目规模不大，三个后端，一个前端，一个测试。 我的管理方式很简单：把需求拆成任务，分给每个人，定好时间节点，然后盯着代码提交。每天晚上我会看一遍大家的提交记录，如果代码逻辑有问题，我会直接在 Review 里改掉或者告诉他们怎么改。 我当时的判断是：项目能按时交付，代码质量过关，这就是管理好了。 有一次一个新同学交了一段代码，判断逻辑嵌套了四层 if-else，我直接在 Review 里批了几条注释，把正确写法贴上去，附了一句”这样更清晰”。他改了，改完没有说什么，项目也按时上线了。 我以为这件事到此为止了。 二、几年后发现不对劲的地方大概 2019 年前后，团队扩到了七八个人，我发现一件奇怪的事：技术方案层面出问题越来越少，但整体推进却越来越费力。 需求讨论会开完，大家回去做，做完了才发现理解不一样。不是哪个人的问题，是同一段话，不同的人读出了不同的意思，但没有人在开会时说出来。 Code Review 提了意见，有人改了但下次继续犯同样的错误，好像那个 Revie ...

接入 Redis 是我做 Java 后端绕不过去的一课。最开始只是单纯地用它做接口缓存，后来随着业务复杂度上升，开始用到分布式锁、Spring Cache 集成，也踩过几个生产环境里让人头疼的坑。这篇文章是当时的使用记录，整理成了速查手册的形式，方便之后翻阅。 基础命令select 0 # 切换数据库（默认 16 个，编号 0~15）keys * # 查看所有 keyset key value # 插入或更新get key # 获取值del key # 删除exists key # 判断是否存在expire key 60 # 设置过期时间（秒）ttl key # 查看剩余过期时间（-1 永不过期，-2 已过期/不存在）type key # 查看数据类型flushdb # 清除当前库flushall # 清除所有库（ ...

Nginx 使用记录项目部署阶段开始接触 Nginx，主要用它做反向代理和前端静态资源托管。记录安装方式和几个用过的配置，备查用。 安装配置网上大多数教程是官方包编译安装，这里记录 yum 安装方式和 Docker 中使用，实际项目用得更多。 一、Linux 直接安装（yum 方式）1、添加源 CentOS 7 默认没有 Nginx 源，从 Nginx 官网添加： rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm 2、通过 yum search nginx 确认源添加成功，然后安装： yum install -y nginx 3、启动并设置开机自动运行 systemctl start nginx.servicesystemctl enable nginx.service 4、查看版本和主要路径 nginx -v# nginx version: nginx/1.18.0 5、常用路径 Nginx 配置路径：/etc/nginx/P ...

五年后，我重新画了一遍自己的技术地图一、触发这次盘点的契机2021 年春天，我参加了一次内部的技术分享，主题是 Redis 集群高可用。 讲的人是外面请进来的，讲了一个小时，主从复制、哨兵、Cluster 模式讲得很清晰。我坐在下面，大部分内容都听懂了，但有几个问题让我不舒服： 他问了一句：Redis Cluster 的数据分片是怎么做的，哈希槽有多少个，怎么分配的？ 我愣了两秒。Redis 我用了两年多了，缓存、分布式锁、消息队列，每天在用。但哈希槽这件事，我说不清楚——我只知道它在做分片，但分片的细节我从没认真看过。 会后我回到工位，查了一下，发现答案其实不难，16384 个槽，按 CRC16 对节点数取模分配。五分钟就搞定了。 但让我难受的不是这个知识点，而是这件事暴露的一个模式：我用了两年的东西，有大量的”我以为我懂其实没深入过”的盲区。 那天晚上我在本子上写了一行字：到底哪些东西我是真的懂，哪些只是会用？ 二、我的技术地图现状诚实地分了两列： 真正懂原理（能解释，能排障，能在不同场景下设计） MySQL：索引结构（B+ 树）、事务隔离级别、MVCC 原理、锁机制、主从复制基 ...