详解yii2实现分库分表的方案与思路

前言

大家可以从任何一个gii生成model类开始代码上溯,会发现:yii2的model层基于ActiveRecord实现DAO访问数据库的能力。

而ActiveRecord的继承链可以继续上溯,最终会发现model其实是一个component,而component是yii2做IOC的重要组成部分,提供了behaviors,event的能力供继承者扩展。

(IOC,component,behaviors,event等概念可以参考http://www.digpage.com/学习)

先不考虑上面的一堆概念,一个站点发展历程一般是1个库1个表,1个库N个表,M个库N个表这样走过来的,下面拿订单表为例,分别说说。

1)1库1表:yii2默认采用PDO连接mysql,框架默认会配置一个叫做db的component作为唯一的mysql连接对象,其中dsn分配了数据库地址,数据库名称,配置如下:

'components' => [ 'db' => [ 'class' => 'yii\db\Connection', 'dsn' => 'mysql:host=10.10.10.10;port=4005;dbname=wordpress', 'username' => 'wp', 'password' => '123', 'charset' => 'utf8', ],

这就是yii2做IOC的一个典型事例,model层默认就会取这个db做为mysql连接对象,所以model访问都经过这个connection,可以从ActiveRecord类里看到。

class ActiveRecord extends BaseActiveRecord { /** * Returns the database connection used by this AR class. * By default, the "db" application component is used as the database connection. * You may override this method if you want to use a different database connection. * @return Connection the database connection used by this AR class. */ public static function getDb() { return Yii::$app->getDb(); }

追踪下去,最后会走yii2的ioc去创建名字叫做”db”的这个component返回给model层使用。

abstract class Application extends Module { /** * Returns the database connection component. * @return \yii\db\Connection the database connection. */ public function getDb() { return $this->get('db'); }

yii2上述实现决定了只能连接了1台数据库服务器,选择了其中1个database,那么具体访问哪个表,是通过在Model里覆写tableName这个static方法实现的,ActiveRecord会基于覆写的tableName来决定表名是什么。

class OrderInfo extends \yii\db\ActiveRecord { /** * @inheritdoc * @return */ public static function tableName() { return 'order_info'; }

2)1库N表:因为orderInfo数据量变大,各方面性能指标有所下降,而单机硬件性能还有较大冗余,于是可以考虑分多张order_info表,均摊数据量。假设我们要份8张表,那么可以依据uid(用户ID)%8来决定订单存储在哪个表里。

然而1库1表的时候,tableName()返回是的order_info,于是理所应当的重载这个函数,提供一种动态变化的能力即可,例如:

class OrderInfo extends \yii\db\ActiveRecord { private static $partitionIndex_ = null; // 分表ID /** * 重置分区id * @param unknown $uid */ private static function resetPartitionIndex($uid = null) { $partitionCount = \Yii::$app->params['Order']['partitionCount']; self::$partitionIndex_ = $uid % $partitionCount; } /** * @inheritdoc */ public static function tableName() { return 'order_info' . self::$partitionIndex_; }

提供一个resetParitionIndex($uid)函数,在每次操作model之前主动调用来标记分表的下标,并且重载tableName来为model层拼接生成本次操作的表名。

3)M库N表:1库N表逐渐发展,单机存储和性能达到瓶颈,只能将数据分散到多个服务器存储,于是提出了分库的需求。但是从”1库1表”的框架实现逻辑来看,model层默认取db配置作为mysql连接的话,是没有办法访问多个mysql实例的,所以必须解决这个问题。

一般产生这个需求,产品已经进入中期稳步发展阶段。有2个思路解决M库问题,1种是yii2通过改造直连多个地址进行访问多库,1种是yii2仍旧只连1个地址,而这个地址部署了dbproxy,由dbproxy根据你访问的库名代理连接多个库。

如果此前没有熟练的运维过dbproxy,并且php集群规模没有大到单个mysql实例客户端连接数过多拒绝服务的境地,那么第1种方案就可以解决了。否则,应该选择第2种方案。

无论选择哪种方案,我们都应该进一步改造tableName()函数,为database名称提供动态变化的能力,和table动态变化类似。

class OrderInfo extends \yii\db\ActiveRecord { private static $databaseIndex_ = null; // 分库ID private static $partitionIndex_ = null; // 分表ID /** * 重置分区id * @param unknown $uid */ private static function resetPartitionIndex($uid = null) { $databaseCount = \Yii::$app->params['Order']['databaseCount']; $partitionCount = \Yii::$app->params['Order']['partitionCount']; // 先决定分到哪一张表里 self::$partitionIndex_ = $uid % $partitionCount; // 再根据表的下标决定分到哪个库里 self::$databaseIndex_ = intval(self::$partitionIndex_ / ($partitionCount / $databaseCount)); } /** * @inheritdoc */ public static function tableName() { $database = 'wordpress' . self::$databaseIndex_; $table = 'order_info' . self::$partitionIndex_; return $database . '.' . $table; }

在分表逻辑基础上稍作改造,即可实现分库。假设分8张表,那么分别是00,01,02,03…07,然后决定分4个库,那么00,01表在00库,02,03表在01库,04,05表在02库,06,07表在03库,根据这个规律对应的计算代码如上。最终ActiveRecord生效的代码都会类似于”select * from wordpress0.order_info1″,这样就可以解决连接dbproxy访问多库的需求了。

那么yii直接访问多Mysql实例怎么做呢,其实类似tableName() ,我们只需要覆盖getDb()方法即可,同时要求我们首先配置好4个mysql实例,从而可以通过yii的application通过IOC设计来生成多个db连接,所有改动如下:

先配置好4个数据库,给予不同的component id以便区分,它们连接了不同的mysql实例,其中dsn里的dbname只要存在即可(防止PDO执行use database时候不存在报错),真实的库名是通过tableName()动态变化的。

'db0' => [ 'class' => 'yii\db\Connection', 'dsn' => 'mysql:host=10.10.10.10;port=6184;dbname=wordpress0', 'username' => 'wp', 'password' => '123', 'charset' => 'utf8', // 'tablePrefix' => 'ktv_', ], 'db1' => [ 'class' => 'yii\db\Connection', 'dsn' => 'mysql:host=10.10.10.11;port=6184;dbname=wordpress2', 'username' => 'wp', 'password' => '123', 'charset' => 'utf8', // 'tablePrefix' => 'ktv_', ], 'db2' => [ 'class' => 'yii\db\Connection', 'dsn' => 'mysql:host=10.10.10.12;port=6184;dbname=wordpress4', 'username' => 'wp', 'password' => '123', 'charset' => 'utf8', // 'tablePrefix' => 'ktv_', ], 'db3' => [ 'class' => 'yii\db\Connection', 'dsn' => 'mysql:host=10.10.10.13;port=6184;dbname=wordpress6', 'username' => 'wp', 'password' => '123', 'charset' => 'utf8', // 'tablePrefix' => 'ktv_', ],

覆写getDb()方法,根据库下标返回不同的数据库连接即可。

class OrderInfo extends \yii\db\ActiveRecord { private static $databaseIndex_ = null; // 分库ID private static $partitionIndex_ = null; // 分表ID /** * 重置分区id * @param unknown $uid */ private static function resetPartitionIndex($uid = null) { $databaseCount = \Yii::$app->params['Order']['databaseCount']; $partitionCount = \Yii::$app->params['Order']['partitionCount']; // 先决定分到哪一张表里 self::$partitionIndex_ = $uid % $partitionCount; // 再根据表的下标决定分到哪个库里 self::$databaseIndex_ = intval(self::$partitionIndex_ / ($partitionCount / $databaseCount)); } /** * 根据分库分表,返回库名.表名 */ public static function tableName() { $database = 'wordpress' . self::$databaseIndex_; $table = 'order_info' . self::$partitionIndex_; return $database . '.' . $table; } /** * 根据分库结果,返回不同的数据库连接 */ public static function getDb() { return \Yii::$app->get('db' . self::$databaseIndex_); }

这样,无论是yii连接多个mysql实例,还是yii连接1个dbproxy,都可以实现了。

网上有一些例子,试图通过component的event机制,通过在component的配置中指定onUpdate,onBeforeSave等自定义event去hook不同的DAO操作来隐式(自动)的变更database或者connection或者tablename的做法,都是基于model object才能实现的,如果直接使用model class的类似updateAll()方法的话,是绕过DAO直接走了PDO的,不会触发这些event,所以并不是完备的解决方案。

这样的方案原理简单,方案对框架无侵入,只是每次DB操作前都要显式的resetPartitionIndex($uid)调用。如果要做到用户无感知,那必须对ActiveRecord类进行继承,进一步覆盖所有class method的实现以便插入选库选表逻辑,代价过高。

补充:关于分库分表的一些实践细节,分表数量建议2^n,例如n=3的情况下分8张表,然后确定一下几个库,库数量是2^m,但要<=表数量,例如这里1个库,2个库,4个库,8个库都是可以的,表顺序坐落在这些库里即可。
为什么数量都是2指数,是因为如果面临扩容需求,数据的迁移将方便一些。假设分了2张表,数据按uid%2打散,要扩容成4张表,那么只需要把表0的部分数据迁移到表2,表1的部分数据迁移到表3,即可完成扩容,也就是uid%2和uid%4造成的迁移量是很小的,这个可以自己算一下。

总结

以上就是关于yii2实现分库分表的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流。

时间: 2024-10-05 14:43:02

详解yii2实现分库分表的方案与思路的相关文章

TSharding:用于蘑菇街交易平台的分库分表组件

  tsharding TSharding is the simple sharding component used in mogujie trade platform. 分库分表业界方案 分库分表TSharding TSharding组件目标 很少的资源投入即可开发完成 支持交易订单表的Sharding需求,分库又分表 支持数据源路由 支持事务 支持结果集合并 支持读写分离 TSharding Resources Abstract TSharding Resources Classes TS

大众点评订单分库分表实践之路

本文是关于大众点评订单分库分表实践的一个具体分享,包含对订单库的具体切分策略,以及我个人的一些思考. 背景   订单单表早已突破两百G,因查询维度较多,即使加了两个从库,各种索引优化,依然存在很多查询不理想的情况.加之去年大量的抢购活动的开展,数据库达到瓶颈,应用只能通过限速.异步队列等对其进行保护.同时业务需求层出不穷,原有的订单模型很难满足业务需求,但是基于原订单表的DDL又非常吃力,无法达到业务要求.随着这些问题越来越突出,订单数据库的切分就愈发急迫了. 我们的目标是未来十年内不需要担心订

Mysql分库分表Mycat详解介绍

一直对Mysql分库分表有点兴趣,但是也一直停留在有兴趣的阶段,没有遇到能应用的场景.人生苦短,与其等一个机会,不如自己创造吧.稍微调研了下,选择使用 Mycat 这样一款开源产品.没有什么特别的理由,也不去讨论挖掘机哪家强,只是为了学习. 本机环境 电脑环境:Ubuntu 16.04 JDK:1.8 Docker version 1.11.2 Mysql 5.7.13 Mycat 1.5-RELEASE Navicat for Mysql 安装Mysql 为了测试方便,Mysql都跑在Dock

MySQL分库分表的实现过程详解介绍

MySQL分库分表基础表介绍 表基本模型结构 这里我们模拟一个商城的基本的表结.此结构由(用户.门店.导购.门店商品.订单.订单对应的商品).其中,导购也是一个用户,门店是只属于一个店主的,同时店主本身也是一个导购也是一个普通用户. 结构图:   构造数据脚本 MySQL分库分表(1)-脚本 对业务场景进行模拟 场景1:购买者下订单. 1.从session中获得客户ID. 2.可以通过时间戳等拼凑一个订单ID(在创建表的时候为了方便我用自增的,在以下我们一直就吧订单ID看成不是自增的,是用程序生

透明的分库分表方案

问题提出 随着应用规模的不断扩大,单机数据库就慢慢无法满足应用的需要了,这主要表现在如下方面: 存量数据越来越大,查询速度越来越慢 访问并发越来越大,磁盘IO.网络IO.CPU都慢慢成为瓶颈 事务数越来越多,事务冲突越来越严重,导致TPS越来越少 这个时候,有的人采用了换商用数据库的方案比如Oracle,然后用Oracle的RAC方式进行水平扩展.但是带来的缺点也比较明显,第一是成本太高,一般人吃不消:第二,管理复杂度较单节点有非常大的提升,风险及管理成本也相应增加:第三,对人员的水平要求更高,

mysql 分库分表的方法

分表后怎么做全文搜索 1.merge方式分表(不好) 2. 使用 sql union 3 使用Sphinx全文检索引擎 一,先说一下为什么要分表 当一张的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了.分表的目的就在于此,减小数据库的负担,缩短查询时间. 根据个人经验,MySQL执行一个sql的过程如下: 1,接收到sql;2,把sql放到排队队列中 ;3,执行sql;4,返回执行结果.在这个执行过程中最花时间在什么地方呢?第一,是排队等待的时间,第二,

【资料整理】分库&amp;分表

      此贴用于扫盲.===============================  [分表] (下面说到的内容都是基于"按照关系型数据库的第三范式要求应该在同一个表的"的情况)          分表,最直白的意思,就是将一个表结构分为多个表,分表后,可以存在于同一个库里,也可以放到不同的库.   [为什么要分表?]         保证单表的容量不会太大,从而来保证单表的查询等处理能力.例如单表记录条数达到百万到千万级别时就要使用分表.   [分表方式?]   1.纵向分表

【转】微服务MySQL分库分表数据到MongoDB同步方案

需求背景 近年来,微服务概念持续火热,网络上针对微服务和单体架构的讨论也是越来越多,面对日益增长的业务需求是,很多公司做技术架构升级时优先选用微服务方式.我所在公司也是选的这个方向来升级技术架构,以支撑更大访问量和更方便的业务扩展. 发现问题 微服务拆分主要分两种方式:拆分业务系统不拆分数据库,拆分业务系统拆分库.如果数据规模小的话大可不必拆分数据库,因为拆分数据看必将面对多维度数据查询,跨进程之间的事务等问题.而我所在公司随着业务发展单数据库实例已经不能满足业务需要,所以选择了拆分业务系统同时

分库分表下uuid的生成

    分库分表时一般有必要自定义生成uuid,大企业一般有自己的uuid生成服务,其他它的实现很简单.我们以订单号为例,组成可以是"业务标识号+年月日+当日自增数字格式化",如0001201608140000020.当然,如果我们用"业务标识号+用户唯一标识+当前时间"也是可以达到uuid的目的的,但用户唯一标识是敏感信息且可能不太方便处理为数字,所以弄一套uuid生成服务是很有必要的.本文就来研究下怎么实现自增数字,且性能能满足企业中的多方业务调用.起初,我想的