标签: 架构
大厂出来的人，为什么这么废
网上流传一句据称出自 Sam Altman 的刻薄话：从大公司出来的人，野心、抱负和认知已经退化到了极低的程度。你跟他讲一件能改变行业的事，他第一反应是这事该谁批。 这话我深有同感，因为我见过太多了。不是没有反例，但很少。 评论区照例分两拨。一拨说可不是嘛，不过一颗螺丝钉；另一拨说酸什么，人家收入是你三倍。 两边都没什么意思。把一件事归结为“人不行”，是所有解释里最省事、也最没有信息量的一种。 真正值得问的是另一个问题：一个聪明、勤奋、通过了层层筛选的人，究竟是怎么被搞成这样的？ 太长不看 先把 …
网上流传一句据称出自 Sam Altman 的刻薄话：从大公司出来的人，野心、抱负和认知已经退化到了极低的程度。你跟他讲一件能改变行业的事，他第一反应是这事该谁批。 这话我深有同感，因为我见过太多了。不是没有反例，但很少。 评论区照例分两拨。一拨说可不是嘛，不过一颗螺丝钉；另一拨说酸什么，人家收入是你三倍。 两边都没什么意思。把一件事归结为“人不行”，是所有解释里最省事、也最没有信息量的一种。 真正值得问的是另一个问题：一个聪明、勤奋、通过了层层筛选的人，究竟是怎么被搞成这样的？ 太长不看 先把 …
赛博道德经：设计结构，而非规定行为
赛博经藏系列：用 AI Agent 解释宗教理念，并用宗教智慧启迪工程。本文为系列第二篇 —— 赛博道教。 万法归机——古老智慧与 AI Agent 的七重映射 引子：一个奇怪的发现 2017 年，Vaswani 等人发表《Attention is All You Need》。他们设计了一个结构——不是设计了一种智能，只是设计了一个让信息自行寻找路径的数学结构——然后智能从结构中涌现出来了。 没有人编程让 GPT 写十四行诗。没有人告诉 DALL·E 什么是“赛博朋克风格的东京街头”。这些能力不 …
赛博经藏系列：用 AI Agent 解释宗教理念，并用宗教智慧启迪工程。本文为系列第二篇 —— 赛博道教。 万法归机——古老智慧与 AI Agent 的七重映射 引子：一个奇怪的发现 2017 年，Vaswani 等人发表《Attention is All You Need》。他们设计了一个结构——不是设计了一种智能，只是设计了一个让信息自行寻找路径的数学结构——然后智能从结构中涌现出来了。 没有人编程让 GPT 写十四行诗。没有人告诉 DALL·E 什么是“赛博朋克风格的东京街头”。这些能力不 …
从 KV Cache 到 AI 内存系统：大模型推理架构的演进
原作者：xieydd · 微信公众号转载页 摘要 这篇文章想回答一个看似分散、其实高度统一的问题：为什么这两年围绕大模型推理的系统创新，越来越不像是在“优化一个神经网络”，反而像是在“设计一个内存系统”？ 如果把 2023 年以前的大模型工程叙事概括成“拼 FLOPS、拼 Tensor Core、拼训练吞吐”，那么 2024–2026 年的推理叙事，已经明显转向了另一条主线：KV cache、TTFT/TPOT、continuous batching、prefix …
原作者：xieydd · 微信公众号转载页 摘要 这篇文章想回答一个看似分散、其实高度统一的问题：为什么这两年围绕大模型推理的系统创新，越来越不像是在“优化一个神经网络”，反而像是在“设计一个内存系统”？ 如果把 2023 年以前的大模型工程叙事概括成“拼 FLOPS、拼 Tensor Core、拼训练吞吐”，那么 2024–2026 年的推理叙事，已经明显转向了另一条主线：KV cache、TTFT/TPOT、continuous batching、prefix …
下云数据库自建：从手艺活到工业化
前几天和几个做 SaaS 的老板聊"下云"。账大家都算得清：云数据库太贵，规模一上来，直接吃掉两三成利润。但真要迈出"自建"这一步时，负责技术的合伙人李总说了一句大实话： “老冯，我不怕技术难，我怕的是 被绑架。” 一语道破天机。买云服务虽然是交"保护费"，但买到了标准化的东西，出了问题还能找别人接盘。而自建呢？找个大神搭一套只有他自己懂的系统，万一哪天他要涨薪、离职，或者单纯心情不好，公司的数据命脉就攥在他手里。 这种组织风险，远比云服务的账单更让老板寝食难安。 守着"祖传代码"的老师傅 李总 …
前几天和几个做 SaaS 的老板聊"下云"。账大家都算得清：云数据库太贵，规模一上来，直接吃掉两三成利润。但真要迈出"自建"这一步时，负责技术的合伙人李总说了一句大实话： “老冯，我不怕技术难，我怕的是 被绑架。” 一语道破天机。买云服务虽然是交"保护费"，但买到了标准化的东西，出了问题还能找别人接盘。而自建呢？找个大神搭一套只有他自己懂的系统，万一哪天他要涨薪、离职，或者单纯心情不好，公司的数据命脉就攥在他手里。 这种组织风险，远比云服务的账单更让老板寝食难安。 守着"祖传代码"的老师傅 李总 …
OpenAI：将PostgreSQL伸缩至新阶段
在 PGConf.Dev 2025 全球 PG 开发者大会上， 来自 OpenAI 的 Bohan Zhang 分享了 OpenAI 在 PostgreSQL 上的最佳实践， 让我们得以一窥最牛独角兽内部的数据库使用情况。 “在 OpenAI，我们在使用一写多读的未分片架构，证明了 PostgreSQL 在海量读负载下也可以伸缩自如” —— PGConf.Dev 2025 Bohan Zhang from OpenAI Bohan Zhang 是 OpenAI Infra 组成员，师从 CMU …
在 PGConf.Dev 2025 全球 PG 开发者大会上， 来自 OpenAI 的 Bohan Zhang 分享了 OpenAI 在 PostgreSQL 上的最佳实践， 让我们得以一窥最牛独角兽内部的数据库使用情况。 “在 OpenAI，我们在使用一写多读的未分片架构，证明了 PostgreSQL 在海量读负载下也可以伸缩自如” —— PGConf.Dev 2025 Bohan Zhang from OpenAI Bohan Zhang 是 OpenAI Infra 组成员，师从 CMU …
数据库即业务架构
数据库是业务架构的核心，是不言自明的共识。但如果我们更进一步，将数据库作为业务架构本身，将业务逻辑，Web Server，甚至是整个前后端都放入数据库中，又会擦出怎么样的火花？未来会是一个数据库吞噬后端，前端，操作系统，甚至一切的世界吗？ 驱动未来的数据库 不久之前，Omnigres 的创始人 Yurii 在 第七届PG生态大会 上 进行了题为《数据库驱动未来》的演讲分享。抛出了一个有趣的观点 —— 数据库就是业务架构。 他的开源项目 Omnigres 做了一件“疯狂”的事：把所有应用逻辑，甚至 …
数据库是业务架构的核心，是不言自明的共识。但如果我们更进一步，将数据库作为业务架构本身，将业务逻辑，Web Server，甚至是整个前后端都放入数据库中，又会擦出怎么样的火花？未来会是一个数据库吞噬后端，前端，操作系统，甚至一切的世界吗？ 驱动未来的数据库 不久之前，Omnigres 的创始人 Yurii 在 第七届PG生态大会 上 进行了题为《数据库驱动未来》的演讲分享。抛出了一个有趣的观点 —— 数据库就是业务架构。 他的开源项目 Omnigres 做了一件“疯狂”的事：把所有应用逻辑，甚至 …
基础架构部，真的没有必要了么？
原作者：程序员 Aike · 微信公众号转载页 今天一篇基础架构部，还有必要吗？的文章刷屏了，作为一名资深的基础架构从业者，浅谈下自己的看法，期望引发广大基础架构从业者、业务开发、测试人员等相关从业者更多的思考和判断！ 01 基础架构部的定位 不同公司对基础架构部的定位不同，以下是可能的几个方面： 1、通过技术和工程手段、运维手段，保障线上服务稳定性。比如运维人员保障业务核心指标健康，网络、服务器等基础设施组件能承受业务压力等。 2、构建统一的基础服务，比如数据库、消息中间件、微服务框架，或者 …
原作者：程序员 Aike · 微信公众号转载页 今天一篇基础架构部，还有必要吗？的文章刷屏了，作为一名资深的基础架构从业者，浅谈下自己的看法，期望引发广大基础架构从业者、业务开发、测试人员等相关从业者更多的思考和判断！ 01 基础架构部的定位 不同公司对基础架构部的定位不同，以下是可能的几个方面： 1、通过技术和工程手段、运维手段，保障线上服务稳定性。比如运维人员保障业务核心指标健康，网络、服务器等基础设施组件能承受业务压力等。 2、构建统一的基础服务，比如数据库、消息中间件、微服务框架，或者 …
基础架构部需要先进技术吗？
原作者：思维男人 · 微信公众号转载页 前两天，瑞典马工发了一篇《基础架构部，还有必要吗？》，文章的逻辑是基础架构部（或者技术平台部，或者运维开发部，或者架构平台部）为业务单元提供技术支撑，然后技术支撑需要自身有优秀技术，然后尝试列出一些反例去证明基础架构没有优秀技术，所以支撑不了业务单元，就该解散或者消失了。 我当时看完，觉得文章逻辑就不对，因为支撑业务单元不一定要优秀技术，很多时候只需要补充业务单元的弱项和空白就行了；然后列出来的反例都是些表象，但这些表象放在不同组织内是否真的都是反例？不 …
原作者：思维男人 · 微信公众号转载页 前两天，瑞典马工发了一篇《基础架构部，还有必要吗？》，文章的逻辑是基础架构部（或者技术平台部，或者运维开发部，或者架构平台部）为业务单元提供技术支撑，然后技术支撑需要自身有优秀技术，然后尝试列出一些反例去证明基础架构没有优秀技术，所以支撑不了业务单元，就该解散或者消失了。 我当时看完，觉得文章逻辑就不对，因为支撑业务单元不一定要优秀技术，很多时候只需要补充业务单元的弱项和空白就行了；然后列出来的反例都是些表象，但这些表象放在不同组织内是否真的都是反例？不 …
基础架构，路在何方？
原作者：titi · 微信公众号转载页 这两天马工关于基础架构部的文章「基础架构部，还有必要吗？」进一步在朋友圈疯转，没想到比起喷DBA、喷国内云厂商，这篇文章竟然会引来这么多反对的声音，坦白来讲确实有些出人意料。笔者忍不住也在第一时间拜读了全文。其实严格来说，这篇文章更应该被看作前一篇关于多云的文章「多云战略：无奈的现实，危险的选择」的姊妹篇。众所周知，马工时常说话难听，在更多时候也喜爱把事情推极端，虽然笔者也因为各种话题和马工有观点上的分歧，经常没事互怼。但不代表今天文中所主张的观点没人讲 …
原作者：titi · 微信公众号转载页 这两天马工关于基础架构部的文章「基础架构部，还有必要吗？」进一步在朋友圈疯转，没想到比起喷DBA、喷国内云厂商，这篇文章竟然会引来这么多反对的声音，坦白来讲确实有些出人意料。笔者忍不住也在第一时间拜读了全文。其实严格来说，这篇文章更应该被看作前一篇关于多云的文章「多云战略：无奈的现实，危险的选择」的姊妹篇。众所周知，马工时常说话难听，在更多时候也喜爱把事情推极端，虽然笔者也因为各种话题和马工有观点上的分歧，经常没事互怼。但不代表今天文中所主张的观点没人讲 …
基础架构部不死，只是慢慢消逝
原作者：李令辉 · 微信公众号转载页 瑞典马工昨天的文章《基础架构部，还有必要吗？》里面点名质疑了基础架构部存在的必要性。我自己从事基础架构工作多年，希望可以从相对客观的角度来回答这篇文章提出的问题。也谨以此文致敬基础架构的老兵们。 基础架构部的价值是什么？ 正如马工文中所说，基础架构部是为了向业务单位交付技术，并且要具备两个前提： 自己有优秀的技术 要能引导业务部门使用优秀的技术 技术的“优秀”与否要看场景 但是，“优秀”不是有唯一标准的，什么算优秀的技术？技术都是有 tradeoff 的， …
原作者：李令辉 · 微信公众号转载页 瑞典马工昨天的文章《基础架构部，还有必要吗？》里面点名质疑了基础架构部存在的必要性。我自己从事基础架构工作多年，希望可以从相对客观的角度来回答这篇文章提出的问题。也谨以此文致敬基础架构的老兵们。 基础架构部的价值是什么？ 正如马工文中所说，基础架构部是为了向业务单位交付技术，并且要具备两个前提： 自己有优秀的技术 要能引导业务部门使用优秀的技术 技术的“优秀”与否要看场景 但是，“优秀”不是有唯一标准的，什么算优秀的技术？技术都是有 tradeoff 的， …
基础架构部，还有必要吗？
原作者：瑞典马工 · 微信公众号转载页 过去二十年，中国互联网公司取得了巨大的成就。基础架构部（或者技术平台部，或者运维开发部，或者架构平台部）作为互联网公司的技术底座维护者，贡献巨大。但是随着技术的进步，此类部门的老经验在云时代，越来越不适用，而他们又普遍跟不上新问题。两项加起来，使得大家不得不问一个问题：基础架构部，真的还有价值吗？ 基础架构部的价值是向业务单元交付技术 基础架构部出于一个目的建立：集中公司的基础设施和架构人才，为业务单元提供技术支撑。 要达到这个目的，基础架构部需要达到两 …
原作者：瑞典马工 · 微信公众号转载页 过去二十年，中国互联网公司取得了巨大的成就。基础架构部（或者技术平台部，或者运维开发部，或者架构平台部）作为互联网公司的技术底座维护者，贡献巨大。但是随着技术的进步，此类部门的老经验在云时代，越来越不适用，而他们又普遍跟不上新问题。两项加起来，使得大家不得不问一个问题：基础架构部，真的还有价值吗？ 基础架构部的价值是向业务单元交付技术 基础架构部出于一个目的建立：集中公司的基础设施和架构人才，为业务单元提供技术支撑。 要达到这个目的，基础架构部需要达到两 …
单租户时代：SaaS范式转移
作者：David Heinemeier Hansson，网名DHH，37 Signal 联创与CTO，Ruby on Rails 作者，下云倡导者、实践者、领跑者。反击科技巨头垄断的先锋。 译者：冯若航，网名 Vonng 。磐吉云数创始人与CEO。Pigsty 作者，PostgreSQL 专家/布道师。公众号《非法加冯》主理人，云计算泥石流，数据库老司机。 多租户是Web服务的复杂之源 Multi-tenancy is what’s hard about scaling web …
作者：David Heinemeier Hansson，网名DHH，37 Signal 联创与CTO，Ruby on Rails 作者，下云倡导者、实践者、领跑者。反击科技巨头垄断的先锋。 译者：冯若航，网名 Vonng 。磐吉云数创始人与CEO。Pigsty 作者，PostgreSQL 专家/布道师。公众号《非法加冯》主理人，云计算泥石流，数据库老司机。 多租户是Web服务的复杂之源 Multi-tenancy is what’s hard about scaling web …
互联网技术大师速成班
原作者：瑞典马工 · 微信公众号转载页 人人都知道，互联网是个钱多责小离家近的好行业。这个行业流传着许多飞檐走壁技术大师的故事，激励了很多学过高数课的年轻人。本文意在讨论互联网技术大师的修炼之道，试图找到一个共通的速成模式，希望对年轻人有所助益。 第一步：先进大厂 进大厂是成为大师的第一步，无可通融。 有些小朋友说“大厂 HR 卡学历，不让我进，可我还是想当技术大师，怎么办啊？“ 我只能遗憾的表示，小朋友你生不逢时啊。 你看那些到处开课的技术大师，他们十几年前入职 Google /阿里/腾讯的 …
原作者：瑞典马工 · 微信公众号转载页 人人都知道，互联网是个钱多责小离家近的好行业。这个行业流传着许多飞檐走壁技术大师的故事，激励了很多学过高数课的年轻人。本文意在讨论互联网技术大师的修炼之道，试图找到一个共通的速成模式，希望对年轻人有所助益。 第一步：先进大厂 进大厂是成为大师的第一步，无可通融。 有些小朋友说“大厂 HR 卡学历，不让我进，可我还是想当技术大师，怎么办啊？“ 我只能遗憾的表示，小朋友你生不逢时啊。 你看那些到处开课的技术大师，他们十几年前入职 Google /阿里/腾讯的 …
数据库应该放入K8S里吗？
数据库是否应该放入 Kubernetes / Docker 里，到今天仍然是一个充满争议的话题。k8s 作为一个先进的容器编排工具，在无状态应用管理上非常趁手；但其在处理有状态服务 —— 特别是PostgreSQL和MySQL这样的数据库时，有着本质上的局限性。 在上一篇文章《数据库放入Docker是个好主意吗？》中，我们已经讨论了容器化数据库的利弊权衡；今天我们就来聊一聊将数据库放入 K8S 中编排调度所涉及的利弊权衡 —— 并深入探讨为什么将数据库放入 K8S 中不是一个明智的选择。 摘要 …
数据库是否应该放入 Kubernetes / Docker 里，到今天仍然是一个充满争议的话题。k8s 作为一个先进的容器编排工具，在无状态应用管理上非常趁手；但其在处理有状态服务 —— 特别是PostgreSQL和MySQL这样的数据库时，有着本质上的局限性。 在上一篇文章《数据库放入Docker是个好主意吗？》中，我们已经讨论了容器化数据库的利弊权衡；今天我们就来聊一聊将数据库放入 K8S 中编排调度所涉及的利弊权衡 —— 并深入探讨为什么将数据库放入 K8S 中不是一个明智的选择。 摘要 …
正本清源：技术反思录
最近在技术圈有一些热议的话题，云数据库是不是智商税？？公有云是不是杀猪盘？分布式数据库是不是伪需求？微服务是不是蠢主意？你还需要运维和DBA吗？中台是不是一场彻头彻尾的自欺欺人？在Twitter与HackerNews上也有大量关于这类话题的讨论与争辩。 在这些议题的背后的脉络是大环境的改变：降本增效压倒其他一切，成为绝对的主旋律。开发者体验，架构可演化性，研发效率这些属性依然重要，但在 ROI 面前都要让路 —— 社会思潮与根本价值观的变化会触发所有技术的重新估值。 有人说，互联网公司砍掉一半人 …
最近在技术圈有一些热议的话题，云数据库是不是智商税？？公有云是不是杀猪盘？分布式数据库是不是伪需求？微服务是不是蠢主意？你还需要运维和DBA吗？中台是不是一场彻头彻尾的自欺欺人？在Twitter与HackerNews上也有大量关于这类话题的讨论与争辩。 在这些议题的背后的脉络是大环境的改变：降本增效压倒其他一切，成为绝对的主旋律。开发者体验，架构可演化性，研发效率这些属性依然重要，但在 ROI 面前都要让路 —— 社会思潮与根本价值观的变化会触发所有技术的重新估值。 有人说，互联网公司砍掉一半人 …
数据库需求层次金字塔
与马斯洛需求金字塔类似，用户对于数据库的需求也有着一个递进的层次。用户对于数据库的需求从下往上可以分为八个层次，分别与人的八个需求层次相对应： 生理需求，功能：内核/正确性/ACID 安全需求，安全：备份/保密/完整/可用 归属需求，可靠：高可用/监控/告警 尊重需求，ROI：性能/成本/复杂度 认知需求，洞察：可观测性/数字化/可视化 审美需求，掌控：可控制性/易用性/IaC 自我实现，智能：标准化/产品化/智能化 超越需求，变革：真·自治数据库 安全需求与生理需求同属 基础需求，一个用于生产 …
与马斯洛需求金字塔类似，用户对于数据库的需求也有着一个递进的层次。用户对于数据库的需求从下往上可以分为八个层次，分别与人的八个需求层次相对应： 生理需求，功能：内核/正确性/ACID 安全需求，安全：备份/保密/完整/可用 归属需求，可靠：高可用/监控/告警 尊重需求，ROI：性能/成本/复杂度 认知需求，洞察：可观测性/数字化/可视化 审美需求，掌控：可控制性/易用性/IaC 自我实现，智能：标准化/产品化/智能化 超越需求，变革：真·自治数据库 安全需求与生理需求同属 基础需求，一个用于生产 …
微服务是不是个蠢主意？
亚马逊的Prime Video团队发表了一篇非常引人注目的案例研究[2] ，讲述了他们为什么放弃了微服务与Serverless架构而改用单体架构。这一举措让他们在运营成本上节省了惊人的 90%，还简化了系统复杂度，堪称一个巨大的胜利。 但除了赞扬他们的明智之举之外，我认为这里还有一个重要洞察适用于我们整个行业： “我们最初设计的解决方案是：使用Serverless组件的分布式系统架构… 理论上这个架构可以让我们独立伸缩扩展每个服务组件。然而，我们使用某些组件的方式导致我们在大约5%的预期负载时， …
亚马逊的Prime Video团队发表了一篇非常引人注目的案例研究[2] ，讲述了他们为什么放弃了微服务与Serverless架构而改用单体架构。这一举措让他们在运营成本上节省了惊人的 90%，还简化了系统复杂度，堪称一个巨大的胜利。 但除了赞扬他们的明智之举之外，我认为这里还有一个重要洞察适用于我们整个行业： “我们最初设计的解决方案是：使用Serverless组件的分布式系统架构… 理论上这个架构可以让我们独立伸缩扩展每个服务组件。然而，我们使用某些组件的方式导致我们在大约5%的预期负载时， …
高可用PgSQL集群架构设计与落地
把数据库拉起来是一回事，部署专业水准的数据库集群又是另一回事。想要真正用好管好数据库，需要良好的架构设计让多种组件协同配合起来。今天我们就来介绍一下典型的高可用PgSQL集群架构及其 落地方式。 本文将以 Pigsty v0.8 为例，介绍高可用集群的设计与部署。 “ Pigsty针对大规模数据库集群监控与管理而设计，提供业界顶尖的PostgreSQL监控系统与开箱即用的高可用数据库供给方案，为用户带来极致的可观测性与丝滑的数据库使用体验。 Pigsty基于开源生态构建，旨在降低 …
把数据库拉起来是一回事，部署专业水准的数据库集群又是另一回事。想要真正用好管好数据库，需要良好的架构设计让多种组件协同配合起来。今天我们就来介绍一下典型的高可用PgSQL集群架构及其 落地方式。 本文将以 Pigsty v0.8 为例，介绍高可用集群的设计与部署。 “ Pigsty针对大规模数据库集群监控与管理而设计，提供业界顶尖的PostgreSQL监控系统与开箱即用的高可用数据库供给方案，为用户带来极致的可观测性与丝滑的数据库使用体验。 Pigsty基于开源生态构建，旨在降低 …
数据库集群管理概念与实体命名规范
名之则可言也，言之则可行也。 概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。 TL;DR 集群（Cluster） 是基本自治单元，由用户指定唯一标识，表达业务含义，作为顶层命名空间。 集群在硬件层面上包含一系列的 节点（Node），即物理机，虚机（或Pod），可以通过IP唯一标识。 集群在软件层面上包含一系列的 实例（Instance），即软件服务器，可以通过IP:Port唯一标识。 …
名之则可言也，言之则可行也。 概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。 TL;DR 集群（Cluster） 是基本自治单元，由用户指定唯一标识，表达业务含义，作为顶层命名空间。 集群在硬件层面上包含一系列的 节点（Node），即物理机，虚机（或Pod），可以通过IP唯一标识。 集群在软件层面上包含一系列的 实例（Instance），即软件服务器，可以通过IP:Port唯一标识。 …
PostgreSQL 常见复制拓扑方案
复制是系统架构中的核心问题之一。 集群拓扑 假设我们使用4单元的标准配置：主库，同步从库，延迟备库，远程备库，分别用字母M,S,O,R标识。 M：Master, Main, Primary, Leader, 主库，权威数据源。 S: Slave, Secondary, Standby, Sync Replica，同步副本，需要直接挂载至主库 R: Remote Replica, Report instance，远程副本，可以挂载到主库或同步从库上 O: Offline，离线延迟备库，可以挂载到主 …
复制是系统架构中的核心问题之一。 集群拓扑 假设我们使用4单元的标准配置：主库，同步从库，延迟备库，远程备库，分别用字母M,S,O,R标识。 M：Master, Main, Primary, Leader, 主库，权威数据源。 S: Slave, Secondary, Standby, Sync Replica，同步副本，需要直接挂载至主库 R: Remote Replica, Report instance，远程副本，可以挂载到主库或同步从库上 O: Offline，离线延迟备库，可以挂载到主 …
容器化数据库是个好主意吗？
前言：这篇文章是19年1月写的，四年过去了，涉及到数据库与容器的利弊权衡依然成立。这里进行细微调整后重新发出。明天我会发布一篇《数据库是否应当放入K8S中？》，那么今天就先用这篇老文来预热一下吧。 对于无状态的应用服务而言，容器是一个相当完美的开发运维解决方案。然而对于带持久状态的服务 —— 数据库来说，事情就没有那么简单了。生产环境的数据库 是否应当放入容器中，仍然是一个充满争议的问题。 站在开发者的角度上，我非常喜欢Docker，并相信容器也许是未来软件开发部署运维的标准方式。但站在DBA …
前言：这篇文章是19年1月写的，四年过去了，涉及到数据库与容器的利弊权衡依然成立。这里进行细微调整后重新发出。明天我会发布一篇《数据库是否应当放入K8S中？》，那么今天就先用这篇老文来预热一下吧。 对于无状态的应用服务而言，容器是一个相当完美的开发运维解决方案。然而对于带持久状态的服务 —— 数据库来说，事情就没有那么简单了。生产环境的数据库 是否应当放入容器中，仍然是一个充满争议的问题。 站在开发者的角度上，我非常喜欢Docker，并相信容器也许是未来软件开发部署运维的标准方式。但站在DBA …
UUID性质原理与应用
最近一个项目需要生成业务流水号，需求如下： ID必须是分布式生成的，不能依赖中心节点分配并保证全局唯一。 ID必须包含时间戳并尽量依时序递增。（方便阅读，提高索引效率） ID尽量散列。（分片，与HBase日志存储需要） 在造轮子之前，首先要看一下有没有现成的解决方案。 Serial 传统实践上业务流水号经常通过数据库自增序列或者发码服务来实现。 MySQL 的 Auto Increment,Postgres 的 Serial,或者 Redis+lua 写个小发码服务都是方便快捷的解决方案。这种方 …
最近一个项目需要生成业务流水号，需求如下： ID必须是分布式生成的，不能依赖中心节点分配并保证全局唯一。 ID必须包含时间戳并尽量依时序递增。（方便阅读，提高索引效率） ID尽量散列。（分片，与HBase日志存储需要） 在造轮子之前，首先要看一下有没有现成的解决方案。 Serial 传统实践上业务流水号经常通过数据库自增序列或者发码服务来实现。 MySQL 的 Auto Increment,Postgres 的 Serial,或者 Redis+lua 写个小发码服务都是方便快捷的解决方案。这种方 …