1. 为什么我劝你先想清楚“要不要用 Cassandra”而不是“怎么用”先说个真实经历。三年前我接手过一个项目技术负责人拍板要上 Cassandra理由是“公司未来数据量会到 PB 级”“分布式是趋势”“MySQL 不够高级”。结果半年后团队被备份恢复、一致性坑和运维成本折磨得苦不堪言最后灰溜溜迁回了 PostgreSQL。问题不在 Cassandra 本身而在选型那一刻就错了。Cassandra 确实是一款极其优秀的分布式 NoSQL 数据库它源自 Amazon Dynamo 的分布式架构思想结合了 Google Bigtable 的列族存储模型由 Facebook 开源后捐给了 Apache 基金会。它的核心卖点用一句话概括在跨多数据中心、多节点的集群中提供高可用、无单点故障、线性扩展的写入能力。注意我这里强调的是“写入能力”和“高可用”而不是“强一致”也不是“复杂查询”。如果你正面临以下场景Cassandra 可能是合适的写多读少写入吞吐要求极高例如每秒数十万级写入数据天然按某个维度分区用户 ID、设备 ID、传感器 ID需要跨机房多活部署不能容忍任何一个机房挂掉后整个服务不可用数据量增长可预期且巨大希望加机器就能线性扩容不用做复杂的分库分表对最终一致性有容忍度能接受“延迟一小段时间才看到最新数据”反过来如果你的业务以事务为核心转账、订单状态强一致、需要大量 join 查询和灵活聚合分析或者团队没有专职的运维/基础设施人员我劝你慎重。Cassandra 不是“MySQL 的替代品”它和关系型数据库的适用边界非常清晰跨过边界使用再好的技术也会变成灾难。这篇文章不是一个“官网文档翻译”而是我从选型、数据建模、集群部署到性能调优、故障排查的全流程实战记录。我会把那些文档里不写、但实际一定会踩的坑尽量都摊开讲清楚希望能帮你少走几个月的弯路。2. 数据模型设计成也 Partition Key败也 Partition KeyCassandra 的数据模型经常被拿来和关系型模型对比但如果你带着 MySQL 的思维来设计 Cassandra 的表那基本是开局就崩。Cassandra 的表结构设计完全围绕“查询模式”展开而不是围绕“业务实体关系”展开。换句话说你先想清楚你的查询长什么样再去设计表。2.1 Primary Key 的三层拆解Partition Key、Clustering Key、Static ColumnCassandra 的 Primary Key 由两部分组成Partition Key 和 Clustering Key。举个实际例子假设我们设计一张用户行为日志表CREATE TABLE user_actions ( user_id UUID, action_time TIMESTAMP, action_type TEXT, action_detail TEXT, PRIMARY KEY ((user_id), action_time, action_type) );这里user_id是 Partition Keyaction_time和action_type是 Clustering Key。Partition Key 决定这一行数据存储在集群中的哪个节点通过一致性哈希计算 token 范围来确定归属它的选择直接决定了数据分布的均匀程度。Clustering Key 则负责在同一个分区内对数据进行排序和去重它决定了你在读取时能以什么顺序拿到数据。还有一类特殊的列叫 Static Column它在同一分区内所有行之间共享。比如你可以把用户的昵称存成 static column查询该分区任意一行时都能直接取到不需要额外存储每个行为事件都带一份冗余昵称。这个特性在处理“实体属性 实体行为”混合场景时非常实用。设计时一定要牢牢记住两个规则Partition Key 不能过大。单个分区能存储的数据量是有限的官方建议单分区数据控制在 100MB 以内实际经验是几百 MB 就会开始出现明显性能问题。如果你用“时间”作分区键一天的数据量达到几个 GB那这天对应的少数几个节点会过热其他节点却闲着——这就是典型的热点问题Hot Spot。查询必须带上 Partition Key。Cassandra 不支持跨分区全表扫描类的查询。如果你想查“所有用户今天的行为”这个需求在 Cassandra 原生查询里是做不到的除非用 Spark 之类的分析框架配合做全表扫描但那是另一套引擎了。2.2 一个反直觉的建模原则数据冗余不是灾难是设计手段关系型数据库设计追求规范化尽可能消除冗余Cassandra 恰恰相反它鼓励你按照查询模式做“反规范化”设计。同一个业务数据可以存在多张表中每张表服务于一种查询模式。空间换查询效率这是分布式系统里最常见的取舍。继续用用户行为日志的例子。假设现在有两个主要的查询需求查某个用户最近 100 条行为按时间倒序查某个时间窗口内所有执行了特定操作比如“下单”的用户针对需求 1设计如上表即可Clustering Key 是action_time配合ORDER BY action_time DESC就能高效拿到数据。针对需求 2如果你在原来的表上加一个action_type的二级索引数据量小时还行一旦数据量大到一定程度二级索引的查询性能会急剧恶化它本质上是在多个节点间做分布式扫描Cosmos DB 和 DynamoDB 的二级索引设计也基本如此。更好的方案是单独建一张“操作类型维度的行为汇总表”CREATE TABLE actions_by_type ( action_type TEXT, bucket_time TIMESTAMP, user_id UUID, action_time TIMESTAMP, action_detail TEXT, PRIMARY KEY ((action_type, bucket_time), action_time, user_id) );这里我把(action_type, bucket_time)作为复合分区键bucket_time按小时或天做时间分桶控制单个分区的数据量查询某个时间窗口内执行了某种操作的用户本质上就是精确命中少数几个分区效率远高于在超大分区里做过滤。在 Cassandra 的世界里写重复数据是常态、是设计的一部分而不是“数据库没设计好”的体现。读路径的性能是靠写路径的冗余换来的。如果你对这句话没有切身感受说明你还没有用 Cassandra 处理过真正大的数据量——等你试过在一个 2TB 的分区上执行带过滤条件的查询你就懂了。2.3 时间建模用“时间分桶 倒序排列”而不是“精确时间点”很多从关系型数据库转过来的开发者在设计时间字段时习惯把时间精确到毫秒当作 Clustering Key。这在 Cassandra 里往往不是最优解。举例来说如果 Clustering Key 是action_time且精度到毫秒并发写入同一个 user 的行为时可能出现同一毫秒内多条记录导致写入冲突或顺序不确定。更合理的做法是引入“分桶时间”把 Clustering Key 设计成“小时桶 精确时间”的组合。例如PRIMARY KEY ((user_id, hour_bucket), action_time)hour_bucket作为分区键的一部分决定了行为落在哪个分区action_time仍然是精确时间戳负责分区内排序。这样既控制了分区大小一个用户一个小时内产生的行为是有限的又能按需查询。如果直接以user_id为分区键、action_time为 clustering key一个活跃用户几年的积累会导致分区过大最终触发 Compaction 的性能问题和查询超时。时间分桶的粒度需要结合业务量来估算目标是把单个分区的行数控制在几万到几十万级别。量级估算公式其实很简单每小时平均写入量 × 留存时长 单分区行数如果超过 50 万分桶粒度就需要调小改成按分钟分桶或者改用复合分区键。2.4 数据类型选择的几个隐蔽坑不要用整数自增 ID 做分区键Cassandra 没有自增主键机制而且使用序列 ID 容易产生热点相邻的 ID 会落在相邻的 token 范围上。推荐使用 UUID 或 TimeUUIDuuid类型。TimeUUID 还能内嵌时间信息排序性能优于纯字符串。Decimal vs Double涉及金额计算必须用decimaldouble的浮点误差在金融场景下不能接受。Map/Set/List 集合类型要慎用集合类型的底层实现是特殊的数据结构每次更新都会涉及读改写read-before-write在高并发写入场景下开销极大。能用单独的列或单独的表表达的需求尽量不要用集合类型。空值不占用存储但不建议依赖这个特性Cassandra 在存储层面不保存 null会用 tombstone 标记删除但查询返回时不会出现该列。如果在事务性逻辑里依赖“列不存在”和“列存在但为 null”的区别容易出问题。3. 读写路径的底层逻辑你以为是数据库其实是一套去中心化的消息系统Cassandra 很多诡异行为写性能高、读性能一般、节点故障时部分读写失败都能从底层读写路径找到解释。理解这套机制才能真正做对容量规划和性能调优。3.1 Commit Log、Memtable、SSTable写入为什么这么快Cassandra 的写入路径设计非常聪明。客户端向协调节点Coordinator发送写请求协调节点根据分区键计算 token找到负责该 token 范围的副本节点将写请求转发给所有副本副本数由 replication factor 决定。每个副本节点收到数据后先把操作追加到 Commit Log顺序写磁盘这是机械硬盘时代专门优化过的点现在 SSD 上优势没那么明显了然后写入内存中的 Memtable一个按排序结构组织的内存缓冲区。当 Memtable 达到阈值默认 64MB可通过memtable_threshold调整就会刷盘生成 SSTable 文件。SSTable 是不可变的有序文件后续的 Compaction 过程会将多个 SSTable 合并清理删除标记和冗余数据。所以写入快的原因主要在于没有任何随机写操作数据先写内存Commit Log 只做顺序追加写SSTable 刷盘也是顺序写整个过程不会像 B树索引那样在磁盘上随机寻道。这也是 Cassandra 能轻松达到单节点每秒数万次写入的原因之一。但在高并发写入时有一个必须注意的参数commitlog_sync。默认配置是periodic每 10 秒批量刷一次 Commit Log 到磁盘。如果写入量巨大且节点突然断电可能会丢失最近几秒的数据。如果业务对数据丢失零容忍需要改成batch模式但每次写入都要同步刷盘写延迟会大幅上升。性能和可靠性在这个环节上是二选一的关系。3.2 Read Path 与 Consistency Level为什么读比写贵这么多读路径要复杂不少。协调节点收到读请求后需要先根据 Consistency Level 决定向多少个副本发起读请求。默认的 QUORUM 级别下意味着必须等到超过半数副本返回结果之后协调节点才能把合并后的结果返回给客户端。如果多个副本返回的数据版本不一致因为某些副本还没追上最新写入协调节点会发起一次“读修复”Read Repair把最新版本的数据推送给滞后的副本。这个机制保证了长期运行下最终一致性但也意味着读操作可能触发额外的写流量。理解这一点非常重要Cassandra 的读操作不是单纯读它可能会变成读写。因此在评估集群容量时不能只按读/写比例估算还需要考虑读修复带来的额外写放大。在我的实践中读密集场景下节点的 CPU 和磁盘 IO 压力往往会比预想中高 30% 到 50%根因就在这。还有一点容易被忽略LOCAL_QUORUM和QUORUM的差异。QUORUM 的计算基于整个集群的副本数而 LOCAL_QUORUM 只基于当前数据中心的副本数。跨机房部署时如果使用 QUORUM一次读请求可能要等另一个机房的副本响应延迟高而且跨机房带宽会占满。多机房场景下读写都建议使用 LOCAL_QUORUM跨机房一致性交给异步复制机制去处理。3.3 Hinted Handoff 的原理与生命周期当某个副本节点宕机时协调节点不会直接返回失败而是把本该发给该节点的数据写入本地一个叫“hinted handoff”的缓冲文件等节点恢复后再把数据补发过去。这个机制对高可用性帮助很大但如果节点宕机时间超过max_hint_window默认 3 小时这些 hint 会被丢弃数据只能依靠后续的读修复来弥补。在使用 Cassandra 时你要接受一个事实节点宕机太久数据就可能永久丢失一部分而且这个丢失是静默的、无告警的。这不是 bug是分布式系统在高可用和一致性之间的取舍。关键运维动作是监控节点 uptime、及时恢复故障节点不要让节点处于 down 状态超过 hint window。如果业务对数据完整性要求极高还需要额外跑全量 repair 任务nodetool repair这是另一个大话题后面部署章节我再展开。4. 部署与集群管理实战从三节点到三十节点你需要明白这些4.1 副本策略与分片计算Cassandra 通过复制策略决定数据在集群中的分布方式。常见的有SimpleStrategy适用于单机房和NetworkTopologyStrategy适用于多机房。在使用生产环境时永远选择NetworkTopologyStrategy即使你当前只有单机房。因为后续扩容到多机房时SimpleStrategy 无法平滑迁移需要重建 keyspace那是灾难级的操作。每个节点的 token 范围是通过一致性哈希计算的。默认的随机分区器Murmur3Partitioner会把整个哈希空间划分为 2 的 64 次方个 token。配置 vnode虚拟节点后每个物理节点会被分配多个 token这样做有几个明显的好处负载分布更均匀避免某些节点存储量远高于其他节点扩缩容时数据迁移粒度更细迁移速度更快不同性能的硬件可以配置不同数量的 vnode从 Cassandra 1.2 之后就推荐默认开启 vnode默认num_tokens为 256生产实践里一般不用调整除非遇到非常特殊的数据分布场景。但需要注意vnode 的数量并不是越多越好如果节点数很少3 节点token 数量过大反而可能导致查询路由时的元数据膨胀权衡下来 3 节点集群用默认 256 是没问题的。4.2 复制因子Replication Factor该怎么定复制因子决定了每个分区被复制到几个节点上。生产环境最常见的配置是 RF3。这里的计算逻辑很简单在LOCAL_QUORUM读、LOCAL_QUORUM写的场景下要允许一个节点宕机而不影响读写可用性你至少需要 3 个副本。如果 RF2任何一个副本宕机QUORUM 就无法达成服务就不可用了。RF3 的情况下容忍一节点宕机没有问题想容忍两节点同时宕机需要 RF5但这样存储成本会显著上升。我见过很多团队为了省钱把 RF 设为 2结果每遇节点故障就提心吊胆不得不定期跑 repair最后算下来运维成本远高于省下来的那一点点存储费用。容量规划时直接按 RF3 来估算存储需求每个业务表的原始数据量 × 3就是你需要的物理存储总量。4.3 我用 Docker Compose 搭三节点集群的全过程这里分享一个我常用的本地开发环境搭建方式。生产环境一般用专门的集群管理工具或云厂商托管服务但本地用 Docker Compose 最快能起一套完整的集群来验证数据模型和代码逻辑。version: 3 services: cassandra-node1: image: cassandra:4.1 container_name: node1 ports: - 9042:9042 environment: - CASSANDRA_CLUSTER_NAMETestCluster - CASSANDRA_SEEDSnode1 - CASSANDRA_ENDPOINT_SNITCHSimpleSnitch cassandra-node2: image: cassandra:4.1 container_name: node2 ports: - 9043:9042 environment: - CASSANDRA_CLUSTER_NAMETestCluster - CASSANDRA_SEEDSnode1 depends_on: - cassandra-node1 cassandra-node3: image: cassandra:4.1 container_name: node3 ports: - 9044:9042 environment: - CASSANDRA_CLUSTER_NAMETestCluster - CASSANDRA_SEEDSnode1 depends_on: - cassandra-node1启动之后等待大约 60 秒让三个节点建立 gossip 通信然后进入任意容器执行docker exec -it node1 nodetool status如果输出中三个节点都显示UNUp Normal说明集群已正常工作。这里有一个容易踩的坑CASSANDRA_SEEDS只需要配置种子节点seed node的 IP不是所有节点都要写进去。种子节点的作用只是方便新节点快速发现其他节点而不是承担更多数据负载。不要把 seed 理解成“主节点”Cassandra 是无主架构所有节点角色对等。4.4 Snitch、Gossip 和 Failure Detection 的联动机制Snitch 负责告诉 Cassandra 每个节点的机架和数据中心位置信息它决定了副本的物理分布策略。常见的生产环境选择是GossipingPropertyFileSnitch通过配置文件cassandra-rackdc.properties声明每个节点的 dc 和 rack 信息。这个信息直接影响到故障域的隔离能力——例如同一个分区的三个副本应该尽量分布在不同机架甚至不同机房避免一个机架断电导致所有副本同时丢失。Failure Detection 依赖 gossip 协议的心跳信息。节点之间每秒钟交换一次状态信息默认phi_convict_threshold为 8当某个节点被标记为 down协调节点上的 hinted handoff 会立刻启动。如果网络质量不好容易出现误判可以通过调大phi_convict_threshold来降低误判率但这样也会延长真正故障时发现的时间。建议在云环境尤其是有网络抖动时调到 10 到 12物理机房内网络稳定时可以保持默认值。4.5 备份与恢复别等到数据丢了才意识到 repair 有多重要Cassandra 的备份有两种快照备份和增量备份。nodetool snapshot会在每个节点上生成当前 SSTable 文件的硬链接这个操作非常快一般不影响线上读写。恢复时先把快照文件拷贝回数据目录然后重启节点。但要注意快照备份只能恢复到备份时刻的数据状态之后的新写入数据如果没有增量备份就会丢失。对于长周期数据安全最重要的事情是定期执行全量 repair。nodetool repair -pr-pr表示只 repair 当前节点负责的范围而不是全集群的应该作为每周的例行任务去跑。repair 的过程本质上是比对副本间的数据差异并补齐它会消耗不少磁盘 IO 和网络带宽一般建议在业务低峰期执行并且一次只在一个节点上跑不要在集群所有节点同时发起 repair。我见过不少团队因为嫌 repair 消耗资源几个月不执行一次。结果某天一台机器磁盘坏了数据恢复之后发现少了很大一块——因为多个副本都在过去某个时间点加载了同一条损坏的 SSTable 或者不同步。这些数据不是靠“重启”就能找回来的只能靠 repair 机制在平时慢慢修复。所以我的建议是从集群建好的第一天起就把 repair 列入固定巡检项不要拖。5. 性能调优与故障排查那些文档没告诉你的事5.1 为什么写入变慢了先从 Compaction 和 GC 找起Cassandra 写入性能突然下降最常见的元凶是两个Compaction 风暴和 JVM Full GC。Compaction 是 Cassandra 在后台把多个 SSTable 合并成一个更大 SSTable 的过程。当写入压力大时生成的 SSTable 数量会激增Compaction 线程会消耗大量 CPU 和磁盘 IO。如果同时触发了多个大表的 Compaction就会出现 IO 争抢前端写入延迟就会明显上升。应对策略选择合适的 Compaction 策略。SizeTieredCompactionStrategySTCS在写入量大时会导致临时空间需求巨大LeveledCompactionStrategyLCS读性能更好、空间更可控但 Compaction 更频繁CPU 开销稍高。对于时序数据写入为主的场景TimeWindowCompactionStrategyTWCS是最合适的——它按时间窗口组织 SSTable可以显着降低 Compaction 压力。控制concurrent_compactors的数量默认是 min(CPU 核数 / 2, 8)。如果磁盘是 HDD建议调低到 2~3避免 Compaction 占满磁盘队列导致前端的读写全部排队。Full GC 的问题同样需要关注。Cassandra 的 JVM 堆默认配置是 8GB老版本。如果数据写入频繁导致堆内存中的对象积累过多就会触发频发的 GC每次 GC 会有停顿stop-the-world客户端会有明显的超时感知。调优手段主要是两个方向减少堆内对象分配尽量使用堆外内存off-heap配置比如cassandra.max_map_count相关的内存映射配置以及file_cache_size_in_mb的合理设置。换用更合适的 GC 算法例如 G1GC但也要注意 G1GC 在大堆场景下可能出现 RSet 过大问题。我个人在 64GB 堆以上的节点上比较推荐 ZGC需要 JDK11停顿时间控制在毫秒级。5.2 Cassandra 的“慢查询”定位方法排查慢查询不要猜要动手。先用nodetool tablestats查看表的 SSTable 数量和每层大小再用nodetool cfhistograms查看读写延迟分布。如果发现ReadLatency的 99 百分位明显高于 95 百分位说明存在少量的长尾读请求这类请求通常来自分区过大大分区或二级索引扫描。更理想的定位工具是开启全量查询日志Full Query Loggingnodetool enablefullquerylog --path /var/log/cassandra/fql开启之后配合fqltool dump导出查询日志可以精确地看到每个慢查询的语句、涉及的表、执行耗时和返回行数。生产环境下这种方式比猜测高效得多。此外在应用侧我给所有 Cassandra 查询都加了 trace使用 driver 自带的 trace 或简单地用nodetool trace打开 session 级 trace可以直观看到请求在协调节点、副本节点之间的流转时间。通常你会发现瓶颈要么在某个节点 GC要么在副本间通信特别是有跨机房流量时要么是读取了过多分区导致序列化到客户端的开销大。5.3 一致性级别选错了读写延迟翻倍很多人在代码里图省事读写都默认用QUORUM。如果集群跨了两个机房且延迟较高这种配置会让每次请求都等待跨机房 RTT延迟轻松翻倍。我的经验法则是单机房读写都用LOCAL_QUORUM多机房业务流量同时写入多个机房每个机房内部读写都使用LOCAL_QUORUM依靠异步复制保证两个机房最终一致如果某些关键读操作要求绝对的“看到最新写入”允许接受略高延迟可以使用QUORUM但只用于那些特定查询不要全表统一在配置层面quorum的计算受replication factor影响如果 RF3QUORUM 的最小成功数为 2LOCAL_QUORUM 同理。如果 RF5QUORUM 是 3。这意味着 RF 越大可用性和一致性越好但每次操作的等待副本数也越多性能相应下降。选 RF3 还是 RF5本质上是在“性能”和“故障容忍度”之间权衡。5.4 一个排查数据丢失的典型案例之前有一个用户反馈“数据偶尔丢”我排查了三天三夜最终定位到根因他们的代码用了INSERT ... IF NOT EXISTS语法来去重但这个语法会触发轻量级事务LWT。LWT 在 Cassandra 里是一类性能极差的操作它需要对分区内的所有副本进行共识协调在跨机房部署时每次 LWT 都需要跨机房达成 quorum节点延迟稍微一高客户端就会触发超时重试而重试的写操作和首次写操作可能发生在不同的 coordinator 上导致部分副本上的数据相互覆盖表面看起来就是“数据随机丢”。解法很简单评估业务是否真的要“数据已存在就不写入”如果是LWT 确实是唯一原生方案但需要接受它比普通写入慢 10 倍以上的事实如果业务逻辑能容忍“重复写入后手动去重”那就去掉IF NOT EXISTS换用普通写入如果必须去重则可以把去重逻辑移到应用层用一个单独的去重表用 Redis 或者另一个 Cassandra 表做唯一键检查不要直接压在 Cassandra 的 LWT 机制上Cassandra 的适合场景里默认就有一条“不要依赖强一致性保证”LWT 是它提供的例外能力但代价极高。用很少要慎重不要把它当成事务型数据库来做。5.5 监控之外容量规划的经验公式最后分享一个我做容量规划的简化公式单节点写入能力预估每节点每秒可接受 5000~10000 次普通写入视硬件和数据大小而定这是保守值节点数 预期峰值写入 TPS / 5000 × 副本因子存储容量 每日新增原始数据量 × 副本因子 × 30 ~ 90 天保留期举个例子假如你有 20 万 TPS 写入峰值每天产生 100GB 原始数据需要保留 30 天RF3节点数200000 / 5000 × 3 120 节点这是 TPS 角度存储100GB × 3 × 30 9TB如果单节点有效存储 1TB需要 9 节点两者取大则需要 120 节点但这里显然有优化空间提高单节点处理能力可以降低节点数。比如选择更好的 SSD 和更充裕的内存可以让单节点写入能力提升到 2 万 TPS那节点数就变成 30存储角度 9 节点取 30 即可。容量规划的最终目的是找到吞吐瓶颈和存储瓶颈之间的平衡点合理配置副本因子和压缩策略。Cassandra 默认支持LZ4Compressor生产环境建议把表级压缩改为ZstdCompressor压缩率更高对 CPU 的额外开销也很小存储量可以进一步减少 25% 到 30%。6. 关于 Cassandra 的生态与适用边界最后一轮思考Cassandra 不是万能的但它是目前开源分布式数据库里在高可用写入、多机房多活场景下比较成熟的选择之一。很多人在选择 Cassandra 之前都先被它的性能数据或分布式能力吸引然后才意识到它的数据模型约束和运维复杂度才是真正的门槛。我自己的经验是一个项目适不适合 Cassandra先不要看性能指标先看业务查询模式适不适合分区键 Clustering Key 的天然表达方式。如果业务查询的路径和你设计的 primary key 路径不一致性能再好的数据库也会变成负担。反过来如果业务天然是按用户、设备、传感器 ID 这类维度做读写那 Cassandra 几乎是为这种场景量身定制的。实际项目实施过程中我还会额外注意几个环节团队是否有人能持续关注 JVM 和 Compaction 状态、是否接受每周跑 repair、是否有能力处理偶发的 gossip 分区和网络分区问题。这些都不是 Cassandra “不好”而是分布式系统的固有复杂度不能指望通过某个工具、某个配置一劳永逸地消除。我个人的使用体感是Cassandra 的“学习曲线”其实不算陡峭——它的 CQL 很接近 SQLAPI 也很稳定写个 demo 很快。真正的难点在于深入使用之后对运维能力的考验以及面对数据模型设计失误时修改成本非常高。数据模型一旦开跑调整 partition key 意味着全量数据重分布这在量大之后几乎等于重做系统。所以设计阶段多花时间在建模上比上线后再补强要划算得多。最后再分享一个小技巧如果你当前业务还在早期阶段数据量没过亿业务形态还在快速迭代先用 PostgreSQL/MySQL 跑起来完全没有问题。等真正遇到写入吞吐瓶颈了、需要多机房多活了再把数据分层抽到 Cassandra 里。第一版用单机数据库快速验证业务模式第二版才引入分布式系统这是我见过成功率最高的演进路径。Cassandra 是一门值得深入学习的技术它的分布式架构设计很多思路放到今天依然先进。希望这篇实践分享能让你在动手使用之前对这些底层机制和隐藏成本有一个相对完整的图景少走一些我当初走过的弯路。