重新思考多租户存储

[wanghenshui]

多租户存户的主要目的是为了均衡打散资源，提高资源利用率

• 独占一个集群，降低其他业务影响，充分利用资源 （可能一个进程独占一个盘，需要足够多的内存来cache，数据分片显然也不能按照盘为单位，通常可以拆一百个分片 这样通过copyset远离，将资源充分打散降低同时故障的概率

• 数据规模足够大，方便均摊与均衡 和偷CPU，也更能利用空闲资源

其实这俩需求并不是完全的能站得住脚，很多小厂机器并没有那么多，甚至很多公司就是用混合云自己搞一套paas管理平台，云平台都给你做好

• 独占集群，利用k8s分组管理，但问题是爆炸半径无法解决，以及可用区挂掉一锅端，虽然copyset降低了故障率，那也是单可用区的锦上添花，业务还是要做多可用区的。甚至三可用区，业务思考的是自己怎么省事多活，怎么多活是存储的事，多租户存储，多活转发也是一个比较复杂的点
  • 肯定要有个log落盘，这个开销就很大，基本上各种raft瓶颈都在这里，和多租户就没啥关系了，多租户还有点优势，多组分片还能提高吞吐
  • 转发就要设计一套CDC玩法，然后传过去的数据也会有静默损坏的问题
  • facebook甚至玩flexraft这种异地同步的骚操作，省掉转发的工作量
• 资源利用率提升 这种和云服务商给你一批机器你自己上层paas管理 分配，那种资源利用率高呢，很难说，对于小厂而言，并没有独占PB级别资源给你玩多租户的条件，更多的是你先接上业务再说 资源利用率提升的两种角度吧，你哼哧哼哧搞多租户，上层paas调度就绕过去了
• 多租户要引入qos和ru设计，而这也是云平台在上层已经规划好了的，除非你独占的集群有单独的网卡/rdma 为了更好的实现性能提升，不得不采用的手段，而qos和ru设计也不是简单的工作
• 多租户的路由管理要更复杂，router要维护多账户多版本路由，也要维护账户上下文信息，这些管理工作不简单
• 独占集群，集群级别的管理资源上下架也是很重的工作，控制面管理要比想象中的复杂的多
  • 当然控制面对于普通单体集群也是要做的，不过就简单的多

多租户对于大厂来说是杀手锏，使得大厂员工过于重视数据规模以及数据规模带来的问题，对于一般用户，这种问题其实并不在考虑范围内，一般用户活下去就挺费劲了

所以说redis kvrocks 这种主备 / 社区集群模式 也不是不能用，就对付用了

我们先活下去再说