go + cassandra 能支撑每秒数万写入和毫秒级查询，但必须显式调优 gocql 连接池（如 numconnsperhost 设为 cpu 核数×2、timeout 提至 2s）、合理设计分区键（避免时间戳单一分区、采用哈希+日期组合）、禁用 batch 改用 executeasync 并发提交、关闭初始主机查找、使用 localquorum 一致性级别，并确保读写直连无 http 中间层。
直接说结论：Go + Cassandra 能撑住每秒数万写入、毫秒级查询，但前提是绕开常见建模陷阱和驱动默认配置——否则并发一上来就 timeout 或 UnavailableException。
gocql 连接池配置必须显式调优
默认的 gocql.NewCluster() 用的是极保守连接策略，高并发下会快速耗尽连接或触发重试风暴。
-
cluster.Timeout = 2 * time.Second—— 默认是 600ms，Cassandra GC 暂停或网络抖动时大量请求直接失败 -
cluster.NumConnsPerHost = 4—— 单 host 默认只开 2 连接，goroutine 数 > 100 时排队严重；建议设为 CPU 核数 × 2 -
cluster.Consistency = gocql.Quorum—— 不要盲目用One换性能，写入丢失风险陡增；读多写少场景可考虑LocalQuorum - 务必启用
cluster.DisableInitialHostLookup = true，避免启动时 DNS 查询阻塞服务就绪
分区键设计决定吞吐上限
Cassandra 不是“能存就行”，INSERT 和 SELECT 的性能差异全在分区键上。一个错误的分区键会让 10k QPS 直接掉到 200 QPS。
- 避免用时间戳（如
created_at）单独作分区键——导致热点写入，所有请求打到同一台节点 - 推荐组合：高频查询字段 + 哈希后缀，例如用户行为表用
user_id % 16作为分区键一部分，再拼上日期，形成user_id_hash_20260706 - 单个分区数据量别超 100MB —— 否则 compaction 压力大，读延迟飙升；用
token()函数验证分布是否均匀
批量写入别用 Batch，改用 Session.ExecuteAsync 并发提交
gocql.Batch 是逻辑批量，实际仍串行执行、共用单次超时；高并发写场景下极易卡死或丢数据。
- 把一批数据拆成多个独立
INSERT，每个用session.Query(...).ExecAsync()提交 - 控制并发 goroutine 数，建议用带缓冲的 channel 限流，比如
sem := make(chan struct{}, 50)防止瞬时打爆节点 - 写入失败时不要简单重试——先检查错误类型：
gocql.WriteTimeoutError说明负载已满，应降速；gocql.UnavailableError则需跳过该批次，等集群恢复
微服务里查 Cassandra 别走 HTTP 中间层
常见错误是 Go 服务 → REST API → Cassandra，这引入额外序列化/反序列化和网络跳转，延迟从 2ms 变成 15ms+，且无法利用 gocql 的连接复用和预编译语句。
- Go 微服务直接依赖
gocql，把 session 封装成 singleton 或依赖注入对象，全局复用 - 所有 CQL 语句提前用
session.Query(...).Bind(...)绑定参数，避免运行时字符串拼接 - 读请求加
WithContext(ctx)并设置合理 deadline，防止慢查询拖垮整个 goroutine pool
最易被忽略的点：Cassandra 的 read_repair_chance 和 dclocal_read_repair_chance 配置，在跨 DC 部署时若没调低，一次读可能触发多次后台协调，放大延迟波动。上线前必须确认这些值是 0.0 或 0.1，而不是默认的 0.1/0.2。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
