我们真的需要多租户吗

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

  • 独占一个集群,降低其他业务影响,充分利用资源 (可能一个进程独占一个盘,需要足够多的内存来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