我们真的需要多租户吗

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

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

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

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

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

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

我们先活下去再说

update 2024 06

  • 这里讨论的多租户指的是db层，类似tidb/crdb/baikaldb那种针对 sql类型的表级别多租户
  • 当然现在的思路是serverless，是面向api/流量设计，底层可能混合部署，主要是为了偷CPU，数据层大概率是拆开的，不混合部署
  • 当然这里混合部署有raft组性能不行的折中

update 2024 07 关于raft的一些思考

  • 用raft不用多租户(multi-raft)，除非是meta server，否则发挥不出性能优势
  • 但是大部分业务规模撑不起多租户设计，多租户kv越看越像过度设计
    • a. 关系型天然多租户，有不同用户不同表模式，所有数据混合部署，而kv混合部署也可以，纯纯的增加实现难度
    • b. 如果FS针对KV进行设计，类似分布式对象存储的解决办法，完全可以从另一个高度绕过混部方案，显得多租户磁盘模式非常小丑
  • 提高磁盘利用率的前提是盘都给你用，很多基于云平台做的paas上的设计，你拿不到那么多东西，成本直接拒绝
    • a. 甚至PVC网盘都不能放开了用，成本太高了，用S3接口又变得特复杂
    • b. 这种天然接近云厂商的设计，做冷存S3的需求非常高，这也是一个优化方向

参考业界的一些kv实践比如abase2 memorydb 其实还是主备，更多的探索是多活，多可用区，全球同步

memorydb做的是兼容redis的前提上把log抽出来做可用性保证，最小化log，本身和写入路径没关系

如果写路径非得走raft，对于kv来说开销很难接受，关系型能接受是因为他们的业务逻辑本身要比raft开销重

kv + raft 开销很难弥补

  • 当然也有可能是raft实现不行
  • 无论如何也得等一跳，就算你做什么bound view那也得有一跳
  • 如果业务能接受弱一致，完全可以和主写路径剥离 优化这不就来了

参考资料

  • abase2的探索 https://zhuanlan.zhihu.com/p/614227806
  • https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247686974&idx=1&sn=5d98f7f2981447bb60e691c7a681b121&chksm=fbd9a952ccae204484ac8aa3ea76b70b5715beab9dcfef3b16869402cd3e2dcb927cce0c99fa&scene=0&xtrack=1