基于 Canal 监听 MySQL Binlog 并推送 Redis 队列的增量同步方案 # 在一些业务系统中，我们经常会遇到这样的场景：主业务数据写入 MySQL 后，需要把变更通知给另一个系统处理，例如数据同步、异步补偿、缓存刷新、搜索索引更新、历史数据迁移等。
最直接的做法是在业务代码里写同步逻辑，但这种方式侵入性强，而且容易因为代码路径复杂而遗漏。更通用的方案是基于 MySQL Binlog 做 CDC（Change Data Capture）：业务系统正常写数据库，独立订阅服务监听 Binlog，解析出变更事件后投递到消息队列或缓存队列，下游消费者再异步处理。
缓存 # # 简介 # 简而言之，即是数据存储的缓冲区。使用缓存之后，可以减轻访问数据库的压力，显著的提升系统的性能。
引言 # 在软件开发中，良好的版本控制实践是维持项目健康和可持续发展的关键。一个清晰、一致的提交历史不仅可以加强团队合作，还能提高代码的可维护性。本文将介绍 Conventional Commits 规范，一种帮助您实现这一目标的提交信息格式规范。
什么是 Conventional Commits？ # Conventional Commits 是一个轻量级的、社区驱动的提交信息格式规范。它的核心目的是使提交信息更加可读和易于理解。遵循这一规范，可以让您的 Git 历史成为一个清晰的故事，而不仅仅是代码的变更记录。
Conventional Commits：让您的Git历史更加清晰和有意义 # 引言 # 在软件开发中，良好的版本控制实践是维持项目健康和可持续发展的关键。一个清晰、一致的提交历史不仅可以加强团队合作，还能提高代码的可维护性。本文将介绍 Conventional Commits 规范，一种帮助您实现这一目标的提交信息格式规范。
用户密码方式验证登入过程分析 # 客户端ssh向服务器发送连接请求，传递用户名及ip端口 服务端接收到请求，检查用户名是否存在，不存在则拒绝。反之，会将公钥及指纹（公钥对应的sha256值）发送给客户端 若客户端是第一次请求连接，则会提醒用户确认该指纹是否来自目的服务器，若用户输入yes确认则会将指纹存放到known_host中，下次再连接时，当发现服务器传过来的指纹与已存入到known_host中的指纹一致，则服务器身份直接验证通过，无需提醒确认。反之会发出警告：提醒说该公钥和指纹可能是由于中间人拦截而被篡改的或者可能是服务器更新了新的公私钥对。 客户端完成公钥接收及指纹对比后，需要输入密码，将密码使用服务器公钥进行加密发送到服务器，服务器私钥解密验证成功则允许登入。 公钥身份验证登入过程分析 # 客户端在本地生成一对密钥，包括一个公钥和一个私钥。且将自己的公钥放到到服务器上的 ~/.ssh/authorized_keys 文件中 客户端ssh向服务器发送连接请求 服务端检查用户名存在后，生成一个随机串返给客户端 客户端自己的私钥对随机串进行签名并发送给服务器 服务器使用已存入authorized_keys 中的公钥进行验签，若验签通过则客户端身份认证成功
Http # jsonp # 概念：浏览器通过script标签中src属性向服务端发送执行函数的名字，服务端根据函数名、服务端数据，拼接成一个函数调用的字符串给客户端script标签执行，这称之为JSONP
特点：
gRPC 四种模式及应用场景 # 在 gRPC 中，RPC 调用模式有四种，每种模式适用于不同的业务场景。下面将详细分析这四种模式及其对应的应用场景。
参考官方文档概念：https://grpc.io/docs/what-is-grpc/core-concepts
1. 简单 RPC (Unary RPC) # 模式描述 # 客户端发送一个请求，服务端返回一个响应。双方的通信都是一次性的。
控制反转 IoC 与依赖注入 DI # 引入 # 讨论之前，先来简述一下软件对象中的耦合
Kafka 简要技术博客：从消息模型到 Go 实践 # Github 地址
背景 # Kafka 是一个高吞吐、可持久化、分布式的发布订阅消息系统。它常被放在业务系统和数据处理系统之间，用来承接事件流、日志流、指标流和异步消息。和传统“发一条、取一条”的队列相比，Kafka 更强调顺序追加、分区扩展、按偏移量消费，以及消息在一定保留周期内可重复读取。
etcd 简要技术博客 # Github 地址
一、etcd 是什么 # etcd 是一个使用 Go 语言实现的分布式、高可用、强一致性的键值存储系统。它常被用作分布式系统中的协调组件，用来保存配置、服务节点信息、租约状态、锁状态等小体量但高价值的数据。