你作为一个后台开发正在负责维护一个网站或者APP，某一天运维突然告诉你我们要升级数据库的版本，你上报Leader后，此时Leader让你给出一个升级的技术方案。于是你脑袋一拍说我们可以夜间停机升级，此时的用户访问量低。如果是小应用，这样做倒是无妨，如果你运行的是一个大型应用，即使在夜间用户的访问基数也相当大，停机升级则肯定不是个能让领导们接受的方案。如果你的应用还是像uber这样一个需要跨全球多个时区，那几乎24小时都有大量的用户在使用。 这次就来看看uber是如何解决这个线上不停机无损升级的。

最近去日本关西玩了几天，旅途从神户、大阪、京都到奈良，每个城市都给我留下了非常深的印象。人总是扛不住年纪大了之后记忆的退化，所以在回来之后，就想对这段旅程做一些记录。这不是攻略，而我实际也没去到很多攻略提到的地方，只是想记录我对这个国家的一些观察。

最近读了一本书，叫《如何找到想做的事》，作者是八木仁平。这书也就三百多页，我花了两个多个小时把它看完了。总的来说就是作者用自己构建的一套自我认知体系推导出了两个”找到想做的事“的公式。虽然这书在微信读书上评分不高，但我觉得里面的一些观点和认知还是挺值得借鉴和思考的，尤其是当自己比较迷茫的时候，或许是可以作为一些参考的方向。

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

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

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

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

Blog，也就是博客，也有被称为部落格，在移动互联网兴起前，曾是一种主流的表达自我的方式，尤其是一些有一定知名度的人。我那个时候就会时不时的去看五月天的阿信写的博客，那时候他用的是新浪博客，也经常被他的文笔折服。后来移动互联网开始了，微博、朋友圈出现后，博客就慢慢的淡出了公众的视野了，至少在非互联网的圈子里俨然已经是一种过时的表达方式了。而曾经的那些大V和明星，也不再在这些平台表达自己的想法和情感，当然这也可能是和现在的互联网环境和曾经大为不同的原因导致，有些时候小小的事情可能就会引发很大的舆论。

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

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

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

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

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

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

好多年没写个人的年终总结了，上一次写还是2016年初的时候写给2015年的，内容主要还是围绕工作在写。为什么今年又有了想写总结的冲动呢。一方面是觉得今年在很多方面有了新的认知和想法，另一方面也是成为人父后身份的升级，在生活上有了更多的体验。也因此这次的总结我想从不同的层面来写，也算是一个多个方面的回顾了。

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

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

每个人都希望自己能够养成良好的习惯，例如希望自己能养成健身的习惯，养成阅读的习惯。也有很多人希望自己能够改掉已经养成的不良习惯，例如改掉刷短视频的习惯，改掉抽烟的习惯。可是大家好像对一个行为之所谓能成为习惯的原因却一直没有了解，只是简单的认为，我们只要逼着自己重复的去执行一件事情，它就能成为习惯。

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

《金钱心理学》应该是今年在商业类书籍里很热门的一本书了，其实我一直都不怎么喜欢书籍标题有心理学的字样，总感觉在卖弄一些什么。但出于这本书人们的程度，也见过好几个播客讲过这本书，我还是去看了。不得不说，是本好书。虽然书里很多案例都是在讲投资，但依旧也能对生活有一定启发，尤其是对消费的观念有了更进一步的理解。后来我又听了播客“纵横四海”对这本书的解读，又加深了对里面内容的理解。这篇文章，我想将书里一些我认为对我影响很深的整理出来。