关注核心竞争力，用思考找到技术价值再动手做事，而非关注代码/项目本身
- 项目背景
- 为什么做这个项目？
- 目标和路径是什么？
- 其中技术亮点在哪里？
- 取得了那些收益？
- 目标与评估
- 可量化的目标是什么？
- 实现这个系统的技术约束是什么？
- 技术方案
大约 1 分钟
simplesql
simple sql database implement
simplekv
A simple KV database implementation
simplesrv
simple, high performance, easy to use web framework.
simplerpc
A simple, easy to use, high performance, pluggable micro services framework
tinyos
基于 risc-v 平台的简单操作系统，旨在学习 risc-v 和实践
用一种新的方式来学习 LSM Tree。
什么是 LSM Tree
一个老生常谈的话题
文心一言的解释是：
ChatGPT 的解释是：
综合来看，ChatGPT 的解释更加的直观，也更加符合工程师视角，而文心一言的解释更加适合做 PPT。
下面就跟随 ChatGPT 来学习 LSM Tree。
学习 LSM Tree
首先客套一下，提问：
大约 15 分钟
前言
之前有幸学习过徐昊的 TDD 课程，收获颇大，但是一直没有好的 idea 去实践，这次就用 TDD 的模式来实现一个简单的 Mybatis，取名为 TinyBatis。
TDD 流程
以下仅为个人理解，一千个读者就有一千个哈姆雷特，欢迎大家探讨。
TDD(Test-Driven Development)核心是一套指导思想。
大约 4 分钟
前言
上一篇文章探讨了 RGA 算法的原理与实现，本文我们将介绍另一种 CRDT 算法——YATA。
YATA 全称为 Yet Another Transformation Approach，于 2016 年由 Kevin 在论文 Near Real-Time Peer-to-Peer Shared Editing on Extensible Data Types 中提出。
大约 14 分钟
大约 14 分钟
前言
CRDT 全称 convergent or commutative replicated data type (CRDT)，是近年来分布式领域的新宠。
与其它分布式系统不同，CRDT 在设计上放弃了共识；这意味着一个 CRDT 副本执行操作时，完全无需与其它副本进行协商，大大提升了副本执行效率。
没有协商并不代表副本数据之间会有差异，CRDT 通过良好的数据结构设计来使所有副本最终达到一致，但前提是任何副本执行的操作都必须通过网络传输并应用到其它副本，即使这些操作到达时是乱序的，但最后的数据仍然保证一致。
大约 14 分钟
旨在探索分布式缓存的设计与实现
架构设计
目标
- 支持大容量缓存、持久化，PB 级别；
- 支持哈希槽分片，动态收缩；
- 支持 List，Set，String，Hash，Sorted set 等数据结构；
- 集成 Deno，支持脚本事务；
- 使用简单，redis-cli 客户端可直接使用，直连代理节点；
- 二次封装 redis 客户端，支持代理模式自动切换；
整体架构
distributed-kv 基于 Tikv 实现，并提供兼容 redis 数据结构的 API，支持基本 5 种基本类型数据结构，不支持 Pub/Sub，Pipeline 等高级特性，旨在探索超大容量缓存的架构实践。
大约 8 分钟
一步一步推导演进持久化磁盘队列的设计与实现。
在方向不明确，不够熟练的情况下，从 demo 做起，一步步学习先进的设计理念并付诸行动。
第一版，单文件持久化队列
- 元数据、堆数据存储在一个文件中；
- 元数据：记录读、写消费指针，队列大小；
- 堆数据：item 长度、数据；
- 元数据 + 堆数据单文件存储；
UML 类图：
读：
写：
大约 2 分钟
旨在探索 MQ 的设计与实现，掌握基本原型即可，不上升高级功能。
中间件三驾马车：数据库、缓存，MQ，是每个后端工程师都应深入理解的必备技能，同时也是工作、面试的常客。
自工作以来，笔者基本每天都在与消息队列（MQ）打交道，无论是模块解耦，流量削峰，还是事件通知，MQ 都太好用了。
彻底搞懂 MQ，这个目标一直都在，但苦于下面的原因所以一直没有实施：
- 工作内容又繁又杂，没有一个整块时间去思考与沉淀；
- MQ 选型众多，Kafka，RocketMQ，Pulsar 等都非常好用，但各有各的特点与不同；
- MQ 经过这么多年的发展，本来也越来越复杂，一头扎进去难免一叶障目；
大约 6 分钟
探索一个简单、易用RPC框架——tinyrpc的设计与实现
整体设计
RPC（Remote Procedure Call），全称为远程调用。一个完整的RPC架构分为了以下几个核心组件：
- Server：服务器；
- Client：客户端；
- Server Stub：服务端接收到Client发送的数据之后进行消息解包，调用本地方法；
- Client Stub：将客户端请求的参数、服务名称、服务地址进行打包，统一发送给server方；
大约 9 分钟