Cassandra 不适合替代 MySQL 做事务型微服务核心数据存储，但它是高吞吐、低延迟、多写入点场景下极少数能扛住每秒数万写入的持久层选择——前提是业务能接受最终一致性、无 JOIN、无外键、不依赖强事务语义。
直接说结论：Cassandra 不适合替代 MySQL 做“事务型”微服务核心数据存储，但它是高吞吐、低延迟、多写入点场景下极少数能扛住每秒数万写入的持久层选择——前提是你的业务能接受最终一致性、无 JOIN、无外键、不依赖强事务语义。
为什么不能把 Cassandra 当 MySQL 用
很多团队踩的第一个坑，就是拿 gocql 驱动连上 Cassandra，照着 MySQL 的建模习惯写 CREATE TABLE users (id UUID PRIMARY KEY, name TEXT, email TEXT)，然后发现查询慢、索引失效、删数据卡死。根本原因在于 Cassandra 的数据模型不是为关系型操作设计的：
- Cassandra 没有真正的二级索引（
CREATE INDEX在高基数字段上会严重拖慢写入，且查询性能不可控） - 不支持
JOIN、GROUP BY、子查询；所有查询必须基于主键（PRIMARY KEY）或物化视图（MATERIALIZED VIEW），而后者在 4.0+ 版本已被标记为 deprecated -
DELETE不是立即生效，而是打 tombstone 标记，大量 delete + insert 会引发 compaction 压力，导致读放大和 GC 压力飙升 - 没有事务回滚能力，
BATCH仅保证原子性（同一 partition 内），跨 partition 的 batch 实际是客户端模拟，失败需手动补偿
gocql 连接池与超时配置必须显式调优
默认的 gocql.ClusterConfig 是为测试环境设计的，生产中不调参等于裸奔。常见错误现象包括：goroutine 泄漏、连接耗尽、RPC 超时后重试风暴打垮节点。
- 务必设置
Timeout和ConnectTimeout（建议 ≤ 1s），否则网络抖动时请求会卡在 dial 阶段长达 30 秒 -
NumConnsPerHost别设成 0 或过小（默认 2）；单节点写入压力大时，建议设为 4–8，配合Consistency级别（如Quorum）平衡延迟与可用性 - 启用
QueryTimeout（比如 500ms），并在业务代码里用context.WithTimeout包裹每次session.Query(...).WithContext(ctx).Exec()，避免单个慢查询拖垮整个 goroutine - 禁用
DisableInitialHostLookup: true（除非你确定 DNS 稳定），否则首次连接失败率极高；同时设置HostFilter排除已知不健康节点
主键设计决定一切性能，不是“先写再优化”
Cassandra 的读写性能几乎完全由表的 PRIMARY KEY 结构决定。一个典型反例：PRIMARY KEY (user_id, timestamp) 看似合理，但如果按时间范围查（比如“查用户最近 10 条操作”），就会触发全 partition scan —— 因为 timestamp 是 clustering key，Cassandra 只能按前缀匹配，无法跳过中间值。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 高频查询路径必须能映射到单个 partition key + clustering key 前缀，例如按设备 ID + 小时粒度时间分桶：
PRIMARY KEY ((device_id, hour), ts, seq) - 避免热点 partition：不要用全局递增 ID 或时间戳作 partition key；用
MD5(device_id || day)或shard_id = device_id % 16打散写入 - 写多读少场景，优先用 wide-column 模型（一行存数百列），而非“一行一事件”；Cassandra 对宽行读写极其友好，但对海量窄行扫描极不友好
- 删除操作尽量用 TTL（
USING TTL 86400）代替DELETE，避免 tombstone 积压；TTL 到期后由 compaction 自动清理
最终一致性下的业务补偿必须前置设计
你无法用 tx.Commit() 保证“订单写入 + 库存扣减 + 日志落盘”原子性。Cassandra 本身不提供跨表事务，更不提供跨服务事务。所有“写成功但下游没收到”的情况，都得靠业务层兜底。
- 所有写入必须附带幂等 key（如
request_id），并存入 Cassandra 同一分区（用于快速去重查询） - 关键状态变更（如“订单已支付”）必须落库后立即发 Kafka 消息，消费者端用
INSERT ... IF NOT EXISTS实现幂等写入 - 监控
system.peers表和system.local中的rpc_address、schema_version，及时发现节点失联或 schema 不一致 - 不要依赖
ALLOW FILTERING做 ad-hoc 查询——它会扫全表，线上禁止使用；临时排查用cqlsh加LIMIT，生产接口必须走预定义主键查询路径
最常被忽略的一点：Cassandra 的“高并发”是建立在写入路径极度简化的基础上的。它快，是因为不做约束检查、不维护复杂索引、不执行事务日志刷盘。一旦你开始在应用层补这些缺失的能力（比如手写分布式锁、自研唯一索引校验、定时清理 tombstone），性能优势就迅速瓦解。选它，就得接受它的哲学——用数据模型换吞吐，用最终一致性换扩展性。
