在中台的哥们，昨天凌晨说他们的服务支持几十万 TPS 和 百万级 QPS，这个量级相当可以了
压测结果也很理想
根据以往的经验，写了一套方案，也想能支持几十万的 TPS + 百万 QPS
支持十万级别的 TPS + 百万级 QPS 方案： 1、nginx + keepalive + web server 2、粗细管道限流措施（粗管道 200万/秒；细管道 10万/秒）； 3、以 UID 分为 n个订单库 + m个订单分表（每个库）（当时做的是电商） 4、事务操作时，采用 keepalive + master 5、读取操作时，采用 LVS + slave + redis 读取中间件 MYCAT
我们现在abs -- tps 20 W左右
tps的 瓶颈 在 io 上 所以要优先考虑 存储架构 我们用的cds
qps的瓶颈在 相应时间和 应用内存上 要考虑分布式扩展就可以 具体应用上层的代理负载什么的 很多中间件都可以做到 我们不是依赖的cds cds那套策略 只是用着方便 随便一个分库分表中间件或者自己写一套都可以替代
主要还是看存储的 冷热数据 和数据命中率的io 效率
cds作为分库分表的中间件 替代品很多 但是作为一个cds平台 我想在业界没有几个公司有这样的 我们现在仅仅轻度依赖了他们的分库分表 在abs老版本的时候 没有用cds 我们自己写的分库分表 依旧玩得转
恩，恩，在客户端搞定，还是用了中间件，例如：MYCAT
嗯嗯 咱们可以 用用 sharding jdbc
这个中间件 比起mycat 还是有优势的吧
而且是京东开源的 apache 顶级项目了吧
恩，在客户端实现，应该在性能上有优势的
但是，运维配置是否就比较麻烦了？
一般大公司 在分库分表已经早就放弃咱们现在的这种模式了吧 用 proxy模式了吧 我想阿里 内部应该就是这种模式了 咱们京东cds也在做 不过没做好呢吧
proxy是可以吧 所有存储做管理 对于 存储 彻底与应用隔离 但是就是对于资源和体量有要求 性能是最大挑战了
热数据不过2KW 冷数据不过5KW 就不需要考虑存储 这个量级 单库 单表 虚机的mysql 差不多 玩的转 如果要是预期超过这个量级 就需要考虑一下 分库分表虚机 如果非要物理机 单台的物理机 不如四台虚机玩的转 分布式存储是解决tps的利器
农行，百万 TPS，走起
