面向有经验的后端/数据/平台工程师。本文不堆术语,只讲清楚三类数据库各自擅长什么、在什么场景下会踩坑,以及真实业务里怎么组合使用。原理部分点到为止,深入链接放在文末。数据库选型这件事,八成的争论其实源于一个误会:把"存储模型"当成了"产品好坏"来比。行式、列式、向量,本质是三种不同的数据组织方式,各自为一类访问模式做了极致优化。选错的代价不是"慢一点",而是整个架构跑偏。下面按"它怎么存 →...

在落地 Pulsar 的过程中，开发者最容易踩的坑集中在两个问题上：问题一："我有多个消费者，消息是怎么分发的？顺序能保证吗？"问题二："消费者处理业务逻辑很慢，会不会把整个消费流程阻塞住？"这两个问题的答案，分别对应 Pulsar 的订阅模式（Subscription Type） 和消费模型（Consumption Pattern）。本文基于 Go 语言，通过完整可运行的代码，逐一拆解四种...

场景：撮合引擎多 Pod 部署，每个 Pod 维护本地 L1 内存深度数据，如何通过 Redis L2 实现跨 Pod 无损同步？一、背景与问题定义撮合引擎（Matching Engine）是交易系统的核心，订单簿（Order Book）的买卖深度数据有以下特点：写频率极高：每秒数千次挂单、撤单、成交读频率更高：行情推送、风控查询、前端展示强一致性要求：深度数据不能乱序、不能丢失延迟敏感：毫...

本文是《产品要懂得的性能指标：性能需求，你要好好提》的下篇。上一篇解决的是“产品需要看懂哪些性能指标”：响应时间、并发用户数、吞吐量、成功率、可用性、资源利用率、数据规模、客户端流畅度，以及启动、耗电和流量。但认识指标只是第一步。真正写需求时，产品还要解决几个更现实的问题：哪些功能必须重点保障？性能需求什么时候提？写到什么程度才可以验收？最后达不到又该怎么办？这篇不再逐个解释指标，而是继续往...

产品经理提性能需求时，最容易写出的一句话是：页面打开要快一点，系统要稳定，用户多的时候也不能卡。这句话方向没错，但没法开发，也没法验收。“快一点”到底是 1 秒还是 5 秒？“用户多”是 100 人同时在线，还是 100 人同一秒提交订单？“稳定”是全年不宕机，还是请求成功率达到 99.9%？如果这些问题没有说清楚，开发只能凭经验实现，测试也只能凭感觉验收。一份可执行的性能需求，至少要说清楚...