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

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

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

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

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

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

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

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

Web3.0是近几年无论是风投还是互联网从业者都热衷讨论与参与的话题。近期通过对这个领域做了个初步的了解，因此整理成这篇文章。

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