性能方向

在中台的哥们，昨天凌晨说他们的服务支持几十万 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，走起