我们有时会在一些大公司的数据库规范里看到说MySQL单表的数据量最大不能超过两千万，超过了就要进行分库分表，不然就影响查询性能。这种说法是否有依据，为什么是两千万，而不是五百万、五千万，有没什么场景下即使存储一亿行数据也不会有性能问题。这篇文章就是想要来解答这个疑问的。

在如今设计分布式系统的时候，我们通常会采用消息队列来作为请求的中间件，削峰填谷、异步处理和服务解耦是其核心作用，而消息队列又有点对点模型和发布与订阅模型，这里就不对这些基础概念不做过多解释，可以自行google。而在消息队列的选型上，目前大多都偏向于Kafka。

在分布式支付系统中，一个常见的挑战是避免双重支付，即同一笔交易被错误地处理两次。简单来说，就是当你在app上点击支付后，因为各种原因使得app上没有收到支付是否成功的结果，此时用户完全可能重复点击支付按钮，如果我们的系统没有很好的处理这种情况，将很可能导致用户被重复扣款，这是非常严重的问题。

事情的起因是这样的，最近在RSS上订阅了一些博主，偶然发现有个博主还有一个自己的照片网站，就是把自己拍的照片放到自己的网站上，我觉得蛮有意思的，要不也给自己搞一个。那网站的照片放哪呢，为此去花钱买个对象存储也不值得。所以我就去翻了下cloudflare的网站，不愧是互联网里的活菩萨，它提供的对象存储（即R2）每个月有10GB的免费额度，还不限制访问流量。我一般是用手机拍照，一张照片通常在4MB左右，也就说在R2上可以存储2500多张照片，这不用太浪费了。

相信每个程序员多少都遇到这样的场景，需要将磁盘上的文件读取出来然后发送给客户端。要实现这样一个功能并不难，基本上每一门语言都提供了对操作系统的IO操作的类库。不过如果我们的场景换成是如何在高并发的场景下，为客户端提供读取文件的操作时，可能在实现上就没有那么简单了。

数据复制在分布式数据库是老生常谈的事，几乎所有数据库都会支持数据复制，以实现数据系统的可靠性。我们在设计自己的分布式系统时，也应该关注这块的知识。最近在看《数据密集型应用系统设计》这本书，其中第二章详细介绍了这块的知识，因此想对这部份做下记录。

后台开发中，大多数工作都是建立在网络通信这个过程中，客户端发起连接的请求后，服务端接收客户端的请求数据，服务端处理后给客户端返回响应，然后关闭连接。在这个过程中，网络可能会存在各式各样的问题，导致我们无法正常返回响应，也可能有一些异常的场景导致服务器性能受到影响。因此本文想整理下服务器端在可能会存在的异常场景，以及应对的方式。

Mysql中存在好几种日志，其中bin log、redo log、undo log被用于支持数据库的可靠性，例如数据备份、崩溃恢复等，今天来认识下这几种日志。

如何保证数据库的数据和缓存中的数据的一致性。也就是说，当我们对数据库中的数据进行修改后，此时缓存的数据已经与数据库中的数据不一致，如何修复这种不一致的状态。显而易见，不一致的场景都是出现在缓存中已经存在数据的情况，接下来我们就以这个来分析实现数据一致性的各种方式。

Redis虽然是以单线程高性能著称，在一些可能会影响到性能的场景下，redis都做了很多优化来避免主线程受到阻塞，例如开辟子线程来处理。不过即使如此，也依旧有很多场景可能会导致主线程受到阻塞进而影响到系统的吞吐能力，尤其是海量业务场景下，更有可能发生。因此本文想梳理下这些场景，帮助自己在后面的工作能够关注这些场景。

SOLID 是面向对象编程和设计中的五个基本原则的首字母缩写，旨在提高软件开发的可维护性、灵活性和扩展性。本文将基于Go语言给出这个五个原则实现，加强对这五个原理的理解。

在现代软件开发的世界里，可维护性不仅是代码质量的标志，更是项目成功的关键。想象一下，一段精心编写的代码，它能够在不断变化的需求和技术前景中稳如泰山，这不仅减少了维护成本，也极大提高了软件的生命周期。而当代码运行在生产环境中，面临着不断的挑战和意外情况时，可维护性也显得尤为重要。一段易于理解和修改的代码，可以让开发者在面对紧急问题，如性能瓶颈、安全漏洞或突发故障时，迅速定位并解决问题。这不仅提升了应对紧急情况的效率，也确保了系统的稳定性和用户体验的连续性。

git merge应该是大部分人合并分支的方式，可能很多人也只知道这种。但除了merge的方式之外还有rebase的方式，你知道这两种的区别么？是否知道这两者的应用场景呢？ 而当分支合并之后，或者你提交的代码被发现存在问题之后，你知道如何回滚么，知道git revert如何使用么？ 本文想通过几个简单的例子来帮助理解几个常用的分支合并和回滚指令，即git merge、git rebase和git revert的使用。

做后台开发的都知道，当我们需要对服务进行重启，例如升级发版、异常重启时，会面临到有新的请求在不断进来，同时当前可能还有请求还未处理完成，如果此时直接对服务进行关闭重启，是有一定风险的。尤其是一些写操作，可能会造成数据丢失或损害。 正因如此我们应该等到请求都处理完成了才进行程序的退出，本文接下来就来介绍下在go语言中，针对http服务的场景如何进行优雅的程序退出。

我的一些开发环境配置

本文重点介绍grpc的底层原理

从一个简单的例子开始学习go的接口

grpc是google于2015年开源的rpc框架，它具备标准化、可通用和跨平台的特点。这些特点使得不同微服务间可以方便的进行调用外，还支持可拓展的负载均衡、链路跟踪、健康检查等特性。而底层的通信，grpc采用的是HTTP/2来进行，性能和效率上能够得到充分的发挥。grpc也加入了CNCF（云原生计算基金会），逐渐的也成为了主流的社区上rpc框架。

一步步了解什么是HTTP2

用一篇文章带你一步步认识go context