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

 

tsharding

TSharding is the simple sharding component used in mogujie trade platform.

分库分表业界方案

分库分表TSharding

TSharding组件目标
  • 很少的资源投入即可开发完成
  • 支持交易订单表的Sharding需求，分库又分表
  • 支持数据源路由
  • 支持事务
  • 支持结果集合并
  • 支持读写分离
TSharding Resources Abstract

TSharding Resources Classes

TSharding组件接入过程：
  • 引入TSharding JAR包
  • 配置所有分库的JDBC连接信息
  • Mybatis Mapper方法参数增加ShardingOrderPara/ShardingBuyerPara/ShardingSellerPara注解
  • 批量查询增加结果集合并逻辑

 

http://www.ctolib.com/tsharding.html

 

时间： 2024-08-07 01:29:06

TSharding：用于蘑菇街交易平台的分库分表组件的相关文章

【资料整理】分库&分表

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

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

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

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

分库分表下uuid的生成

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

透明的分库分表方案

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

mysql 分库分表的方法

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

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

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

分库分表总结

单库单表 单库单表是最常见的数据库设计,例如,有一张用户(user)表放在数据库db中,所有的用户都可以在db库中的user表中查到.   单库多表 随着用户数量的增加,user表的数据量会越来越大,当数据量达到一定程度的时候对user表的查询会渐渐的变慢,从而影响整个DB的性能.如果使用mysql, 还有一个更严重的问题是,当需要添加一列的时候,mysql会锁表,期间所有的读写操作只能等待. 可以通过某种方式将user进行水平的切分,产生两个表结构完全一样的user_0000,user_000

水平分库分表的关键问题及解决思路

分片技术的由来 关系型数据库本身比较容易成为系统性能瓶颈,单机存储容量.连接数.处理能力等都很有限,数据库本身的"有状态性"导致了它并不像Web和应用服务器那么容易扩展.在互联网行业海量数据和高并发访问的考验下,聪明的技术人员提出了分库分表技术(有些地方也称为Sharding.分片).同时,流行的分布式系统中间件(例如MongoDB.ElasticSearch等)均自身友好支持Sharding,其原理和思想都是大同小异的. 分布式全局唯一ID 在很多中小项目中,我们往往直接使用数据库自