|
|
51CTO旗下网站
|
|
移步端
  • 别再问“国库分表”了,再问就崩溃了!

    在议论必发娱乐登录架构和必发娱乐登录优化的时节,咱们经常会听到分库分表,国库分表其实涉及到众多难题,当日我们来汇总一下必发娱乐登录分库分表解决方案。

    笔者:butterfly100 来源:博客园| 2019-12-17 09:29

    在议论必发娱乐登录架构和必发娱乐登录优化的时节,咱们经常会听到分库分表,国库分表其实涉及到众多难题,当日我们来汇总一下必发娱乐登录分库分表解决方案。


    图表来自 Pexels

    数量切分

    沟通型必发娱乐登录本身比较容易成为系统瓶颈,裸机存储容量、联网数、拍卖能力都有数。

    顶单表之多寡量达到 1000W 或 100G 自此,出于查询维度较多,即使添加从库、多极化索引,做很多操作时性能仍下降严重。

    此刻就要考虑对他进行切分了,数的目的就在于减少必发娱乐登录的承受,缩短查询时间。

    必发娱乐登录分布式核心内容无非就是数据切分(Sharding),以及切分后对数据的一定、构成。

    数量切分就是将数据分散储存到多个必发娱乐登录中,有效单一必发娱乐登录中的数据量变小,穿过扩展主机的多寡缓解单一必发娱乐登录的性质问题,故而达到提升必发娱乐登录操作性能的目的。

    数量切分根据她切分类型,可以分为两种方法:

  • 笔直(走向)数
  • 水平(走向)数
  • 笔直(走向)数

    笔直切分常见有垂直分库和垂直分表两种。

    笔直分库就是根据工作耦合性,名将关联度低的不同表存储在不同之必发娱乐登录。书法与大体系拆分为多个小系统类似,按业务分类进行独立划分。

    与"微服务治理"的作法相似,每个微服务使用单独的一个必发娱乐登录,如下图:

    笔直分表是基于必发娱乐登录中的"趟"拓展,某个表字段较多,可以新建一张扩展表,名将不经常用或字段长度较大的字段拆分出去到扩展表中。

    在字段很多之情况下(例如一个大表有 100 多个字段),穿过"大表拆小表",更便于开发与维护,也能避免跨页问题,MySQL 底层是通过数据页存储的,一枝记录占用空间过大会导致跨页,造成额外的性质开销。

    此外必发娱乐登录以行为单位将数据加载到内存中,这样表中字段长度较短且访问频率较高,内存能加载更多的多寡,汇率更高,调减了磁盘 IO,故而提升了必发娱乐登录性能。

    笔直切分的长处如下:

  • 消灭工作系统层面的耦合,工作清晰
  • 与微服务的治理类似,也能对不同工作的多寡进行分级管理、保护、监督、推而广之等
  • 高并发场景下,笔直切分一定水平的升级 IO、必发娱乐登录连接数、裸机硬件资源之瓶颈
  • 笔直切分的弱点如下:

  • 局部表无法 join,只能通过接口聚合方式解决,提升了开发的复杂度
  • 分布式事务处理复杂
  • 依然存在单表数据量过大的题材(要求水平切分)
  • 水平(走向)数

    顶一个用到难以再细粒度的垂直切分,或数后数据量行数巨大,存在单库读写、存储性能瓶颈,此刻就要求展开水平切分了。

    水平切分分为库内分表和分库分表,是根据表内数据内在的逻辑关系,名将同一个表按不同之尺度分散到多个必发娱乐登录或多个表中,每个表中只包含一部分数目,故而有效单个表的多寡量变小,到达分布式的功力。

    如图所示:

    库内分表只解决了单一表数据量过大的题材,但没有将表分布到不同机器的库上。

    故此对于减轻 MySQL 必发娱乐登录的压力来说,赞助不是很大,大家还是竞争同一个物理机的 CPU、内存、网络 IO,最好通过分库分表来解决。

    水平切分的长处如下:

  • 不存在单库数据量过大、高并发的性质瓶颈,提升系统稳定性和负载能力
  • 使用端改造较小,不需要拆分业务模块
  • 水平切分的弱点:

  • 跨分片的工作一致性难以保证
  • 跨库的 join 沟通查询性能较差
  • 数量多次扩展难度和保护量极大
  • 水平切分后同一张表会出现在多个必发娱乐登录/表面中,每个库/表面的情节不同。几种典型的多寡分片规则为:

    ①根据数值范围:按照时间区间或 ID 区间来切分。

    例如:按日期将不同月甚至是日的多寡分散到不同之库中;名将 userId 为 1~9999 的记录分到第一个库,10000~20000 的成分到第二个库,举一反三。

    那种意义上,少数系统中采用的"冷热数据分离",名将部分用到较少的历史数据迁移到其它库中,工作功能上只提供热点数据的询问,也是类似之实行。

    这样的长处在于:

  • 单表大小可控
  • 原始便于水平扩展,末了如果想对全部分片集群扩容时,只要求添加节点即可,不要对其它分片的多寡进行迁移
  • 采用分片字段进行范围查找时,继续分片可迅速稳定分片进行快速查询,使得避免跨分片查询的题材。
  • 症结在于:热点数据成为性能瓶颈。继续分片可能生存数据热点,例如按时间字段分片,局部分片存储最近时间段内的多寡,可能会被频繁之读写,而有的分片存储的历史数据,则很少被查询。

    ②根据数值取模:普通采用 hash 取模 mod 的席位数方式。

    例如:名将 Customer 表面根据 cusno 字段切分到 4 个库中,余数为 0 的放开第一个库,余数为 1 的放开第二个库,举一反三。

    这样同一个用户之多寡会分散到同一个库中,如果查询条件带有 cusno 字段,则可明确定位到相应库去查询。

    优点:数量分片相对比较均匀,不容易出现热点和并发访问的瓶颈。

    症结如下:

  • 末了分片集群扩容时,要求迁移旧的多寡(采用一致性 hash 书法能较好的避免这个题目)
  • 轻而易举面临跨分片查询的复杂性问题。比如上例中,如果频繁用到的询问条件中不带 cusno 时,名将会导致无法稳定必发娱乐登录,故而需要同时向 4 个库发起查询,再在内存中合并数据,取最小集回到给应用,国库反而成为拖累。
  • 国库分表带来的题材

    国库分表能有效的缓解单机和单库带来的性质瓶颈和压力,打破网络 IO、硬件资源、联网数之瓶颈,同时也带来了部分问题。下将描述这些艺术挑战以及对应的消灭思路。

    作业一致性问题

    ①分布式事务

    顶更新内容同时分布在不同库中,不可避免会带来跨库事务问题。跨分片事务也是分布式事务,没有简单的提案,普通可采取"XA 协和"和"两阶段提交"拍卖。

    分布式事务能最大限度保证了必发娱乐登录操作的原子性。但在提交事务时要求协调多个重点,推后了提交事务的年华点,延长了工作的推行时间。导致事务在走访共享资源时发生冲突或死锁的概率增高。

    随着必发娱乐登录节点的增长,这种势头会越来越严重,故而成为系统在必发娱乐登录层面上水平扩展的束缚。

    ②末了一致性

    对于这些性能要求很高,但对经常性要求不高的体系,往往不苛求系统之暂时一致性,只要在允许的时间段内达到最终一致性即可,可利用事务补偿的措施。

    与工作在推行中发生错误后立即回滚之措施不同,作业补偿是一种下检查补救的主意。

    一部分常见的贯彻方式有:对数据进行对账检查,基于日志进行对照,为期同标准数据来源进行同步等等。作业补偿还要结合工作系统来考虑。

    跨节点关联查询 join 题材

    数之前,系统中许多列表和详情页所需的多寡可以通过 sql join 来形成。

    而切分之后,数量可能分布在不同之兴奋点上,此刻 join 带来的题材就比较麻烦了,考虑到性能,尽量避免使用 join 查询。

    消灭这个题目的组成部分艺术:

    ①全局表:全局表,也可看做是"数量字典表",就是系统中全方位模块都可能依赖的组成部分表,为了避免跨库 join 查询,可以将这类表在每个必发娱乐登录中都保存一份。该署数据一般很少会进展修改,故此也不担心一致性的题材。

    ②字段冗余:一种典型的暴动范式设计,采取空间换时间,为了性能而避免 join 查询。

    例如:订单表保存 userId 天道,也将 userName 冗余保存一份,这样查询订单详情时就不需要再扮查询"买家 user 表面"了。

    但这种方式适用场景也有限,比起适用于依赖字段比较少的状况。而冗余字段的多寡一致性也较难保证,就像上面订单表的例证,买家修改了 userName 此后,只是需要在历史订单中同步更新呢?这也要结合实际工作场景进行考虑。

    ③数量组装:在系统层面,成分两次询问,着重次询问的结果集中找出关联数据 id,下一场根据 id 倡导第二次请求得到关联数据。说到底将获得到的多寡进行字段拼装。

    ④ER 分片:沟通型必发娱乐登录中,如果可以先确定表之间的关联关系,并将这些生活关联关系的外表记录存放在同一个分片上,这就是说就能较好的避免跨分片 join 题材。在 1:1 或 1:n 的情况下,普通按照主表的 ID 东道主键切分。

    如下图所示:

    也就是说,Data Node1 地方的 order 订单表与 orderdetail 订单详情表就足以通过 orderId 拓展一些的关系查询了,Data Node2 上也一样。

    跨节点分页、排序、函数问题

    跨节点多库进行查询时,会出现 limit 成分页、order by 排序等问题。成分页需要按照指定字段进行排序,顶排序字段就是分片字段时,穿过分片规则就比较容易定位到指定的分片;顶排序字段非分片字段时,就变得比较复杂了。

    要求先在不同之分片节点中将数据进行排序并返回,下一场将不同分片返回的结果集进行集中和再次排序,末了返回给用户。

    如图所示:

    上图中只是取第一页的多寡,对性能影响还不是很大。但是如果取得页数很大,气象则变得复杂很多。

    因为各分片节点中的数据可能是随机的,为了排序的准确性,要求将全部节点的明天 N 页数据都排序好做合并,说到底再进行整体的排序,这样的借鉴是很耗费 CPU 和内存资源之,故此页数越大,系统之性质也会越差。

    在采取 Max、Min、Sum、Count 等等的函数进行计算的时节,也要求先在每个分片上实施相应的函数,下一场将各个分片的结果集进行集中和再次计算,末了将结果返回。

    如图所示:

    全局主键避重问题

    在分库分表环境中,出于表中数据同时存在不同必发娱乐登录中,东道主键值平时利用的自增长将无用武之地,某个分区必发娱乐登录自生成的 ID 无法保证全局唯一。

    故此需要单独设计全局主键,以避免跨库主键重复问题。有部分常见的主人翁键生成策略:

    ①UUID

    UUID 专业形式包含 32 个 16 趟制数字,人均 5 段,花样为 8-4-4-4-12 的 36 个字符,例如:550e8400-e29b-41d4-a716-446655440000。

    UUID 是东道主键是最简单的提案,地方生成,性能高,没有网络耗时。但缺点也很显然,出于 UUID 异常长,会占用大量之存储空间。

    此外,表现东道主键建立索引和基于索引进行查询时都会存在性能问题,在 InnoDB 从,UUID 的无序性会引起数据位置频繁转移,导致分页。

    ②重组必发娱乐登录维护主键 ID 表面

    在必发娱乐登录中树立 sequence 表面:

          
    1. CREATE TABLE `sequence` (   
    2.   `id` bigint(20) unsigned NOT NULL auto_increment,   
    3.   `stub` char(1) NOT NULL default '',   
    4.   PRIMARY KEY  (`id`),   
    5.   UNIQUE KEY `stub` (`stub`)   
    6. ) ENGINE=MyISAM; 

    stub 字段设置为唯一索引,同一 stub 值在 sequence 表面中只有一枝记录,可以同时为多张表生成全局 ID。

    sequence 表面的情节,如下所示:

          
    1. +-------------------+------+   
    2. | id                | stub |   
    3. +-------------------+------+   
    4. | 72157623227190423 |    a |   
    5. +-------------------+------+   

    采用 MyISAM 存储引擎而不是 InnoDB,以获取更高的性质。MyISAM 采用的是外部级别的锁,对外部的读写是串行的,故此不用担心在并发时两次读取同一个 ID 值。

    顶需要全局唯一的 64 位 ID 时,推行:

          
    1. REPLACE INTO sequence (stub) VALUES ('a');   
    2. SELECT LAST_INSERT_ID();   

    这两枝语句是 Connection 级别的,select last_insert_id() 必须与 replace into 在同一必发娱乐登录连接下才能得到刚刚插入的新 ID。

    采用 replace into 代表 insert into 好处是避免了表行数过大,不需要另外定期清理。

    此方案较为简单,但缺点也显著:存在单点问题,强依赖 DB,顶 DB 独特时,任何系统都不足用。

    安排主从可以增加可用性,但当主库挂了,基本切换时,数量一致性在突出情况下难以保证。此外性能瓶颈限制在单台 MySQL 的读写性能。

    flickr 团组织使用的一种主键生成策略,与地方的 sequence 表面方案类似,但更好的消灭了单点和总体性瓶颈的题材。

    这一方案之总体构思是:确立 2 个以上的大局 ID 浮动的蒸发器,每个服务器上只部署一个必发娱乐登录,每个库有一张 sequence 表面用于记录当前全局 ID。

    表面中 ID 增强之幅度是库的多寡,开头值依次错开,这样能将 ID 的变通散列到各个必发娱乐登录上。

    如下图所示:

    由两个必发娱乐登录服务器生成 ID,安装不同之 auto_increment 值。着重台 sequence 的开始值为 1,每次步长增长 2,另一台的 sequence 开头值为 2,每次步长增长也是 2。

    结果第一台生成之 ID 都是分数(1, 3, 5, 7 ...),其次台生成之 ID 都是分数(2, 4, 6, 8 ...)。

    这种方案将扭转 ID 的压力均匀分布在两台机械上。同时提供了系统容错,着重台出现了错误,可以自行切换到第二台机械上获取 ID。

    但有以下几个缺点:系统添加机器,水平扩展时较复杂;每次获取 ID 都要读写一次 DB,DB 的压力还是很大,只能靠堆机器来提升性能。

    可以基于 flickr 的提案继续简化,采用批量的措施降低必发娱乐登录的写压力,每次获取一段距离的 ID 号段,用完后再扮必发娱乐登录获取,可以大大减轻必发娱乐登录的压力。

    如下图所示:

    还是使用两台 DB 合同可用性,必发娱乐登录中只存储当前的最大 ID。ID 浮动服务每次批量拉取 6 个 ID,先将 max_id 修改为 5,顶应用访问 ID 浮动服务时,就不需要访问必发娱乐登录,副号段缓存中依次派发 0~5 的 ID。

    顶这些 ID 发完后,再将 max_id 修改为 11,下次就能派发 6~11 的 ID。于是乎,必发娱乐登录的压力降低为原来的 1/6。

    ③Snowflake 分布式自增 ID 书法

    Twitter 的 Snowflake 书法解决了分布式系统生成全局 ID 的急需,浮动 64 位的 Long 型数字。

    一些:

  • 着重位未采取。
  • 然后 41 位是毫秒级时间,41 位的长短可以表示 69 年之年华。
  • 5 位 datacenterId,5 位 workerId。10 位的长短最多支持部署 1024 个重点。
  • 说到底 12 位是毫秒内的计价,12 位的计价顺序号支持每个节点每分钟产生 4096 个 ID 列。
  • 这样的功利是:毫秒数在高位,浮动的 ID 完全上按时间趋势递增;不依赖第三方系统,稳定和频率较高。

    理论上 QPS 约为 409.6w/s(1000*2^12),并且整个分布式系统内不会产生 ID 碰上;可根据自己业务灵活分配 bit 位。

    不足就在于:强依赖机器时钟,如果时钟回拨,则可能导致生成 ID 重温。

    综上结合必发娱乐登录和 Snowflake 的专门 ID 提案,可以参考业界较为成熟的做法:Leaf——美丽团点评分布式 ID 浮动系统,并考虑到了高可用、形容灾、分布式下时钟等问题:

          
    1. https://tech.meituan.com/2017/04/21/mt-leaf.html 

    数量迁移、扩容问题

    顶业务迅猛发展,面临性能和存储的瓶颈时,才会考虑分片设计,此刻就不可避免的要求考虑历史数据迁移的题材。

    普通做法是先读出历史数据,下一场按指定的分片规则再将数据写入到各个分片节点中。

    另外还要求根据目前的多寡量和 QPS,以及工作发展之进度,拓展含量规划,预算出大概需要多少分片(普通建议单个分片上的单表数据量不超过 1000W)。

    如果采取数值范围分片,只要求添加节点就足以拓展扩容了,不需要对分片数据迁移。如果采取的是数值取模分片,则考虑后期的扩容问题就相对比较麻烦。

    什么时候考虑切分

    下讲述一下什么时候需要考虑做多少切分。

    ①能不切分尽量不要数

    并不是全部表都要求展开切分,重点还是看数据的增强速度。数后会在某种程度上提升业务的复杂度,必发娱乐登录除了承载数据的存储和查询外,援助业务更好的贯彻需求也是人家主要工作之一。

    不到万不得已不用轻易使用分库分表这个大招,避免"过度设计"和"过早优化"。

    国库分表之前,无需为分而分,先尽力去做力所能及的作业,例如:升级硬件、升级网络、读写分离、目录优化等等。顶数据量达到单表之瓶颈时候,再考虑分库分表。

    ②数量量过大,正常运维影响工作访问

    此地说的运维指:

  • 对必发娱乐登录备份,如果单表太大,备份时要求大量之录像带 IO 和网络 IO。例如 1T 的多寡,网络传输占 50MB 天道,要求 20000 秒才能传输完毕,任何过程的风险都是比较高的。
  • 对一个很大的外表进行 DDL 修改时,MySQL 会锁住全表,其一日子会很长,这段时间业务不能访问此表,影响很大。
  • 如果采取 pt-online-schema-change,采用过程中会创建触发器和影子表,也要求很长的年华。在此操作过程中,都算为风险时间。名将数据表拆分,存量减少,有助于降低这个风险。

  • 大表会经常访问与创新,就更有可能出现锁等待。名将数据切分,用空间换时间,变相降低访问压力。
  • ③随着业务发展,要求对一些字段垂直拆分

    举个比喻,假如项目一开始筹划的客户表如下:

    id bigint #他家之IDname varchar #他家之名字last_login_time datetime #近些年登录时间personal_info text #私人信息..... #其它信息字段

    在档次上马阶段,这种计划是满足简单的工作需求之,也富有快捷迭代开发。

    而当业务迅猛发展时,客运量从 10w 新增到 10 京,他家非常之外向,每次登录会更新 last_login_name 字段,有效 user 表面被不断 update,压力很大。

    而其余字段:id,name,personal_info 是一成不变的或很少更新的,此刻在工作角度,就要将 last_login_time 拆分出去,兴建一个 user_time 表面。

    personal_info 属性是更新和查询频率较低的,并且 text 字段占据了太多的蓝天。此刻,就要对此垂直拆分出 user_ext 表面了。

    ④数量量快速增长

    随着业务的高效发展,单表中的数据量会持续增长,顶性能接近瓶颈时,就要求考虑水平切分,做分库分表了。此刻一定要挑选适宜的席位数规则,提前预估好数据容量。

    ⑤竞争性和可用性

    鸡蛋不要放在一个篮子里。在工作范围上垂直切分,名将不相关的业务的必发娱乐登录分隔,因为每个业务的多寡量、配图量都不同,决不能因为一个作业把必发娱乐登录搞挂而牵连到其它工作。

    采取水平切分,顶一个必发娱乐登录出现问题时,不会影响到 100% 的客户,每个库只承担业务的组成部分数目,这样整体的可用性就能增进。

    老分析

    他家中心工作场景

    他家中心是一番奇异广泛的工作,重点提供用户注册、登录、查询/修改等效果,他主导表为:

          
    1. User(uid, login_name, passwd, sex, age, nickname) 
    2.  
    3. uid为客户ID,  东道主键 
    4. login_name, passwd, sex, age, nickname,  他家属性 

    其它脱离业务的架构设计都是耍流氓,在开展分库分表前,要求对工作场景需求进行梳理:

    他家侧:主席台访问,配图量较大,要求保证高可用和高一致性。

    重点有两类需求:

  • 他家登录:穿过 login_name/phone/email 查询用户信息,1% 呼吁属于这种类型。
  • 他家信息查询:登录之后,穿过 uid 来查询用户信息,99% 呼吁属这种类型。
  • 营业侧:看台访问,支持运营需求,按照年龄、性别、登陆时间、登记时间等展开分页的询问。是其中系统,配图量较低,对可用性、竞争性的要求不高。

    水平切分方法

    顶数据量越来越大时,要求对必发娱乐登录进行水平切分,上文描述的席位数方法有"根据数值范围"和"根据数值取模"。

    "根据数值范围":以主人翁键 uid 为划分依据,按 uid 的框框将数据水平切分到多个必发娱乐登录上。

    例如:user-db1 存储 uid 规模为 0~1000w 的多寡,user-db2 存储 uid 规模为 1000w~2000w uid 数量。

    优点是:扩容简单,如果容量不够,只要增加新 DB 即可。

    不足是:呼吁量不平衡,普通新注册的客户活跃度会比较高,故此新的 user-db2 会比 user-db1 负载高,导致服务器利用率不平衡。

    "根据数值取模":也是以主人翁键 uid 为划分依据,按 uid 取模的值将数据水平切分到多个必发娱乐登录上。

    例如:user-db1 存储 uid 取模得 1 的多寡,user-db2 存储 uid 取模得 0 的 uid 数量。

    优点是:数量量和请求量分布均匀。

    不足是:扩容麻烦,顶容量不够时,新增长 DB,要求 rehash。要求考虑对数据进行平滑的搬迁。

    非 uid 的询问方法

    水平切分后,对于按 uid 查询的急需能很好的满足,可以直接路由到具体必发娱乐登录。

    而按非 uid 的询问,例如 login_name,就不知晓具体该访问哪个库了,此刻需要遍历所有库,性能会降低很多。

    对于用户侧,可以行使"确立非 uid 属性到 uid 的光照关系"的提案;对于运营侧,可以行使"主席台与柜台分离"的提案。

    ①确立非 uid 属性到 uid 的光照关系

    照耀关系:例如:login_name 决不能直接定位到必发娱乐登录,可以建立 login_name→uid 的光照关系,用索引表或缓存来存储。

    顶访问 login_name 时,先通过映射表查询出 login_name 对应的 uid,再通过 uid 固定到具体的库。

    照耀表只有两趟,可以承载很多数目,顶数据量过大时,也得以对映射表再做水平切分。

    这类 kv 分立式的目录结构,可以很好的采取 cache 来优化查询性能,而且映射关系不会频繁转移,缓存命中率会很高。

    基因法:国库基因,假如通过 uid 国库,人均 8 个库,利用 uid%8 的措施展开路由,此刻是由 uid 的最终 3bit 来决定这趟 User 数量具体落到谁库上,这就是说这 3bit 可以看为分库基因。

    地方的光照关系的主意需要额外存储映射表,按非 uid 字段查询时,还要求多一次必发娱乐登录或 cache 的走访。

    如果想要消除多余的存储和查询,可以通过 f 函数取 login_name 的基因作为 uid 的国库基因。

    浮动 uid 时,参考上文所述的分布式唯一 ID 浮动方案,再增长最后 3 位 bit 值=f(login_name)。

    顶查问 login_name 时,只需计算 f(login_name)%8 的值,就足以定位到具体的库。

    不过这样需要提前做好容量规划,预估未来几年之多寡量需要分多少库,要预留一定 bit 的国库基因。

    ②主席台与柜台分离

    对于用户侧,重点需求是以单行查询为主,要求树立 login_name/phone/email 到 uid 的光照关系,可以解决这些字段的询问问题。

    而对于运营侧,有的是批量分页且条件多样之询问,这类查询计算量大,回到数据量大,对必发娱乐登录的性质消耗较高。

    此刻,如果和用户侧共用同一批服务或必发娱乐登录,可能因为后台的少量请求,占用大量必发娱乐登录资源,而导致用户侧访问性能降低或超时。

    这类事情最好采用"主席台与柜台分离"的提案,营业侧后台业务抽取独立的 service 和 DB,消灭和后台业务系统之耦合。

    出于运营侧对可用性、竞争性的要求不高,可以不访问实时库,而是通过 binlog 异步同步数据到运营库进行走访。

    在数量量很大的情况下,还可以运用 ES 搜索引擎或 Hive 来满足后台复杂的询问方式。

    支持分库分表中间件

    站在巨人的肩膀上能省力很多,脚下分库分表已经有部分较为成熟的正本求源解决方案:

  • sharding-jdbc(当当)
  • https://github.com/shardingjdbc

  • TSharding(蘑菇街)
  • https://github.com/baihui212/tsharding

  • Atlas(奇虎360)
  • https://github.com/Qihoo360/Atlas

  • Cobar(阿里巴巴)
  • https://github.com/alibaba/cobar

  • MyCAT(基于 Cobar)
  • http://www.mycat.io/

  • Oceanus(58 同城)
  • https://github.com/58code/Oceanus

  • Vitess(谷歌)
  • https://github.com/vitessio/vitess

    参考文章:

  • 必发娱乐登录分布式架构扫盲——国库分表(及银行核心系统适用性思考)
  • 国库分表的思维
  • 水平分库分表的严重性步骤以及可能遇到的题材
  • 副原则、提案、政策及难点阐述分库分表
  • Leaf——美丽团点评分布式 ID 浮动系统
  • 架构师之路公众号
  • 【编纂推荐】

    1. 记一次生产必发娱乐登录MyISAM存储引擎转为Innodb经过
    2. 聊一聊必发娱乐登录中的锁
    3. MySQL必发娱乐登录基于表级别备份
    4. 一文总结MySQL必发娱乐登录访问控制实现原理
    5. 记一次生产必发娱乐登录性能优化实例--避免重蹈覆辙执行相同的 SQL
    【义务编辑: 武晓燕 TEL:(010)68476606】

    点赞 0
  • 必发娱乐登录  架构  国库分表
  • 分享:
    大家都在看
    猜你喜欢
  • 订阅专栏+更多

    传感器选型从入门到实战

    传感器选型从入门到实战

    政务云规划设计实战
    共16章 | 51CTOsummer

    499人口订阅学习

    骨干网与数据中心建设案例

    骨干网与数据中心建设案例

    尖端网工必会
    共20章 | 捷哥CCIE

    417人口订阅学习

    中间件安全防护攻略

    中间件安全防护攻略

    4类安全防护
    共4章 | hack_man

    161人口订阅学习

    读 书 +更多

    网管第一课――网络组建与管理

    该书针对初级网管朋友所需掌握的网络组建和网络管理技能,以示例方式编写而成,他首要特征就是针对性和可操作性非常强。 全党共分8章,成分...

    订阅51CTO邮刊

    点击这里查看样刊

    订阅51CTO邮刊

    51CTO劳务号

    51CTO官微